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

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