[PATCH v2 0/2] Mention regression mailing list in reporting-bugs and MAINTAINERS

[PATCH v2 0/2] Mention regression mailing list in reporting-bugs and MAINTAINERS

[Thorsten Leemhuis]

Hi! A mailing list for regressions was finally created as
regressions@lists.linux.dev (we dropped the linux- prefix as the term is already
in the domain name). Hence, add it to MAINTAINERS, as that where people will
look it up. I was a bit unsure how to actually do that, see the note in the
first patch of the series for details.

The second patch makes reporting-issues.rst mention the new list, so people CC
it.

@Jonathan: this hopefully is the last round of patches for reporting-issues.rst
for this cycle. Please let me known if you think the addition to the MAINTAINERS
file should better go through a different maintainer.

Ciao, Thorsten

Thorsten Leemhuis (2):
  MAINTAINERS: add regressions mailing list
  docs: reporting-issues: make everyone CC the regressions list

 .../admin-guide/reporting-issues.rst          | 55 ++++++++++++-------
 MAINTAINERS                                   |  5 ++
 2 files changed, 40 insertions(+), 20 deletions(-)


base-commit: dfc7927d4ee008c69c5b60f9076e2ad8980589bc
-- 
2.30.2

[PATCH v2 1/2] MAINTAINERS: add regressions mailing list

[Thorsten Leemhuis]

Add the newly created regression mailing list finally created after it
already had been agreed on during the maintainers summit 2017 (see
https://lwn.net/Articles/738216/ ). The topic was recently discussed
again, where an idea to create a broader list for all issues was
discussed, but Linus preferred a more targeted list:
https://lkml.kernel.org/r/CAHk-=wgiYqqLzsb9-UpfH+=ktk7ra-2fOsdc_ZJ7WF47wS73CA@mail.gmail.com/

Hence, the creation for that list was asked for and granted:
https://bugzilla.kernel.org/show_bug.cgi?id=212557

In the end it became regressions@lists.linux.dev instead of
linux-regressions@lists.linux.dev as 'Linux' would have been redundant
in the latter case.

Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
v1->v2
* use the approach suggested by Greg, which doesn't have a K: entry,
  but that is likely not much of a help anyway
---
 MAINTAINERS | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 83472755a255..2553fec1d272 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9730,6 +9730,11 @@ F:	include/uapi/linux/sunrpc/
 F:	net/sunrpc/
 F:	Documentation/filesystems/nfs/
 
+KERNEL REGRESSIONS
+M:	Thorsten Leemhuis <linux@leemhuis.info>
+L:	regressions@lists.linux.dev
+S:	Supported
+
 KERNEL SELFTEST FRAMEWORK
 M:	Shuah Khan <shuah@kernel.org>
 M:	Shuah Khan <skhan@linuxfoundation.org>
-- 
2.30.2

[PATCH v2 2/2] docs: reporting-issues: make people CC the regressions list

[Thorsten Leemhuis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=yes, Size: 6871 bytes --]

Make people CC the recently created mailing list dedicated to Linux
kernel regressions when reporting one. Some paragraphs had to be
reshuffled and slightly rewritten during the process, as the text
otherwise would have gotten unnecessarily hard to follow.

Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
v1->v2
* drop the bits that a would help a automatic tracking solution

FWIW, a quick reminder about something I wrote in v1, but nobody said
anything about it: now that we have a mailing list for regressions I was
inclined to remove the "Make the report's subject start with
'[REGRESSION]'" part from the text. But in the end I left it, to make it
obvious on other lists that the mail is about a regression.
Nevertheless, I'm still wondering if it should be toned down a bit, as
it might be enough if the subject starts with "regression:" or contains
the word somewhere.

Ciao, Thorsten
---
 .../admin-guide/reporting-issues.rst          | 55 ++++++++++++-------
 1 file changed, 35 insertions(+), 20 deletions(-)

diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index 5791eaa34ade..48b4d0ef2b09 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -23,7 +23,8 @@ longterm series? One still supported? Then search the `LKML
 <https://lore.kernel.org/stable/>`_ archives for matching reports to join. If
 you don't find any, install `the latest release from that series
 <https://kernel.org/>`_. If it still shows the issue, report it to the stable
-mailing list (stable@vger.kernel.org).
+mailing list (stable@vger.kernel.org) and CC the regressions list
+(regressions@lists.linux.dev).
 
 In all other cases try your best guess which kernel part might be causing the
 issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
@@ -44,10 +45,11 @@ ensure it's vanilla (IOW: not patched and not using add-on modules). Also make
 sure it's built and running in a healthy environment and not already tainted
 before the issue occurs.
 
-While writing your report, include all information relevant to the issue, like
-the kernel and the distro used. In case of a regression try to include the
-commit-id of the change causing it, which a bisection can find. If you're facing
-multiple issues with the Linux kernel at once, report each separately.
+If you are facing multiple issues with the Linux kernel at once, report each
+separately. While writing your report, include all information relevant to the
+issue, like the kernel and the distro used. In case of a regression, CC the
+regressions mailing list (regressions@lists.linux.dev) to your report; also try
+to include the commit-id of the change causing it, which a bisection can find.
 
 Once the report is out, answer any questions that come up and help where you
 can. That includes keeping the ball rolling by occasionally retesting with newer
@@ -192,12 +194,14 @@ report them:
    kernel. Ensure this kernel is not tainted and still shows the problem, as
    the issue might have already been fixed there. If you first noticed the
    problem with a vendor kernel, check a vanilla build of the last version
-   known to work performs fine as well.*
+   known to work performs fine as well.
 
  * Send a short problem report to the Linux stable mailing list
-   (stable@vger.kernel.org). Roughly describe the issue and ideally explain
-   how to reproduce it. Mention the first version that shows the problem and
-   the last version that's working fine. Then wait for further instructions.*
+   (stable@vger.kernel.org) and CC the Linux regressions mailing list
+   (regressions@lists.linux.dev). Roughly describe the issue and ideally
+   explain how to reproduce it. Mention the first version that shows the
+   problem and the last version that's working fine. Then wait for further
+   instructions.
 
 The reference section below explains each of these steps in more detail.
 
@@ -1235,14 +1239,23 @@ Reports for high priority issues need special handling.
 **Severe issues**: make sure the subject or ticket title as well as the first
 paragraph makes the severeness obvious.
 
-**Regressions**: If the issue is a regression add [REGRESSION] to the mail's
-subject or the title in the bug-tracker. If you did not perform a bisection
-mention at least the latest mainline version you tested that worked fine (say
-5.7) and the oldest where the issue occurs (say 5.8). If you did a successful
-bisection mention the commit id and subject of the change that causes the
-regression. Also make sure to add the author of that change to your report; if
-you need to file your bug in a bug-tracker forward the report to him in a
-private mail and mention where your filed it.
+**Regressions**: make the report's subject start with '[REGRESSION]'.
+
+In case you performed a successful bisection, use the title of the change that
+introduced the regression as the second part of your subject. Make the report
+also mention the commit id of the culprit. In case of an unsuccessful bisection,
+make your report mention the latest tested version that's working fine (say 5.7)
+and the oldest where the issue occurs (say 5.8-rc1).
+
+When sending the report by mail, CC the Linux regressions mailing list
+(regressions@lists.linux.dev). In case the report needs to be filed to some web
+tracker, proceed to do so; once filed, forward the report by mail to the
+regressions list. Make sure to inline the forwarded report, hence do not attach
+it. Also add a short note at the top where you mention the URL to the ticket.
+
+When mailing or forwarding the report, in case of a successful bisection add the
+author of the culprit to the recipients; also CC everyone in the signed-off-by
+chain, which you find at the end of its commit message.
 
 **Security issues**: for these issues your will have to evaluate if a
 short-term risk to other users would arise if details were publicly disclosed.
@@ -1522,9 +1535,11 @@ Report the regression
 ~~~~~~~~~~~~~~~~~~~~~
 
     *Send a short problem report to the Linux stable mailing list
-    (stable@vger.kernel.org). Roughly describe the issue and ideally explain
-    how to reproduce it. Mention the first version that shows the problem and
-    the last version that's working fine. Then wait for further instructions.*
+    (stable@vger.kernel.org) and CC the Linux regressions mailing list
+    (regressions@lists.linux.dev). Roughly describe the issue and ideally
+    explain how to reproduce it.  Mention the first version that shows the
+    problem and the last version that's working fine. Then wait for further
+    instructions.*
 
 When reporting a regression that happens within a stable or longterm kernel
 line (say when updating from 5.10.4 to 5.10.5) a brief report is enough for
-- 
2.30.2

Re: [PATCH v2 1/2] MAINTAINERS: add regressions mailing list

[Greg KH]

On Fri, Apr 09, 2021 at 01:47:23PM +0200, Thorsten Leemhuis wrote:
> Add the newly created regression mailing list finally created after it
> already had been agreed on during the maintainers summit 2017 (see
> https://lwn.net/Articles/738216/ ). The topic was recently discussed
> again, where an idea to create a broader list for all issues was
> discussed, but Linus preferred a more targeted list:
> https://lkml.kernel.org/r/CAHk-=wgiYqqLzsb9-UpfH+=ktk7ra-2fOsdc_ZJ7WF47wS73CA@mail.gmail.com/
> 
> Hence, the creation for that list was asked for and granted:
> https://bugzilla.kernel.org/show_bug.cgi?id=212557
> 
> In the end it became regressions@lists.linux.dev instead of
> linux-regressions@lists.linux.dev as 'Linux' would have been redundant
> in the latter case.
> 
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH v2 2/2] docs: reporting-issues: make people CC the regressions list

[Greg KH]

On Fri, Apr 09, 2021 at 01:47:24PM +0200, Thorsten Leemhuis wrote:
> Make people CC the recently created mailing list dedicated to Linux
> kernel regressions when reporting one. Some paragraphs had to be
> reshuffled and slightly rewritten during the process, as the text
> otherwise would have gotten unnecessarily hard to follow.
> 
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> ---
> v1->v2
> * drop the bits that a would help a automatic tracking solution
> 
> FWIW, a quick reminder about something I wrote in v1, but nobody said
> anything about it: now that we have a mailing list for regressions I was
> inclined to remove the "Make the report's subject start with
> '[REGRESSION]'" part from the text. But in the end I left it, to make it
> obvious on other lists that the mail is about a regression.
> Nevertheless, I'm still wondering if it should be toned down a bit, as
> it might be enough if the subject starts with "regression:" or contains
> the word somewhere.

Let's see if anyone notices about [REGRESSION] or not, it can evolve
over time :)

thanks,

greg k-h

Re: [PATCH v2 0/2] Mention regression mailing list in reporting-bugs and MAINTAINERS

[Jonathan Corbet]

Thorsten Leemhuis <linux@leemhuis.info> writes:

> Hi! A mailing list for regressions was finally created as
> regressions@lists.linux.dev (we dropped the linux- prefix as the term is already
> in the domain name). Hence, add it to MAINTAINERS, as that where people will
> look it up. I was a bit unsure how to actually do that, see the note in the
> first patch of the series for details.
>
> The second patch makes reporting-issues.rst mention the new list, so people CC
> it.
>
> @Jonathan: this hopefully is the last round of patches for reporting-issues.rst
> for this cycle. Please let me known if you think the addition to the MAINTAINERS
> file should better go through a different maintainer.

Naw...we all stick our fingers into MAINTAINERS at will...:)  I've
applied both, thanks.

jon