lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ