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

[Leon Romanovsky <leon@kernel.org>]

On Thu, Apr 16, 2020 at 04:08:10AM +0000, Saeed Mahameed wrote:
> 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 ..

I tried to imagine such flow and failed to do so. Are you talking about
anything specific or imaginary case?

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

Bugs are inevitable, I don't see many differences between bugs
introduced by manually cherry-picking or automatically one.

Of course, it is true if this automatically cherry-picking works as
expected and evolving.

>
> > 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 ?

The main reason is a difference in a volume between net and drivers/net.
While net/* patches are watched by many eyes and carefully selected to be
ported to stable@, most of the drivers/net patches are not.

Except 3-5 the most active drivers, rest of the driver patches almost never
asked to be backported.

Thanks