LTS isn't dying — but the contract behind it is being renegotiated. A Qualcomm engineer asked the awkward question at Linux Plumbers this week, and here's my take.

This week, at the Linux Plumbers Conference in Prague, Qualcomm engineer Khem Raj stood up and asked a question most of the kernel world has been politely avoiding: does Linux Long Term Support still make sense in the era of generative AI?

The facts behind his question are hard to argue with. AI coding agents have turned the kernel's patch pipeline into a firehose. The volume of submissions — and bug reports — keeps climbing, and every one of those patches lands on the same small group of human maintainers who have to review them. Then it lands a second time, on a different group of people entirely: the distro vendors and LTS maintainers who backport the fixes into trees that are years old.

Raj's argument, as covered by Phoronix, is that rolling-release distributions look increasingly sensible in this world. Follow mainline closely and you get the fixes for free: less backporting, smaller divergence from upstream, faster security updates. The pain points he names are real — CI/CD queues, release management bottlenecks, the sheer human labor of re-applying a flood of patches onto an old tree.

He was honest about the other side, too: rolling release is a nightmare for certification and qualification. And he floated the idea that GenAI itself could help maintain LTS trees.

Good. Now let me tell you what I actually think.

I've run both kinds of systems for longer than I care to admit. LTS servers that hummed for five years without a surprise. Rolling systems that broke on a Tuesday because a maintainer fixed something nobody asked them to fix. Anyone who has held a pager knows the real currency here isn't novelty or stability — it's surprise. LTS is a contract that says: nothing will surprise you except the things we backport, and we backport only the things that matter.

The problem is that contract was written for a human-paced world.

Linus Torvalds himself has started calling the new patch baseline the "AI normal" — the steady stream of small error-path fixes and cleanups, much of it AI-assisted, is now just an ordinary part of a release cycle. That was the signal from the 7.3-rc6 cycle earlier this month, which I covered here: the flood isn't a spike, it's the weather.

And weather erodes everything, including the LTS model. Backporting was already the least glamorous job in Linux. Now it scales with a patch volume that no longer grows at the speed of humans. You can feel the strain at every layer: maintainers drowning in review queues, vendors choosing which floods to sandbag, CI systems melting under test matrices nobody had to run before.

So is Raj right? Should we all go rolling?

Not quite. Here's the part nobody at the conference wants to say out loud: rolling release doesn't eliminate the labor — it redistributes it. Every rolling user becomes a partial integrator, a partial tester, a partial triager of upstream's decisions. The work doesn't disappear; it gets smeared across a million desktops, and the cost shows up as your broken Tuesday.

Enterprises know this. Certification, qualification, reproducible environments, auditors with clipboards — none of those care about your patch velocity. For anything that carries money, patients, or aircraft, LTS isn't a preference, it's infrastructure. The awkward truth is that the people most enthusiastic about ending LTS are the people whose employers least need it to end.

So no — LTS is not dead. But the five-year frozen kernel, the sacred tree that barely moves, is an artifact of the human-paced era, and pretending otherwise is nostalgia.

What dies first isn't LTS. It's the assumption that LTS means frozen. The future of LTS is shorter windows, smarter triage, and yes — AI-assisted backport review, as Raj suggested, though let's be honest about who signs off. An AI can suggest a backport. A human still stakes their reputation on it. Nobody ever gets promoted because their AI suggested the right patch; people get blamed when the server goes down at 3 a.m. The signature on the maintenance contract is still a human one, and it will stay that way until someone volunteers their production cluster to test the alternative.

Here's my opinion, stated plainly: keep LTS for the servers, embrace rolling on the desktop where the cost of surprise is a fun debugging session, and stop treating "stable" as a synonym for "unchanged." Stability was never about the age of the code. It was always about the discipline of the people maintaining it. AI can write ten thousand patches a week. It cannot care about any of them. That part is still ours.

The firehose isn't going away. The question isn't whether LTS survives it — it's whether we finally admit that maintaining software was never the kernel's job. It was always the community's. And communities, unlike firehoses, run on human attention, which remains the scarcest resource in all of computing.

Sources