@gregkh is it true that Linus doesn't want hotfixes for stuff that doesn't fix things other than bugs that comes from code added in the most recent merge window?

How do you guys in stable deal with that if so?

@ljs I'm not @gregkh , but whatever.

The answer is somewhat tricky, as language is tricky – when you say "bugs", do you mean all bugs? Then "the most recent merge window" is wrong, as Linus wants regressions from recent cycles (note the plural here) fixed, even in the last minute afaics[1].

Is your confusion maybe coming from this? https://lore.kernel.org/lkml/CAHk-=wjt1NiKOdyAMz_DT7NmZ++SizPOhRSi492ukdTnpDzHQw@mail.gmail.com/

To quote: """So I think I'll start being a bit more hardnosed about this kind of unnecessary churn this late in the game. We are supposed to look for *regressions*. Non-critical fixes to long-standing issues are simply not appropriate for this late in the release cycle."""

[1] https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/

@ljs stable takes whatever is tagged for it in Linus's tree + other stuff people ask for (and AUTOSEL at times, it was on a break for a while but is now back!)

For my subsystems, I send bug fixes to Linus for stuff that fixes bugs, it's usually not that complicated. Don't want for -rc1 to get reported bugs fixed that were reported the previous development cycle if at all possible as that just delays this for no good reason.

@kernellogger @ljs what he said, as he knows this better than probably anyone!

@gregkh @kernellogger thanks, I think there's been some general confusion about this :)

@ljs yeah, there definitely is quite a bit of confusion.

Partly because there are always developers/maintainers that will miss statements from Linus (like the two aforementioned ones).

Partly it's "language is tricky" again, as everybody interprets statements from Linus slightly differently, especially when it comes to weighting older and newer ones against each other.

Partly it's just misremembering and some "game of telephone".

Not sure how to solve this. In normal projects putting guidelines/rules in the docs and enforcing them would help a lot. But for the kernel that often doesn't help much from what I've seen (at least when it comes to the docs wrt on fixing regressions).

CC @gregkh

@kernellogger @gregkh what you need is docs + people nagging and referencing those docs :)

One without the other doesn't quite work

@ljs @gregkh yup, but nagging in the end only really works if it comes from some place of authority, e.g. a point of control (subsystem maintainer/reviewer) or Linus himself.

And I don't really have that. Which results is, ehh, disagreements between me and developers/maintainers every now and then when it comes to regressions (and why some might have started to ignore me). Which I don't blame them for; I try to only enforce what Linus wants, but that makes their already hard life yet again somewhat harder, which is annoying.

#sigh

@kernellogger @gregkh