From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11547C2BB1D for ; Tue, 14 Apr 2020 19:41:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D8C75206A2 for ; Tue, 14 Apr 2020 19:41:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586893273; bh=kgaOd5rVtBHnlZhuaat/vYuKrg4YXi+X/x2DRDTu9Mw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=nktenLKoyIODFfrl3Vu5zUNI6raLXqUDdtmZeQ6XzzGFVd2ozFJAILwXGPMYJMb47 /j6mq5YGNMeIixpMkBCIq6Hpg+YwI+kY+ZyWNTa3UPfMGgrtpfDhcy0cUBL390rQVi Yi43A+GeRnwva2cMvYB6Q0Z+V+X79Wb8tC4RdW7s= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2505092AbgDNTlM (ORCPT ); Tue, 14 Apr 2020 15:41:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:37388 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2505018AbgDNTj2 (ORCPT ); Tue, 14 Apr 2020 15:39:28 -0400 Received: from kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com (unknown [163.114.132.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4D470206A2; Tue, 14 Apr 2020 19:03:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586891030; bh=kgaOd5rVtBHnlZhuaat/vYuKrg4YXi+X/x2DRDTu9Mw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=mzlpg17NeNDDHxQ7VGtVBEezIgYsAcfD1uyXygHInxQqe97fdhnEi2ebFkeLh3MVp WOtIvCcoVgTc/TMbiXFdhZlu+WODs/+te9174iUu2k5KgbYsLf72OcePXd+JfLOIWe J+SwfX7StSR4TIGlH2FI+ZMw16hXzI7kDCywR5ZI= Date: Tue, 14 Apr 2020 12:03:47 -0700 From: Jakub Kicinski To: Leon Romanovsky Cc: Edward Cree , Or Gerlitz , Greg KH , Sasha Levin , Stable , Linux Netdev List , Saeed Mahameed , David Miller Subject: Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for representors Message-ID: <20200414120347.6b898e66@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <20200414173718.GE1011271@unreal> References: <20200411231413.26911-1-sashal@kernel.org> <20200411231413.26911-9-sashal@kernel.org> <20200412105935.49dacbf7@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20200414015627.GA1068@sasha-vm> <20200414110911.GA341846@kroah.com> <20200414173718.GE1011271@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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.