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/.