On Tue, 14 Apr 2020 20:37:18 +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 think that all Fedora users are indirectly use those stable@ trees. +1 I think folks how mark things for stable explicitly and carefully have an obvious bias because they only see the false positives of auto-sel and never the benefits.
