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/?id=bdbc98abb3aa323f6323b11db39c740e6f8fc5b1 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/?id=5b3f249c94ce1f46bacd9814385b0ee2d1ae52f3 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?
