All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: Thorsten Leemhuis <linux@leemhuis.info>,
	Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 05/26] docs: reporting-bugs: begin reference section providing details
Date: Fri, 2 Oct 2020 09:49:48 -0700	[thread overview]
Message-ID: <0c188514-0cf2-7201-004f-5a78398eef6c@infradead.org> (raw)
In-Reply-To: <cd3e2465fec04e83d55ec6821fd6f111709eaf8e.1601541165.git.linux@leemhuis.info>

Hi--

On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> Provide an introduction to the reference section that will provide more
> details how to report an issue. Mention a few general things here. Those
> are not strictly needed, but likely wise to write down somewhere.
> 
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> ---
> 
> = RFC =
> 
> Should we keep the links to
> https://www.chiark.greenend.org.uk/~sgtatham/bugs.html and
> http://www.catb.org/esr/faqs/smart-questions.html? Are they worth it? Or is
> there anything similar or better that's a bit fresher and ideally still
> maintained?

Dunno. They are interesting but outdated.

> ---
>  Documentation/admin-guide/reporting-bugs.rst | 46 +++++++++++++++++---
>  1 file changed, 40 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst
> index e0a6f4328e87..be1bce8d43aa 100644
> --- a/Documentation/admin-guide/reporting-bugs.rst
> +++ b/Documentation/admin-guide/reporting-bugs.rst
> @@ -205,6 +205,46 @@ rebased on new stable or longterm releases. If that case follow these steps:
>     stable mailing list.
>  
>  
> +Reference section: Reporting issues to the kernel maintainers
> +=============================================================
> +
> +The detailed guides above outlines all the mayor steps in brief fashion, which

                             outline          major

> +should be enough for most people. But sometimes there are situations where even
> +experienced users might wonder how to actually do one of those steps. That's
> +what this section is for, as it will provide a lot more details on each of the
> +steps. Consider this a reference documentation: it's possible to read it from

                        as

> +top to bottom, but more meant to skim over and a place to look up details in
> +case you need them.
> +
> +A few words of general advice before digging into the details:
> +
> + * The Linux kernel developers are well aware this process is complicated and
> +   demands more than other FLOSS projects. We'd love to make it simpler, but
> +   that would require work in various places as well as infrastructure that
> +   would need constant maintenance; nobody has stepped up to do that work, so
> +   that's just how things are for now.
> +
> + * A warranty or support contract with some vendor doesn't entitle you to
> +   request fixes from developers in the upstream Linux kernel community: such
> +   contracts are completely outside the scope of the Linux kernel, its
> +   development community, and this document. That's why you can't demand
> +   anything such a contract guarantees in this context, not even if the
> +   developer handling the issue works for the vendor in question. If you want to
> +   claim your rights, use the vendors support channel instead. When doing so,

                                 vendor's

> +   you might want to mention you'd like to see the issue fixed in the upstream
> +   Linux kernel; motivate them by saying it's the only way to ensure the fix in
> +   the end will get incorporated in all Linux distributions.
> +
> + * If you never reported an issue to a FLOSS project before you should consider
> +   reading `How to Report Bugs Effectively
> +   <https://www.chiark.greenend.org.uk/~sgtatham/bugs.html>`_
> +   and `How To Ask Questions The Smart Way
> +   <http://www.catb.org/esr/faqs/smart-questions.html>`_.
> +
> +With that of the table, find below the details on how to properly report issues

             off

> +to the Linux kernel developers.
> +
> +
>  .. ############################################################################
>  .. 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.
> @@ -281,12 +321,6 @@ http://vger.kernel.org/lkml/).
>  Tips for reporting bugs
>  -----------------------
>  
> -If you haven't reported a bug before, please read:
> -
> -	https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
> -
> -	http://www.catb.org/esr/faqs/smart-questions.html
> -
>  It's REALLY important to report bugs that seem unrelated as separate email
>  threads or separate bugzilla entries.  If you report several unrelated
>  bugs at once, it's difficult for maintainers to tease apart the relevant
> 


-- 
~Randy


  reply	other threads:[~2020-10-02 16:49 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01  8:39 [RFC PATCH v1 00/26] Make reporting-bugs easier to grasp and yet more detailed Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 01/26] docs: reporting-bugs: temporary markers for licensing and diff reasons Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 02/26] docs: reporting-bugs: Create a TLDR how to report issues Thorsten Leemhuis
2020-10-02  2:32   ` Randy Dunlap
2020-10-03  7:27     ` Thorsten Leemhuis
2020-11-11 15:24       ` Thorsten Leemhuis
2020-11-12  3:33         ` Randy Dunlap
2020-11-12  4:56           ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 03/26] docs: reporting-bugs: step-by-step guide on " Thorsten Leemhuis
2020-10-02  3:02   ` Randy Dunlap
2020-10-03  8:05     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 04/26] docs: reporting-bugs: step-by-step guide for issues in stable & longterm Thorsten Leemhuis
2020-10-02  3:25   ` Randy Dunlap
2020-10-03  8:24     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 05/26] docs: reporting-bugs: begin reference section providing details Thorsten Leemhuis
2020-10-02 16:49   ` Randy Dunlap [this message]
2020-10-03  8:27     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 06/26] docs: reporting-bugs: point out we only care about fresh vanilla kernels Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 07/26] docs: reporting-bugs: let users classify their issue Thorsten Leemhuis
2020-10-02 16:59   ` Randy Dunlap
2020-10-03  9:42     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 08/26] docs: reporting-bugs: make readers check the taint flag Thorsten Leemhuis
2020-10-02 17:08   ` Randy Dunlap
2020-10-03  9:56     ` Thorsten Leemhuis
2020-10-03 17:47       ` Randy Dunlap
2020-10-01  8:39 ` [RFC PATCH v1 09/26] docs: reporting-bugs: help users find the proper place for their report Thorsten Leemhuis
2020-10-04  4:03   ` Randy Dunlap
2020-10-07 12:05     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 10/26] docs: reporting-bugs: remind people to look for existing reports Thorsten Leemhuis
2020-10-02 17:17   ` Randy Dunlap
2020-10-03  9:58     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 11/26] docs: reporting-bugs: remind people to back up their data Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 12/26] docs: reporting-bugs: tell users to disable DKMS et al Thorsten Leemhuis
2020-10-02 17:28   ` Randy Dunlap
2020-10-03  9:59     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 13/26] docs: reporting-bugs: point out the environment might be causing issue Thorsten Leemhuis
2020-10-02 17:32   ` Randy Dunlap
2020-10-03 10:00     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 14/26] docs: reporting-bugs: make users write notes, one for each issue Thorsten Leemhuis
2020-10-02 17:35   ` Randy Dunlap
2020-10-03 10:01     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 15/26] docs: reporting-bugs: make readers test mainline, but leave a loophole Thorsten Leemhuis
2020-10-02 17:51   ` Randy Dunlap
2020-10-03 10:11     ` Thorsten Leemhuis
2020-11-11 15:36       ` Thorsten Leemhuis
2020-11-12  3:42         ` Randy Dunlap
2020-11-12  5:22           ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 16/26] docs: reporting-bugs: let users check taint status again Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 17/26] docs: reporting-bugs: explain options if reproducing on mainline fails Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 18/26] docs: reporting-bugs: let users optimize their notes Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 19/26] docs: reporting-bugs: decode failure messages [need help] Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 20/26] docs: reporting-bugs: instructions for handling regressions Thorsten Leemhuis
2020-10-04  4:03   ` Randy Dunlap
2020-10-04  6:31     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 21/26] docs: reporting-bugs: details on writing and sending the report Thorsten Leemhuis
2020-10-09  2:45   ` Randy Dunlap
2020-10-09  7:38     ` Thorsten Leemhuis
2020-10-01  8:50 ` [RFC PATCH v1 22/26] docs: reporting-bugs: explain what users should do once the report got out Thorsten Leemhuis
2020-10-09 17:37   ` Randy Dunlap
2020-10-11 13:29     ` Thorsten Leemhuis
2020-10-11 15:06       ` Randy Dunlap
2020-10-01  8:50 ` [RFC PATCH v1 23/26] docs: reporting-bugs: details for issues specific to stable and longterm Thorsten Leemhuis
2020-10-09 18:42   ` Randy Dunlap
2020-10-11 13:29     ` Thorsten Leemhuis
2020-10-01  8:50 ` [RFC PATCH v1 24/26] docs: reporting-bugs: explain why users might get neither reply nor fix Thorsten Leemhuis
2020-10-04  4:03   ` Randy Dunlap
2020-10-04  6:35     ` Thorsten Leemhuis
2020-10-01  8:50 ` [RFC PATCH v1 25/26] docs: reporting-bugs: explain things could be easier Thorsten Leemhuis
2020-10-04  4:03   ` Randy Dunlap
2020-10-04  6:36     ` Thorsten Leemhuis
2020-10-01  8:50 ` [RFC PATCH v1 26/26] docs: reporting-bugs: add SPDX tag and license hint, remove markers Thorsten Leemhuis
2020-11-09 11:01 ` [RFC PATCH v1 00/26] Make reporting-bugs easier to grasp and yet more detailed Thorsten Leemhuis
2020-11-09 18:21   ` Jonathan Corbet
2020-11-10 12:01     ` Thorsten Leemhuis
2020-11-10  3:23   ` 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=0c188514-0cf2-7201-004f-5a78398eef6c@infradead.org \
    --to=rdunlap@infradead.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@leemhuis.info \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.