An additional quote

The big lie about backports is that a backport is somehow not a new version that is also untested and might also introduce new bugs.

I know that's tongue-in-cheek kind of thing but backported kernels are not the panacea stability-wise (compared to LTS or even normal kernels).

Plus, and that's the whole point, pulling a google and updating the kernel once in a bluemoon, using "critical" CVEs as an indicator for backports and most ARM boards not even doing that and giving you the finger are not practices that should be condoned. This kind of backporting gives you an illusion of stability and security (it does improve ABI stability a fair bit but at the expense of other things).

I know the term has lost quite a fair bit of meaning but I'd argue the whole point of devop-ing is precisely developing ways to perform updates (and rollbacks) that are the most seamless so that your systems are always up and if something had to be rolled-back, gives you and your team the time to sort it out.

If you do so often, it's only little bits and bobs you need to fix here and there. If you don't and use Ubuntu LTS, it's a full migration, with many arguments, tears and pain every time you switch to a new LTS.

The debian model is catered towards sysadmins who install everything by hand once and generally would be in it very deep if any of their servers actually fell because of hardware or because config became invalid after an update.

If kernel updates are all that is possible to really get a secure one (because backports require too much work), the Linux ecosystem will evolve. Debian, for instance, will probably track LTS kernels instead but will also ask the kerbel dev to be much more methodic with how changes are made and documented.

The kernel devs' point is that CVEs are rubbish. A lot of them being redundant or not real and a lot of them downplaying the impact they have on the system. My current understanding is that backporting doesn't scale well. But we'll see how it pans out. In the meantime, if an "unfortunate" kernel upgrade has large business impact, try to think and implement ways to negate that impact. We are mostly using on-prem resources here and yet I can redeploy bare-metal servers as I wish and most our OSes provided automatic rollback should anything go wrong. That's the way to go, instead of complaining an update, any update, broke something in prod.

Anyone who cares about that should run production canaries and do actual regression testing. Yes, the Linux kernel testing strategy is lacking, but why put the onus on the project to do what *you* care about ? Anyone can build and test for regressions. And even do that in advance for the -rc versions (stable or upstream), so that when the release comes, you already know if it's breaking anything.