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

["Danilo Krummrich" <dakr@kernel.org>]

On Tue Nov 3, 2026 at 11:48 PM CET, Rodrigo Vivi wrote:
> On Tue, Nov 03, 2026 at 04:19:11PM -0500, Alex Deucher wrote:
>> On Tue, Nov 3, 2026 at 4:11 PM Danilo Krummrich <dakr@kernel.org> wrote:
>> >
>> > On Tue Nov 3, 2026 at 9:33 PM CET, Rodrigo Vivi wrote:
>> > > On Tue, Nov 03, 2026 at 08:32:48PM +0100, Danilo Krummrich wrote:
>> > >> IOW, linux-next merges tip/for-linux-next, and tip/for-linux-next merges
>> > >> $tree/for-linux-next, rather than $tree/$tree-next.
>> > >
>> > > For this to work we need:
>> > > 1. xe to create for-linux-next for-linux-next-fixes
>> > > 2. amd to create for-linux-next for-linux-next-fixes
>> >
>> > Huh, I thought all the trees are doing this already. Well, that explains
>> > where the the problem comes from. :)
>> >
>> > In any case, drm-misc, drm-rust and drm-intel already have for-linux-next and
>> > for-linux-next-fixes, and the implementation is generic. So, adding it to xe and
>> > amd is trivial.
>> 
>> I've started doing this for amdgpu this cycle as well, but I still
>> pushed an amdgpu-next branch as well since that is the source of all
>> of the cherry-picks for -fixes and -next-fixes.
>
> But it only works if you stop this branch of updating after you sent your last
> -PR and from that point and on you merge or cherry-pick-from your -next-fixes.
> Otherwise you are sending next.next material to -linux-next.
> And this is the current issue Mark is raising to us for a while.
>
> We have 2 proposals on the table:
> 1. (this RFC): a global unified drm-for-linux-next that is a chop-point while
>    drm-tip is getting constructed.
>    If we go with this option you don't need to do anything, but stop maintaining
>    your for-linux-next.
> 2. (Danilo's proposal): Each driver/domain keep their for-intel-next and
>    for-intel-next-fixes for granular control of the blackout weeks
>    and dim merge them together into a drm-for-linux-next
>    If we go with this you need to at least ensure that your for-linux-next
>    doesn't contain next.next material during our blackout periods.

dim already does that, fully automatically, it checks:

	git merge-base --is-ancestor $remote/$linux_next_fixes $remote/$linux_fixes

which means:

- If -next-fixes is an ancestor of (or equal to) -fixes: feed for-linux-next
  from -next. This means -fixes has caught up with all of -next-fixes.

- Otherwise: feed it from -next-fixes, which contains changes that haven’t
  reached -fixes.

The only think maintainers need to do is push $tree-next-fixes to catch up with
$tree-next, which they need to do anyways.

IMO, this is more robust than relying on all maintainers freezing $tree-next at
exactly one global cutoff.