Re: [RFC PATCH v1 02/26] docs: reporting-bugs: Create a TLDR how to report issues

[Thorsten Leemhuis <linux@leemhuis.info>]

Am 03.10.20 um 09:27 schrieb Thorsten Leemhuis:
> Randy, many thanks for looking through this, you feedback is much
> appreciated! Consider all the obvious spelling and grammatical mistakes
> you pointed out fixed, I won't mention all of them in this reply to keep
> things easier to follow.
> 
> Am 02.10.20 um 04:32 schrieb Randy Dunlap:
>> On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
>> […]
>>> +<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/MAINTAINERS>`_
>>> +how developers of that particular area expect to be told about issues; note,
>>     for how
>> ?
> Not sure myself, but I guess you're right and thus followed your advice :-D

I'm preparing to send v2 and was a bit unhappy with this and another 
section when seeing it again after weeks. In the end I reshuffled and 
rewrote significant parts of it, see below.

Randy, would be great if you could take another look, but no pressure: 
just ignore it, if you lack the time or energy.

```
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 it 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 impassable. 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, it round about needs to be reported like a problem in mainline 
(including the bisection).

If you reached this point without a solution, ask for advice one the 
subsystem's mailing list.
```

Ciao, Thorsten