linux-kernel - Re: [PATCH v1 05/30] docs: reporting-issues: outline why reporting is complicated

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] [day] [month] [year] [list]

Message-ID: <ae9a3fec-4872-4cb7-9e9f-dbeafb4daab7@leemhuis.info>
Date: Tue, 13 Jan 2026 17:07:33 +0100
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Jonathan Corbet <corbet@....net>
Cc: workflows@...r.kernel.org, linux-doc@...r.kernel.org,
 regressions@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 05/30] docs: reporting-issues: outline why reporting is
 complicated

On 10/27/25 18:44, Jonathan Corbet wrote:
> Thorsten Leemhuis <linux@...mhuis.info> writes:
> 
>> Replace the closing words with a section that describes why reporting
>> Linux kernel bugs is more complicated than in other FLOSS projects.
>>
>> Signed-off-by: Thorsten Leemhuis <linux@...mhuis.info>
>> ---
>>  .../admin-guide/reporting-issues.rst          | 67 ++++++++++++++++---
>>  1 file changed, 59 insertions(+), 8 deletions(-)
> 
> So the text is OK but ... this is now the second section that is
> essentially a long apology for the kernel process being so difficult.
> It seems redundant with the other text, and I'm not convinced we need
> it.
> 
> Again, length is an impediment to getting people to actually read this
> stuff; we should be trying to be as concise as we can.  Do we really
> need this?

I thought about this for a while, but in the end I this section and the
one from 4/30 are worth it. Let me explain my line of thought:

* Yes, they make the document a longer, but it's in an appendix, which
makes it relatively obvious that these are optional background details
you don't have to read.

* You in your reply to 3/30 asked to "Consider also soliciting patches
to improve it" -- something I in the context had found obvious and not
worth mentioning, as I thought, "everybody that knows how to send
patches will do so without us mentioning it here". But for these two
sections it's different: is stuff that is obvious for us, but not
obvious for many non-developers (at least from what I see when
processing bugs/regressions reports= and relevant for them. That's
because the kernel IMHO is not "an open-source program like any other",
as you mentioned in a reply to 4/30:

- Other FLOSS software is relatively independent, but the kernel is
mostly drivers -- so without the right hardware, there sometimes is
nothing that developers can do in case of bugs. We also normally don't
remove orphaned code due to the "no regressions" rule, unless it's
getting really old and/or in the way, so there is nothing anybody will
do about a bug report -- which is unusual. The stuff in 4/30 explains
such aspects.

- The kernel development model is different in some important aspects,
which can be even confusing for people familiar with FLOSS practices.
Like the "mainline developers might not care about bugs in
stable/longterm kernels, while the stable team will leave things to the
mainline developers if the problem happens there, too". This is rare and
IMHO needs to be explained somewhere, as then we can point people to
this explanation that otherwise will just feel pushed around and become
annoyed by the kernel (some obviously will nevertheless feel that, but
that way we can get at least some people to understand things and/or on
our side).

Ciao, Thorsten