On Tue, Nov 03, 2026 at 04:19:11PM -0500, Alex Deucher wrote: > 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.
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. :)
