On Mon Nov 2, 2026 at 7:41 PM CET, Rodrigo Vivi wrote: > Hi folks, > > We'd like to replace most of the DRM trees in linux-next with a single > branch: > > https://gitlab.freedesktop.org/drm/tip.git#drm-for-linux-next > > It replaces these entries: > > drm/drm-next, drm/drm-fixes > drm-misc/for-linux-next, drm-misc/for-linux-next-fixes > drm-intel/for-linux-next, drm-intel/for-linux-next-fixes > drm-xe/drm-xe-next > drm-rust/for-linux-next, drm-rust/for-linux-next-fixes > amdgpu (agd5f/linux.git#drm-next) > > drm-exynos, drm-msm, drm-msm-fixes, drm-msm-lumag, drm-nova and etnaviv > are not part of it and stay as they are. > > The main reason is to reduce the conflict pain that Mark constantly faces. > All of them should be handled already when we are rebuilding drm-tip. > > During this work, I realized that drm-xe is a big culprit for leaking > future work without a blackout date from -rc6 to <next>-rc1. > So, another quick solution would be to get a drm-xe for-linux-next like > the other domains are doing. However, I still believe that this unified > one will make Mark's life much easier anyway. > > 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?
