Linux 7.4 has the biggest merge window ever, and AI is behind much of it

Linux is built in cycles. Each cycle starts with a merge window, a stretch of about two weeks when Torvalds accepts big batches of new work.

The people who look after each area of the kernel, like graphics or file storage, send him their finished changes. Each change is called a commit, a saved edit with a short note about what it does.

When the window closes, Torvalds publishes a first test version called rc1, short for release candidate. After that, only fixes are supposed to come in.

Phoronix counted 19,671 commits since Linux 7.3 as it wrote on Sunday. It called this the busiest merge window on record by commit count.

Phoronix also looked back at windows since Linux 3.1, released in 2011. Typically they held 13,000 to 14,000 commits or fewer. Now they are pushing 20,000.

• Commits: 19,671 since Linux 7.3, with a few more possible before rc1.
• Source tree size: 41,605,120 lines, according to Phoronix.
• Code: 31,417,938 lines, plus 4,993,604 lines of comments and 5,193,578 blank lines.
• Added in this window: nearly half a million lines of code, ignoring comments and blank lines.

By the numbers: Linux 7.3 was the first time a whole cycle passed 20,000 commits, with 20,260 from v7.2 to v7.3. Linux 7.4 reached almost that many in the merge window alone.

Phoronix says the kernel's pace has been climbing for about a year. Linux is popular, from consumer devices to giant data centers. But it says a lot of the extra patches are due to AI and LLM tools.

An LLM, or large language model, is the kind of AI behind chatbots. Here it reads code and looks for mistakes.

Phoronix writes that kernel maintainers are "completely overwhelmed" by both AI generated bug reports and AI generated patches and fixes. Much of the AI activity is around fixes, so the flood does not stop when the merge window ends.

In real life Imagine a school with one teacher grading homework. Suddenly every student has a helper that finds mistakes in everyone's essays. The teacher gets far more corrections to read, and each one still needs a human decision.

Slashdot quotes Torvalds' weekly state-of-the-kernel update. He described this release as "Large, and full of fixes for issues found by AI."

He added that more and more patches have been suggested by AI too, "although they often get rewritten." That means a person usually reworks the suggestion before it goes in.

Torvalds also gave a second reason. "People are expecting 7.4 to be the next long-term support release," he wrote.

He called that "another independent reason why some releases tend larger than others." His conclusion: "So it may not just be the flood of AI patches."

Most kernel versions are supported for a short time. A long-term support (LTS) release is picked to get fixes for years.

Phone makers, server companies and device builders lean on those versions. So developers have a reason to get their work in before the version is locked in.

That is why Torvalds says the AI flood may not be the whole story. Both things can be true at once: more machine-found fixes, and more people rushing to land work in a version that will stick around.

It has been building for months. In August, TechRadar reported that Torvalds called the Linux 7.2-rc7 test build part of a "new normal" of oversized release candidates, with many fixes coming from reviews by various AI tools.

TechRadar counted more than 400 fixes from upwards of 230 contributors in that single pull. That is a size you would expect early in a cycle, not near the end.

The kernel has also been working out its rules for AI help. We covered how maintainers moved to drop the Assisted-by tag that asked contributors to disclose AI help in their patches.

The big picture: TechRadar draws a line between AI that reviews code and AI that writes it. The tools in that story were review agents that produce bug reports. Humans then write the fixes and send them through the normal process.

Linux 7.4 follows a Linux 7.3 cycle that already ran hot. The Next Web counted 615 commits from 292 contributors in the 7.3-rc2 announcement alone. An rc2 is normally the quiet week.

Torvalds joked about it in that post. "It might be just random," he wrote, "but we'll obviously all blame it on AI, because whether that's really the cause or not, it's an easy thing to blame."

He then noted that nothing looked particularly odd. The joke came instead of a diagnosis, and a month later the record merge window arrived.

The catch: the numbers show a bigger flow, not a cause. Commit counts cannot say how much came from AI tools and how much from the long-term support rush. That is why Torvalds himself says it may not just be the flood of AI patches.

The kernel runs on a trust chain. A few trusted maintainers read and test code before it reaches Torvalds, who pulls it into the main tree.

TechRadar notes the risk in that model: a few people may not want an AI-powered firehose of fixes to review forever. Phoronix uses the word "overwhelmed" for the same pressure.

Torvalds has not asked anyone to slow down. In the rc7 post he said nothing looked particularly scary, and the fixes were spread across drivers, filesystems, core networking and architecture code, as TechRadar reports.

Phoronix said Linux 7.4-rc1 was expected later on Sunday, once the last commits trickled in. After rc1, the kernel normally goes through a series of weekly test builds.

The sources do not give a final release date. They also do not say how Torvalds and the maintainers plan to handle a flow of patches this size.

What's next: the rc builds will show whether the bug fixes flowing in now make the final release calmer. The open question is how long volunteers and company engineers can keep reading a firehose of changes.

• If you use Linux: more fixes landing early is generally good news, though you will not notice it day to day. Your distribution decides when 7.4 reaches you.
• If you write code: AI review is turning into a normal part of big projects. The human still has to read, rewrite and take responsibility.
• If you run a team or project: plan for review capacity. Finding bugs is getting cheaper; deciding what to merge is not.