Hacker News Reader

Comment by mjw1007 | Hacker News Reader

Allegedly this was the patch introducing the bug: https://lore.kernel.org/stable/20221228144337.512799851@linu...

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

View on HN

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.

Well, that's all in my interpretation :) for more broad background see https://lwn.net/Articles/863505/

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).

You know, this is a really good point.

The last three 'stable' releases have contained an annoying number of refactors and fixes for amdgpu in particular

Play with PowerPlay tables in staging, I haven't been able to upgrade

I can't edit now but a note for posterity... when I say 'staging' I actually suggest mainline or linux-next, whichever is actually more appropriate

Stable seems an odd place /shrug

Those 'fixes' may have fixed what they looked at, but I'm still broken. Feels more like rearranging chairs than actually fixing

That's an absolutely awful policy!

It should fix an actual problem, even if not found until now.

Why do you think fixes for minor problems should be backported to stable kernels?

Because many times minor problems are not minor at all.

Test the damn thing!

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.

Reply on news.ycombinator.com