From: Thorsten Leemhuis <email@example.com> To: ksummit <firstname.lastname@example.org>, Greg KH <email@example.com>, Sasha Levin <firstname.lastname@example.org>, Jonathan Corbet <email@example.com>, Randy Dunlap <firstname.lastname@example.org> Cc: Linux Kernel Mailing List <email@example.com>, firstname.lastname@example.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: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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 Ksummitemail@example.com https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
next prev 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: 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [Ksummit-discuss] [1/5] reporting-issues: header and TLDR' \ /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
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).