On Wed, Nov 04, 2026 at 06:49:29AM +0100, Thorsten Leemhuis wrote: > On 11/2/26 19:41, Rodrigo Vivi wrote:
> > 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? I'm hoping is that the theory is that they will work like a lot of other trees and merge all the fixes branches first, push that out as something I can pick up, then merge the other branches on top of that. That works well elsewhere, I'd expect it to also work well for DRM. One of the goals from my point of view is that the mess caused by all the cherry picking is resolved by DRM and isn't visible to -next.
signature.asc
Description: PGP signature
