Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

Mark Brown <[email protected]> Wed, 12 Aug 2026 13:48:26 +0100
Newsgroups	dev.linux.lists.ksummit
Message-ID	<[email protected]>
On Wed, Aug 12, 2026 at 06:05:32PM +1000, Dave Airlie wrote:
> On Wed, 12 Aug 2026 at 17:43, Greg KH <[email protected]> wrote:

> > Why would anyone need to "stop working" for 2-3 weeks?  That's not what
> > other trees do, the patches just go into a different queue/tree until
> > the merge window is over and then they flow into the normal -next branch
> > (or whatever you want to call it.)

> Where is this magic tree, how do you keep CI on that tree, is there a
> maintainer who isn't saying, I won't review stuff for 3 weeks because
> the merge window is open, etc. There are plenty of examples of

I certainly don't stop looking at stuff, nor do I tell people to stop
sending me stuff.  Currently I don't end up applying non-fix things but
it tends to be in the space where I'm leaving stuff on the list anyway
to give other people a chance to review, it never really seemed to be
causing anyone too many issues.  Since I switched to b4 to drive my
review I might actually start just applying stuff again, I mainly
stopped because it used to flow a bit more neatly with my own scripts.
When I'm not applying stuff I'm generally queueing it, it all gets
dropped into the tree once -rc1 appears and then gets into the tree as
my CI recovers from the onslaught.  When I did actually apply things I
did exactly what drm is doing and just appply them to a branch that
didn't get pushed into -next, my scripting still has all the bits for
that so I'd just have to open the new branch to restart.

Keeping CI available seems like one of the more trivial problems, just
point the CI at a for-ci branch that merges whatever should be CIed or
something.

> maintainers not merging stuff into trees for weeks on end around
> release->rc1 etc, shit developers get used to but it cuts their
> velocity for upstream work. We've had plenty of examples of

That's definitely a thing for some trees, and there's some trees that
close down betwen say -rc6 and -rc3 which is a very big window and I do
feel not ideally helpful.  That length of shutdown is unusual though,
and my inbox tells me that there's plenty of development and review
activity going on during the merge window.

> development been taken in house and then upstreamed by separate teams
> later, which is the result of what we previously did. I hate to sound
> like an asshole, but we tried most of the things people with the 5-10
> developers 5 years ago and 5 years ago before that, and they never
> scaled out. There was always shit falling on the floor because of
> various bottlenecks introduced by the upstream process vs what
> internal teams were trying to deliver. Often you have internal teams
> trying to deliver a coherent driver across non-upstream and when that
> becomes easier or the priority upstream suffers from it.

I think you're overindexing on how much of a snowflake DRM is here TBH,
of course DRM is at the upper end of all the various scaling issues but
there seems to be this big disconnect where you're assuming no other
maintainers can relate to anything you're seeing at all.

> There is a lot of subtley the smaller trees get away with if they do
> one next and one or two fixes pulls to Linus. We send 1-2 next and a
> fixes round for every rc for Intel and AMD, I'm lucky if I get one
> batch of fixes out of qualcomm in the middle of the rc cycle. Despite
> Kryzstof's efforts to convince otherwise, Qualcomm are small potatoes
> from at least a GPU pov.

I dunno, I find myself sending fixes most -rcs.  It really should be all
of them but sometimes I don't get round to it in time or there's
something I want to let cook a bit longer.  I don't think that's super
weird?  

> We have tried to fix Fixes: and tried to fix cherry-picking, and to be
> honest I've lost track of the objections we've had from the same
> people no matter which way we go.

It might help if someone could write down what's been tried somewhere
people can refer to, that way people could link to that and give a
clearer explanation of things instead of the briefer replies that tend
to happen.  It'd also be a useful reference for people considering
updating their workflows, perhaps there should be some central idea
sharing place for this sort of thing.

It'd also help if there were some work on mitigations for the externally
visible impacts of the unusual workflows drm is adopting.  For example,
I've mentioned the idea of marking the cherry picks as being cherry
picks.  That would help me a bit and I think also the stable people (if
a cherry pick gets tagged as being fixed they could then find the
original commit).  It's difficult to think why it would not be possible
to do this, and it should be low enough effort that even if it only
helps a little it'd be worth it.

Personally I'd also really appreciate it if the branches drm is pushing
into -next had the merges with the fixes branches already done, I
believe those merges do end up happening anyway and it would save me a
huge amount of time.  That's a bit more specialist but others have
mentioned that they also end up merging drm's development branches for
non-next stuff so it wouldn't *just* be me.
signature.asc (application/pgp-signature, 488 B)