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

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

[Rodrigo Vivi]

Hi folks,

We'd like to replace most of the DRM trees in linux-next with a single
branch:

  https://gitlab.freedesktop.org/drm/tip.git#drm-for-linux-next

It replaces these entries:

  drm/drm-next, drm/drm-fixes
  drm-misc/for-linux-next, drm-misc/for-linux-next-fixes
  drm-intel/for-linux-next, drm-intel/for-linux-next-fixes
  drm-xe/drm-xe-next
  drm-rust/for-linux-next, drm-rust/for-linux-next-fixes
  amdgpu (agd5f/linux.git#drm-next)

drm-exynos, drm-msm, drm-msm-fixes, drm-msm-lumag, drm-nova and etnaviv
are not part of it and stay as they are.

The main reason is to reduce the conflict pain that Mark constantly faces.
All of them should be handled already when we are rebuilding drm-tip.

During this work, I realized that drm-xe is a big culprit for leaking
future work without a blackout date from -rc6 to <next>-rc1.
So, another quick solution would be to get a drm-xe for-linux-next like
the other domains are doing. However, I still believe that this unified
one will make Mark's life much easier anyway.

The unified branch is rebuilt by dim together with drm-tip. It has all the DRM
-fixes, drm-next, -next-fixes and driver -next branches merged, with
the conflicts between them already resolved on our side. From -rc6
until -rc1 (per Linus' tree) the driver -next branches are left out, so
nothing for the following merge window lands early.

It contains the DRM fixes too, so it would go where "drm" is today.

During the past weeks I have confirmed that the drm blackout period
works well on this new branch.

The dim changes:

  d875049d2b29 dim: build a unified drm-for-linux-next branch
  3009867cd318 dim: keep -next branches out of drm-for-linux-next during the freeze
  https://gitlab.freedesktop.org/drm/maintainer-tools/-/commits/master

AMD:
Alex, Christian: linux-next takes amdgpu from
agd5f/linux.git#drm-next today, which differs from drm-amdgpu-next in
drm-tip. Is drm-amdgpu-next fine for linux-next?

All other maintainers, please ack if you are okay with this approach.

Mark, you're in Cc for visibility only. Once we have all the acks, I'll
send you the formal request. After linux-next switches, we stop
updating the old for-linux-next* branches (patch below).

Thanks,
Rodrigo.

---
dim: stop updating the per-repo for-linux-next branches

linux-next now pulls the unified drm-for-linux-next branch instead.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 dim | 53 -----------------------------------------------------
 1 file changed, 53 deletions(-)

diff --git a/dim b/dim
index e3f616b..b3ed8f7 100755
--- a/dim
+++ b/dim
@@ -658,52 +658,6 @@ function dim_range_diff
 	fi
 }
 
-# update for-linux-next* branches
-function update_linux_next # branch next next-fixes fixes [for-linux-next] [for-linux-next-fixes]
-{
-	local branch linux_next linux_next_fixes linux_fixes for_linux_next for_linux_next_fixes repo remote
-
-	cd $DIM_PREFIX/drm-tip
-	branch=$1
-	linux_next=$2
-	linux_next_fixes=$3
-	linux_fixes=$4
-	for_linux_next=${5:-for-linux-next}
-	for_linux_next_fixes=${6:-for-linux-next-fixes}
-
-	repo=$(branch_to_repo $branch)
-
-	if [[ $repo != $(branch_to_repo $linux_next) ]] ; then
-		return
-	fi
-
-	remote=$(repo_to_remote $repo)
-
-	git_fetch_helper $remote
-
-	if [ -n "$for_linux_next_fixes" ] ; then
-		echo -n "Pushing $linux_fixes to $for_linux_next_fixes... "
-		git_push $remote +$remote/$linux_fixes:$for_linux_next_fixes
-		echo "$DONE_OR_SKIP"
-	fi
-
-	if git merge-base --is-ancestor $remote/$linux_next_fixes $remote/$linux_fixes ; then
-		# -fixes has caught up to dinf, i.e. we're out of the merge
-		# window. Push the next queue.
-		echo -n "Out of merge window. Pushing $linux_next to $for_linux_next... "
-		git_push $remote +$remote/$linux_next:$for_linux_next
-		echo "$DONE_OR_SKIP"
-	else
-		# dinf is ahead of -fixes, i.e. drm-next has already closed for
-		# the next merge window and we've started to gather new fixes
-		# for the current -next cycle. Push dinf
-
-		echo -n "Pushing $linux_next_fixes to $for_linux_next... "
-		git_push $remote +$remote/$linux_next_fixes:$for_linux_next
-		echo "$DONE_OR_SKIP"
-	fi
-}
-
 function check_conflicts # tree
 {
 	if git diff | grep -q '\(<<<<<<<\|=======\|>>>>>>>\||||||||\)' ; then
@@ -1192,13 +1146,6 @@ function dim_push_branch
 
 	git_push $remote $branch "$@"
 
-	update_linux_next $branch drm-intel-next drm-intel-next-fixes drm-intel-fixes
-	update_linux_next $branch drm-intel-gt-next drm-intel-next-fixes drm-intel-fixes \
-		for-linux-next-gt "" # no for-linux-next-gt-fixes for now
-	update_linux_next $branch drm-misc-next drm-misc-next-fixes drm-misc-fixes
-	update_linux_next $branch drm-rust-next drm-rust-next-fixes drm-rust-fixes
-	update_linux_next $branch drm-amd-next drm-amd-next-fixes drm-amd-fixes
-
 	dim_rebuild_tip
 }
 

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

[Danilo Krummrich]

On Mon Nov 2, 2026 at 7:41 PM CET, Rodrigo Vivi wrote:
> Hi folks,
>
> We'd like to replace most of the DRM trees in linux-next with a single
> branch:
>
>   https://gitlab.freedesktop.org/drm/tip.git#drm-for-linux-next
>
> It replaces these entries:
>
>   drm/drm-next, drm/drm-fixes
>   drm-misc/for-linux-next, drm-misc/for-linux-next-fixes
>   drm-intel/for-linux-next, drm-intel/for-linux-next-fixes
>   drm-xe/drm-xe-next
>   drm-rust/for-linux-next, drm-rust/for-linux-next-fixes
>   amdgpu (agd5f/linux.git#drm-next)
>
> drm-exynos, drm-msm, drm-msm-fixes, drm-msm-lumag, drm-nova and etnaviv
> are not part of it and stay as they are.
>
> The main reason is to reduce the conflict pain that Mark constantly faces.
> All of them should be handled already when we are rebuilding drm-tip.
>
> During this work, I realized that drm-xe is a big culprit for leaking
> future work without a blackout date from -rc6 to <next>-rc1.
> So, another quick solution would be to get a drm-xe for-linux-next like
> the other domains are doing. However, I still believe that this unified
> one will make Mark's life much easier anyway.
>
> The unified branch is rebuilt by dim together with drm-tip. It has all the DRM
> -fixes, drm-next, -next-fixes and driver -next branches merged, with
> the conflicts between them already resolved on our side. From -rc6
> until -rc1 (per Linus' tree) the driver -next branches are left out, so
> nothing for the following merge window lands early.

Seems reasonable; I assume the logic for individual trees would remain? I.e.
-next goes into tip/for-linux-next until -next-fixes is fast forwarded? IOW,
trees keep control over when exactly -next closes for the upcoming merge window?

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

On Mon, Nov 02, 2026 at 01:41:52PM -0500, Rodrigo Vivi wrote:

> We'd like to replace most of the DRM trees in linux-next with a single
> branch:

>   https://gitlab.freedesktop.org/drm/tip.git#drm-for-linux-next

Thanks, I really appreciate this!

> drm-exynos, drm-msm, drm-msm-fixes, drm-msm-lumag, drm-nova and etnaviv
> are not part of it and stay as they are.

Those are all fairly quiet anyway, and if they do get rolled in it's
easy enough to make the updates.  Your rollup includes all the frequent
fliers.

> During this work, I realized that drm-xe is a big culprit for leaking
> future work without a blackout date from -rc6 to <next>-rc1.
> So, another quick solution would be to get a drm-xe for-linux-next like
> the other domains are doing. However, I still believe that this unified
> one will make Mark's life much easier anyway.

Yeah, drm-xe and amdgpu were the biggest non-rebasing sources of commits
in -next that don't get merged this time around - I actually just
mentioned this in my "here's what's going on" mail to Linus a few
minutes ago.  Their numbers were:

  96	amdgpu
  84	drm-xe

> Mark, you're in Cc for visibility only. Once we have all the acks, I'll
> send you the formal request. After linux-next switches, we stop
> updating the old for-linux-next* branches (patch below).

I'll wait for a separate mail.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Rodrigo Vivi]

On Mon, Nov 02, 2026 at 07:51:13PM +0100, Danilo Krummrich wrote:
> >
> > The unified branch is rebuilt by dim together with drm-tip. It has all the DRM
> > -fixes, drm-next, -next-fixes and driver -next branches merged, with
> > the conflicts between them already resolved on our side. From -rc6
> > until -rc1 (per Linus' tree) the driver -next branches are left out, so
> > nothing for the following merge window lands early.
> 
> Seems reasonable; I assume the logic for individual trees would remain? I.e.
> -next goes into tip/for-linux-next until -next-fixes is fast forwarded? IOW,
> trees keep control over when exactly -next closes for the upcoming merge window?

Well, the flows of -next, -next-fixes, -fixes keeps the same. No change in that
or in our PR flows.

As for the mechanics of the closes, I'd say that for drm-xe and drm-intel, there's
absolutely no change. We consider our closure when send the last PR on that cycle.
But perhaps this was anyway a gap on our side?! to ensure that our -next-fixes are
in sync with our last PR?! (plus the gap of xe which was feeding with drm-xe-next
directly).

For the rust and others, the honest answer is: "not exactly..."

not exactly... The per-tree check goes away and there's one global rule:
the driver -next branches are left out from Linus' -rc6 until -rc1.
But this is the cutoff the drm-rust docs already describe and used by everyone
anyway.

So, the maintainers are still in control on when their -next is closed. But that
is their last PR. around -rc5/-rc6. And if they need extra PRs after that, it
is also fine, because drm/drm-next is still feeding this unified for-next.

So, whatever Dave and Sima accept during the blackout will be covered. Regardless
the state of your -next-fixes.
And, in any case, -next-fixes is always included, even during the freeze.

IOW, when you fast-forward drm-rust-next-fixes at your cutoff, that content stays
in linux-next whenever you do it. The only difference is that drm-rust-next
itself stops at -rc6, not when you fast-forward.

Thanks,
Rodrigo.

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

[Danilo Krummrich]

On Mon Nov 2, 2026 at 8:20 PM CET, Rodrigo Vivi wrote:
> not exactly... The per-tree check goes away and there's one global rule:
> the driver -next branches are left out from Linus' -rc6 until -rc1.
> But this is the cutoff the drm-rust docs already describe and used by everyone
> anyway.

As a general rule that's correct, but in practice we have been leaving -next
open for a bit longer (with the last PR at -rc7, depending on what's contained),
as it sometimes helps with cross-tree coordination for interactions with other
trees while we're still ramping up Rust infrastructure throughout the kernel.

The Nova vGPU parts are getting closer to something that can be used in
production, but it still remains that it is useful to retain some flexibility as
we will keep having some more cross tree dependencies for a while.

> So, the maintainers are still in control on when their -next is closed. But that
> is their last PR. around -rc5/-rc6. And if they need extra PRs after that, it
> is also fine, because drm/drm-next is still feeding this unified for-next.

For a late PR that leaves a gap for stuff landing in -next and only ever hitting
linux-next *after* it has been merged in drm/drm-next. Exposure to linux-next
should however be a prerequisite for making it into drm/drm-next.

So, I think maintainers would have to commit to strictly close with -rc6 to
avoid such a situation.

> IOW, when you fast-forward drm-rust-next-fixes at your cutoff, that content stays
> in linux-next whenever you do it. The only difference is that drm-rust-next
> itself stops at -rc6, not when you fast-forward.

Sure, but that'd mean -next PR a few days after -rc6 would need to originate
from -next-fixes in order to get linux-next exposure. Thus, with this approach
it just boils down to "no flexibility on this".

Can't we just keep the per-tree for-linux-next branches and just merge them into
tip/for-linux-next?

for-linux-next-fixes could of course be removed as it always follows -fixes
anyways.

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

[Alex Deucher]

On Mon, Nov 2, 2026 at 1:51 PM Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>
> Hi folks,
>
> We'd like to replace most of the DRM trees in linux-next with a single
> branch:
>
>   https://gitlab.freedesktop.org/drm/tip.git#drm-for-linux-next
>
> It replaces these entries:
>
>   drm/drm-next, drm/drm-fixes
>   drm-misc/for-linux-next, drm-misc/for-linux-next-fixes
>   drm-intel/for-linux-next, drm-intel/for-linux-next-fixes
>   drm-xe/drm-xe-next
>   drm-rust/for-linux-next, drm-rust/for-linux-next-fixes
>   amdgpu (agd5f/linux.git#drm-next)
>
> drm-exynos, drm-msm, drm-msm-fixes, drm-msm-lumag, drm-nova and etnaviv
> are not part of it and stay as they are.
>
> The main reason is to reduce the conflict pain that Mark constantly faces.
> All of them should be handled already when we are rebuilding drm-tip.
>
> During this work, I realized that drm-xe is a big culprit for leaking
> future work without a blackout date from -rc6 to <next>-rc1.
> So, another quick solution would be to get a drm-xe for-linux-next like
> the other domains are doing. However, I still believe that this unified
> one will make Mark's life much easier anyway.
>
> The unified branch is rebuilt by dim together with drm-tip. It has all the DRM
> -fixes, drm-next, -next-fixes and driver -next branches merged, with
> the conflicts between them already resolved on our side. From -rc6
> until -rc1 (per Linus' tree) the driver -next branches are left out, so
> nothing for the following merge window lands early.
>
> It contains the DRM fixes too, so it would go where "drm" is today.
>
> During the past weeks I have confirmed that the drm blackout period
> works well on this new branch.
>
> The dim changes:
>
>   d875049d2b29 dim: build a unified drm-for-linux-next branch
>   3009867cd318 dim: keep -next branches out of drm-for-linux-next during the freeze
>   https://gitlab.freedesktop.org/drm/maintainer-tools/-/commits/master
>
> AMD:
> Alex, Christian: linux-next takes amdgpu from
> agd5f/linux.git#drm-next today, which differs from drm-amdgpu-next in
> drm-tip. Is drm-amdgpu-next fine for linux-next?

They should be the same.  I just mirror drm-amdgpu-next to
agd5f/linux.git#drm-next in case anyone is still looking there.

Alex

>
> All other maintainers, please ack if you are okay with this approach.
>
> Mark, you're in Cc for visibility only. Once we have all the acks, I'll
> send you the formal request. After linux-next switches, we stop
> updating the old for-linux-next* branches (patch below).
>
> Thanks,
> Rodrigo.
>
> ---
> dim: stop updating the per-repo for-linux-next branches
>
> linux-next now pulls the unified drm-for-linux-next branch instead.
>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>  dim | 53 -----------------------------------------------------
>  1 file changed, 53 deletions(-)
>
> diff --git a/dim b/dim
> index e3f616b..b3ed8f7 100755
> --- a/dim
> +++ b/dim
> @@ -658,52 +658,6 @@ function dim_range_diff
>         fi
>  }
>
> -# update for-linux-next* branches
> -function update_linux_next # branch next next-fixes fixes [for-linux-next] [for-linux-next-fixes]
> -{
> -       local branch linux_next linux_next_fixes linux_fixes for_linux_next for_linux_next_fixes repo remote
> -
> -       cd $DIM_PREFIX/drm-tip
> -       branch=$1
> -       linux_next=$2
> -       linux_next_fixes=$3
> -       linux_fixes=$4
> -       for_linux_next=${5:-for-linux-next}
> -       for_linux_next_fixes=${6:-for-linux-next-fixes}
> -
> -       repo=$(branch_to_repo $branch)
> -
> -       if [[ $repo != $(branch_to_repo $linux_next) ]] ; then
> -               return
> -       fi
> -
> -       remote=$(repo_to_remote $repo)
> -
> -       git_fetch_helper $remote
> -
> -       if [ -n "$for_linux_next_fixes" ] ; then
> -               echo -n "Pushing $linux_fixes to $for_linux_next_fixes... "
> -               git_push $remote +$remote/$linux_fixes:$for_linux_next_fixes
> -               echo "$DONE_OR_SKIP"
> -       fi
> -
> -       if git merge-base --is-ancestor $remote/$linux_next_fixes $remote/$linux_fixes ; then
> -               # -fixes has caught up to dinf, i.e. we're out of the merge
> -               # window. Push the next queue.
> -               echo -n "Out of merge window. Pushing $linux_next to $for_linux_next... "
> -               git_push $remote +$remote/$linux_next:$for_linux_next
> -               echo "$DONE_OR_SKIP"
> -       else
> -               # dinf is ahead of -fixes, i.e. drm-next has already closed for
> -               # the next merge window and we've started to gather new fixes
> -               # for the current -next cycle. Push dinf
> -
> -               echo -n "Pushing $linux_next_fixes to $for_linux_next... "
> -               git_push $remote +$remote/$linux_next_fixes:$for_linux_next
> -               echo "$DONE_OR_SKIP"
> -       fi
> -}
> -
>  function check_conflicts # tree
>  {
>         if git diff | grep -q '\(<<<<<<<\|=======\|>>>>>>>\||||||||\)' ; then
> @@ -1192,13 +1146,6 @@ function dim_push_branch
>
>         git_push $remote $branch "$@"
>
> -       update_linux_next $branch drm-intel-next drm-intel-next-fixes drm-intel-fixes
> -       update_linux_next $branch drm-intel-gt-next drm-intel-next-fixes drm-intel-fixes \
> -               for-linux-next-gt "" # no for-linux-next-gt-fixes for now
> -       update_linux_next $branch drm-misc-next drm-misc-next-fixes drm-misc-fixes
> -       update_linux_next $branch drm-rust-next drm-rust-next-fixes drm-rust-fixes
> -       update_linux_next $branch drm-amd-next drm-amd-next-fixes drm-amd-fixes
> -
>         dim_rebuild_tip
>  }
>

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

[Dave Airlie]

On Tue, 3 Nov 2026 at 06:01, Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Mon Nov 2, 2026 at 8:20 PM CET, Rodrigo Vivi wrote:
> > not exactly... The per-tree check goes away and there's one global rule:
> > the driver -next branches are left out from Linus' -rc6 until -rc1.
> > But this is the cutoff the drm-rust docs already describe and used by everyone
> > anyway.
>
> As a general rule that's correct, but in practice we have been leaving -next
> open for a bit longer (with the last PR at -rc7, depending on what's contained),
> as it sometimes helps with cross-tree coordination for interactions with other
> trees while we're still ramping up Rust infrastructure throughout the kernel.

It might be time to pull back to -rc6 though, we could just keep the
rust tree in -next separate,

It shouldn't cause any extra conflicts, but I'd rather not keep all
the -next trees in -next once
we merge this, otherwise we may end up with trees getting ahead of the
next cycle again.

>
> For a late PR that leaves a gap for stuff landing in -next and only ever hitting
> linux-next *after* it has been merged in drm/drm-next. Exposure to linux-next
> should however be a prerequisite for making it into drm/drm-next.
>
> So, I think maintainers would have to commit to strictly close with -rc6 to
> avoid such a situation.
>
> > IOW, when you fast-forward drm-rust-next-fixes at your cutoff, that content stays
> > in linux-next whenever you do it. The only difference is that drm-rust-next
> > itself stops at -rc6, not when you fast-forward.
>
> Sure, but that'd mean -next PR a few days after -rc6 would need to originate
> from -next-fixes in order to get linux-next exposure. Thus, with this approach
> it just boils down to "no flexibility on this".
>
> Can't we just keep the per-tree for-linux-next branches and just merge them into
> tip/for-linux-next?

I'm not sure need to have that complexity for everyone, but if we need
to keep the rust tree as an extra then I'm fine with that for now,
until it stabilises.

But it seems that we already have confusion about what was going into
next after rc6 so this will lock that down and keep it clearer.

Dave.

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

[Danilo Krummrich]

On Tue Nov 3, 2026 at 3:05 AM CET, Dave Airlie wrote:
> It might be time to pull back to -rc6 though, we could just keep the
> rust tree in -next separate,

Agreed, I think that makes sense (I am thinking more about occasional cases
where we may need a few days more due to cross-tree dependencies). Otherwise,
that's an option too, but I'd like to avoid a special case; if we take the
proposed approach, I'd rather try and see how it goes.

> It shouldn't cause any extra conflicts, but I'd rather not keep all
> the -next trees in -next once
> we merge this, otherwise we may end up with trees getting ahead of the
> next cycle again.

I'm not entirely sure what you mean by "keep all the -next trees in -next", but
just to clarify:

I'm proposing that linux-next only merge the unified tip/for-linux-next branch.
The per-tree for-linux-next branches would remain as inputs to that branch,
preserving their existing selection logic.

IOW, linux-next merges tip/for-linux-next, and tip/for-linux-next merges
$tree/for-linux-next, rather than $tree/$tree-next.

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
(unless all trees really commit to tagging and sending their final -next PR at
the global cutoff).

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.

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.

So, in the end, it comes down to whether each tree's closure controls what
enters linux-next, or whether maintainers need to coordinate their branch
updates around a single cutoff defined by tip. While the latter sounds like the
ideal case, I'm not entirely sure if it isn't too strict in practice. I'm
thinking more generally here, from a practical or organisational point of view.

(For instance, in practice Intel has sometimes sent its final -next PR a couple
of days before -rc6 and continued applying changes afterwards; I think their
cutoff is generally around -rc5/-rc6.)

> I'm not sure need to have that complexity for everyone, but if we need
> to keep the rust tree as an extra then I'm fine with that for now,
> until it stabilises.

Appreciate it, but I'd prefer not to special case it; I can see how my drm-rust
example focused the discussion on that case, whereas my concern is more general.

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

[Rodrigo Vivi]

On Tue, Nov 03, 2026 at 08:32:48PM +0100, Danilo Krummrich wrote:
> On Tue Nov 3, 2026 at 3:05 AM CET, Dave Airlie wrote:
> > It might be time to pull back to -rc6 though, we could just keep the
> > rust tree in -next separate,
> 
> Agreed, I think that makes sense (I am thinking more about occasional cases
> where we may need a few days more due to cross-tree dependencies). Otherwise,
> that's an option too, but I'd like to avoid a special case; if we take the
> proposed approach, I'd rather try and see how it goes.
> 
> > It shouldn't cause any extra conflicts, but I'd rather not keep all
> > the -next trees in -next once
> > we merge this, otherwise we may end up with trees getting ahead of the
> > next cycle again.
> 
> I'm not entirely sure what you mean by "keep all the -next trees in -next", but
> just to clarify:
> 
> I'm proposing that linux-next only merge the unified tip/for-linux-next branch.
> The per-tree for-linux-next branches would remain as inputs to that branch,
> preserving their existing selection logic.
> 
> 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
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
4. Instrument dim to have this secondary reconstructed tree instead of the
implemented chop.
5. Prepare every committer to deal with this extra build time and extra
conflict resolution.

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

The current proposal of dim taking care for us with a single rule is what will
make this less error prone and ensure we are all following the same steps.

> (unless all trees really commit to tagging and sending their final -next PR at
> the global cutoff).
> 
> 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.
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).

> 
> So, in the end, it comes down to whether each tree's closure controls what
> enters linux-next, or whether maintainers need to coordinate their branch
> updates around a single cutoff defined by tip. While the latter sounds like the
> ideal case, I'm not entirely sure if it isn't too strict in practice. I'm
> thinking more generally here, from a practical or organisational point of view.
> 
> (For instance, in practice Intel has sometimes sent its final -next PR a couple
> of days before -rc6 and continued applying changes afterwards; I think their
> cutoff is generally around -rc5/-rc6.)
> 
> > I'm not sure need to have that complexity for everyone, but if we need
> > to keep the rust tree as an extra then I'm fine with that for now,
> > until it stabilises.
> 
> Appreciate it, but I'd prefer not to special case it; I can see how my drm-rust
> example focused the discussion on that case, whereas my concern is more general.

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

[Rodrigo Vivi]

On Mon, Nov 02, 2026 at 06:07:15PM -0500, Alex Deucher wrote:
> On Mon, Nov 2, 2026 at 1:51 PM Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> >
> > Hi folks,
> >
> > We'd like to replace most of the DRM trees in linux-next with a single
> > branch:
> >
> >   https://gitlab.freedesktop.org/drm/tip.git#drm-for-linux-next
> >
> > It replaces these entries:
> >
> >   drm/drm-next, drm/drm-fixes
> >   drm-misc/for-linux-next, drm-misc/for-linux-next-fixes
> >   drm-intel/for-linux-next, drm-intel/for-linux-next-fixes
> >   drm-xe/drm-xe-next
> >   drm-rust/for-linux-next, drm-rust/for-linux-next-fixes
> >   amdgpu (agd5f/linux.git#drm-next)
> >
> > drm-exynos, drm-msm, drm-msm-fixes, drm-msm-lumag, drm-nova and etnaviv
> > are not part of it and stay as they are.
> >
> > The main reason is to reduce the conflict pain that Mark constantly faces.
> > All of them should be handled already when we are rebuilding drm-tip.
> >
> > During this work, I realized that drm-xe is a big culprit for leaking
> > future work without a blackout date from -rc6 to <next>-rc1.
> > So, another quick solution would be to get a drm-xe for-linux-next like
> > the other domains are doing. However, I still believe that this unified
> > one will make Mark's life much easier anyway.
> >
> > The unified branch is rebuilt by dim together with drm-tip. It has all the DRM
> > -fixes, drm-next, -next-fixes and driver -next branches merged, with
> > the conflicts between them already resolved on our side. From -rc6
> > until -rc1 (per Linus' tree) the driver -next branches are left out, so
> > nothing for the following merge window lands early.
> >
> > It contains the DRM fixes too, so it would go where "drm" is today.
> >
> > During the past weeks I have confirmed that the drm blackout period
> > works well on this new branch.
> >
> > The dim changes:
> >
> >   d875049d2b29 dim: build a unified drm-for-linux-next branch
> >   3009867cd318 dim: keep -next branches out of drm-for-linux-next during the freeze
> >   https://gitlab.freedesktop.org/drm/maintainer-tools/-/commits/master
> >
> > AMD:
> > Alex, Christian: linux-next takes amdgpu from
> > agd5f/linux.git#drm-next today, which differs from drm-amdgpu-next in
> > drm-tip. Is drm-amdgpu-next fine for linux-next?
> 
> They should be the same.  I just mirror drm-amdgpu-next to
> agd5f/linux.git#drm-next in case anyone is still looking there.

That's fine. But please let us know your thoughts on either going with
this approach proposed here or with the other approach proposed by
Danilo, where we in xe and you would need to create a for-linux-next
and for-linux-next-fixes.

Both xe and amd are leaking next.next patches into linux-next right now.
And we definitely need to stop that.

Thanks,
Rodrigo.

> 
> Alex
> 
> >
> > All other maintainers, please ack if you are okay with this approach.
> >
> > Mark, you're in Cc for visibility only. Once we have all the acks, I'll
> > send you the formal request. After linux-next switches, we stop
> > updating the old for-linux-next* branches (patch below).
> >
> > Thanks,
> > Rodrigo.
> >
> > ---
> > dim: stop updating the per-repo for-linux-next branches
> >
> > linux-next now pulls the unified drm-for-linux-next branch instead.
> >
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > ---
> >  dim | 53 -----------------------------------------------------
> >  1 file changed, 53 deletions(-)
> >
> > diff --git a/dim b/dim
> > index e3f616b..b3ed8f7 100755
> > --- a/dim
> > +++ b/dim
> > @@ -658,52 +658,6 @@ function dim_range_diff
> >         fi
> >  }
> >
> > -# update for-linux-next* branches
> > -function update_linux_next # branch next next-fixes fixes [for-linux-next] [for-linux-next-fixes]
> > -{
> > -       local branch linux_next linux_next_fixes linux_fixes for_linux_next for_linux_next_fixes repo remote
> > -
> > -       cd $DIM_PREFIX/drm-tip
> > -       branch=$1
> > -       linux_next=$2
> > -       linux_next_fixes=$3
> > -       linux_fixes=$4
> > -       for_linux_next=${5:-for-linux-next}
> > -       for_linux_next_fixes=${6:-for-linux-next-fixes}
> > -
> > -       repo=$(branch_to_repo $branch)
> > -
> > -       if [[ $repo != $(branch_to_repo $linux_next) ]] ; then
> > -               return
> > -       fi
> > -
> > -       remote=$(repo_to_remote $repo)
> > -
> > -       git_fetch_helper $remote
> > -
> > -       if [ -n "$for_linux_next_fixes" ] ; then
> > -               echo -n "Pushing $linux_fixes to $for_linux_next_fixes... "
> > -               git_push $remote +$remote/$linux_fixes:$for_linux_next_fixes
> > -               echo "$DONE_OR_SKIP"
> > -       fi
> > -
> > -       if git merge-base --is-ancestor $remote/$linux_next_fixes $remote/$linux_fixes ; then
> > -               # -fixes has caught up to dinf, i.e. we're out of the merge
> > -               # window. Push the next queue.
> > -               echo -n "Out of merge window. Pushing $linux_next to $for_linux_next... "
> > -               git_push $remote +$remote/$linux_next:$for_linux_next
> > -               echo "$DONE_OR_SKIP"
> > -       else
> > -               # dinf is ahead of -fixes, i.e. drm-next has already closed for
> > -               # the next merge window and we've started to gather new fixes
> > -               # for the current -next cycle. Push dinf
> > -
> > -               echo -n "Pushing $linux_next_fixes to $for_linux_next... "
> > -               git_push $remote +$remote/$linux_next_fixes:$for_linux_next
> > -               echo "$DONE_OR_SKIP"
> > -       fi
> > -}
> > -
> >  function check_conflicts # tree
> >  {
> >         if git diff | grep -q '\(<<<<<<<\|=======\|>>>>>>>\||||||||\)' ; then
> > @@ -1192,13 +1146,6 @@ function dim_push_branch
> >
> >         git_push $remote $branch "$@"
> >
> > -       update_linux_next $branch drm-intel-next drm-intel-next-fixes drm-intel-fixes
> > -       update_linux_next $branch drm-intel-gt-next drm-intel-next-fixes drm-intel-fixes \
> > -               for-linux-next-gt "" # no for-linux-next-gt-fixes for now
> > -       update_linux_next $branch drm-misc-next drm-misc-next-fixes drm-misc-fixes
> > -       update_linux_next $branch drm-rust-next drm-rust-next-fixes drm-rust-fixes
> > -       update_linux_next $branch drm-amd-next drm-amd-next-fixes drm-amd-fixes
> > -
> >         dim_rebuild_tip
> >  }
> >

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

[Danilo Krummrich]

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

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

[Alex Deucher]

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.

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

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

[Alex Deucher]

On Tue, Nov 3, 2026 at 3:35 PM Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>
> On Mon, Nov 02, 2026 at 06:07:15PM -0500, Alex Deucher wrote:
> > On Mon, Nov 2, 2026 at 1:51 PM Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> > >
> > > Hi folks,
> > >
> > > We'd like to replace most of the DRM trees in linux-next with a single
> > > branch:
> > >
> > >   https://gitlab.freedesktop.org/drm/tip.git#drm-for-linux-next
> > >
> > > It replaces these entries:
> > >
> > >   drm/drm-next, drm/drm-fixes
> > >   drm-misc/for-linux-next, drm-misc/for-linux-next-fixes
> > >   drm-intel/for-linux-next, drm-intel/for-linux-next-fixes
> > >   drm-xe/drm-xe-next
> > >   drm-rust/for-linux-next, drm-rust/for-linux-next-fixes
> > >   amdgpu (agd5f/linux.git#drm-next)
> > >
> > > drm-exynos, drm-msm, drm-msm-fixes, drm-msm-lumag, drm-nova and etnaviv
> > > are not part of it and stay as they are.
> > >
> > > The main reason is to reduce the conflict pain that Mark constantly faces.
> > > All of them should be handled already when we are rebuilding drm-tip.
> > >
> > > During this work, I realized that drm-xe is a big culprit for leaking
> > > future work without a blackout date from -rc6 to <next>-rc1.
> > > So, another quick solution would be to get a drm-xe for-linux-next like
> > > the other domains are doing. However, I still believe that this unified
> > > one will make Mark's life much easier anyway.
> > >
> > > The unified branch is rebuilt by dim together with drm-tip. It has all the DRM
> > > -fixes, drm-next, -next-fixes and driver -next branches merged, with
> > > the conflicts between them already resolved on our side. From -rc6
> > > until -rc1 (per Linus' tree) the driver -next branches are left out, so
> > > nothing for the following merge window lands early.
> > >
> > > It contains the DRM fixes too, so it would go where "drm" is today.
> > >
> > > During the past weeks I have confirmed that the drm blackout period
> > > works well on this new branch.
> > >
> > > The dim changes:
> > >
> > >   d875049d2b29 dim: build a unified drm-for-linux-next branch
> > >   3009867cd318 dim: keep -next branches out of drm-for-linux-next during the freeze
> > >   https://gitlab.freedesktop.org/drm/maintainer-tools/-/commits/master
> > >
> > > AMD:
> > > Alex, Christian: linux-next takes amdgpu from
> > > agd5f/linux.git#drm-next today, which differs from drm-amdgpu-next in
> > > drm-tip. Is drm-amdgpu-next fine for linux-next?
> >
> > They should be the same.  I just mirror drm-amdgpu-next to
> > agd5f/linux.git#drm-next in case anyone is still looking there.
>
> That's fine. But please let us know your thoughts on either going with
> this approach proposed here or with the other approach proposed by
> Danilo, where we in xe and you would need to create a for-linux-next
> and for-linux-next-fixes.
>
> Both xe and amd are leaking next.next patches into linux-next right now.
> And we definitely need to stop that.

I'm not quite sure I understand what you are proposing.  Is the idea
that there would effectively be one drm-next composed from all of the
constituent drm-next or drm-next-fixes trees (depending whether we are
in or out of the blackout period) and that is what higher level -next
trees would integrate?  Isn't that what -next-fixes is supposed to be?
 Maybe we just need better documentation for the upstream -next
maintainers?  Maybe the actual vendor -next branches should just be
renamed to something like vendor-dev and then during the blackout
period vendor-next points to vendor-next-fixes and then after that
vendor-next points to vendor-dev.

Alex

>
> Thanks,
> Rodrigo.
>
> >
> > Alex
> >
> > >
> > > All other maintainers, please ack if you are okay with this approach.
> > >
> > > Mark, you're in Cc for visibility only. Once we have all the acks, I'll
> > > send you the formal request. After linux-next switches, we stop
> > > updating the old for-linux-next* branches (patch below).
> > >
> > > Thanks,
> > > Rodrigo.
> > >
> > > ---
> > > dim: stop updating the per-repo for-linux-next branches
> > >
> > > linux-next now pulls the unified drm-for-linux-next branch instead.
> > >
> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > ---
> > >  dim | 53 -----------------------------------------------------
> > >  1 file changed, 53 deletions(-)
> > >
> > > diff --git a/dim b/dim
> > > index e3f616b..b3ed8f7 100755
> > > --- a/dim
> > > +++ b/dim
> > > @@ -658,52 +658,6 @@ function dim_range_diff
> > >         fi
> > >  }
> > >
> > > -# update for-linux-next* branches
> > > -function update_linux_next # branch next next-fixes fixes [for-linux-next] [for-linux-next-fixes]
> > > -{
> > > -       local branch linux_next linux_next_fixes linux_fixes for_linux_next for_linux_next_fixes repo remote
> > > -
> > > -       cd $DIM_PREFIX/drm-tip
> > > -       branch=$1
> > > -       linux_next=$2
> > > -       linux_next_fixes=$3
> > > -       linux_fixes=$4
> > > -       for_linux_next=${5:-for-linux-next}
> > > -       for_linux_next_fixes=${6:-for-linux-next-fixes}
> > > -
> > > -       repo=$(branch_to_repo $branch)
> > > -
> > > -       if [[ $repo != $(branch_to_repo $linux_next) ]] ; then
> > > -               return
> > > -       fi
> > > -
> > > -       remote=$(repo_to_remote $repo)
> > > -
> > > -       git_fetch_helper $remote
> > > -
> > > -       if [ -n "$for_linux_next_fixes" ] ; then
> > > -               echo -n "Pushing $linux_fixes to $for_linux_next_fixes... "
> > > -               git_push $remote +$remote/$linux_fixes:$for_linux_next_fixes
> > > -               echo "$DONE_OR_SKIP"
> > > -       fi
> > > -
> > > -       if git merge-base --is-ancestor $remote/$linux_next_fixes $remote/$linux_fixes ; then
> > > -               # -fixes has caught up to dinf, i.e. we're out of the merge
> > > -               # window. Push the next queue.
> > > -               echo -n "Out of merge window. Pushing $linux_next to $for_linux_next... "
> > > -               git_push $remote +$remote/$linux_next:$for_linux_next
> > > -               echo "$DONE_OR_SKIP"
> > > -       else
> > > -               # dinf is ahead of -fixes, i.e. drm-next has already closed for
> > > -               # the next merge window and we've started to gather new fixes
> > > -               # for the current -next cycle. Push dinf
> > > -
> > > -               echo -n "Pushing $linux_next_fixes to $for_linux_next... "
> > > -               git_push $remote +$remote/$linux_next_fixes:$for_linux_next
> > > -               echo "$DONE_OR_SKIP"
> > > -       fi
> > > -}
> > > -
> > >  function check_conflicts # tree
> > >  {
> > >         if git diff | grep -q '\(<<<<<<<\|=======\|>>>>>>>\||||||||\)' ; then
> > > @@ -1192,13 +1146,6 @@ function dim_push_branch
> > >
> > >         git_push $remote $branch "$@"
> > >
> > > -       update_linux_next $branch drm-intel-next drm-intel-next-fixes drm-intel-fixes
> > > -       update_linux_next $branch drm-intel-gt-next drm-intel-next-fixes drm-intel-fixes \
> > > -               for-linux-next-gt "" # no for-linux-next-gt-fixes for now
> > > -       update_linux_next $branch drm-misc-next drm-misc-next-fixes drm-misc-fixes
> > > -       update_linux_next $branch drm-rust-next drm-rust-next-fixes drm-rust-fixes
> > > -       update_linux_next $branch drm-amd-next drm-amd-next-fixes drm-amd-fixes
> > > -
> > >         dim_rebuild_tip
> > >  }
> > >

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

[Rodrigo Vivi]

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.

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

[Rodrigo Vivi]

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

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

[Danilo Krummrich]

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.

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

[Rodrigo Vivi]

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.

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

[Dave Airlie]

On Wed, 4 Nov 2026 at 12:37, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>
> 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.

Yes this is the thing I like, while I like maintainers having freedom,
relying on them to do something manually every release at the same
time doesn't seem to scale so well.

If we can't have the tool enforce what we send to -next after -rc6
then it's going to have gaps.

Dave.

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

[Thorsten Leemhuis]

On 11/2/26 19:41, Rodrigo Vivi wrote:
> 
> We'd like to replace most of the DRM trees in linux-next with a single
> branch:
> 
>   https://gitlab.freedesktop.org/drm/tip.git#drm-for-linux-next
> 
> It replaces these entries:
> 
>   drm/drm-next, drm/drm-fixes
>   drm-misc/for-linux-next, drm-misc/for-linux-next-fixes
>   drm-intel/for-linux-next, drm-intel/for-linux-next-fixes
>   drm-xe/drm-xe-next
>   drm-rust/for-linux-next, drm-rust/for-linux-next-fixes
>   amdgpu (agd5f/linux.git#drm-next)
> 
> drm-exynos, drm-msm, drm-msm-fixes, drm-msm-lumag, drm-nova and etnaviv
> are not part of it and stay as they are.
> 
> The main reason is to reduce the conflict pain that Mark constantly faces.
> All of them should be handled already when we are rebuilding drm-tip.> [...]

Please correct me if I'm wrong: this seems to mix up patches for the
current cycle (e.g., -fixes branches) with those for the next one -- so
I assume the former won't end up in next/pending-fixes anymore?

Do we care? Or is this a situation along the lines of "yeah, that's a
downside of this, but given the upsides, we do this nevertheless"?

For my work it was kind of nice to have the two tracks separated, as it
allowed me to easily check "is this fix for a recent regression in
pending-fixes, as it should, because it should be fixed this cycle".

Side note: two years ago there was also the idea to increase testing of
pending-fixes or branches feeding into it separately, but it afaics got
no real traction:

linus-next: improving functional testing for to-be-merged pull requests
https://lore.kernel.org/all/ZyI-Y00J3DBUkon3@sashalap/

Ciao, Thorsten

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

[Danilo Krummrich]

On Wed Nov 4, 2026 at 4:29 AM CET, Dave Airlie wrote:
> Yes this is the thing I like, while I like maintainers having freedom,
> relying on them to do something manually every release at the same
> time doesn't seem to scale so well.

I think maintainers have to do something manually every release in both cases.

The difference is between "everyone has to do it at the exact cutoff day" vs.
"everyone has to fast-forward their -next-fixes branch" (which to be fair has to
be done in both cases).

For the former, a tree that closes before the global cutoff can still leak
following-cycle work into linux-next.

I.e. the global switch is automatic, but doesn't ensure correctness by itself.
In order to be correct, maintainers have to do something manually.

So eventually it comes down to whether doing the correct thing derives from an
explicit operation (i.e. fast-forward -next-fixes, or just add the --final
helper), or an implicit commitment to push and tag branches on a specific day.

I think it is better to derive the tree status from its actual state rather than
a promise about that state at a specified cutoff day.

> If we can't have the tool enforce what we send to -next after -rc6
> then it's going to have gaps.

I don't think either option can enforce correctness. The difference is that one
approach relies on a timing promise about the tree state, while the other uses
the tree state itself to make the decision.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

On Wed, Nov 04, 2026 at 06:49:29AM +0100, Thorsten Leemhuis wrote:
> On 11/2/26 19:41, Rodrigo Vivi wrote:

> >   drm/drm-next, drm/drm-fixes
> >   drm-misc/for-linux-next, drm-misc/for-linux-next-fixes
> >   drm-intel/for-linux-next, drm-intel/for-linux-next-fixes
> >   drm-xe/drm-xe-next
> >   drm-rust/for-linux-next, drm-rust/for-linux-next-fixes
> >   amdgpu (agd5f/linux.git#drm-next)

> > drm-exynos, drm-msm, drm-msm-fixes, drm-msm-lumag, drm-nova and etnaviv
> > are not part of it and stay as they are.

> > The main reason is to reduce the conflict pain that Mark constantly faces.
> > All of them should be handled already when we are rebuilding drm-tip.> [...]

> Please correct me if I'm wrong: this seems to mix up patches for the
> current cycle (e.g., -fixes branches) with those for the next one -- so
> I assume the former won't end up in next/pending-fixes anymore?

I'm hoping is that the theory is that they will work like a lot of other
trees and merge all the fixes branches first, push that out as something
I can pick up, then merge the other branches on top of that.  That works
well elsewhere, I'd expect it to also work well for DRM.  One of the
goals from my point of view is that the mess caused by all the cherry
picking is resolved by DRM and isn't visible to -next.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Sasha Levin]

On Wed, Nov 04, 2026 at 06:49:29AM +0100, Thorsten Leemhuis wrote:
>On 11/2/26 19:41, Rodrigo Vivi wrote:
>>
>> We'd like to replace most of the DRM trees in linux-next with a single
>> branch:
>>
>>   https://gitlab.freedesktop.org/drm/tip.git#drm-for-linux-next
>>
>> It replaces these entries:
>>
>>   drm/drm-next, drm/drm-fixes
>>   drm-misc/for-linux-next, drm-misc/for-linux-next-fixes
>>   drm-intel/for-linux-next, drm-intel/for-linux-next-fixes
>>   drm-xe/drm-xe-next
>>   drm-rust/for-linux-next, drm-rust/for-linux-next-fixes
>>   amdgpu (agd5f/linux.git#drm-next)
>>
>> drm-exynos, drm-msm, drm-msm-fixes, drm-msm-lumag, drm-nova and etnaviv
>> are not part of it and stay as they are.
>>
>> The main reason is to reduce the conflict pain that Mark constantly faces.
>> All of them should be handled already when we are rebuilding drm-tip.> [...]
>
>Please correct me if I'm wrong: this seems to mix up patches for the
>current cycle (e.g., -fixes branches) with those for the next one -- so
>I assume the former won't end up in next/pending-fixes anymore?
>
>Do we care? Or is this a situation along the lines of "yeah, that's a
>downside of this, but given the upsides, we do this nevertheless"?
>
>For my work it was kind of nice to have the two tracks separated, as it
>allowed me to easily check "is this fix for a recent regression in
>pending-fixes, as it should, because it should be fixed this cycle".
>
>Side note: two years ago there was also the idea to increase testing of
>pending-fixes or branches feeding into it separately, but it afaics got
>no real traction:
>
>linus-next: improving functional testing for to-be-merged pull requests
>https://lore.kernel.org/all/ZyI-Y00J3DBUkon3@sashalap/

This is actually still happening today, just evolved a bit!

I have a tree similar to linux-next, but it's fully automated, using LLMs for
conflict resolutions, and generated a few times a day:

https://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-next.git/

Instead of just a single tree, it builds the tree with categories, grouping
them into "%s-next" trees for easier testing by subsystem or theme, and later
merges them all into the one big "all-next" branch.

The equivalent of the auto-pending-fixes branch you mentioned would be the
"fixes-next" branch, and for the drm folks it would be the "drm-next" branch.

This whole thing is still being very much used today, finding real problems :)

-- 
Thanks,
Sasha

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

[Rodrigo Vivi]

On Wed, Nov 04, 2026 at 12:08:08PM +0100, Danilo Krummrich wrote:
> On Wed Nov 4, 2026 at 4:29 AM CET, Dave Airlie wrote:
> > Yes this is the thing I like, while I like maintainers having freedom,
> > relying on them to do something manually every release at the same
> > time doesn't seem to scale so well.
> 
> I think maintainers have to do something manually every release in both cases.
> 
> The difference is between "everyone has to do it at the exact cutoff day" vs.
> "everyone has to fast-forward their -next-fixes branch" (which to be fair has to
> be done in both cases).
> 
> For the former, a tree that closes before the global cutoff can still leak
> following-cycle work into linux-next.

On that I already agreed that we should move the blackout from -rc6 to -rc5.
So, the only thing that every maintainer needs to ensure is to prepare,
at least, one PR after -rc5 and we won't have absolutely any leak.

And I believe we are all already doing this anyway, so again, there won't be any
special thing that maintainers would need to do to ensure correctness.

> 
> I.e. the global switch is automatic, but doesn't ensure correctness by itself.
> In order to be correct, maintainers have to do something manually.
> 
> So eventually it comes down to whether doing the correct thing derives from an
> explicit operation (i.e. fast-forward -next-fixes, or just add the --final
> helper), or an implicit commitment to push and tag branches on a specific day.
> 
> I think it is better to derive the tree status from its actual state rather than
> a promise about that state at a specified cutoff day.
> 
> > If we can't have the tool enforce what we send to -next after -rc6
> > then it's going to have gaps.
> 
> I don't think either option can enforce correctness. The difference is that one
> approach relies on a timing promise about the tree state, while the other uses
> the tree state itself to make the decision.