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

On Wed, 12 Aug 2026 at 16:01, Krzysztof Kozlowski <[email protected]> wrote:
>
> On 11/08/2026 05:29, Dave Airlie wrote:
> >>>> If your assumption is correct, this is internal cat herding ... MM has
> >>>> much the same problem except that it has to deal with somewhat
> >>>> opinionated architecture maintainers (around 22 of them) to agree on
> >>>> the internal abstractions for MM primitives.  Perhaps rather than
> >>>> getting into my problem is bigger than yours type arguments, we could
> >>>> observe that MM might run a bit more smoothly because it gets an
> >>>> additional 3 day conference (LSF/MM) plus a MC at Plumbers to sort
> >>>> itself out?
> >>
> >>> I guess the question is, what exactly is being big for DRM that it needs to do
> >>> cherry-picking for their linux-next branch whereas Networking and ARM do
> >>> not? Is DRM bigger than either of those? From what I understand VFS doesn't
> >>> have to do that either. And VFS has a large range of file systems to deal
> >>> with. But it also has one of the best abstraction layers of the kernel.
> >>
> >> 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.
>
> Qualcomm has also between 50-100 people in different teams upstreaming
> to similar subsystems (like SoC) and they try to understand the cycle.
>
> It's just AMD and Intel do not care to understand, because it is easier
> for them and no one nags them...

Get back to me when their devices are in a place to be running
upstream kernels as much as AMD or Intel at the same scale.

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,

Qualcomm is not in the same position, a lot of their pipeline delivery
is via Android or ChromeOS and they have nowhere near the amount of
regression finding problems that upstream GPUs have.

small potatoes...

Dave.