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

On Wed, 12 Aug 2026 at 17:43, Greg KH <[email protected]> wrote:
>
> On Wed, Aug 12, 2026 at 04:20:04PM +1000, Dave Airlie wrote:
> > We've tried to keep the upstream schedule for ages, as Rodrigo points
> > out it falls down, stuff goes missing in the shutdown periods, telling
> > teams to stop working for 2-3 weeks isn't an option in most companies.
> > Intel and AMD are trying to upstream GPUs that aren't even on the
> > market yet, velocity mattters a lot more because thier customers are
> > usually on the end of the pipeline via Linus' tree,
>
> 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
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
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.

> The only one that needs to worry about the merge window is the
> maintainers.  Developers just need to be aware of "is this a new feature
> or a bugfix", and all other subsystems seem to be able to enforce that
> tiny rule, which guides which branch to apply a commit to.

Maintainers care about the merge window, but also disappear or
shutdown progress in it, if you tell me this never happens, I've got a
number of bridges I'm selling.

> And again, I hate how the DRM tree works, and I think overall you
> greatly suffer for this model as the "Fixes:" tags all are wrong which
> cause regression and CVE tracking to be totally broken for all
> backports.  So I guess the teams for those 2 companies don't really care
> about stable trees?  :)

Hey you said very explicitly and in many forums in the past that
nobody needs to care about stable trees, not my fault if people
listen!

They are not aware if they are fixing a bug in Linux or Windows
sometimes, they might not know what Linux release they are fixing a
bug in, or what the state of backported patches to that tree are. They
also don't have access to CI for all of that. They also don't know
that rc6 fixes are different than rc2 fixes, and sending Linus an rc2
fix in rc7 is an internet fame earning offence.

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.

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's possible to have a coherent view of things and Fixes can be made
to work, how do I know, because we deal with this inside of my
employer quite regularly.

Dave.