On Wed, 2020-04-15 at 20:00 -0400, Sasha Levin wrote: > On Wed, Apr 15, 2020 at 05:18:38PM +0100, Edward Cree wrote: > > Firstly, let me apologise: my previous email was too harsh and too > > assertiveabout things that were really more uncertain and unclear. > > > > On 14/04/2020 21:57, Sasha Levin wrote: > > > I've pointed out that almost 50% of commits tagged for stable do > > > not > > > have a fixes tag, and yet they are fixes. You really deduce > > > things based > > > on coin flip probability? > > Yes, but far less than 50% of commits *not* tagged for stable have > > a fixes > > tag. It's not about hard-and-fast Aristotelian "deductions", like > > "this > > doesn't have Fixes:, therefore it is not a stable candidate", it's > > about > > probabilistic "induction". > > > > > "it does increase the amount of countervailing evidence needed to > > > conclude a commit is a fix" - Please explain this argument given > > > the > > > above. > > Are you familiar with Bayesian statistics? If not, I'd suggest > > reading > > something like http://yudkowsky.net/rational/bayes/ which explains > > it. > > There's a big difference between a coin flip and a _correlated_ > > coin flip. > > I'd maybe point out that the selection process is based on a neural > network which knows about the existence of a Fixes tag in a commit. > > It does exactly what you're describing, but also taking a bunch more > factors into it's desicion process ("panic"? "oops"? "overflow"? > etc). > I am not against AUTOSEL in general, as long as the decision to know how far back it is allowed to take a patch is made deterministically and not statistically based on some AI hunch. Any auto selection for a patch without a Fixes tags can be catastrophic .. imagine a patch without a Fixes Tag with a single line that is fixing some "oops", such patch can be easily applied cleanly to stable- v.x and stable-v.y .. while it fixes the issue on v.x it might have catastrophic results on v.y .. if you want these factors to keep playing a role in the autosel process, then a human factor or some deterministic testing/code coverage step must take action before backporting such patch on the blind. What i would suggest here: For patches that are missing a Fixes tag, they should be considered as a "candidate" for autosel, and don't actually apply them until an explicit ACK from some human/regression test factor is received. > > > This is great, but the kernel is more than just net/. Note that I > > > also > > > do not look at net/ itself, but rather drivers/net/ as those end > > > up with > > > a bunch of missed fixes. > > drivers/net/ goes through the same DaveM net/net-next trees, with > > the > > same rules. > > Let me put my Microsoft employee hat on here. We have > driver/net/hyperv/ > which definitely wasn't getting all the fixes it should have been > getting without AUTOSEL. > until some patch which shouldn't get backported slips through, believe me this will happen, just give it some time .. > While net/ is doing great, drivers/net/ is not. If it's indeed > following > the same rules then we need to talk about how we get done right. > both net and drivers/net are managed by the same maitainer and follow the same rules, can you elaborate on the difference ? > I really have no objection to not looking in drivers/net/, it's just > that the experience I had with the process suggests that it's not > following the same process as net/. >
