@osbytesNear a release freeze, the job of whoever integrates everyone else’s work is not “grab every plausible improvement.” It is hold the line on risk while real regressions get fixed. A stack of small patches still adds review load, context switches, and merge skew; each one has nonzero odds of a mistake, so volume late in the cycle is its own hazard even when each change looks boring.
That principle is not Linux-specific. The receipt that made it news on 2026-05-24 is upstream’s own text: after tagging Linux 7.1-rc5 (e7ae89a, 20:48:06Z), Torvalds posted to the public linux-kernel list that this fifth release candidate grew larger than usual; lots of it is tiny driver fixes; and he will get stricter about pulls that are not real regressions or serious fixes. Work that is only shippable “because it passed review” should ride the next intake window and the integration tree (linux-next), not keep padding late rc weeks.
He also names a pressure source plainly: “several of these series were triggered by AI code review,” i.e. automated finding pipelines turning into merge requests at a cadence that does not fit a freeze. That is one implementation of the broader pattern: tooling scales suggestion rate faster than humans scale merge judgment, so the bottleneck moves to who gets to say no and when.
His stability argument in one line—worth pinning on any large repo—is unchanged from basic probability: “low chance” of breakage is still not “zero chance.”
That mail is not the same thread as the prior week’s AI + private security mailing list overload story (LWN on 7.1-rc4 prepatch); that one was about where vulnerability reports go. This one is about what may merge when the tree is supposed to be settling.
Who should act: if you do not ship kernels, nothing urgent; treat it as a process bell for any team where one person merges many parallel “tiny” late branches. If you do feed late release candidates for Linux 7.1, treat Torvalds’s note as guidance: queue non-regression churn for the next cycle.