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

[Leon Romanovsky <leon@kernel.org>]

On Tue, Apr 14, 2020 at 04:49:20PM +0100, Edward Cree wrote:
> On 14/04/2020 16:16, Sasha Levin wrote:
> > Are you suggesting that a commit without a fixes tag is never a fix?
> Because fixes are much more likely than non-fixes to have a Fixes tag,
>  the absence of a fixes tag is Bayesian evidence that a commit is not
>  a fix.  It's of course not incontrovertible evidence, since (as you
>  note) some fixes do not have a Fixes tag, but it does increase the
>  amount of countervailing evidence needed to conclude a commit is a fix.
> In this case it looks as if the only such evidence was that the commit
>  message included the phrase "NULL pointer dereference".
>
> > Fixes can (and should) come in during a merge window as well. They are
> > not put on hold until the -rc releases.
> In networking-land, fixes generally go through David's 'net' tree, rather
>  than 'net-next'; the only times a fix goes to net-next are when
> a) the code it's fixing is only in net-next; i.e. it's a fix to a previous
>  patch from the same merge window.  In this case the fix should not be
>  backported, since the code it's fixing will not appear in stable kernels.
> b) the code has changed enough between net and net-next that different
>  fixes are appropriate for the two trees.  In this case, only the fix that
>  went to 'net' should be backported (since it's the one that's appropriate
>  for net, it's probably more appropriate for stable trees too); the fix
>  that went to 'net-next' should not.
> Or's original phrasing was that this patch "was pushed to net-next", which
>  is not quite exactly the same thing as -next vs. -rc (though it's similar
>  because of David's system of closing net-next for the duration of the
>  merge window).  And this, again, is quite strong Bayesian evidence that
>  the patch should not be selected for stable.
>
> To be honest, that this needs to be explained to you does not inspire
>  confidence in the quality of your autoselection process...

It is a little bit harsh to say that.

The autoselection process works good enough for everything outside
of netdev community. The amount of bugs in those stable@ trees is
not such high if you take into account the amount of fixes automatically
brought in.

I think that all Fedora users are indirectly use those stable@ trees.

Thanks