Re: [MAINTAINERS SUMMIT] Hidden commits from next (aka why maintainers hoard them in backpack)

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 11 Sep 2025 22:29:14 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:

> > I now have several topic branches, and I try hard to avoid merges as they
> > tend to make my pull requests more complex. But every so often, I have a
> > patch that comes in that is required for work in two of my existing topic
> > branches. This is a case where one change is required for two topic
> > branches to continue more work.  
> 
> Do you then send an individual pull request for each topic branch to
> Linus ?

Yes I do. Linus suggested it. I use to keep everything in a single branch,
but when Linus had an issue with one aspect of the pull request, it caused
me to rebase the entire thing. That's when Linus said I needed to break up
my changes into different topics so that if he had an issue with one, it
wouldn't stop the rest from getting in unmodified.

> 
> What if one of those topic branches had to aggregate patches from, let's
> say, 10 different series from 10 contributors who each sent you a pull
> request ? Would you merge them or cherry-pick them ?

Currently, the only pull requests I take are separate topic branches where
the merge usually ends up being a simple fast forward. Most of my updates
come from patches that I just pull into my topic branches directly from
patchwork.

I likely don't have the complexity of DRM.

But looking more at the tip tree, which is much more complex than my own,
which also has several topic branches. They merge in branches from others
via pull requests, just like Linus would from us. They don't cherry-pick
nor rebase, unless its patches from the mailing list. I believe Linus is OK
with that workflow.

-- Steve