On Thu, May 03, 2018 at 11:36:51AM +0200, Pavel Machek wrote:
On Tue 2018-04-17 16:19:35, Sasha Levin wrote:
On Tue, Apr 17, 2018 at 05:55:49PM +0200, Jan Kara wrote:
On Tue 17-04-18 13:31:51, Sasha Levin wrote:
We may be able to guesstimate the 'regression chance', but there's no way we can guess the 'annoyance' once. There are so many different use cases that we just can't even guess how many people would get "annoyed" by something.
As a maintainer, I hope I have reasonable idea what are common use cases for my subsystem. Those I cater to when estimating 'annoyance'. Sure I don't know all of the use cases so people doing unusual stuff hit more bugs and have to report them to get fixes included in -stable. But for me this is a preferable tradeoff over the risk of regression so this is the rule I use when tagging for stable. Now I'm not a -stable maintainer and I fully agree with "those who do the work decide" principle so pick whatever patches you think are appropriate, I just wanted explain why I don't think more patches in stable are necessarily good.
The AUTOSEL story is different for subsystems that don't do -stable, and subsystems that are actually doing the work (like yourself).
I'm not trying to override active maintainers, I'm trying to help them make decisions.
Ok, cool. Can you exclude LED subsystem, Hibernation and Nokia N900 stuff from autosel work?
Curiousity got me, and I had to see what these subsystems do as far as stable commits:
$ git log --oneline --grep 'stable@vger' --since="01-01-2016" kernel/power drivers/leds drivers/media/i2c/et8ek8 drivers/media/i2c/ad5820.c arch/x86/kernel/acpi/ | wc -l 7
Which got me a bit surprised: maybe indeed leds is mostly fine, but hibernation is definitely tricky, I've been stung by it a few times...
So why not pick something an actual user reported, and see how that was dealt with?
Googling first showed this:
https://bugzilla.kernel.org/show_bug.cgi?id=97201
Which was fixed by:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
But that's not in any -stable tree. Hmm.. ok..
Next one on google was:
https://bugzilla.kernel.org/show_bug.cgi?id=117971
Which, in turn, was fixed by:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Oh look at that, it's not in -stable either...
So seeing how you have concerns with my selection of -stable commits, maybe you could explain to me why these commits didn't end up in -stable?