[PATCH v1 0/4] Improve reporting-issues.rst and make it official

[PATCH v1 0/4] Improve reporting-issues.rst and make it official

[Thorsten Leemhuis]

This patchset makes reporting-issues.rst fully official and thus removes
reporting-bugs.rst. It also adds an entry for the text in MAINTAINERS as
discussed earlier. Then there is the new text for the TLDR already posted as a
draft and a patch which assorted fixes and small enhancements.

Thorsten Leemhuis (4):
  docs: make reporting-issues.rst official and delete reporting-bugs.rst
  MAINTAINERS: add entry for
    Documentation/admin-guide/reporting-issues.rst
  docs: reporting-issues.rst: reshuffle and improve TLDR
  docs: reporting-issues: reduce quoting and assorted fixes

 Documentation/admin-guide/index.rst           |   1 -
 Documentation/admin-guide/reporting-bugs.rst  | 187 ---------------
 .../admin-guide/reporting-issues.rst          | 218 ++++++++----------
 MAINTAINERS                                   |   6 +
 4 files changed, 96 insertions(+), 316 deletions(-)
 delete mode 100644 Documentation/admin-guide/reporting-bugs.rst


base-commit: 8d295fbad687a61eaa0cf14958c284a3ddbf2173
-- 
2.30.2

[PATCH v1 1/4] docs: make reporting-issues.rst official and delete reporting-bugs.rst

[Thorsten Leemhuis]

Remove the WIP and two FIXME notes in the text to make it official, as
it's now considered fully ready for consumption. To make sure this
step is okay for people the intent of this change and the latest version
of the text were posted to ksummit-discuss; nobody complained, thus
lets move ahead.

Add a footer to point out people can contact Thorsten directly in case
they find something to improve in the text.

Dear reporting-bugs.rst, I'm sorry to tell you, but that makes you fully
obsolete and we thus have to let you go now. Thank you very much for
your service, you in one form or another have been around for a long
time. I'm sure over the years you got read a lot and helped quite a few
people. But it's time to retire now. Rest in peace.

Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
CC: Harry Wei <harryxiyou@gmail.com>
CC: Alex Shi <alex.shi@linux.alibaba.com>
CC: Federico Vaga <federico.vaga@vaga.pv.it>
CC: Greg KH <gregkh@linuxfoundation.org>
---
Removing Documentation/admin-guide/reporting-bugs.rst will break links
in some of the translations. I was unsure if simply changing them to
Documentation/admin-guide/reporting-issue.rst was wise, so I didn't
touch anything for now and CCed the maintainers for the Chinese and
Italian translation. I couldn't find one for the Japanse translation.

Please advice. For completeness, this are the places where things will
break afaics:

$ grep -ri 'reporting-bugs.rst' Documentation/
Documentation/translations/zh_CN/SecurityBugs:是有帮助的信息，那就请重温一下admin-guide/reporting-bugs.rst文件中的概述过程。任
Documentation/translations/zh_CN/process/howto.rst:内核源码主目录中的:ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
Documentation/translations/zh_CN/admin-guide/reporting-issues.rst:   本文档将取代“Documentation/admin-guide/reporting-bugs.rst”。主要的工作
Documentation/translations/zh_CN/admin-guide/reporting-issues.rst:   “Documentation/admin-guide/reporting-bugs.rst”中的旧文字非常相似。它和它
Documentation/translations/it_IT/process/howto.rst:Il file admin-guide/reporting-bugs.rst nella cartella principale del kernel
Documentation/translations/ja_JP/howto.rst:admin-guide/reporting-bugs.rstはカーネルバグらしいものについてどうレポー

Ciao, Thorsten
---
 Documentation/admin-guide/index.rst           |   1 -
 Documentation/admin-guide/reporting-bugs.rst  | 187 ------------------
 .../admin-guide/reporting-issues.rst          |  64 +-----
 3 files changed, 10 insertions(+), 242 deletions(-)
 delete mode 100644 Documentation/admin-guide/reporting-bugs.rst

diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 423116c4e787..dc00afcabb95 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -35,7 +35,6 @@ problems and bugs in particular.
    :maxdepth: 1
 
    reporting-issues
-   Reporting bugs (obsolete) <reporting-bugs>
    security-bugs
    bug-hunting
    bug-bisect
diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst
deleted file mode 100644
index 409fa91d7495..000000000000
--- a/Documentation/admin-guide/reporting-bugs.rst
+++ /dev/null
@@ -1,187 +0,0 @@
-.. _reportingbugs:
-
-.. note::
-
-   This document is obsolete, and will be replaced by
-   'Documentation/admin-guide/reporting-issues.rst' in the near future.
-
-Reporting bugs
-++++++++++++++
-
-Background
-==========
-
-The upstream Linux kernel maintainers only fix bugs for specific kernel
-versions.  Those versions include the current "release candidate" (or -rc)
-kernel, any "stable" kernel versions, and any "long term" kernels.
-
-Please see https://www.kernel.org/ for a list of supported kernels.  Any
-kernel marked with [EOL] is "end of life" and will not have any fixes
-backported to it.
-
-If you've found a bug on a kernel version that isn't listed on kernel.org,
-contact your Linux distribution or embedded vendor for support.
-Alternatively, you can attempt to run one of the supported stable or -rc
-kernels, and see if you can reproduce the bug on that.  It's preferable
-to reproduce the bug on the latest -rc kernel.
-
-
-How to report Linux kernel bugs
-===============================
-
-
-Identify the problematic subsystem
-----------------------------------
-
-Identifying which part of the Linux kernel might be causing your issue
-increases your chances of getting your bug fixed. Simply posting to the
-generic linux-kernel mailing list (LKML) may cause your bug report to be
-lost in the noise of a mailing list that gets 1000+ emails a day.
-
-Instead, try to figure out which kernel subsystem is causing the issue,
-and email that subsystem's maintainer and mailing list.  If the subsystem
-maintainer doesn't answer, then expand your scope to mailing lists like
-LKML.
-
-
-Identify who to notify
-----------------------
-
-Once you know the subsystem that is causing the issue, you should send a
-bug report.  Some maintainers prefer bugs to be reported via bugzilla
-(https://bugzilla.kernel.org), while others prefer that bugs be reported
-via the subsystem mailing list.
-
-To find out where to send an emailed bug report, find your subsystem or
-device driver in the MAINTAINERS file.  Search in the file for relevant
-entries, and send your bug report to the person(s) listed in the "M:"
-lines, making sure to Cc the mailing list(s) in the "L:" lines.  When the
-maintainer replies to you, make sure to 'Reply-all' in order to keep the
-public mailing list(s) in the email thread.
-
-If you know which driver is causing issues, you can pass one of the driver
-files to the get_maintainer.pl script::
-
-     perl scripts/get_maintainer.pl -f <filename>
-
-If it is a security bug, please copy the Security Contact listed in the
-MAINTAINERS file.  They can help coordinate bugfix and disclosure.  See
-:ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` for more information.
-
-If you can't figure out which subsystem caused the issue, you should file
-a bug in kernel.org bugzilla and send email to
-linux-kernel@vger.kernel.org, referencing the bugzilla URL.  (For more
-information on the linux-kernel mailing list see
-http://vger.kernel.org/lkml/).
-
-
-Tips for reporting bugs
------------------------
-
-If you haven't reported a bug before, please read:
-
-	https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
-
-	http://www.catb.org/esr/faqs/smart-questions.html
-
-It's REALLY important to report bugs that seem unrelated as separate email
-threads or separate bugzilla entries.  If you report several unrelated
-bugs at once, it's difficult for maintainers to tease apart the relevant
-data.
-
-
-Gather information
-------------------
-
-The most important information in a bug report is how to reproduce the
-bug.  This includes system information, and (most importantly)
-step-by-step instructions for how a user can trigger the bug.
-
-If the failure includes an "OOPS:", take a picture of the screen, capture
-a netconsole trace, or type the message from your screen into the bug
-report.  Please read "Documentation/admin-guide/bug-hunting.rst" before posting your
-bug report. This explains what you should do with the "Oops" information
-to make it useful to the recipient.
-
-This is a suggested format for a bug report sent via email or bugzilla.
-Having a standardized bug report form makes it easier for you not to
-overlook things, and easier for the developers to find the pieces of
-information they're really interested in.  If some information is not
-relevant to your bug, feel free to exclude it.
-
-First run the ver_linux script included as scripts/ver_linux, which
-reports the version of some important subsystems.  Run this script with
-the command ``awk -f scripts/ver_linux``.
-
-Use that information to fill in all fields of the bug report form, and
-post it to the mailing list with a subject of "PROBLEM: <one line
-summary from [1.]>" for easy identification by the developers::
-
-  [1.] One line summary of the problem:
-  [2.] Full description of the problem/report:
-  [3.] Keywords (i.e., modules, networking, kernel):
-  [4.] Kernel information
-  [4.1.] Kernel version (from /proc/version):
-  [4.2.] Kernel .config file:
-  [5.] Most recent kernel version which did not have the bug:
-  [6.] Output of Oops.. message (if applicable) with symbolic information
-       resolved (see Documentation/admin-guide/bug-hunting.rst)
-  [7.] A small shell script or example program which triggers the
-       problem (if possible)
-  [8.] Environment
-  [8.1.] Software (add the output of the ver_linux script here)
-  [8.2.] Processor information (from /proc/cpuinfo):
-  [8.3.] Module information (from /proc/modules):
-  [8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
-  [8.5.] PCI information ('lspci -vvv' as root)
-  [8.6.] SCSI information (from /proc/scsi/scsi)
-  [8.7.] Other information that might be relevant to the problem
-         (please look in /proc and include all information that you
-         think to be relevant):
-  [X.] Other notes, patches, fixes, workarounds:
-
-
-Follow up
-=========
-
-Expectations for bug reporters
-------------------------------
-
-Linux kernel maintainers expect bug reporters to be able to follow up on
-bug reports.  That may include running new tests, applying patches,
-recompiling your kernel, and/or re-triggering your bug.  The most
-frustrating thing for maintainers is for someone to report a bug, and then
-never follow up on a request to try out a fix.
-
-That said, it's still useful for a kernel maintainer to know a bug exists
-on a supported kernel, even if you can't follow up with retests.  Follow
-up reports, such as replying to the email thread with "I tried the latest
-kernel and I can't reproduce my bug anymore" are also helpful, because
-maintainers have to assume silence means things are still broken.
-
-Expectations for kernel maintainers
------------------------------------
-
-Linux kernel maintainers are busy, overworked human beings.  Some times
-they may not be able to address your bug in a day, a week, or two weeks.
-If they don't answer your email, they may be on vacation, or at a Linux
-conference.  Check the conference schedule at https://LWN.net for more info:
-
-	https://lwn.net/Calendar/
-
-In general, kernel maintainers take 1 to 5 business days to respond to
-bugs.  The majority of kernel maintainers are employed to work on the
-kernel, and they may not work on the weekends.  Maintainers are scattered
-around the world, and they may not work in your time zone.  Unless you
-have a high priority bug, please wait at least a week after the first bug
-report before sending the maintainer a reminder email.
-
-The exceptions to this rule are regressions, kernel crashes, security holes,
-or userspace breakage caused by new kernel behavior.  Those bugs should be
-addressed by the maintainers ASAP.  If you suspect a maintainer is not
-responding to these types of bugs in a timely manner (especially during a
-merge window), escalate the bug to LKML and Linus Torvalds.
-
-Thank you!
-
-[Some of this is taken from Frohwalt Egerer's original linux-kernel FAQ]
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index 1fc98276160e..ca809a4be620 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -9,25 +9,6 @@
    (for example by the kernel's build system) might contain content taken from
    files which use a more restrictive license.
 
-.. important::
-
-   This document is being prepared to replace
-   'Documentation/admin-guide/reporting-bugs.rst'. The main work is done and
-   you are already free to follow its instructions when reporting issues to the
-   Linux kernel developers. But keep in mind, below text still needs a few
-   finishing touches and review. It was merged to the Linux kernel sources at
-   this stage to make this process easier and increase the text's visibility.
-
-   Any improvements for the text or other feedback is thus very much welcome.
-   Please send it to 'Thorsten Leemhuis <linux@leemhuis.info>' and 'Jonathan
-   Corbet <corbet@lwn.net>', ideally with 'Linux kernel mailing list (LKML)
-   <linux-kernel@vger.kernel.org>' and the 'Linux Kernel Documentation List
-   <linux-doc@vger.kernel.org>' in CC.
-
-   Areas in the text that still need work or discussion contain a hint like this
-   which point out the remaining issues; all of them start with the word "FIXME"
-   to make them easy to find.
-
 
 Reporting issues
 ++++++++++++++++
@@ -710,26 +691,6 @@ example above does not have such a line. That is the case for most sections, as
 Linux kernel development is completely driven by mail. Very few subsystems use
 a bug tracker, and only some of those rely on bugzilla.kernel.org.
 
-
-.. note::
-
-   FIXME: The old text took a totally different approach to bugzilla.kernel.org,
-   as it mentions it as the place to file issue for people that don't known how
-   to contact the appropriate people. The new one mentions it rarely; and when
-   it does like here, it warns users that it's often the wrong place to go.
-
-   This approach was chosen as the main author of this document noticed quite a
-   few users (or even a lot?) get no reply to the bugs they file in bugzilla.
-   That's kind of expected, as quite a few (many? most?) of the maintainers
-   don't even get notified when reports for their subsystem get filed there. And
-   not getting a single reply to report is something that is just annoying for
-   users and might make them angry. Improving bugzilla.k.o would be an option,
-   but on the kernel and maintainers summit 2017 it was agreed on to first go
-   this route (sorry it took so long): it's easier to achieve and less
-   controversial, as putting additional burden on already overworked maintainers
-   is unlikely to get well received.
-
-
 In this and many other cases you thus have to look for lines starting with
 'Mail:' instead. Those mention the name and the email addresses for the
 maintainers of the particular code. Also look for a line starting with 'Mailing
@@ -742,21 +703,6 @@ and might leave some work for other developers on the subsystem specific list;
 and LKML is important to have one place where all issue reports can be found.
 
 
-.. note::
-
-   FIXME: Above section tells users to always CC LKML. These days it's a kind of
-   "catch-all" list anyway, which nearly nobody seems to follow closely. So it
-   seems appropriate to go "all in" and make people send their reports here,
-   too, as everything (reports, fixes, ...) then can be found in one place (at
-   least for all reports sent by mail and all subsystems that CC LKML).
-
-   Related: Should we create mailing list like 'linux-issues@vger.kernel.org'
-   and tell users above to always CC it when reporting issues? Then there would
-   be one central place reporters could search for existing reports (at least
-   for issues reported by mail) without getting regular LKML traffic mixed into
-   the results.
-
-
 Finding the maintainers with the help of a script
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -1776,3 +1722,13 @@ issues to the Linux kernel developers: the length and complexity of this
 document and the implications between the lines illustrate that. But that's how
 it is for now. The main author of this text hopes documenting the state of the
 art will lay some groundwork to improve the situation over time.
+
+
+..
+   This text is maintained by Thorsten Leemhuis <linux@leemhuis.info>. If you
+   spot a typo or small mistake, feel free to let him know directly and he'll
+   fix it. You are free to do the same in a mostly informal way if you want
+   to contribute changes to the text, but for copyright reasons please CC
+   linux-doc@vger.kernel.org and "sign-off" your contribution as
+   Documentation/process/submitting-patches.rst outlines in the section "Sign
+   your work - the Developer's Certificate of Origin".
-- 
2.30.2

Re: [PATCH v1 1/4] docs: make reporting-issues.rst official and delete reporting-bugs.rst

[Greg KH]

On Tue, Mar 30, 2021 at 04:13:04PM +0200, Thorsten Leemhuis wrote:
> Removing Documentation/admin-guide/reporting-bugs.rst will break links
> in some of the translations. I was unsure if simply changing them to
> Documentation/admin-guide/reporting-issue.rst was wise, so I didn't
> touch anything for now and CCed the maintainers for the Chinese and
> Italian translation. I couldn't find one for the Japanse translation.
> 
> Please advice. For completeness, this are the places where things will
> break afaics:
> 
> $ grep -ri 'reporting-bugs.rst' Documentation/
> Documentation/translations/zh_CN/SecurityBugs:是有帮助的信息，那就请重温一下admin-guide/reporting-bugs.rst文件中的概述过程。任
> Documentation/translations/zh_CN/process/howto.rst:内核源码主目录中的:ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
> Documentation/translations/zh_CN/admin-guide/reporting-issues.rst:   本文档将取代“Documentation/admin-guide/reporting-bugs.rst”。主要的工作
> Documentation/translations/zh_CN/admin-guide/reporting-issues.rst:   “Documentation/admin-guide/reporting-bugs.rst”中的旧文字非常相似。它和它
> Documentation/translations/it_IT/process/howto.rst:Il file admin-guide/reporting-bugs.rst nella cartella principale del kernel
> Documentation/translations/ja_JP/howto.rst:admin-guide/reporting-bugs.rstはカーネルバグらしいものについてどうレポー

Traditionally translations catch up much later on, you shouldn't have to
worry about them the authors will clean them up and submit patches for
them when they get the chance.

thanks,

greg k-h

Re: [PATCH v1 1/4] docs: make reporting-issues.rst official and delete reporting-bugs.rst

[Jonathan Corbet]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Tue, Mar 30, 2021 at 04:13:04PM +0200, Thorsten Leemhuis wrote:
>> Removing Documentation/admin-guide/reporting-bugs.rst will break links
>> in some of the translations. I was unsure if simply changing them to
>> Documentation/admin-guide/reporting-issue.rst was wise, so I didn't
>> touch anything for now and CCed the maintainers for the Chinese and
>> Italian translation. I couldn't find one for the Japanse translation.
>
> Traditionally translations catch up much later on, you shouldn't have to
> worry about them the authors will clean them up and submit patches for
> them when they get the chance.

Agreed.  None of the broken references actually generate warnings
(though perhaps some should) so we can let the translators catch up on
their own time.

I've applied the set and stuck in this tweak:

> FWIW, this needs a
> 
>  s!stable/>_`!stable/>`_!
> 
> Sorry, this slipped through. :-/ Ciao, Thorsten

while I was at it.

Thanks,

jon

Re: [PATCH v1 1/4] docs: make reporting-issues.rst official and delete reporting-bugs.rst

[Thorsten Leemhuis]

On 31.03.21 21:47, Jonathan Corbet wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> 
>> On Tue, Mar 30, 2021 at 04:13:04PM +0200, Thorsten Leemhuis wrote:
>>> Removing Documentation/admin-guide/reporting-bugs.rst will break links
>>> in some of the translations. I was unsure if simply changing them to
>>> Documentation/admin-guide/reporting-issue.rst was wise, so I didn't
>>> touch anything for now and CCed the maintainers for the Chinese and
>>> Italian translation. I couldn't find one for the Japanse translation.
>>
>> Traditionally translations catch up much later on, you shouldn't have to
>> worry about them the authors will clean them up and submit patches for
>> them when they get the chance.
> 
> Agreed.  None of the broken references actually generate warnings
> (though perhaps some should) so we can let the translators catch up on
> their own time.

Ahh, good to know.

BTW to the translators in the CC: sorry for not giving you a heads up
earlier, things were supposed to get slower, but then had to be
accelerated.

> I've applied the set and stuck in this tweak:
> 
>> FWIW, this needs a
>>
>>  s!stable/>_`!stable/>`_!
>>
>> Sorry, this slipped through. :-/ Ciao, Thorsten
> 
> while I was at it.

Great, thx everyone, that what I had hoped for when I posted it.

BTW, can't see the patches in docs-next yet, but I just assume it's just
not pushed out yet for some reason. Whatever.

Side note, FWIW: I have no further patches for the text in my queue, but
I might sent one depending on how fast the new mailing list
linux-regressions will be created (will as for that later today).

Ciao, Thorsten

Re: [PATCH v1 1/4] docs: make reporting-issues.rst official and delete reporting-bugs.rst

[Greg KH]

On Tue, Mar 30, 2021 at 04:13:04PM +0200, Thorsten Leemhuis wrote:
> Remove the WIP and two FIXME notes in the text to make it official, as
> it's now considered fully ready for consumption. To make sure this
> step is okay for people the intent of this change and the latest version
> of the text were posted to ksummit-discuss; nobody complained, thus
> lets move ahead.
> 
> Add a footer to point out people can contact Thorsten directly in case
> they find something to improve in the text.
> 
> Dear reporting-bugs.rst, I'm sorry to tell you, but that makes you fully
> obsolete and we thus have to let you go now. Thank you very much for
> your service, you in one form or another have been around for a long
> time. I'm sure over the years you got read a lot and helped quite a few
> people. But it's time to retire now. Rest in peace.
> 
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> CC: Harry Wei <harryxiyou@gmail.com>
> CC: Alex Shi <alex.shi@linux.alibaba.com>
> CC: Federico Vaga <federico.vaga@vaga.pv.it>
> CC: Greg KH <gregkh@linuxfoundation.org>

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

Re: [PATCH v1 1/4] docs: make reporting-issues.rst official and delete reporting-bugs.rst

[Wu X.C.]

Cc Alex Shi's new email <alexs@kernel.org>

On Tue, Mar 30, 2021 at 04:13:04PM +0200, Thorsten Leemhuis wrote:
> Removing Documentation/admin-guide/reporting-bugs.rst will break links
> in some of the translations. I was unsure if simply changing them to
> Documentation/admin-guide/reporting-issue.rst was wise, so I didn't
> touch anything for now and CCed the maintainers for the Chinese and
> Italian translation. I couldn't find one for the Japanse translation.
> 
> Please advice. For completeness, this are the places where things will
> break afaics:
> 
> $ grep -ri 'reporting-bugs.rst' Documentation/
> Documentation/translations/zh_CN/SecurityBugs:是有帮助的信息，那就请重温一下admin-guide/reporting-bugs.rst文件中的概述过程。任
> Documentation/translations/zh_CN/process/howto.rst:内核源码主目录中的:ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
> Documentation/translations/zh_CN/admin-guide/reporting-issues.rst:   本文档将取代“Documentation/admin-guide/reporting-bugs.rst”。主要的工作
> Documentation/translations/zh_CN/admin-guide/reporting-issues.rst:   “Documentation/admin-guide/reporting-bugs.rst”中的旧文字非常相似。它和它

Yeah, as Greg said, we will solve that after you patches be merged in next
tree. Since I have translate the zh reporting-issues.rst in the next tree,
will correct the link when I sync it with your new version. May cause 
Warning for some days, but don't worry about it.

Wu X.C.

> Documentation/translations/it_IT/process/howto.rst:Il file admin-guide/reporting-bugs.rst nella cartella principale del kernel
> Documentation/translations/ja_JP/howto.rst:admin-guide/reporting-bugs.rstはカーネルバグらしいものについてどうレポー
> 
> Ciao, Thorsten

Re: [PATCH v1 1/4] docs: make reporting-issues.rst official and delete reporting-bugs.rst

[Alex Shi]

On 2021/3/31 下午4:33, Wu X.C. wrote:
> Cc Alex Shi's new email <alexs@kernel.org>
> 
> On Tue, Mar 30, 2021 at 04:13:04PM +0200, Thorsten Leemhuis wrote:
>> Removing Documentation/admin-guide/reporting-bugs.rst will break links
>> in some of the translations. I was unsure if simply changing them to
>> Documentation/admin-guide/reporting-issue.rst was wise, so I didn't

A bit time info late won't hurt sth, people would update them soon if it's
their care.

>> touch anything for now and CCed the maintainers for the Chinese and
>> Italian translation. I couldn't find one for the Japanse translation.
>>
>> Please advice. For completeness, this are the places where things will
>> break afaics:
>>
>> $ grep -ri 'reporting-bugs.rst' Documentation/
>> Documentation/translations/zh_CN/SecurityBugs:是有帮助的信息，那就请重温一下admin-guide/reporting-bugs.rst文件中的概述过程。任
>> Documentation/translations/zh_CN/process/howto.rst:内核源码主目录中的:ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
>> Documentation/translations/zh_CN/admin-guide/reporting-issues.rst:   本文档将取代“Documentation/admin-guide/reporting-bugs.rst”。主要的工作
>> Documentation/translations/zh_CN/admin-guide/reporting-issues.rst:   “Documentation/admin-guide/reporting-bugs.rst”中的旧文字非常相似。它和它
> 
> Yeah, as Greg said, we will solve that after you patches be merged in next
> tree. Since I have translate the zh reporting-issues.rst in the next tree,
> will correct the link when I sync it with your new version. May cause 
> Warning for some days, but don't worry about it.

yes, also thanks for generous commitment!

thanks
Alex

[PATCH v1 2/4] MAINTAINERS: add entry for Documentation/admin-guide/reporting-issues.rst

[Thorsten Leemhuis]

Thorsten will keep an eye on the new document about reporting issues
(aka bugs).

Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e66ff3daf23c..b5d38fedff6c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5413,6 +5413,12 @@ X:	Documentation/power/
 X:	Documentation/spi/
 X:	Documentation/userspace-api/media/
 
+DOCUMENTATION REPORTING ISSUES
+M:	Thorsten Leemhuis <linux@leemhuis.info>
+L:	linux-doc@vger.kernel.org
+S:	Maintained
+F:	Documentation/admin-guide/reporting-issues.rst
+
 DOCUMENTATION SCRIPTS
 M:	Mauro Carvalho Chehab <mchehab@kernel.org>
 L:	linux-doc@vger.kernel.org
-- 
2.30.2

[PATCH v1 3/4] docs: reporting-issues.rst: reshuffle and improve TLDR

[Thorsten Leemhuis]

Make the TLDR a bit shorter while improving it at the same time by going
straight to the aspects readers are more interested it. The change makes
the process especially more straight-forward for people that hit a
regression in a stable or longterm kernel. Due to the changes the TLDR
now also matches the step by step guide better.

Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
v1
- Incorporated feedback received from posting a draft to LKML. Also
  slightly change the beginning of the third paragraph to improve the
  flow.
---
 .../admin-guide/reporting-issues.rst          | 75 +++++++++----------
 1 file changed, 35 insertions(+), 40 deletions(-)

diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index ca809a4be620..77d38acca282 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -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 (stable@vger.kernel.org).
+
+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
 =================================================================
-- 
2.30.2

Re: [PATCH v1 3/4] docs: reporting-issues.rst: reshuffle and improve TLDR

[Thorsten Leemhuis]

Argh, sent this just one hour ago and I already found the first problem:

On 30.03.21 16:13, Thorsten Leemhuis wrote:
> Make the TLDR a bit shorter while improving it at the same time by going
> straight to the aspects readers are more interested it. The change makes
> the process especially more straight-forward for people that hit a
> regression in a stable or longterm kernel. Due to the changes the TLDR
> now also matches the step by step guide better.
> 
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> 
>[...]
> +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/>_` 

FWIW, this needs a

 s!stable/>_`!stable/>`_!

Sorry, this slipped through. :-/ Ciao, Thorsten

[PATCH v1 4/4] docs: reporting-issues: reduce quoting and assorted fixes

[Thorsten Leemhuis]

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

A pile of small fixes:

- don't quote terms like vanilla, mainline, and stable, unless in they
  occur in places where readers new to the kernel might see them for the
  first time

- make people rule out that vendor patches are interfering if they face
  a regression in a stable or longterm kernel they saw in a vendor
  kernel for the first time

- s/bugs/issues/ in a selected spots

- exchange two headlines that got mixed up somehow

- add a few links to some of the steps in the guide

- Greg mentioned sending reports to the stable mailing list is
  sufficient, so remove the "CC stable maintainers" bits

- fix a few typos and mistakes in the text, with a few very small
  improvements along the way

Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
 .../admin-guide/reporting-issues.rst          | 79 +++++++++++--------
 1 file changed, 45 insertions(+), 34 deletions(-)

diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index 77d38acca282..e6137c971007 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -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
+   (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.*
 
 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
+    (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.*
 
 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 (stable@vger.kernel.org).
 
 
 Why some issues won't get any reaction or remain unfixed after being reported
-- 
2.30.2