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

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

On Wed, Nov 04, 2026 at 12:01:36AM +0100, Danilo Krummrich wrote:
> 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:

right, but like xe, they don't have this for-linux-next setup with dim taking
care. So they do need to take some action.

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

This is the part that I disagree most. In my proposal, maintainers need to do
absolutely nothing. The freezing is already guaranteed by our rules.

In the current individual trees with maintainer control we are seeing that
only -misc and -rust are fitting this dim freeze and procedures
and it is fragile at best.

Again, at -intel branches we have no way of synchronizing that. we will
need to have a different solution for -intel, we need to modify current
flow for -xe and -amdgpu.

But right, feel free to propose your dim changes, then I will take care of
-intel and -xe on a follow up.

Thanks,
Rodrigo.