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

Hi Dave,

On Tue, 11 Aug 2026 at 05:30, Dave Airlie <[email protected]> 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.

Doesn't this cause internal (to AMD and Intel) issues, too?
How come we cannot educate contributors at these two large companies,
while we expect other contributors to be aware?
I would hope the people who do the actual commits do know?

> 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.

Just merging fixes into next[*], and resolving the conflicts, before
publishing the latter would help a lot.  That would mean the conflicts
would no longer impact every user of your next branch.
[*] This doesn't need to be the real next you will send to Linus
    later. Many maintainers use a conglomerate "for-next" branch that
    is never sent upstream as-is, but its sub-branches are.

FTR, when I create the bi-weekly renesas-drivers releases, drm merge
conflicts are usually the largest conflicts.  Looking at the resolutions
in drm-tip (and linux-next, but broonie is in a less convenient time
zone than sfr was ;-) does help.
Once in a while I think "#@ it, I'll ignore the conflicts and just leave
the conflict markers, my consumers don't use these drivers anyway",
but then the kernel test robot would start complaining to me...

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds