[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200414210019.GG1068@sasha-vm>
Date: Tue, 14 Apr 2020 17:00:19 -0400
From: Sasha Levin <sashal@...nel.org>
To: Leon Romanovsky <leon@...nel.org>
Cc: Edward Cree <ecree@...arflare.com>,
Or Gerlitz <gerlitz.or@...il.com>,
Greg KH <gregkh@...uxfoundation.org>,
Jakub Kicinski <kuba@...nel.org>,
Stable <stable@...r.kernel.org>,
Linux Netdev List <netdev@...r.kernel.org>,
Saeed Mahameed <saeedm@...lanox.com>,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for
representors
On Tue, Apr 14, 2020 at 08:37:18PM +0300, Leon Romanovsky wrote:
>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'll add that it's funny that we're discussing AUTOSEL in this context
given that a conversation I had with Leon quite a few years back around
issues with Mellanox patches not going to -stable was one of the
triggers for AUTOSEL :)
--
Thanks,
Sasha
Powered by blists - more mailing lists