On Mon, Apr 16, 2018 at 06:06:08PM +0200, Pavel Machek wrote: >On Mon 2018-04-16 15:50:34, Sasha Levin wrote: >> On Mon, Apr 16, 2018 at 05:30:31PM +0200, Pavel Machek wrote: >> >On Mon 2018-04-16 08:18:09, Linus Torvalds wrote: >> >> On Mon, Apr 16, 2018 at 6:30 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: >> >> > >> >> > I wonder if the "AUTOSEL" patches should at least have an "ack-by" from >> >> > someone before they are pulled in. Otherwise there may be some subtle >> >> > issues that can find their way into stable releases. >> >> >> >> I don't know about anybody else, but I get so many of the patch-bot >> >> patches for stable etc that I will *not* reply to normal cases. Only >> >> if there's some issue with a patch will I reply. >> >> >> >> I probably do get more than most, but still - requiring active >> >> participation for the steady flow of normal stable patches is almost >> >> pointless. >> >> >> >> Just look at the subject line of this thread. The numbers are so big >> >> that you almost need exponential notation for them. >> > >> >Question is if we need that many stable patches? Autosel seems to be >> >picking up race conditions in LED state and W+X page fixes... I'd >> >really like to see less stable patches. >> >> Why? Given that the kernel keeps seeing more and more lines of code in >> each new release, tools around the kernel keep evolving (new fuzzers, >> testing suites, etc), and code gets more eyes, this guarantees that >> you'll see more and more stable patches for each release as well. >> >> Is there a reason not to take LED fixes if they fix a bug and don't >> cause a regression? Sure, we can draw some arbitrary line, maybe >> designate some subsystems that are more "important" than others, but >> what's the point? > >There's a tradeoff. > >You want to fix serious bugs in stable, and you really don't want >regressions in stable. And ... stable not having 1000s of patches >would be nice, too. I don't think we should use a number cap here, but rather look at the regression rate: how many patches broke something? Since the rate we're seeing now with AUTOSEL is similar to what we were seeing before AUTOSEL, what's the problem it's causing? >That means you want to ignore not-so-serious bugs, because benefit of >fixing them is lower than risk of the regressions. I believe bugs that >do not bother anyone should _not_ be fixed in stable. > >That was case of the LED patch. Yes, the commit fixed bug, but it >introduced regressions that were fixed by subsequent patches. How do you know if a bug bothers someone? If a user is annoyed by a LED issue, is he expected to triage the bug, report it on LKML and patiently wait for the appropriate patch to be backported?
