Linux 7.2 and the New Normal: The Largest Merge Window Ever Counted
Torvalds' first words on the busiest week of the release, on 9 August 2026, were not "we shipped it." They were: it's fine, "nothing looks particularly scary per se, it's just that there's a lot here" [1]. A lot of what, exactly, was more than four hundred fixes from over two hundred and thirty contributors in a single release candidate, a volume he attributed to something specific: review by AI tools that now read kernel code continuously and surface bugs that human reviewers had missed or deprioritised, some for years [1] [3]. He had a phrase for it. "The new normal" [1].
He used the same two words again a week later, on 16 August 2026, when Linux 7.2 actually shipped: "this last week of the release was, once again, bigger than I would have wished for, but hey, with the whole 'new normal' thing, if I delayed releases for that reason we'd probably never have a release at all" [1] [4]. Two separate statements, seven days apart, about two related but distinct things: the volume of AI-flagged review work on 9 August, and the size and lateness of the release itself on 16 August. Between them, LWN's Jonathan Corbet counted what those words actually added up to. The 7.2 merge window pulled in contributions from 2,138 people, almost certainly a record. Four hundred and four of them had never had a patch merged before. Thirteen thousand, four hundred and twelve non-merge commits landed inside that window alone, the busiest since the 6.7 cycle closed in late 2023 [2].
Eric Raymond's founding claim about open-source development, the one this series has organised itself around since its second episode, is that enough eyes make any bug shallow. It was always a claim about people: put enough of them on the same code and the failures surface faster than any single reviewer, however good, could manage alone. Nobody proposed to test that claim at the scale it just got tested at. Two thousand, one hundred and thirty-eight contributors in one merge window is not a research project or a foundation-funded push. It is what happened when a kernel that has been open for review since 1991 kept absorbing whoever showed up, and in August 2026, a record number of people showed up.
What makes this cycle different from every prior record is not the headcount. It is who, or what, is doing an increasing share of the looking. LWN's own numbers put it precisely: seven hundred and six commits in the 7.2 merge window, about five per cent of the total, carried an "Assisted-by" tag disclosing that an AI tool had a hand in the patch [2]. That tag is opt-in and self-reported, not a total measure of AI involvement in the release, a distinction worth holding onto rather than letting five per cent read as a hard ceiling. This series covered the tag's creation in Episode 22, while Linux 7.2 was still in development and the kernel's first formal AI-contribution policy was just taking shape. This episode is the first full cycle under that policy, and the number it produced is the first real answer to the question Episode 22 could only pose.
It matters which "new normal" is in play at each point, because Torvalds used the phrase for two different things and it is easy to collapse them into one undifferentiated claim that neither statement, read on its own, actually supports. The 9 August statement is about review volume: AI tools are now finding things in kernel code that used to sit unaddressed, and the resulting stream of fixes has to be merged even in the closing days of a release candidate cycle, because the alternative is shipping known problems. The 16 August statement is about the release itself: the size and timing pressure that review volume creates, and the decision to ship anyway rather than chase an ever-receding point where everything looks tidy. The first "new normal" produces work. The second is what it feels like to be the person who has to close it out on a schedule.
Neither statement is a verdict on whether AI-assisted review is good or bad for the kernel. Torvalds' own words are descriptive, closer to resigned than triumphant: "if I delayed releases for that reason we'd probably never have a release at all" is a statement about a workload that will not go away, not an endorsement of the tooling that surfaced it [1]. The honest reading is narrower than the headline version of this story: something changed in how much gets found, and the person at the top of the review chain has stopped treating the resulting volume as a spike to be pushed through and has started treating it as the baseline he now works against.
The same release that set an AI-assisted contribution record also closed out something that had nothing to do with AI at all. After roughly six years of patient, mostly manual work, Linux 7.2 removed strncpy(), a decades-old string function responsible for a long tail of buffer-handling bugs, along with its per-architecture optimised variants. The completed effort spans three hundred and sixty-two commits from seventy contributors. One of them, Google engineer Justin Stitt, is reported to have authored well over half of those commits himself, with Kees Cook, who leads the Kernel Self Protection Project, coordinating the wider effort and closing out the final instances [5]. Nobody's AI tool flagged this as a six-year project. It got finished because a small number of named people kept at it long after it stopped being interesting.
I have spent a fair share of a thirty-year career on exactly this kind of work: the remediation project with no dramatic launch date, the incremental clean-up that quietly finishes while everyone's attention is on something flashier, across architecture and security programmes in government, banking, transport and aviation here in New Zealand. The instinct in any large technical organisation is to reward the visible fix over the patient one. Linux 7.2 shipped both in the same release, and the contrast is the more honest picture of what actually keeps a system like this trustworthy over time: not a single mode of contribution, human or AI-assisted, but both running at once, on different clocks.
A second, smaller thread from the same cycle makes a related point about who does the unglamorous work and why it matters. A patch series from IBM's Jan Polensky finally wired up Rust support for the s390 mainframe architecture, closing a tracking issue that had sat open for five years. Rust-for-Linux maintainer Miguel Ojeda's review reply captured it in twelve words: "IBM getting involved and being able to close a 5 year issue!" [6]. Elsewhere in the same window, the kernel picked up a rewritten memory-reclaim path showing close to a thirty per cent throughput gain on database-style workloads, a swap-handling rework that trims hundreds of megabytes of overhead per terabyte of swap, and, most relevant to where this article ends up, a build system that now generates a software bill of materials directly, through the SPDX integration, alongside everything else that landed this cycle [7].
Read next to this series' Episode 25 coverage of maintainer burnout, and the Nixpkgs Core Team's disbandment earlier this year, the record contributor count sits less comfortably than it first appears. A kernel that has never had more eyes on it and a maintainer community that several unrelated open-source projects have separately named as running short on capacity are, on the numbers, moving in opposite directions at the same time. More people are submitting. It is not obvious the number of people positioned to actually review and merge what they submit is growing at anything like the same rate, AI-assisted or not. Torvalds' own description of the workload as a permanent baseline rather than a spike is one data point in that direction, from the person for whom it is least possible to look away from the question.
The free-software community's own quality-control layer is still keeping pace, at least for now. FSF Latin America shipped GNU Linux-libre 7.2-gnu, the fully-free variant used by distributions such as Trisquel and Parabola, one day after the mainline release, stripping proprietary firmware blobs from AMD, Qualcomm, Intel and MediaTek drivers among others [9]. A volunteer project reviewed and re-cut a kernel that had, in the same week, absorbed contributions from over two thousand people and multiple hardware vendors, and did it within twenty-four hours. Scale solved one problem this cycle. Whether it solved, or simply postponed, the maintainer-capacity problem sitting underneath it is not something this release settles either way.
Every reader who has ever had sign-off authority over something they could not personally check line by line will recognise the shape of Torvalds' problem, even if the scale is different. There is a point in any review function, security, audit, architecture assurance, where the volume of what needs checking crosses from "busy period, push through it" into "this is simply what the job is now." I have sat in that seat across several of the programmes I have worked on over three decades, and the practical change is never really about working faster. It is about accepting that the system has to be trusted at a layer you cannot personally verify: subsystem maintainers, review chains, automated checks, each doing a piece nobody above them re-does from scratch. That only works if the layers below are actually trustworthy, which is a different and harder claim than "busy."
The strncpy() removal is the other half of the same lesson, and it is worth sitting with rather than resolving too neatly. Six years and three hundred and sixty-two commits from seventy people is not a story about speed. It is a story about a small number of people who kept doing unglamorous, correct work long after any dashboard would have flagged it as done. A review process built entirely around volume, however well the volume is triaged, will always undervalue that kind of contribution, because it does not produce a spike anyone notices. The most resilient systems I have seen, in software and outside it, have kept a place for both modes of work, not chosen one over the other.
None of this resolves inside a single release cycle, and the next one will say more than this one can. If the Assisted-by tag's roughly five per cent share climbs again at 7.3, that becomes a genuine trend line rather than a single data point, the first one this series will have been able to track release over release. If the maintainer-capacity question Episode 25 raised sharpens rather than eases, the record contributor count in this cycle will look less like a triumph and more like the moment the strain became visible in the numbers rather than only in Torvalds' own words. Both readings are available from where this release leaves things. Neither is settled yet.
Executive Takeaway
- 2,138 contributors, a merge-window record; 404 of them first-time
- 706 commits, about 5%, carried an Assisted-by tag; opt-in, not a total AI-involvement measure
- A six-year, 362-commit manual fix landed in the same release as the AI-assisted record
- Contributor growth and maintainer capacity are not obviously moving together
Linux 7.2's build system gained something easy to miss next to the merge-window record: a software bill of materials, generated directly through SPDX, listing precisely what went into the build. It is not decorative. From 11 September 2026, Article 14 of the European Union's Cyber Resilience Act requires manufacturers selling digital products into the EU to report actively exploited vulnerabilities within twenty-four hours of becoming aware, with fuller notification at seventy-two hours and a root-cause report at fourteen days, reaching back to legacy products still on the market. A Linux-based device shipped years ago and never touched since will need a working answer to exactly the question the kernel's own new SBOM tooling now exists to answer: what is actually inside the software you shipped. The Bazaar's transparency was always a philosophical claim about who gets to look. From next month, in one jurisdiction, it is also a compliance requirement.
That question of who can see inside a distributed, publicly reviewable codebase is not confined to compliance deadlines. Defence and field-operations planners have lived with this longer than this kernel cycle has existed. A kernel absorbing contributions from 2,138 people in one window, with a growing share of the review automated, is also the operating system underneath drones, satellite ground segments and field communications equipment that rarely see a vendor's formal patch cycle. Reported Ukrainian battlefield use of Linux-based systems, adapted by operators outside any conventional release schedule, is the sharpest version of this episode's own question about who reviews code and how quickly: a distributed, partly automated review layer means trusting a process rather than a person, the condition military logistics has run under for years already. Torvalds' new normal is a civilian project catching up to a problem defence planners never had the luxury of calling new.
When did work you did, or oversaw, stop being something you could personally check line by line, and start being something you could only trust the process to have checked for you? Looking back, was that the moment it got better, or the moment it got harder to notice when something had gone wrong?
This is one of seven weekly series in The Hamberger Report. Subscribe on LinkedIn and the next one arrives in your feed.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. I write as director of Te Pono Limited; the views are personal and do not represent the position of any client, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance, and it is politically neutral.
About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." He can be reached at andreas@thehambergerreport.com. A Concise History of Linux chronicles the operating system that changed the world and the lessons it holds for the AI era.
This article was produced with AI assistance under my direction. Research, drafting and images pass through a pipeline I built and govern: automated gates for source verification, forbidden language and political neutrality, and my own review before anything is published. The tools include Claude, Gemini and Openart. The frameworks, arguments and editorial judgements are mine and are the same discipline I apply to the AI systems I audit for clients. AI accelerated the work; the thinking, and the responsibility for it, are mine.
[1] Jonathan Corbet. "The 7.2 kernel has been released." LWN.net. 16-17 August 2026. https://lwn.net/Articles/1088991/
[2] Jonathan Corbet. "The rest of the 7.2 merge window." LWN.net. June 2026. https://lwn.net/Articles/1078539/
[3] "Linus Torvalds says AI has made 'huge' Linux kernel updates the new normal." The Register. 10 August 2026. https://www.theregister.com/os-platforms/2026/08/10/linus-torvalds-says-ai-has-made-huge-linux-kernel-updates-the-new-normal/5285268
[4] "Linux 7.2 debuts, Linus Torvalds says 'new normal' means he had to do it now, or never." The Register. 17 August 2026. https://www.theregister.com/os-platforms/2026/08/17/linux-72-debuts-linus-torvalds-says-new-normal-means-he-had-to-do-it-now-or-never/5288250
[5] "Linux 7.2 Officially Released: Cache Aware Scheduling and the End of strncpy()." vmlinuz.pl. August 2026. https://vmlinuz.pl/en/posts/linux-7.2/
[6] Miguel Ojeda. Review reply on the s390 Rust-support patch series. Linux Kernel Mailing List, mirrored at lkml.iu.edu. 12 May 2026. https://lkml.iu.edu/2605.1/07684.html
[7] kernelnewbies.org. "Linux_7.2" wiki page. August 2026. https://kernelnewbies.org/Linux_7.2
[8] HeroDevs. "CRA Reporting Obligations Start September 2026: What EOL Dependencies Mean for Your Compliance." https://www.herodevs.com/blog-posts/cra-reporting-obligations-start-september-2026-what-eol-dependencies-mean-for-your-compliance
[9] Phoronix; 9to5Linux; Tux Machines. Coverage of the GNU Linux-libre 7.2-gnu release, FSF Latin America, 17 August 2026. No single primary URL independently captured this session; date and attribution consistent across all located outlets.
[10] "Linux MGLRU Improvements Net A 30% Increase For MongoDB, More Than 100% On HDDs." Phoronix. https://www.phoronix.com/news/Linux-MGLRU-30p-MongoDB