On Wed, 04 Nov 2026, Dave Airlie <[email protected]> wrote: > On Wed, 4 Nov 2026 at 12:37, Rodrigo Vivi <[email protected]> wrote: >> This is the part that I disagree most. In my proposal, maintainers need to do >> absolutely nothing. The freezing is already guaranteed by our rules. > > 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. > > If we can't have the tool enforce what we send to -next after -rc6 > then it's going to have gaps.
Taking a few steps back for perspective. We already have a branch that's guaranteed to only have stuff for next, and never contains anything for "next next". It's drm-next. What if we decided to *not* include every driver tree separately in linux-next? Ditto for fixes. Let's just make drm-for-linux-next be drm-next + drm-fixes? Our shared rerere should handle the conflicts there. The cutoff problem goes away completely. The main downside is the delay between merging in a driver tree and hitting linux-next. But we could also decide to mandate more regular pull request to drm-next, maybe weekly, especially for the drivers with more traffic. This will mean lots more pull requests, but it's really not a bad thing to keep them smaller. BR, Jani. -- Jani Nikula, Intel
