Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC PATCH v1 07/26] docs: reporting-bugs: let users classify
 their issue
To:     Thorsten Leemhuis <linux@leemhuis.info>,
        Jonathan Corbet <corbet@lwn.net>
Cc:     linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
References: <cover.1601541165.git.linux@leemhuis.info>
 <d9917c1f15a965f75f20ca9f0db4ca3ae24c9e98.1601541165.git.linux@leemhuis.info>
From:   Randy Dunlap <rdunlap@infradead.org>
Message-ID: <9a6e344f-71ca-209f-c540-3a03949a3a94@infradead.org>
Date:   Fri, 2 Oct 2020 09:59:48 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <d9917c1f15a965f75f20ca9f0db4ca3ae24c9e98.1601541165.git.linux@leemhuis.info>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> Explicitly outline that some issues are more important than others and
> thus need to be handled differently in some steps that are about to
> follow. This makes things explicit and easy to find if you need to look
> up what issues actually qualify as "regression" or a "severe problem".
> 
> The alternative would have been: explain each of the three types in the
> place where it requires special handling for the first time. But that
> makes it quite easy to miss and harder to find when you need to look it
> up.
> 
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> ---
>  Documentation/admin-guide/reporting-bugs.rst | 39 ++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst
> index 434e1a890dfe..430a0c3ee0ad 100644
> --- a/Documentation/admin-guide/reporting-bugs.rst
> +++ b/Documentation/admin-guide/reporting-bugs.rst
> @@ -272,6 +272,45 @@ you want to circumvent it consider installing the mainline kernel yourself; just
>  make sure it's the latest one (see below).
>  
>  
> +Issue of high priority?
> +-----------------------
> +
> +    *See if the issue you are dealing with qualifies as regression, security
> +    issue, or a really severe problem: those are 'issues of high priority' that
> +    need special handling in some steps that are about to follow.*
> +
> +Linus Torvalds and the leading Linux kernel developers want to see some issues
> +fixed as soon as possible, hence these 'issues of high priority' get handled
> +slightly different in the reporting process. Three type of cases qualify:

            differently
at least that's what I would say. :)

> +regressions, security issues, and really severe problems.
> +
> +You deal with a 'regression' if something that worked with an older version of
> +the Linux kernel does not work with a newer one or somehow works worse with it.
> +It thus is a regression when a Wi-Fi driver that did a fine job with Linux 5.7
> +somehow misbehaves with 5.8 or doesn't work at all. It's also a regression if
> +an application shows erratic behavior with a newer kernel, which might happen
> +due to incompatible changes in the interface between the kernel and the
> +userland (like procfs and sysfs). Significantly reduced performance or
> +increased power consumption also qualify as regression. But keep in mind: the
> +new kernel needs to be build with a configuration that is similar to the one

                          built

> +from the old kernel (see below how to archive that). That's because

                                         achieve

> +process is sometimes only possible by doing incompatible changes; but to avoid

eh?  That's because ... ???

> +regression such changes have to be enabled explicitly during build time
> +configuration.
> +
> +What qualifies as security issue is left to your judgment. Consider reading
> +:ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` before
> +proceeding.
> +
> +An issue is a 'really severe problem' when something totally unacceptable bad

                                                                unacceptably

> +happens. That's for example the case when a Linux kernel corrupts the data it's
> +handling or damages hardware it's running on. You're also dealing with a severe
> +issue when the kernel suddenly stops working with an error message ('kernel
> +panic') or without any farewell note at all. Note: do not confused a 'panic' (a

                                                             confuse

> +fatal error where the kernels stop itself) with a 'Oops' (a recoverable error),
> +as the kernel remains running after an 'Oops'.
> +
> +
>  .. ############################################################################
>  .. 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
Reported-by: Randy Dunlap <rdunlap@infradead.org>