On Tue 17-04-18 16:19:35, Sasha Levin wrote: > On Tue, Apr 17, 2018 at 05:55:49PM +0200, Jan Kara wrote: > >> Even regression chance is tricky, look at the commits I've linked > >> earlier in the thread. Even the most trivial looking commits that end up > >> in stable have a chance for regression. > > > >Sure, you can never be certain and I think people (including me) > >underestimate the chance of regressions for "trivial" patches. But you just > >estimate a chance, you may be lucky, you may not... > > > >> >Another point I wanted to make is that if chance a patch causes a > >> >regression is about 2% as you said somewhere else in a thread, then by > >> >adding 20 patches that "may fix a bug that is annoying for someone" you've > >> >just increased a chance there's a regression in the release by 34%. And > >> > >> So I've said that the rejection rate is less than 2%. This includes > >> all commits that I have proposed for -stable, but didn't end up being > >> included in -stable. > >> > >> This includes commits that the author/maintainers NACKed, commits that > >> didn't do anything on older kernels, commits that were buggy but were > >> caught before the kernel was released, commits that failed to build on > >> an arch I didn't test it on originally and so on. > >> > >> After thousands of merged AUTOSEL patches I can count the number of > >> times a commit has caused a regression and had to be removed on one > >> hand. > >> > >> >this is not just a math game, this also roughly matches a real experience > >> >with maintaining our enterprise kernels. Do 20 "maybe" fixes outweight such > >> >regression chance? And I also note that for a regression to get reported so > >> >that it gets included into your 2% estimate of a patch regression rate, > >> >someone must be bothered enough by it to triage it and send an email > >> >somewhere so that already falls into a category of "serious" stuff to me. > >> > >> It is indeed a numbers game, but the regression rate isn't 2%, it's > >> closer to 0.05%. > > > >Honestly, I think 0.05% is too optimististic :) Quick grepping of 4.14 > >stable tree suggests some 13 commits were reverted from stable due to bugs. > >That's some 0.4% and that doesn't count fixes that were applied to > >fix other regressions. > > 0.05% is for commits that were merged in stable but later fixed or > reverted because they introduced a regression. By grepping for reverts > you also include things such as: > > - Reverts of commits that were in the corresponding mainline tree > - Reverts of commits that didn't introduce regressions Actually I was careful enough to include only commits that got merged as part of the stable process into 4.14.x but got later reverted in 4.14.y. That's where the 0.4% number came from. So I believe all of those cases (13 in absolute numbers) were user visible regressions during the stable process. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR