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
