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

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

On Mon Nov 2, 2026 at 8:20 PM CET, Rodrigo Vivi wrote:
> not exactly... The per-tree check goes away and there's one global rule:
> the driver -next branches are left out from Linus' -rc6 until -rc1.
> But this is the cutoff the drm-rust docs already describe and used by everyone
> anyway.

As a general rule that's correct, but in practice we have been leaving -next
open for a bit longer (with the last PR at -rc7, depending on what's contained),
as it sometimes helps with cross-tree coordination for interactions with other
trees while we're still ramping up Rust infrastructure throughout the kernel.

The Nova vGPU parts are getting closer to something that can be used in
production, but it still remains that it is useful to retain some flexibility as
we will keep having some more cross tree dependencies for a while.

> So, the maintainers are still in control on when their -next is closed. But that
> is their last PR. around -rc5/-rc6. And if they need extra PRs after that, it
> is also fine, because drm/drm-next is still feeding this unified for-next.

For a late PR that leaves a gap for stuff landing in -next and only ever hitting
linux-next *after* it has been merged in drm/drm-next. Exposure to linux-next
should however be a prerequisite for making it into drm/drm-next.

So, I think maintainers would have to commit to strictly close with -rc6 to
avoid such a situation.

> IOW, when you fast-forward drm-rust-next-fixes at your cutoff, that content stays
> in linux-next whenever you do it. The only difference is that drm-rust-next
> itself stops at -rc6, not when you fast-forward.

Sure, but that'd mean -next PR a few days after -rc6 would need to originate
from -next-fixes in order to get linux-next exposure. Thus, with this approach
it just boils down to "no flexibility on this".

Can't we just keep the per-tree for-linux-next branches and just merge them into
tip/for-linux-next?

for-linux-next-fixes could of course be removed as it always follows -fixes
anyways.