On 11/2/26 19:41, Rodrigo Vivi wrote: > > 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.> [...]
Please correct me if I'm wrong: this seems to mix up patches for the current cycle (e.g., -fixes branches) with those for the next one -- so I assume the former won't end up in next/pending-fixes anymore? Do we care? Or is this a situation along the lines of "yeah, that's a downside of this, but given the upsides, we do this nevertheless"? For my work it was kind of nice to have the two tracks separated, as it allowed me to easily check "is this fix for a recent regression in pending-fixes, as it should, because it should be fixed this cycle". Side note: two years ago there was also the idea to increase testing of pending-fixes or branches feeding into it separately, but it afaics got no real traction: linus-next: improving functional testing for to-be-merged pull requests https://lore.kernel.org/all/ZyI-Y00J3DBUkon3@sashalap/ Ciao, Thorsten
