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

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Tue, Nov 03, 2026 at 10:04:28PM +0100, Danilo Krummrich 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.

Agreed.

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

Well, 
https://drm.pages.freedesktop.org/maintainer-tools/maintainer/maintainer-drm-intel.html#drm-intel-next-fixes

We promise 'after' not at the same time, nor right-after.
We never specified how much after. I was always doing this on the next week,
or even couple weeks later.

So, I can tell that when I'm handling the drm-intel-next-fixes I was not
doing it right after. So, we certainly had leaks from drm-intel-next, at
least during my rounds for sure.

Right, we just found the other source of the issue and that points back to me
again, I know :)

Oh, we have another complication in the -intel part.
we have a separate drm-intel-gt-next but the -next-fixes and -fixes are just
one. And the maintainers taking care of the -next -gt-next and -next-fixes are
3 different people each round. :(

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

I like the --final option. Except that this doesn't work for -intel and we would
need a different blackout mechanism there.

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

But it is a new pass... The current proposal here is still a single pass and
it chops/derive the drm-for-linux-next in the middle of the pass.

For a separate one you need the second pass that is the merge of the drm-next
with all the individual for-linux-next* ones.

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

In the second pass you can get duplicated or different conflicts.

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

Mark complains for a while of the number of escapes of next-next into linux-next.
Perhaps the current flow is only working well for -misc and -rust.

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

yes, that's the goal. Reduce conflict's for him and stop the 'leaks'.

Thanks,
Rodrigo.