linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thorsten Leemhuis <linux@leemhuis.info>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Randy Dunlap <rdunlap@infradead.org>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC PATCH v2 07/26] docs: reporting-bugs: let users classify their issue
Date: Thu, 12 Nov 2020 18:58:44 +0100	[thread overview]
Message-ID: <f2cf323b319067fbfd46f4d1f3b600a63f567a65.1605203187.git.linux@leemhuis.info> (raw)
In-Reply-To: <cover.1605203187.git.linux@leemhuis.info>

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 9122889509de..fdd79d99c18f 100644
--- a/Documentation/admin-guide/reporting-bugs.rst
+++ b/Documentation/admin-guide/reporting-bugs.rst
@@ -280,6 +280,45 @@ mainline kernel yourself and reporting the issue as outlined in this document;
 just make sure to use really fresh kernel (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 there are 'issues of high priority' that get
+handled slightly differently in the reporting process. Three type of cases
+qualify: 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 WiFi 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 built with a configuration that is similar to the one
+from the old kernel (see below how to achieve that). That's because the kernel
+developers sometimes can not avoid incompatibilities when implementing new
+features; but to avoid regressions such features 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 unacceptably bad
+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 confuse a 'panic' (a
+fatal error where the kernel stop itself) with a 'Oops' (a recoverable error),
+as the kernel remains running after the latter.
+
+
 .. ############################################################################
 .. 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.
-- 
2.28.0


  parent reply	other threads:[~2020-11-12 18:02 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-12 17:58 [RFC PATCH v2 00/26] Make reporting-bugs easier to grasp and yet more detailed & helpful Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 01/26] docs: reporting-bugs: temporary markers for licensing and diff reasons Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 02/26] docs: reporting-bugs: Create a TLDR how to report issues Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 03/26] docs: reporting-bugs: step-by-step guide on " Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 04/26] docs: reporting-bugs: step-by-step guide for issues in stable & longterm Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 05/26] docs: reporting-bugs: begin reference section providing details Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 06/26] docs: reporting-bugs: point out we only care about fresh vanilla kernels Thorsten Leemhuis
2020-11-12 17:58 ` Thorsten Leemhuis [this message]
2020-11-12 17:58 ` [RFC PATCH v2 08/26] docs: reporting-bugs: make readers check the taint flag Thorsten Leemhuis
2020-11-19  0:05   ` Jonathan Corbet
2020-11-19 10:26     ` Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 09/26] docs: reporting-bugs: help users find the proper place for their report Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 10/26] docs: reporting-bugs: remind people to look for existing reports Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 11/26] docs: reporting-bugs: remind people to back up their data Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 12/26] docs: reporting-bugs: tell users to disable DKMS et al Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 13/26] docs: reporting-bugs: point out the environment might be causing issue Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 14/26] docs: reporting-bugs: make users write notes, one for each issue Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 15/26] docs: reporting-bugs: make readers test a fresh kernel Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 16/26] docs: reporting-bugs: let users check taint status again Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 17/26] docs: reporting-bugs: explain options if reproducing on mainline fails Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 18/26] docs: reporting-bugs: let users optimize their notes Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 19/26] docs: reporting-bugs: decode failure messages [need help!] Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 20/26] docs: reporting-bugs: instructions for handling regressions Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 21/26] docs: reporting-bugs: details on writing and sending the report Thorsten Leemhuis
2020-11-19  0:17   ` Jonathan Corbet
2020-11-19  9:42     ` Thorsten Leemhuis
2020-11-12 17:58 ` [RFC PATCH v2 22/26] docs: reporting-bugs: explain what users should do once the report is out Thorsten Leemhuis
2020-11-12 17:59 ` [RFC PATCH v2 23/26] docs: reporting-bugs: details for issues specific to stable and longterm Thorsten Leemhuis
2020-11-12 17:59 ` [RFC PATCH v2 24/26] docs: reporting-bugs: explain why users might get neither reply nor fix Thorsten Leemhuis
2020-11-12 17:59 ` [RFC PATCH v2 25/26] docs: reporting-bugs: explain things could be easier Thorsten Leemhuis
2020-11-12 17:59 ` [RFC PATCH v2 26/26] docs: reporting-bugs: add SPDX tag and license hint, remove markers Thorsten Leemhuis
2020-11-13 22:33 ` [RFC PATCH v2 00/26] Make reporting-bugs easier to grasp and yet more detailed & helpful Jonathan Corbet
2020-11-13 22:47   ` Randy Dunlap
2020-11-15 10:13   ` Thorsten Leemhuis
2020-11-19  0:29     ` Jonathan Corbet
2020-11-19 12:29       ` Thorsten Leemhuis
2020-11-19 16:20         ` Randy Dunlap
2020-11-20 21:59         ` Jonathan Corbet
2020-11-20 10:46       ` Thorsten Leemhuis
2020-11-20 16:27         ` Randy Dunlap
2020-11-20 21:58         ` Jonathan Corbet
2020-11-22  5:33           ` Thorsten Leemhuis
2020-11-22  5:42             ` Randy Dunlap

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=f2cf323b319067fbfd46f4d1f3b600a63f567a65.1605203187.git.linux@leemhuis.info \
    --to=linux@leemhuis.info \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.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).