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".
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?
$ git log --oneline -i --grep "fixes:" v4.19..stable/linux-4.19.y | wc -l
6235
$ git log --oneline v4.19..stable/linux-4.19.y | wc -l
12877
Look at that, most fixes in -stable *don't* have a fixes tag. Shouldn't
your argument be the opposite? If a patch has a fixes tag, it's probably
not a fix?
"it does increase the amount of countervailing evidence needed to
conclude a commit is a fix" - Please explain this argument given the
above.
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
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.
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...
Nothing like a personal attack or two to try and make a point?
--
Thanks,
Sasha
