On Thu Nov 5, 2026 at 10:52 PM CET, Rodrigo Vivi wrote: > On Wed, Nov 04, 2026 at 11:35:10PM +0100, Danilo Krummrich wrote: >> On Wed Nov 4, 2026 at 6:44 PM CET, Rodrigo Vivi wrote: >> > 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. >> >> 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). > > 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.
Of course one still wants to send the final PR somewhen around -rc5/-rc6, but there's no exact point of time where the corresponding tree management has to be done in order for the correct thing to happen for linux-next. I don't agree that the the update of -next-fixes is fragile. It has to be fast forwarded to -next anyway with the cutoff, as otherwise people can't apply fixes for what's staged for the merge window anymore. If we'd cut off but not update -next-fixes accordingly, it's an invitation for committers to keep pushing to -next kicking of the cherry-picks. I also think this works very well for drm-misc (and drm-rust). >> 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. > > I really fail to see how this is a issue... Because it means less exposure to linux-next overall and less exposure where it actually matters, at the end of the cycle. It also means that if something breaks in linux-next during this period the only way to fix it is to 1. send another -next PR, 2. wait until the tree closes and push the fix to -next-fixes, 3. close the tree immediately and push the fix to -next-fixes. > 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. Sure, I'm happy to look into this. >> >> (2) Require each tree's transition to following-cycle work to coincide with >> the global cutoff, in *addition* to managing its branches correctly. >> >> >> 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. >>
