All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.