On Tue, Nov 3, 2026 at 4:11 PM Danilo Krummrich <[email protected]> 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. :)
