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