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.
