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

["Danilo Krummrich" <dakr@kernel.org>]

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.

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

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.

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.