From: Thorsten Leemhuis <linux@leemhuis.info>
To: ksummit <ksummit-discuss@lists.linuxfoundation.org>,
Greg KH <gregkh@linuxfoundation.org>,
Sasha Levin <sashal@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-doc@vger.kernel.org
Subject: [Ksummit-discuss] [1/5] reporting-issues: header and TLDR
Date: Fri, 26 Mar 2021 07:15:17 +0100 [thread overview]
Message-ID: <6a220d2c-568e-2e41-53a4-0800e206d0a6@leemhuis.info> (raw)
In-Reply-To: <c396c91f-27c2-de36-7b05-099e03c213f4@leemhuis.info>
On 26.03.21 07:13, Thorsten Leemhuis wrote:
>
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that basically says "this is WIP".
> But I'd like to remove that warning and delete reporting-bugs.rst in the
> next merge window to make reporting-issues.rst fully official. With this
> mail I want to give everyone a chance to take a look at the text and
> speak up if you don't want me to move ahead for now.
>
> For easier review I'll post the text of reporting-issues.rst in reply to
> this mail. I'll do that in a few chunks, as if this was a cover letter
> for a patch-set.
Here we go:
.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
..
If you want to distribute this text under CC-BY-4.0 only, please use 'The
Linux kernel developers' for author attribution and link this as source:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst
..
Note: Only the content of this RST file as found in the Linux kernel sources
is available under CC-BY-4.0, as versions of this text that were processed
(for example by the kernel's build system) might contain content taken from
files which use a more restrictive license.
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.
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
next prev parent reply other threads:[~2021-03-26 6:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-26 6:13 [Ksummit-discuss] FYI & RFC: obsoleting reporting-bugs and making reporting-issues official Thorsten Leemhuis
2021-03-26 6:15 ` Thorsten Leemhuis [this message]
2021-03-26 6:23 ` [Ksummit-discuss] [1/5] reporting-issues: header and TLDR Guenter Roeck
2021-03-26 9:41 ` Thorsten Leemhuis
2021-03-28 9:23 ` Thorsten Leemhuis
2021-03-28 10:03 ` Greg KH
2021-03-29 22:44 ` Jonathan Corbet
2021-03-30 5:59 ` Greg KH
2021-03-30 8:41 ` Thorsten Leemhuis
2021-03-26 6:16 ` [Ksummit-discuss] [2/5] reporting-issues: step-by-step-guide: main and two sub-processes for stable/longterm Thorsten Leemhuis
2021-03-26 8:57 ` Greg KH
2021-03-26 6:19 ` [Ksummit-discuss] [4/5] reporting-issues: reference section, stable and longterm sub-processes Thorsten Leemhuis
2021-03-26 6:19 ` [Ksummit-discuss] [5/5] reporting-issues: addendum Thorsten Leemhuis
2021-03-26 6:55 ` [Ksummit-discuss] FYI & RFC: obsoleting reporting-bugs and making reporting-issues official Thorsten Leemhuis
2021-03-26 6:57 ` [Ksummit-discuss] [3a/5] reporting-issues: reference section, main guide Thorsten Leemhuis
2021-03-26 6:59 ` [Ksummit-discuss] [3b/5] " Thorsten Leemhuis
2021-03-26 8:59 ` [Ksummit-discuss] FYI & RFC: obsoleting reporting-bugs and making reporting-issues official Greg KH
2021-03-26 9:48 ` Thorsten Leemhuis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a220d2c-568e-2e41-53a4-0800e206d0a6@leemhuis.info \
--to=linux@leemhuis.info \
--cc=gregkh@linuxfoundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sashal@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).