On Thu, Sep 11, 2025 at 03:27:11PM +0300, Laurent Pinchart wrote:
> On Thu, Sep 11, 2025 at 01:04:19PM +0200, Krzysztof Kozlowski wrote:

> > There are two cases here for patches committed by sub-maintainers, but
> > never fed to next:
> > 1. The upstream maintainer took them via pull request.
> > 2. The upstream maintainer rebased everything - changing commit date (to
> > add their own Signed-off-by? otherwise why would you rebase a pull
> > request from someone you trust?).

> I've heard a maintainer saying that Linus doesn't like subsystem trees
> to have lots of merges. Any help debunking that would be appreciated.

AIUI it's a quality of merges issue rather than a number of merges
issue, if the merge commits all have commit messages that convey useful
information about something that makes sense then you should be fine.
If the merge commits are all just default messages not so much.  Things
like taking a pull request with a descriptive commit like the cover
letter for the merge hopefully do have some purpose and a useful commit
message.  

The quantity thing comes up because a common way you end up with a lot
of merges is automation which tends to also imply lacking changelogs and
motivation.