Improve reporting-issues.rst and make it official

index 423116c4e787..dc00afcabb95 100644
@@ -35,7 +35,6 @@ problems and bugs in particular.
    :maxdepth: 1
 
    reporting-issues
-   Reporting bugs (obsolete) <reporting-bugs>
    security-bugs
    bug-hunting
    bug-bisect

187 lines not on this page · raw message

85 lines not on this page · raw message

index e66ff3daf23c..b5d38fedff6c 100644
@@ -5413,6 +5413,12 @@ X:	Documentation/power/
 X:	Documentation/spi/
 X:	Documentation/userspace-api/media/
 
+DOCUMENTATION REPORTING ISSUES
+M:	Thorsten Leemhuis <[email protected]>
+L:	[email protected]
+S:	Maintained
+F:	Documentation/admin-guide/reporting-issues.rst
+
 DOCUMENTATION SCRIPTS
 M:	Mauro Carvalho Chehab <[email protected]>
 L:	[email protected]

index ca809a4be620..77d38acca282 100644
@@ -17,46 +17,41 @@ Reporting issues
 The short guide (aka TL;DR)
 ===========================
 
-If you're facing multiple issues with the Linux kernel at once, report each
-separately to its developers. Try your best guess which kernel part might be
-causing the issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its
-developers expect to be told about issues. Note, it's rarely
-`bugzilla.kernel.org <https://bugzilla.kernel.org/>`_, as in almost all cases
-the report needs to be sent by email!
-
-Check the destination thoroughly for existing reports; also search the LKML
-archives and the web. Join existing discussion if you find matches. If you
-don't find any, install `the latest Linux mainline kernel
-<https://kernel.org/>`_. Make sure it's vanilla, thus is not patched or using
-add-on kernel modules. Also ensure the kernel is running in a healthy
-environment and is not already tainted before the issue occurs.
-
-If you can reproduce your issue with the mainline kernel, send a report to the
-destination you determined earlier. Make sure it includes all relevant
-information, which in case of a regression should mention the change that's
-causing it which can often can be found with a bisection. Also ensure the
-report reaches all people that need to know about it, for example the security
-team, the stable maintainers or the developers of the patch that causes a
-regression. Once the report is out, answer any questions that might be raised
-and help where you can. That includes keeping the ball rolling: every time a
-new rc1 mainline kernel is released, check if the issue is still happening
-there and attach a status update to your initial report.
-
-If you can not reproduce the issue with the mainline kernel, consider sticking
-with it; if you'd like to use an older version line and want to see it fixed
-there, first make sure it's still supported. Install its latest release as
-vanilla kernel. If you cannot reproduce the issue there, try to find the commit
-that fixed it in mainline or any discussion preceding it: those will often
-mention if backporting is planed or considered too complex. If backporting was
-not discussed, ask if it's in the cards. In case you don't find any commits or
-a preceding discussion, see the Linux-stable mailing list archives for existing
-reports, as it might be a regression specific to the version line. If it is,
-report it like you would report a problem in mainline (including the
-bisection).
-
-If you reached this point without a solution, ask for advice one the
-subsystem's mailing list.
-
+Are you facing a regression with vanilla kernels from the same stable or
+longterm series? One still supported? Then search the `LKML
+<https://lore.kernel.org/lkml/>`_ and the `Linux stable mailing list
+<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 ([email protected]).
+
+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
+expect to be told about problems, which most of the time will be by email with a
+mailing list in CC. Check the destination's archives for matching reports;
+search the `LKML <https://lore.kernel.org/lkml/>`_ and the web, too. If you
+don't find any to join, install `the latest mainline kernel
+<https://kernel.org/>`_. If the issue is present there, send a report.
+
+The issue was fixed there, but you would like to see it resolved in a still
+supported stable or longterm series as well? Then install its latest release.
+If it shows the problem, search for the change that fixed it in mainline and
+check if backporting is in the works or was discarded; if it's neither, ask
+those who handled the change for it.
+
+**General remarks**: When installing and testing a kernel as outlined above,
+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.
+
+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
+releases and sending a status update afterwards.
 
 Step-by-step guide how to report issues to the kernel maintainers
 =================================================================

index 77d38acca282..e6137c971007 100644
@@ -77,9 +77,9 @@ process won't feel wasted in the end:
    will often be needed anyway to hunt down and fix issues.
 
  * Perform a rough search for existing reports with your favorite internet
-   search engine; additionally, check the archives of the Linux Kernel Mailing
-   List (LKML). If you find matching reports, join the discussion instead of
-   sending a new one.
+   search engine; additionally, check the archives of the `Linux Kernel Mailing
+   List (LKML) <https://lore.kernel.org/lkml/>`_. If you find matching reports,
+   join the discussion instead of sending a new one.
 
  * See if the issue you are dealing with qualifies as regression, security
    issue, or a really severe problem: those are 'issues of high priority' that

@@ -181,21 +181,23 @@ regressions as quickly as possible, hence there is a streamlined process to
 report them:
 
  * Check if the kernel developers still maintain the Linux kernel version
-   line you care about: go to the front page of kernel.org and make sure it
-   mentions the latest release of the particular version line without an
-   '[EOL]' tag.
+   line you care about: go to the  `front page of kernel.org
+   <https://kernel.org/>`_ and make sure it mentions
+   the latest release of the particular version line without an '[EOL]' tag.
 
- * Check the archives of the Linux stable mailing list for existing reports.
+ * Check the archives of the `Linux stable mailing list
+   <https://lore.kernel.org/stable/>`_ for existing reports.
 
  * Install the latest release from the particular version line as a vanilla
    kernel. Ensure this kernel is not tainted and still shows the problem, as
-   the issue might have already been fixed there.
+   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.*
 
- * Send a short problem report by mail to the people and mailing lists the
-   :ref:`MAINTAINERS <maintainers>` file specifies in the section 'STABLE
-   BRANCH'. 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.
+ * Send a short problem report to the Linux stable mailing list
+   ([email protected]). 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.
 

@@ -205,8 +207,8 @@ Reporting issues only occurring in older kernel version lines
 
 This subsection is for you, if you tried the latest mainline kernel as outlined
 above, but failed to reproduce your issue there; at the same time you want to
-see the issue fixed in older version lines or a vendor kernel that's regularly
-rebased on new stable or longterm releases. If that case follow these steps:
+see the issue fixed in a still supported stable or longterm series or vendor
+kernels regularly rebased on those. If that the case, follow these steps:
 
  * Prepare yourself for the possibility that going through the next few steps
    might not get the issue solved in older releases: the fix might be too big

@@ -291,7 +293,7 @@ distributors are quite distant from the official Linux kernel as distributed by
 kernel.org: these kernels from these vendors are often ancient from the point of
 Linux development or heavily modified, often both.
 
-Most of these vendor kernels are quite unsuitable for reporting bugs to the
+Most of these vendor kernels are quite unsuitable for reporting issues to the
 Linux kernel developers: an issue you face with one of them might have been
 fixed by the Linux kernel developers months or years ago already; additionally,
 the modifications and enhancements by the vendor might be causing the issue you

@@ -816,7 +818,7 @@ kernel for testing, as that where all fixes have to be applied first. Do not let
 that 'rc' scare you, these 'development kernels' are pretty reliable — and you
 made a backup, as you were instructed above, didn't you?
 
-In about two out of every nine to ten weeks, 'mainline' might point you to a
+In about two out of every nine to ten weeks, mainline might point you to a
 proper release with a version number like '5.7'. If that happens, consider
 suspending the reporting process until the first pre-release of the next
 version (5.8-rc1) shows up on kernel.org. That's because the Linux development

@@ -1231,7 +1233,7 @@ Special handling for high priority issues
 
 Reports for high priority issues need special handling.
 
-**Severe bugs**: make sure the subject or ticket title as well as the first
+**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

@@ -1455,11 +1457,11 @@ easier. And with a bit of luck there might be someone in the team that knows a
 bit about programming and might be able to write a fix.
 
 
-Reference for "Reporting issues only occurring in older kernel version lines"
------------------------------------------------------------------------------
+Reference for "Reporting regressions within a stable and longterm kernel line"
+------------------------------------------------------------------------------
 
-This subsection provides details for step you need to perform if you face a
-regression within a stable and longterm kernel line.
+This subsection provides details for the steps you need to perform if you face
+a regression within a stable and longterm kernel line.
 
 Make sure the particular version line still gets support
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

@@ -1475,7 +1477,7 @@ chosen and gets supported for at least two years (often six). That's why you
 need to check if the kernel developers still support the version line you care
 for.
 
-Note, if kernel.org lists two 'stable' version lines on the front page, you
+Note, if kernel.org lists two stable version lines on the front page, you
 should consider switching to the newer one and forget about the older one:
 support for it is likely to be abandoned soon. Then it will get a "end-of-life"
 (EOL) stamp. Version lines that reached that point still get mentioned on the

@@ -1498,7 +1500,9 @@ Reproduce issue with the newest release
 
     *Install the latest release from the particular version line as a vanilla
     kernel. Ensure this kernel is not tainted and still shows the problem, as
-    the issue might have already been fixed there.*
+    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.*
 
 Before investing any more time in this process you want to check if the issue
 was already fixed in the latest release of version line you're interested in.

@@ -1506,14 +1510,22 @@ This kernel needs to be vanilla and shouldn't be tainted before the issue
 happens, as detailed outlined already above in the section "Install a fresh
 kernel for testing".
 
+Did you first notice the regression with a vendor kernel? Then changes the
+vendor applied might be interfering. You need to rule that out by performing
+a recheck. Say something broke when you updated from 5.10.4-vendor.42 to
+5.10.5-vendor.43. Then after testing the latest 5.10 release as outlined in
+the previous paragraph check if a vanilla build of Linux 5.10.4 works fine as
+well. If things are broken there, the issue does not qualify as upstream
+regression and you need switch back to the main step-by-step guide to report
+the issue.
+
 Report the regression
 ~~~~~~~~~~~~~~~~~~~~~
 
-    *Send a short problem report by mail to the people and mailing lists the
-    :ref:`MAINTAINERS <maintainers>` file specifies in the section 'STABLE
-    BRANCH'. 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.*
+    *Send a short problem report to the Linux stable mailing list
+    ([email protected]). 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

@@ -1540,10 +1552,10 @@ the document 'Documentation/admin-guide/bug-bisect.rst' for details how to
 perform one.
 
 
-Reference for "Reporting regressions within a stable and longterm kernel line"
-------------------------------------------------------------------------------
+Reference for "Reporting issues only occurring in older kernel version lines"
+-----------------------------------------------------------------------------
 
-This section provides details for steps you need to take if you could not
+This section provides details for the steps you need to take if you could not
 reproduce your issue with a mainline kernel, but want to see it fixed in older
 version lines (aka stable and longterm kernels).
 

@@ -1648,8 +1660,7 @@ Ask for advice
 If the previous three steps didn't get you closer to a solution there is only
 one option left: ask for advice. Do that in a mail you sent to the maintainers
 for the subsystem where the issue seems to have its roots; CC the mailing list
-for the subsystem as well as the stable mailing list the :ref:`MAINTAINERS
-<maintainers>` file mention in the section "STABLE BRANCH".
+for the subsystem as well as the stable mailing list ([email protected]).
 
 
 Why some issues won't get any reaction or remain unfixed after being reported