Re: [PATCH v1 07/30] docs: reporting-issues: explain need for fresh vanilla kernel

[Jonathan Corbet <corbet@lwn.net>]

Thorsten Leemhuis <linux@leemhuis.info> writes:

> Rewrite the section that explains why a fresh kernel is needed and why
> bug reporters might have to compile one themselves for testing and
> debugging purposes.
>
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> ---
>  .../admin-guide/reporting-issues.rst          | 141 +++++++++++-------
>  1 file changed, 85 insertions(+), 56 deletions(-)
>
> diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
> index 7dfb3ca4b3e322..2f387e8766f21d 100644
> --- a/Documentation/admin-guide/reporting-issues.rst
> +++ b/Documentation/admin-guide/reporting-issues.rst
> @@ -49,11 +49,25 @@ Step-by-step guide on reporting Linux kernel issues
>  Note: Only the steps starting with '*you must*' are strictly required -- but
>  following the others is usually in your own interest.
>  
> - * Are you facing an issue with a Linux kernel a hardware or software vendor
> -   provided? Then in almost all cases you are better off to stop reading this
> -   document and reporting the issue to your vendor instead, unless you are
> -   willing to install the latest Linux version yourself. Be aware the latter
> -   will often be needed anyway to hunt down and fix issues.
> +.. _intro_repisbs:
> +
> +* Be aware:
> +
> +  * You should report issues using a Linux kernel that is both really fresh and
> +    vanilla. That often means that you will have to remove software that
> +    requires externally developed kernel modules and install the newest upstream
> +    Linux development kernel yourself.
> +
> +  * There is a decent chance you will have to report the problem by email, in
> +    which case your email address will become part of public archives.
> +
> +  * You might need to patch and build your own kernel to help developers debug
> +    and fix the bug.
> +
> + If these three aspects sound too demanding, consider reporting the issue to
> + your Linux distributor or hardware manufacturer instead.

So nothing to object to here, but this does make me wonder who the
audience is for this document?  It seems that you are aiming at people
who do not run upstream kernels, but who want to work with upstream to
get bugs fixed...?  That seems worth saying explicitly if so.  How big
of a group is this?

Thanks,

jon