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

Mark Brown <[email protected]> Tue, 11 Aug 2026 15:26:07 +0100
Newsgroups	dev.linux.lists.ksummit
Message-ID	<[email protected]>
On Tue, Aug 11, 2026 at 01:29:37PM +1000, Dave Airlie wrote:

> > It's not even all of DRM, it's specifically the AMD and Intel driver
> > stacks which as far as I can tell just routinely cherry pick all their
> > fixes between their development and fixes branches without even
> > considering the possibility of either merging up the fixes branch or
> > just waiting and letting the fixes propagate back.  None of the rest of
> > the DRM trees ever seems to cause these issues.

> AMD and Intel are just the two largest teams with the longest
> pipelines of internal engineers and teams. There are between 50 and
> 100 people in those groups, across multiple disjoint teams feeding
> into a single driver. It just doesn't scale for all 50-100 people to
> understand the cycle of the upstream Linus tree at all times for all
> patches.

> Which means for CI reasons and pipeline reasons, things go into -next
> is the default, our -next trees are always open, and get disconnected
> from upstream next from rc6->rc1 so not to mess things up.

> Then there are people who understand the upstream cycle dealing with
> fixes, because they know what goes into rc2 isn't what goes into rc4
> isn't what goes into rc7, and that knowledge is hard to disseminate.
> Having fixes be a free for all has usually meant me refusing trees in
> rc6/rc7 because there are inappropriate patches for that time of the
> cycle.

Having everything be a complete free for all does sound like a bad idea
but there's a fairly big gap of processes between there and what's done
currently which is probably worth exploring.  Having a more limited set
of people who can apply things to the fixes branches, having a flow for
getting fixes integrated into the branches that CI looks at and so on.

It strains credibility that it's not possible for people to work out
that a commit clearly labeled as a bug or erratum fix might want to be
routed as a fix, and that with such large teams it's not possible to
arrange for anyone who might be able to confirm this to take a look and
apply to the right place in a reasonably prompt fashion.  Some things it
might be less obvious and some cherry picking might be a sensible way of
dealing with those after the fact but there's a lot of cases where
that's clearly not the case.

Possibly just always merge the fixes branch into the development branch
immediately (or after going through a pile of fixes), it'd result in a
large number of merge commits which would annoy Linus but perhaps he's
not reading the DRM pull requests in enormous detail anyway?

Even just labelling the cherry picks as cherry picks of the original
would be an improvement, right now the cherry picks are completely
silent which really doesn't help anything.  IIRC the stable people have
mentioned that that's one of the things that causes trouble for them.
signature.asc (application/pgp-signature, 488 B)