mirrors/linux-stable
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git synced 2024-09-25 20:05:39 +00:00
Code Issues Releases Wiki Activity

docs: reporting-issues: make people CC the regressions list

Browse source 
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>
Link: https://lore.kernel.org/r/ac28089d710d5d41f295221bc726555ba32f4984.1617967127.git.linux@leemhuis.info
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Thorsten Leemhuis 2021-04-09 13:47:24 +02:00 committed by Jonathan Corbet
parent ad4db83425
commit 6161a4b18a
1 changed files with 35 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

55
Documentation/admin-guide/reporting-issues.rst
View file

@ -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