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