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

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.

Quoted 6 lines

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?

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.

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.

Quoted 4 lines · Rodrigo Vivi

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.

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.

Quoted 3 lines

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?

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.

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.

Quoted 2 lines · Dave Airlie

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.

Quoted 4 lines

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

Quoted 3 lines

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.

Quoted 2 lines · Danilo Krummrich

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.

Quoted 3 lines

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.

Quoted 8 lines

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.

Quoted 1 line

Quoted 3 lines

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

Quoted 7 lines · Rodrigo Vivi

Quoted 2 lines · Danilo Krummrich

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.

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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

Quoted 10 lines

Quoted 3 lines

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.

Quoted 18 lines

Quoted 8 lines

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.

Quoted 1 line

Quoted 6 lines

Quoted 3 lines

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?

Quoted 2 lines

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

Quoted 13 lines · Danilo Krummrich

Quoted 7 lines · Rodrigo Vivi

Quoted 2 lines · Danilo Krummrich

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

Quoted 3 lines

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

Quoted 77 lines

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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

Quoted 10 lines

Quoted 3 lines

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.

Quoted 18 lines

Quoted 8 lines

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.

Quoted 1 line

Quoted 6 lines

Quoted 3 lines

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?

Quoted 2 lines

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

Quoted 14 lines · Alex Deucher

Quoted 13 lines · Danilo Krummrich

Quoted 7 lines · Rodrigo Vivi

Quoted 2 lines · Danilo Krummrich

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

Quoted 7 lines

Quoted 3 lines

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.

Quoted 28 lines · Rodrigo Vivi

Quoted 14 lines · Alex Deucher

Quoted 13 lines · Danilo Krummrich

Quoted 7 lines · Rodrigo Vivi

Quoted 2 lines · Danilo Krummrich

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

Quoted 7 lines

Quoted 3 lines

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.

Quoted 10 lines

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.

Quoted 40 lines · Danilo Krummrich

Quoted 28 lines · Rodrigo Vivi

Quoted 14 lines · Alex Deucher

Quoted 13 lines · Danilo Krummrich

Quoted 7 lines · Rodrigo Vivi

Quoted 2 lines · Danilo Krummrich

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

Quoted 7 lines

Quoted 3 lines

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.

Quoted 10 lines

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.

Quoted 1 line

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.

Quoted 11 lines

      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.

Quoted 5 lines

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.

Quoted 3 lines · Dave Airlie

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.

Quoted 2 lines

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.

Quoted 5 lines · Danilo Krummrich

Quoted 3 lines · Dave Airlie

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.

Quoted 8 lines

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.

Quoted 16 lines

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.

Quoted 2 lines

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.

Quoted 15 lines · Rodrigo Vivi

Quoted 5 lines · Danilo Krummrich

Quoted 3 lines · Dave Airlie

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.

Quoted 8 lines

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.

Quoted 6 lines

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.

It doesn't change the fundamental problem if we define the global cutoff sooner or later.

To preserve both properties, each tree's transition would have to coincide with the global cutoff., otherwise it can happen that either stuff leaks into linux-next that doesn't belong there (tree state updated before cutoff), or you're not getting linux-next exposure in the first place (tree state updated after cutoff).

Making the cutoff day sooner makes it much more unlikely to leak stuff into linux-next, as closing a tree before -rc5 would be pretty odd.

But that trades the leakage risk for patches added after -rc5 losing linux-next exposure until they reach drm-next. That may be preferable, but it still loses intended linux-next coverage.

In a normal cycle this would mean that trees collect up to a full week of patches without them seeing linux-next, which is a concern for me as well.

More generally it remains that correctness is based on a timing promise about the tree state rather than the tree state itself (which is the actual source of truth).

I don't see why we would want to make this kind of compromise where we prevent intended linux-next exposure for up to a week, while the existing per-tree selection logic in dim we have today can preserve both properties:
following-cycle work stays out of linux-next, and work for the upcoming merge window gets linux-next exposure before entering drm-next.

To me a fixed global cutoff in tip comes down to either one of the two:

(1) Make a compromise where e.g. patches that belong in linux-next get up to a week delayed exposure.

(2) Require each tree's transition to following-cycle work to coincide with the global cutoff, in *addition* to managing its branches correctly.

Quoted 16 lines

Quoted 16 lines

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.

Quoted 2 lines

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.

Quoted 42 lines · Danilo Krummrich

Quoted 15 lines · Rodrigo Vivi

Quoted 5 lines · Danilo Krummrich

Quoted 3 lines · Dave Airlie

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.

Quoted 8 lines

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.

Quoted 6 lines

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.

It doesn't change the fundamental problem if we define the global cutoff sooner or later.

To preserve both properties, each tree's transition would have to coincide with the global cutoff., otherwise it can happen that either stuff leaks into linux-next that doesn't belong there (tree state updated before cutoff), or you're not getting linux-next exposure in the first place (tree state updated after cutoff).

Making the cutoff day sooner makes it much more unlikely to leak stuff into linux-next, as closing a tree before -rc5 would be pretty odd.

But that trades the leakage risk for patches added after -rc5 losing linux-next exposure until they reach drm-next. That may be preferable, but it still loses intended linux-next coverage.

In a normal cycle this would mean that trees collect up to a full week of patches without them seeing linux-next, which is a concern for me as well.

Quoted 3 lines

More generally it remains that correctness is based on a timing promise about the tree state rather than the tree state itself (which is the actual source of truth).

The current way is already a 'timing promise'. Multiple promises in a matter of fact. promise that you will send the PR around -rc5, -rc6 anyway + promise that you will update your -next-fixes so the current fragile blackout check works.

Quoted 6 lines

I don't see why we would want to make this kind of compromise where we prevent intended linux-next exposure for up to a week, while the existing per-tree selection logic in dim we have today can preserve both properties:
following-cycle work stays out of linux-next, and work for the upcoming merge window gets linux-next exposure before entering drm-next.

Quoted 4 lines

To me a fixed global cutoff in tip comes down to either one of the two:

(1) Make a compromise where e.g. patches that belong in linux-next get up to a week delayed exposure.

I really fail to see how this is a issue...

But anyway, as I told, please provide the patches to dim for the unified tree with a more reliable way to guarantee our promises and let's take from there.

Quoted 21 lines

(2) Require each tree's transition to following-cycle work to coincide with the global cutoff, in *addition* to managing its branches correctly.

Quoted 16 lines

Quoted 16 lines

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.

Quoted 2 lines

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.

Quoted 2 lines · Rodrigo Vivi

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.

The main downside is the delay between merging in a driver tree and hitting linux-next. But we could also decide to mandate more regular pull request to drm-next, maybe weekly, especially for the drivers with more traffic. This will mean lots more pull requests, but it's really not a bad thing to keep them smaller.

Quoted 5 lines · Jani Nikula

The main downside is the delay between merging in a driver tree and hitting linux-next. But we could also decide to mandate more regular pull request to drm-next, maybe weekly, especially for the drivers with more traffic. This will mean lots more pull requests, but it's really not a bad thing to keep them smaller.

I was already concerned about losing up to a week's linux-next exposure with the proposed global cutoff at -rc5 [1]. This approach would extend that delay throughout the cycle.

Even with weekly PRs, changes could wait up to a week before reaching linux-next. They would also only get that exposure after being merged into drm-next, whereas I'd like them to receive linux-next testing before that merge.

I don't think that such a compromise is acceptable: If a tree breaks linux-next it would mean that linux-next is broken until the next PR hits drm-next (and not only until it is fixed in the tree causing the issue).

I don't want to sound like a broken record (sorry if I already do :), but I still think the

	git merge-base --is-ancestor $remote/$linux_next_fixes $remote/$linux_fixes

switch we already have in dim seems like the best fit. It already does exactly what we (and linux-next) need and is accurate: it preserves direct linux-next coverage and bases the selection on the actual tree state. And with the proposed git request-pull --final option it is very maintainer friendly.

[1] https://lore.kernel.org/all/[email protected]/

The reason we have dim in the first place is to make us do stuff the same way, every time, and not forget stuff. When we screwed up, we addressed it in dim to not screw up again.

Anyway, how about just *prompting* "Is this expected to be the final pull request for the development cycle?", and if yes, update drm-*-next-fixes while at it, and have the automation handle the rest.

Quoted 7 lines · Rodrigo Vivi

Quoted 2 lines · Danilo Krummrich

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.

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 3 lines

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

Quoted 10 lines

Quoted 3 lines

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.

Quoted 18 lines

Quoted 8 lines

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.

Quoted 1 line

Quoted 6 lines

Quoted 3 lines

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?

Quoted 3 lines

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

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

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

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.

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

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 <[email protected]>

---
 dim | 53 -----------------------------------------------------
 1 file changed, 53 deletions(-)

dim +0 -53

index e3f616b..b3ed8f7 100755
@@ -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
 }
 

Quoted 46 lines · 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

Quoted 4 lines

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

Quoted 91 lines

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 <[email protected]>

---
 dim | 53 -----------------------------------------------------
 1 file changed, 53 deletions(-)

dim +0 -53

index e3f616b..b3ed8f7 100755
@@ -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
 }
 

Quoted 47 lines · Alex Deucher

Quoted 46 lines · 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

Quoted 7 lines

Quoted 4 lines

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.

Quoted 94 lines

Alex

Quoted 91 lines

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 <[email protected]>

---
 dim | 53 -----------------------------------------------------
 1 file changed, 53 deletions(-)

dim +0 -53

index e3f616b..b3ed8f7 100755
@@ -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
 }
 

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

Quoted 9 lines · Rodrigo Vivi

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.

Quoted 2 lines

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?

Quoted 15 lines · Rodrigo Vivi

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)

Quoted 5 lines

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/