Re: [RFC] linux-next: replace the DRM trees with a single drm-for-linux-next

[Sasha Levin <sashal@kernel.org>]

On Wed, Nov 04, 2026 at 06:49:29AM +0100, Thorsten Leemhuis wrote:
>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/

This is actually still happening today, just evolved a bit!

I have a tree similar to linux-next, but it's fully automated, using LLMs for
conflict resolutions, and generated a few times a day:

https://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-next.git/

Instead of just a single tree, it builds the tree with categories, grouping
them into "%s-next" trees for easier testing by subsystem or theme, and later
merges them all into the one big "all-next" branch.

The equivalent of the auto-pending-fixes branch you mentioned would be the
"fixes-next" branch, and for the drm folks it would be the "drm-next" branch.

This whole thing is still being very much used today, finding real problems :)

-- 
Thanks,
Sasha