Linux 7.2 and the 'New Normal': Keep the Date, Make Reverts Cheap

Linus Torvalds released Linux 7.2 on Sunday, August 16, on schedule. The feature list is solid, but the part I keep coming back to is the announcement itself. The final week was bigger than he wanted, again, and he shipped anyway with several late reverts. His reasoning: under what he now calls the "new normal" of heavy patch volume, delaying a release over a big week would mean probably never releasing at all. The kernel is showing how a project at that scale copes with AI-driven change volume, and the answer is release discipline, not heroics.

What shipped#

Between Phoronix and The Register's release coverage, the highlights are:

• Cache Aware Scheduling, which makes the kernel better at using data already sitting in caches on manycore chips such as AMD EPYC 5 and Intel Xeon 6.
• The Intel-developed USB4STREAM protocol, AMDGPU HDMI 2.1 FRL, and more Intel and AMD driver work.
• I/O performance improvements on both AMD and Intel systems, faster poll performance, and Intel Arc B390 graphics gains.
• Work that makes it possible to run Linux on Apple M3 devices.
• Dropped support for AppleTalk, and for old ISA and PCMCIA adapters used on ARCNet networks.

Phoronix says 7.2 will power Ubuntu 26.10 and other upcoming distributions. The Register also noted a week earlier that 7.2 is not a long-term support release, so most of us will meet it through a distribution kernel.

Where the "new normal" comes from#

The phrase predates the release. On August 2, Torvalds said rc6 was big even by "new normal" standards, and probably the biggest rc6 in years, at least by commit count. A week later, announcing rc7, he said he was not thrilled about the size and put it down to the new normal: a lot of fixes, many of them coming from review by various AI tools, according to The Register's rc7 report. The same report notes he has previously complained that the kernel security mailing list had become almost unmanageable because of AI-generated bug reports, many of them duplicates, while also saying Linux is not an anti-AI project.

So the load has two shapes at once: more contributions from developers using AI coding tools, and more fixes prompted by AI review of existing code. I run several coding agents in parallel every day, and the effect is familiar at a much smaller scale. Writing code stops being the bottleneck. Deciding what is ready to merge becomes the bottleneck.

Ship the date, revert what isn't ready#

Two decisions in the 7.2 announcement are worth copying.

First, the date held. Torvalds was blunt that if a heavy week were grounds for delay, "we'd probably never have a release at all." A time-based release only works if volume cannot move it. Scope moves instead.

Second, late reverts are treated as a normal tool. The most visible one this cycle: the DRM scheduler had moved to a new "fair" default, that caused a regression, and it went back to FIFO in the final week. Torvalds said reverting may not be pretty but is the correct way to handle code that turned out not to be ready, and that people will try again later. A revert is not a verdict on the idea. It just takes the change out of this release.

That approach only works when reverting is cheap. In a lot of product repos it is not, because one merge carries a refactor, a behavior change and a dependency bump together.

What I'd change in a team repo#

With agent-written PRs piling up, this is what I would bring to Monday planning:

• One PR, one revertable unit. Squash-merge, keep agent PRs small and single-purpose, and do not let an agent bundle a refactor with a behavior change. If a revert touches five unrelated things, nobody will do it under pressure.
• Write the revert rule down. During the stabilization window, a regression gets reverted first and re-landed later with a fix. No debate about whether it is almost fixed.
• Treat changed defaults as the riskiest late change. The DRM revert was a new default. Put new defaults behind a flag so rolling back is a config change, not a code change.
• Deduplicate machine-found bugs before humans see them. If AI review tools file issues, require a reproduction or a failing test, and cluster duplicates before triage. The kernel security list is the warning.
• Keep a merge deadline. Torvalds said he already had 40 pending pull requests for the 7.3 merge window and thanked the people who sent theirs on time. A cutoff that humans and agents both respect is what lets the date stay fixed.

My take#

The interesting part of Linux 7.2 is not that AI increased volume. It is that the kernel did not respond by slowing down, or by trusting the volume more. It kept the calendar and made reverting routine. That is close to the idea behind Quorate, the review CLI I maintain: agent output has to pass deterministic gates before it lands, and a FAIL is a FAIL, not a discussion. What I am adding to my own checklist from this release is the revert rule. In a busy week, taking a change out of the release has to be cheaper than fixing it in place.