Message-ID: <0b60cae3-565e-9e26-9320-b8c8dde4115d@infradead.org>
Date:   Sat, 16 Jan 2021 08:44:08 -0800
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,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Subject: Re: [PATCH] docs: process/howto.rst: make sections on bug reporting
 match practice

On 1/16/21 6:35 AM, Thorsten Leemhuis wrote:
> The file Documentation/process/howto.rst points to bugzilla.kernel.org
> as the primary place to report kernel bugs to. For most of the kernel
> that's the wrong place, as the MAINTAINERS file shows. Adjust those
> sections to make them match current practice.
> 
> This change also removes a contradiction with the recently added text
> Documentation/admin-guide/reporting-issues.rst, which is a reason for a
> 'this needs further discussion' warning note in there. The change is
> thus a prerequisite to remove that warning, nevertheless it is left for
> now to make sure people review the text's approach more carefully.
> 
> Signed-off-by: Thorsten Leemhuis <linux@...mhuis.info>
> ---
> v1:
> - kind of a follow up to "[PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org"[1] – I decided to break that idea down into smaller pieces, which I guess is easier for everyone
> 
> [1] https://lore.kernel.org/lkml/20210110121033.130504-1-linux@leemhuis.info/

LGTM (with one nit below).

Acked-by: Randy Dunlap <rdunlap@...radead.org>


> ---
>  Documentation/process/howto.rst | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
> index 7a5c105e34d4..e4beeca57e5f 100644
> --- a/Documentation/process/howto.rst
> +++ b/Documentation/process/howto.rst
> @@ -342,16 +342,10 @@ Adventurous testers are very welcome to runtime-test the linux-next.
>  Bug Reporting
>  -------------
>  
> -https://bugzilla.kernel.org is where the Linux kernel developers track kernel
> -bugs.  Users are encouraged to report all bugs that they find in this
> -tool.  For details on how to use the kernel bugzilla, please see:
> -
> -	https://bugzilla.kernel.org/page.cgi?id=faq.html
> -
>  The file 'Documentation/admin-guide/reporting-issues.rst' in the main kernel
> -source directory has a good template for how to report a possible kernel bug,
> -and details what kind of information is needed by the kernel developers to help
> -track down the problem.
> +source directory describes how to report a possible kernel bug, and details
> +what kind of information is needed by the kernel developers to help track
> +down the problem.
>  
>  
>  Managing bug reports
> @@ -364,7 +358,13 @@ improve your skills, and other developers will be aware of your presence.
>  Fixing bugs is one of the best ways to get merits among other developers,
>  because not many people like wasting time fixing other people's bugs.
>  
> -To work in the already reported bug reports, go to https://bugzilla.kernel.org.
> +To work on already reported bug reports, find a subsystem you are interested in.
> +Check the MAINTAINERS file where bugs for that subsystem get reported to; often

I would say:
   Check the MAINTAINERS file for where bugs for that subsystem are reported; often

> +it will be a mailing list, rarely a bugtracker. Search the archives of said
> +place for recent reports and help where you see fit. You may also want to check
> +https://bugzilla.kernel.org for bug reports; only a handful of kernel subsystems
> +use it actively for reporting or tracking, nevertheless bugs for the whole
> +kernel get filed there.
>  
>  
>  Mailing lists
> 


-- 
~Randy
You can't do anything without having to do something else first.
-- Belefant's Law

Powered by blists - more mailing lists