public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Guenter Roeck <linux@roeck-us.net>
Cc: stable <stable@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sasha Levin <sashal@kernel.org>
Subject: Re: Regressions in stable releases
Date: Thu, 5 Aug 2021 20:30:55 +0200	[thread overview]
Message-ID: <20210805183055.GA21961@1wt.eu> (raw)
In-Reply-To: <20210805172949.GA3691426@roeck-us.net>

On Thu, Aug 05, 2021 at 10:29:49AM -0700, Guenter Roeck wrote:
> > It looks like a typical "works for me" regression. The best thing that
> > could possibly be done to limit such occurrences would be to wait "long
> > enough" before backporting them, in hope to catch breakage reports before
> > the backport, but here there were already 3 weeks between the patch was
> > submitted and it was backported.
> 
> No. The patch is wrong. It just _looks_ correct at first glance.

So that's the core of the problem. Stable maintainers cannot be tasked
to try to analyse each patch in its finest details to figure whether a
maintainer that's expected to be more knowledgeable than them on their
driver did something wrong.

Then in my opinion we should encourage *not* to use "Fixes:" on untested
patches (untested patches will always happen due to hardware availability
or lack of a reliable reproducer).

What about this to try to improve the situation in this specific case ?

Willy


From ef646bae2139ba005de78940064c464126c430e6 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w@1wt.eu>
Date: Thu, 5 Aug 2021 20:24:30 +0200
Subject: docs: process: submitting-patches.rst: recommend against 'Fixes:' if
 untested

'Fixes:' usually is taken as authority and often results in a backport. If
a patch couldn't be tested although it looks perfectly valid, better not
add this tag to leave a final chance for backporters to ask about the
relevance of the backport or to check for future tests.

Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/submitting-patches.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 0852bcf73630..54782b0e2f4c 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -140,6 +140,15 @@ An example call::
 	$ git log -1 --pretty=fixes 54a4f0239f2e
 	Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
 
+Please note that a 'Fixes:' tag will most often result in your patch being
+automatically backported to stable branches. If for any reason you could not
+test that it really fixes the problem (for example, because the bug is not
+reproducible, or because you did not have access to the required hardware
+at the time of writing the patch to verify it does not cause regressions),
+even if you are absolutely certain of your patch's validity, do not include
+a 'Fixes:' tag and instead explain the situation in the commit message in
+plain English.
+
 .. _split_changes:
 
 Separate your changes
-- 
2.17.5


  reply	other threads:[~2021-08-05 18:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 16:11 Regressions in stable releases Guenter Roeck
2021-08-05 16:19 ` Greg Kroah-Hartman
2021-08-05 17:39   ` Guenter Roeck
2021-08-05 17:43     ` Greg Kroah-Hartman
2021-08-05 19:44       ` Guenter Roeck
2021-08-05 19:51         ` Greg Kroah-Hartman
2021-08-05 16:42 ` Willy Tarreau
2021-08-05 17:29   ` Guenter Roeck
2021-08-05 18:30     ` Willy Tarreau [this message]
2021-08-06 14:16       ` Guenter Roeck
2021-08-06 14:42         ` Willy Tarreau
2021-08-06 14:37       ` Sasha Levin
2021-08-06 14:52         ` Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210805183055.GA21961@1wt.eu \
    --to=w@1wt.eu \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux@roeck-us.net \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox