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