The treadmill is real

It's a bit nuts, but it's not like the devs have a whole lot of options when there are significant vulnerabilities being published so regularly . . .

At my day job we're looking at defining a policy that's pretty much "all systems must be running the latest kernel no more than X weeks after a new release is available" (with X varying depending on the type of node, its exposure, the impacts/risks of rebooting, etc) - so the clock starts when the first new release comes out, the upgrade targets whatever the latest release is when time runs out (with some allowance for testing and validation), and the clock stops when all systems have rebooted into the new kernel. The only exceptions would be if a new vulnerability that specifically impacts us, in which case we'd pull forward the next deadline for the impacted systems being up to date. No arguments about whether each new kernel is worth bothering with, no debates about every single CVE, no pushing things back because rebooting everything is too hard - we decided we needed to track an LTS branch for good reasons and this is what that means in practise.

It's not wonderful - it means a significant amount of churn that takes time from more productive work - but it's hard to see an alternative that doesn't leave us running with known and exploitable vulnerabilities. And sadly, that seems to be the reality we're living in right now . . .