On Mon, Nov 02, 2026 at 07:51:13PM +0100, Danilo Krummrich wrote: > > > > The unified branch is rebuilt by dim together with drm-tip. It has all the > > DRM > > -fixes, drm-next, -next-fixes and driver -next branches merged, with > > the conflicts between them already resolved on our side. From -rc6 > > until -rc1 (per Linus' tree) the driver -next branches are left out, so > > nothing for the following merge window lands early. > > Seems reasonable; I assume the logic for individual trees would remain? I.e. > -next goes into tip/for-linux-next until -next-fixes is fast forwarded? IOW, > trees keep control over when exactly -next closes for the upcoming merge > window?
Well, the flows of -next, -next-fixes, -fixes keeps the same. No change in that or in our PR flows. As for the mechanics of the closes, I'd say that for drm-xe and drm-intel, there's absolutely no change. We consider our closure when send the last PR on that cycle. But perhaps this was anyway a gap on our side?! to ensure that our -next-fixes are in sync with our last PR?! (plus the gap of xe which was feeding with drm-xe-next directly). For the rust and others, the honest answer is: "not exactly..." 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. 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. So, whatever Dave and Sima accept during the blackout will be covered. Regardless the state of your -next-fixes. And, in any case, -next-fixes is always included, even during the freeze. 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. Thanks, Rodrigo.
