On Mon 2018-04-16 21:18:47, Sasha Levin wrote:
On Mon, Apr 16, 2018 at 10:43:28PM +0200, Jiri Kosina wrote:
On Mon, 16 Apr 2018, Sasha Levin wrote:
So I think that Linus's claim that users come first applies here as well. If there's a user that cares about a particular feature being broken, then we go ahead and fix his bug rather then ignoring him.
So one extreme is fixing -stable *iff* users actually do report an issue.
The other extreme is backporting everything that potentially looks like a potential fix of "something" (according to some arbitrary metric), pro-actively.
The former voilates the "users first" rule, the latter has a very, very high risk of regressions.
So this whole debate is about finding a compromise.
My gut feeling always was that the statement in
Documentation/process/stable-kernel-rules.rst
is very reasonable, but making the process way more "aggresive" when backporting patches is breaking much of its original spirit for me.
I agree that as an enterprise distro taking everything from -stable isn't the best idea. Ideally you'd want to be close to the first
Original purpose of -stable was "to be common base of enterprise distros" and our documentation still says it is.
I think that we can agree that it's impossible to expect every single Linux user to go on LKML and complain about a bug he encountered, so the rule quickly becomes "It must fix a real bug that can bother people".
I think you are playing dangerous word games.
My "aggressiveness" comes from the whole "bother" part: it doesn't have to be critical, it doesn't have to cause data corruption, it doesn't have to be a security issue. It's enough that the bug actually affects a user in a way he didn't expect it to (if a user doesn't have expectations, it would fall under the "This could be a problem..." exception.
And it seems documentation says you should be less aggressive and world tells you they expect to be less aggressive. So maybe that's what you should do? Pavel