[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87qzuontlj.fsf@trenco.lwn.net>
Date: Mon, 27 Oct 2025 11:27:04 -0600
From: Jonathan Corbet <corbet@....net>
To: Thorsten Leemhuis <linux@...mhuis.info>
Cc: workflows@...r.kernel.org, linux-doc@...r.kernel.org,
regressions@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 02/30] docs: reporting-issues: tweak the reference
section intro
Thorsten Leemhuis <linux@...mhuis.info> writes:
> Small improvements to the intro of the reference section.
That's a bit uninformative ... what is the purpose of these
improvements? That information would be especially helpful in a patch
that simply replaces that section altogether.
> Signed-off-by: Thorsten Leemhuis <linux@...mhuis.info>
> ---
> .../admin-guide/reporting-issues.rst | 67 +++++++++----------
> 1 file changed, 31 insertions(+), 36 deletions(-)
>
> diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
> index 3bc47afaf85ea0..90b50c27c0d2b6 100644
> --- a/Documentation/admin-guide/reporting-issues.rst
> +++ b/Documentation/admin-guide/reporting-issues.rst
> @@ -244,42 +244,37 @@ The reference section below explains each of these steps in more detail.
[...]
> +The step-by-step guide above outlines all the major steps in brief fashion,
> +which usually covers everything required. But even experienced users will
> +sometimes wonder how to actually realize some of those steps or why they are
> +needed; there are also corner cases the guide ignores for readability. That is
> +what the entries in this reference section are for, which provide additional
> +information for each of the steps in the detailed guide.
> +
> +A few words of general advice:
> +
> +* The Linux kernel developers are well aware that reporting bugs to them is
> + more complicated and demanding than in other FLOSS projects. Quite a few
> + would love to make it simpler. But that would require convincing a lot of
> + developers to change their habits; it, furthermore, would require improvements
> + on several technical fronts and people that constantly take care of various
> + things. Nobody has stepped up to do or fund that work.
This paragraph ... essentially says "we're making it hard on you because
kernel developers can't be bothered to work on GitHub". But a lot of
the complexity, as reflected in this guide, has to do with properly
gathering the information that is needed to have a hope at tracking a
problem down. I'm not sure this paragraph is needed at all but, if
you're going to keep it, have it at least reflect that the complexity of
problem reporting has a lot to do with the complexity of the problem
domain rather than developers who are stuck in their habits.
Otherwise seems OK.
Thanks,
jon
Powered by blists - more mailing lists