Re: [RFC] linux-next: replace the DRM trees with a single drm-for-linux-next

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Tue, Nov 03, 2026 at 08:32:48PM +0100, Danilo Krummrich wrote:
> On Tue Nov 3, 2026 at 3:05 AM CET, Dave Airlie wrote:
> > It might be time to pull back to -rc6 though, we could just keep the
> > rust tree in -next separate,
> 
> Agreed, I think that makes sense (I am thinking more about occasional cases
> where we may need a few days more due to cross-tree dependencies). Otherwise,
> that's an option too, but I'd like to avoid a special case; if we take the
> proposed approach, I'd rather try and see how it goes.
> 
> > It shouldn't cause any extra conflicts, but I'd rather not keep all
> > the -next trees in -next once
> > we merge this, otherwise we may end up with trees getting ahead of the
> > next cycle again.
> 
> I'm not entirely sure what you mean by "keep all the -next trees in -next", but
> just to clarify:
> 
> I'm proposing that linux-next only merge the unified tip/for-linux-next branch.
> The per-tree for-linux-next branches would remain as inputs to that branch,
> preserving their existing selection logic.
> 
> IOW, linux-next merges tip/for-linux-next, and tip/for-linux-next merges
> $tree/for-linux-next, rather than $tree/$tree-next.

For this to work we need:
1. xe to create for-linux-next for-linux-next-fixes
2. amd to create for-linux-next for-linux-next-fixes
3. All maintainers to agree to move their -next-fixes on the same day that
they are sending the last PR. Or have a new dim sub-command dim final-pr
4. Instrument dim to have this secondary reconstructed tree instead of the
implemented chop.
5. Prepare every committer to deal with this extra build time and extra
conflict resolution.

I honestly prefer the simple chop solution. But it would be okay by me
if you take the lead and implement the dim changes for this flow.

> 
> I.e. the ultimate source of what is linux-next material remains to be $tree.
> 
> In general, I think that this is more accurate and probably less error prone

I would argue the other way around.

The reason that we are seeing so much escapes from next-next into linux-next
might be exactly by the fact that the blackout right now depends on 2 separate
actions to help simultaneously (last PR + rebase of -next-fixes). What most
of us are not doing.

The current proposal of dim taking care for us with a single rule is what will
make this less error prone and ensure we are all following the same steps.

> (unless all trees really commit to tagging and sending their final -next PR at
> the global cutoff).
> 
> For instance, let's say a tree closes (i.e. tags the last -next tag of the
> cycle) a few days before -rc6, it could happen that subsequent commits to
> $tree-next still appear in linux-next because tip still picks them up until
> after -rc6. So, after -rc6 those commits (that were in linux-next for a few
> days) would disappear from linux-next again.
> 
> Not that big of a deal, but technically they didn't even belong in linux-next
> for only a few days.

But well, this is a good catch and a bug on the current proposal indeed.
Should we move that to -rc5 to -rc1? We just need to ensure that everyone
have at least 1 PR after -rc5 and we are all aligned.

The only caveat is that patches landing in drivers-next during -rc5/-rc6 will
take a few days more to propagate, but it shouldn't be the end of the world.
It is still a couple weeks before the merge-window.

> 
> If we kept $tree/for-linux-next, tip would never pick those commits up, because
> a tree that closed a few days before -rc6 would already have switched
> $tree/for-linux-next to $tree/$tree-next-fixes.

Well, if you don't move your -next-fixes at the same time of your last PR
you are leaking that as well. And this is happening.
At least now we know why it is happening (besides xe and amd sending
straight from -next instead of having the -for-linux-next branches).

> 
> So, in the end, it comes down to whether each tree's closure controls what
> enters linux-next, or whether maintainers need to coordinate their branch
> updates around a single cutoff defined by tip. While the latter sounds like the
> ideal case, I'm not entirely sure if it isn't too strict in practice. I'm
> thinking more generally here, from a practical or organisational point of view.
> 
> (For instance, in practice Intel has sometimes sent its final -next PR a couple
> of days before -rc6 and continued applying changes afterwards; I think their
> cutoff is generally around -rc5/-rc6.)
> 
> > I'm not sure need to have that complexity for everyone, but if we need
> > to keep the rust tree as an extra then I'm fine with that for now,
> > until it stabilises.
> 
> Appreciate it, but I'd prefer not to special case it; I can see how my drm-rust
> example focused the discussion on that case, whereas my concern is more general.