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 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.

> 3. All maintainers to agree to move their -next-fixes on the same day that
> they are sending the last PR. Or have a new dim sub-command dim final-pr

That's what drm-misc, drm-rust and drm-intel promise, yes.

Something like dim request-pull --final seems like a reasonable helper to me.

> 4. Instrument dim to have this secondary reconstructed tree instead of the
> implemented chop.

I think for this part isn't different; tip/for-linux-next just merges one or the
other.

> 5. Prepare every committer to deal with this extra build time and extra
> conflict resolution.

Which extra build time and conflict resolution? You have two tip trees in either
case, no? One that contains $tree/$tree-next and one that doesn't.

> I honestly prefer the simple chop solution. But it would be okay by me
> if you take the lead and implement the dim changes for this flow.

I don't mind doing this. :)

>> I.e. the ultimate source of what is linux-next material remains to be $tree.
>> 
>> In general, I think that this is more accurate and probably less error prone
>
> I would argue the other way around.
>
> The reason that we are seeing so much escapes from next-next into linux-next
> might be exactly by the fact that the blackout right now depends on 2 separate
> actions to help simultaneously (last PR + rebase of -next-fixes). What most
> of us are not doing.

Interesting, why is that? It seems to work perfectly fine in drm-misc, drm-rust
and drm-intel.

The only thing maintainers need to do is push $tree-next to $tree-next-fixes at
the cutoff. The rest is automatically handled by dim already.

>> For instance, let's say a tree closes (i.e. tags the last -next tag of the
>> cycle) a few days before -rc6, it could happen that subsequent commits to
>> $tree-next still appear in linux-next because tip still picks them up until
>> after -rc6. So, after -rc6 those commits (that were in linux-next for a few
>> days) would disappear from linux-next again.
>> 
>> Not that big of a deal, but technically they didn't even belong in linux-next
>> for only a few days.
>
> But well, this is a good catch and a bug on the current proposal indeed.
> Should we move that to -rc5 to -rc1? We just need to ensure that everyone
> have at least 1 PR after -rc5 and we are all aligned.
>
> The only caveat is that patches landing in drivers-next during -rc5/-rc6 will
> take a few days more to propagate, but it shouldn't be the end of the world.
> It is still a couple weeks before the merge-window.
>
>> 
>> If we kept $tree/for-linux-next, tip would never pick those commits up, because
>> a tree that closed a few days before -rc6 would already have switched
>> $tree/for-linux-next to $tree/$tree-next-fixes.
>
> Well, if you don't move your -next-fixes at the same time of your last PR
> you are leaking that as well. And this is happening.

Where is this happening?

> At least now we know why it is happening (besides xe and amd sending
> straight from -next instead of having the -for-linux-next branches).

I think if xe and amd would have those branches there'd not be a problem to
begin with.

But independent of that, I think it is nice to give the "fully merge conflict
resolved thing" to Mark. :)