ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Thorsten Leemhuis <linux@leemhuis.info>
To: ksummit <ksummit-discuss@lists.linuxfoundation.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Sasha Levin <sashal@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	Randy Dunlap <rdunlap@infradead.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Subject: Re: [Ksummit-discuss] [1/5] reporting-issues: header and TLDR
Date: Sun, 28 Mar 2021 11:23:30 +0200	[thread overview]
Message-ID: <14d9b8a3-94ce-00a6-a17b-934ffd999697@leemhuis.info> (raw)
In-Reply-To: <6a220d2c-568e-2e41-53a4-0800e206d0a6@leemhuis.info>

On 26.03.21 07:15, Thorsten Leemhuis wrote:
> 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:
> [...]
> Reporting issues
> ++++++++++++++++
> The short guide (aka TL;DR)
> ===========================
> [...]

FWIW, on another channel someone mentioned the process in the TLDR is
quite complicated when it comes to regressions in stable and longterm
kernels. I looked at the text and it seemed like a valid complaint, esp.
as those regressions are something we really care about.

To solve this properly I sadly had to shake up the text in this section
completely and rewrite parts of it. Find the result below. I'm quite
happy with it, as it afaics is more straight forward and easier to
understand. And it matches the step-by-step guide better. And the best
thing: it's a bit shorter than the old TLDR.

I'll wait a day or two and then will send it through the regular review
together with a few small other fixes that piled up for the text, just
wanted to add it here for completeness.

The short guide (aka TL;DR)

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 and the stable maintainers.

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.

If you would like to see the issue also fixed in a still supported
stable or longterm series, 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.


Ciao, Thorsten
Ksummit-discuss mailing list

  parent reply	other threads:[~2021-03-28  9:23 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 ` [Ksummit-discuss] [1/5] reporting-issues: header and TLDR Thorsten Leemhuis
2021-03-26  6:23   ` Guenter Roeck
2021-03-26  9:41     ` Thorsten Leemhuis
2021-03-28  9:23   ` Thorsten Leemhuis [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14d9b8a3-94ce-00a6-a17b-934ffd999697@leemhuis.info \
    --to=linux@leemhuis.info \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=sashal@kernel.org \
    --subject='Re: [Ksummit-discuss] [1/5] reporting-issues: header and TLDR' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).