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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 C88ACC07E96 for ; Thu, 15 Jul 2021 09:01:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F31576128D for ; Thu, 15 Jul 2021 09:01:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F31576128D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2808F8D00A5; Thu, 15 Jul 2021 05:01:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 257458D0065; Thu, 15 Jul 2021 05:01:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F8DB8D00A5; Thu, 15 Jul 2021 05:01:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0177.hostedemail.com [216.40.44.177]) by kanga.kvack.org (Postfix) with ESMTP id E14348D0065 for ; Thu, 15 Jul 2021 05:01:19 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 49F7718F54 for ; Thu, 15 Jul 2021 09:01:17 +0000 (UTC) X-FDA: 78364228194.32.37917BA Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) by imf16.hostedemail.com (Postfix) with ESMTP id EE9D7F0017C7 for ; Thu, 15 Jul 2021 09:01:16 +0000 (UTC) Received: by mail-vs1-f43.google.com with SMTP id r18so2575156vsa.4 for ; Thu, 15 Jul 2021 02:01:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wHPy6x4feXL9uDlB10yPqrmcfEqEPnqgR0YupDxTlwk=; b=hQe6Crv3KwnvdzNtr/sC9TaunpqvinBvgxqUmIveu5ffZQYLvf86nymqogQ9YYdN6Z BxEVsq+Ue2TU5acEFjwikEDm3Ww/yeeo9lHopNhMyKJ6FGnsGFkelxSAogmsWoyd6Lmx L1zsG0shCAJOlLbywZU7s59h4saw05cLkPCu2NxxI11Heo0CiLBQrgyZenQW0Jdl3i2u z+E1BNn0SgQHI0tN4oDzZgpbbFEh4QZv4OYkCm6pmObZDb1RxYlFDLCPgWNRx1cjJXCk VonpSziqZDAor4j9hO9Tf4uWy4TRrxzHLKm62E3KZH06Xd9Ihbr1a59EX6z0PFBYJkHw emhA== X-Gm-Message-State: AOAM531S+McoGC+HqQx1XkXLl5RVFvZbJkjiIN9d7nEUvRaQrlA8sSVW pgG3JzwyM+Ge24pGl1ZTnxv9Iy0S7TKyGXy3frE= X-Google-Smtp-Source: ABdhPJyHbu5bKyE9McjVS58P54gR93m9cwPTzGItU00xvW8wNQJ6mPmFugIONz0RDU/lJAyh+7l06tep7NazsZKJYtg= X-Received: by 2002:a67:3c2:: with SMTP id 185mr5002824vsd.42.1626339676281; Thu, 15 Jul 2021 02:01:16 -0700 (PDT) MIME-Version: 1.0 References: <2b1b798e-8449-11e-e2a1-daf6a341409b@google.com> <20210713182813.2fdd57075a732c229f901140@linux-foundation.org> In-Reply-To: From: Geert Uytterhoeven Date: Thu, 15 Jul 2021 11:01:04 +0200 Message-ID: Subject: Re: 5.13.2-rc and others have many not for stable To: Greg Kroah-Hartman Cc: "Theodore Y. Ts'o" , Sasha Levin , Andrew Morton , Michal Hocko , Hugh Dickins , Linus Torvalds , Mike Kravetz , Miaohe Lin , Linux Kernel Mailing List , Linux MM , stable Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of geertuytterhoeven@gmail.com designates 209.85.217.43 as permitted sender) smtp.mailfrom=geertuytterhoeven@gmail.com; dmarc=none X-Rspamd-Server: rspam05 X-Stat-Signature: bjpczzcic7oeyjzsnwsz5c8xyuzx5wpz X-Rspamd-Queue-Id: EE9D7F0017C7 X-HE-Tag: 1626339676-823317 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Greg et al, On Wed, Jul 14, 2021 at 7:36 PM Greg Kroah-Hartman wrote: > On Wed, Jul 14, 2021 at 01:21:59PM -0400, Theodore Y. Ts'o wrote: > > On Wed, Jul 14, 2021 at 05:46:22PM +0200, Greg Kroah-Hartman wrote: > > > The number of valid cases where someone puts a "Fixes:" tag, and that > > > patch should NOT be backported is really really slim. Why would you put > > > that tag and not want to have known-broken kernels fixed? > > > > > > If it really is not an issue, just do not put the "Fixes:" tag? > > > > I think it really boils down to what the tags are supposed to mean and > > what do they imply. > > > > The argument from the other side is if the Stable maintainers are > > interpreting the Fixes: tag as an implicit "CC: stable", why should we > > have the "Cc: stable" tag at all in that case? > > I would love to not have to look at the Fixes: tag, but today we have to > because not all subsystems DO use cc: stable. > > We miss loads of real fixes if we only go by cc: stable right now. If > you can go and fix those subsystems to actually remember to do this > "properly", wonderful, we will not have to mess with only Fixes: tags > again. > > But until that happens, we have to live with what we have. And all we > have are "hints" like Fixes: to go off of. IMHO the biggest issues with "Cc: stable" are that (a) in general it's hard to know if a patch is (not) worthwhile to be backported, and (b) without a Fixes: tag it doesn't tell you what version(s) it should be applied to. Just having a Fixes: tag fixes the latter, and allows you to defer the decision to backport. > > We could also have the policy that in the case where you have a fix > > for a bug, but it's super subtle, and shouldn't be automatically > > backported, that the this should be explained in the commit, e.g., > > > > This commit fixes a bug in "1adeadbeef33: lorem ipsum dolor sit > > amet" but it is touching code which subtle and quick to anger, the > > bug isn't all that serious. So please don't backport it > > automatically; someone should manually do the backport and run the > > fooblat test before sumitting it to the stable maintainers. > > That's wonderful, I would love to see that more, and we do see that on > some commits. And we mostly catch them (I miss them at times, but > that's my fault, not the developer/maintainers fault.) In my experience, the hardest cases are the ones where a patch fixes a real bug, but the fix has an obscure implicit dependency on another commit in a different subsystem (e.g. driver and DTS interaction). When backporting, a regression is introduced if the dependency is not present yet in the stable tree. > > Andrew seems to be of the opinion that these sorts of cases are very > > common. I don't have enough data to have a strong opinion either way. > > But if you are right that it is a rare case, then sure, simply > > omitting the Fixes: tag and using text in the commit description would > > work. We just need to agree that this is the convention that we all > > shoulf be using. > > > > I still wonder though what's the point of having the "Cc: stable" tag > > if it's implicitly assumed to be there if there is a Fixes: tagle. > > Because cc: stable came first, and for some reason people think that it > is all that is necessary to get patches committed to the stable tree, > despite it never being documented or that way. I have to correct > someone about this about 2x a month on the stable@vger list. For a developer, it's much easier to not care about "Cc: stable" at all, because as soon as you add a "Cc: stable" to a patch, or CC stable, someone will compain ;-) Much easier to just add a Fixes: tag, and know it will be backported to trees that have the "buggy" commit. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds