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