On Mon, Apr 16, 2018 at 12:47:11PM -0400, Steven Rostedt wrote: >On Mon, 16 Apr 2018 16:31:09 +0000 >Sasha Levin <Alexander.Levin@xxxxxxxxxxxxx> wrote: > >> On Mon, Apr 16, 2018 at 12:22:44PM -0400, Steven Rostedt wrote: >> >On Mon, 16 Apr 2018 16:14:15 +0000 >> >Sasha Levin <Alexander.Levin@xxxxxxxxxxxxx> wrote: >> > >> >> 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? >> > >> >Does that mean we just doubled the rate of regressions? That's the >> >problem. >> >> No, the rate stayed the same :) >> >> If before ~2% of stable commits were buggy, this is still the case with >> AUTOSEL. > >Sorry, I didn't mean "rate" I meant "number". If the rate stayed the >same, that means the number increased. Indeed, just like the number of regressions in mainline has increased over time. >> >> >> >> >> 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? >> > >> >Yes. >> >> I'm honestly not sure how to respond. >> >> Let me ask my wife (who is happy using Linux as a regular desktop user) >> how comfortable she would be with triaging kernel bugs... > >That's really up to the distribution, not the main kernel stable. Does >she download and compile the kernels herself? Does she use LEDs? > >The point is, stable is to keep what was working continued working. >If we don't care about introducing a regression, and just want to keep >regressions the same as mainline, why not just go to mainline? That way >you can also get the new features? Mainline already has the mantra to >not break user space. When I work on new features, I sometimes stumble >on bugs with the current features. And some of those fixes require a >rewrite. It was "good enough" before, but every so often could cause a >bug that the new feature would trigger more often. Do we back port that >rewrite? Do we backport fixes to old code that are more likely to be >triggered by new features? > >Ideally, we should be working on getting to no regressions to stable. This is exactly what we're doing. If a fix for a bug in -stable introduces a different regression, should we take it or not?