Message-ID: <b7ab110b-3f4d-382c-5802-5dd4291ea118@infradead.org>
Date:   Thu, 1 Oct 2020 20:25:56 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Thorsten Leemhuis <linux@...mhuis.info>,
        Jonathan Corbet <corbet@....net>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 04/26] docs: reporting-bugs: step-by-step guide for
 issues in stable & longterm

On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> Handle stable and longterm kernels in a subsection, as dealing with them
> directly in the main part of the step-by-step guide turned out to make
> it messy and hard to follow: it looked a bit like code with a large
> amount of if-then-else section to handle special cases, which made the
> default code-flow hard to understand.
> 
> Yet again each step will later be repeated in a reference section and
> described in more detail.
> 
> Signed-off-by: Thorsten Leemhuis <linux@...mhuis.info>
> ---
>  Documentation/admin-guide/reporting-bugs.rst | 49 ++++++++++++++++++++
>  1 file changed, 49 insertions(+)
> 
> diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst
> index 203df36af55f..e0a6f4328e87 100644
> --- a/Documentation/admin-guide/reporting-bugs.rst
> +++ b/Documentation/admin-guide/reporting-bugs.rst
> @@ -156,6 +156,55 @@ After these preparations you'll now enter the main part:
>     yourself, if you don't get any help or if it is unsatisfying.
>  
>  
> +Reporting issues only occurring in older kernel version lines
> +-------------------------------------------------------------
> +
> +This section is for you, if you tried the latest mainline kernel as outlined
> +above, but failed to reproduce your issue there; at the same time you want to
> +see the issue fixed in older version lines or a vendor kernel that's regularly
> +rebased on new stable or longterm releases. If that case follow these steps:
> +
> + * Prepare yourself for the possibility that going through the next few steps
> +   might not get the issue solved in older releases: the fix might be too big or
> +   risky to get backported there.
> +
> + * Check if the kernel developers still maintain the Linux kernel version line
> +   you care about: go to `the front-page of kernel.org <https://kernel.org>`_
> +   and make sure it mentions the latest release of the particular version line
> +   without an '[EOL]' tag.

Explain somewhere that EOL = End Of Life (in parens).

> +
> + * Check the `archives of the Linux stable mailing list
> +   <https://lore.kernel.org/stable/>`_  for existing reports.
> +
> + * Install the latest release from the particular version line as a vanilla
> +   kernel. Ensure this kernel is not tainted and still shows the problem, as the
> +   issue might have already been fixed there.
> +
> + * Search the Linux kernel version control system for the change that fixed
> +   the issue in mainline, as its commit message might tell you if the fix is
> +   scheduled for backporting already. If you don't find anything that way,
> +   search the appropriate mailing lists for posts that discuss such an issue or
> +   peer-review possible fixes. That might lead you to the commit with the fix
> +   or tell you if it's unsuitable for backporting. If backporting was not
> +   considered at all, join the newest discussion, asking if its in the cards.

                                                               it's

> +
> + * Check if you're dealing with a regression that was never present in
> +   mainline by installing the first release of the version line you care about.
> +   If the issue doesn't show up with it, you basically need to report the issue
> +   with this version like you would report a problem with mainline (see above).
> +   This ideally includes a bisection followed by a search for existing reports
> +   on the net; with the help of the subject and the two relevant commit-ids. If
> +   that doesn't turn up anything, write the report; CC or forward the report to
> +   the stable maintainers, the stable mailing list, and those that authored the

                                                           those who (?)

> +   change. Include the shortened commit-id if you found the change that causes
> +   it.
> +
> + * One of the former steps should lead to a solution. If that doesn't work out,
> +   ask the maintainers for the subsystem that seems to be causing the issue for
> +   advice; CC the mailing list for the particular subsystem as well as the
> +   stable mailing list.
> +
> +
>  .. ############################################################################
>  .. Temporary marker added while this document is rewritten. Sections above
>  .. are new and dual-licensed under GPLv2+ and CC-BY 4.0, those below are old.
> 


-- 
~Randy

Powered by blists - more mailing lists