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