It seems to me that for a long time now stable releases haven't been trying very hard to follow the stated policy [1], in particular the parts that say
> It must fix a real bug that bothers people (not a, "This could be a problem..." type thing).
and
> It must fix a problem that causes a build error ([...]), an oops, a hang, data corruption, a real security issue, or some "oh, that’s not good" issue. In short, something critical.
It's a long-standing issue/debate at this point. The maintainers of long-term stable kernels have for some years now used scripts to automatically pick as many appropriate-looking stand-alone patches as possible, looking at what's merged into Linus' "tip" tree (usually to find fixes targeting rc(N) kernels). Since they do the work they get to decide, but many others have found this an inappropriately regression-prone way to manage longterm-stable kernels. If you want all the latest fixes and improvements, you can use the latest kernel. If you use the longterm-stable it's because you want less risk from unrelated/unmotivated changes, you want only the specific fixes found to be most needed.
I have no strong opinion on what the policy should be, but I think there's no excuse for allowing the stated policy to get so far out of sync with the actual policy.
That is, I think the stable-release maintainers should update Documentation/process/stable-kernel-rules.rst so that it tells the truth.
(I think this is about normal stable kernels, not 'longterm' ones. I don't think 6.0 was expected to become the next LTS release.)
Yeah, good point, in any case I would expect the "most recent stable" branch to get _all_ the "potential fixes" (that otherwise would only be available in RC releases).
Is this the sort of thing you feel is worth someone else's time and effort, or do you think it's meaningful enough to consume some of your own? If the latter you can offer to do it, if the former you can pound sand.
The issue isn't effort here, but that each backported fix risks breaking something else. People who want all the latest fixes can choose the latest kernel, instead of relying on backports to stable kernels.
It seems to me that for a long time now stable releases haven't been trying very hard to follow the stated policy [1], in particular the parts that say
> It must fix a real bug that bothers people (not a, "This could be a problem..." type thing).
and
> It must fix a problem that causes a build error ([...]), an oops, a hang, data corruption, a real security issue, or some "oh, that’s not good" issue. In short, something critical.
[1]: https://docs.kernel.org/process/stable-kernel-rules.html