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.
