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

On Tue, Aug 11, 2026 at 09:12:24AM +0200, Geert Uytterhoeven wrote:
> 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?

We currently have 52 devs with commit rights in drm-intel and 47 devs
with commit rights on drm-xe (I'm sorry, but I didn't check the union).

But honestly, I don't believe this is the key argument anyway. The key
argument for the drm-intel flow is the CI, pipeline (like Dave wrote
below) and also for historical reasons. When we didn't have this clear
separation with this quarantine weeks (-rc6->-rc1) many last minute
regressions were introduced causing hic-ups on the -rc1 flow for Linus.

Probably worse in our case because our regression makes the screen to
not appear... I don't know.

But well, let's say we keep the quarantine and go with the -fixes and
-next branches without the direct cherry-pick, but the commiters deciding
for witch branch they apply the patches. (Similar to drm-misc flow).
I still see some potential risk scenarios and not a clear benefit:

1. Increase the risk of hic-ups in other fronts. For instance: patches
that should had been merged to -fixes only going to next and forgotten
to be ported to the previous version. And patches that should be new
features due to the risk of regression, added to the previous version.

But here one could argue that in a distributed commit rights flow, this
is exactly why maintainers role is more critical, tto ensure we are not
missing anything and that the patches are moved to the right place.
Fair enough, but this makes our hashes more likely to change. We try
to keep the non-rebasing tree to avoid disruptions in OSVs and many
other teams that are consuming our trees.

2. The conflicts would happen anyway. I still see a lot of conflicts
in the drm-misc flow.

3. Harder to manage the conflicts. Our cherry-pick flow brings some very
obvious conflict resolution to the table. If you are in a newer kernel
you likely only need to go with it is already in our -next branches,
if you are in the current -rc based you likely need to go with what
it ported to -fixes. It really is not something complicated to solve.
But if you go with a flow that the patches don't have the same baseline
like we have the -next and our -tip, then you get harder conflicts to
solve and likely to make more mistakes.

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

Well, I was going to tell about the drm-tip, but that you already know.
And yes, we cannot have that for-next because it contains topic branches
we really don't want to send up.

Dave, Sima, Jani, perhaps we could instrument dim to create a drm-for-next
that is the merge of all of our relevant branches excluding the topic
branches?

Thanks,
Rodrigo.