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).
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. 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. 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/. -- Thanks, Sasha
