Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for representors

[Saeed Mahameed <saeedm@mellanox.com>]

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