Message-ID: <3c8cac2f-cc01-4b72-8967-e1d4f188d0e0@leemhuis.info>
Date: Fri, 16 Jan 2026 10:42:38 +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 1/14/26 06:02, Thorsten Leemhuis wrote:
> On 1/13/26 17:07, Thorsten Leemhuis wrote:
> 
>> I thought about this for a while, but in the end I this section and the
>> one from 4/30 are worth it.
> 
> And having slept about this once more, I after my reply yesterday now
> think it might be wise to merge the important parts from 4/30 into this
> patch -- that should get things shorter and still get across chat I care
> about. Sorry, took me a moment to realize that.

FYI, wrote something new (see below) which is even a few lines shorter
than what is in the document right now, yeah. :-D

Ciao, Thorsten

---

Appendix: Why it's harder to report kernel bugs
===============================================

The developers are well aware that reporting Linux kernel bugs is harder
than in other Free/Libre Open Source Projects. Many reasons for that lie
in the nature of the kernel, its development model, and how the world
uses it:

* *Most kernels of Linux distributions are totally unsuitable for
reporting bugs upstream.* The reference section above already explained
this in detail: outdated codebases as well as modifications and add-ons
lead to kernel bugs that were fixed upstream a long time ago or never
happened there in the first place. Developers of other Open Source
software face these problems as well, but the situation is a lot worse
when it comes to the Linux kernel, as the changes and their impact are
much more severe -- which is why many developers expect reports with
kernels built from fresh and nearly unmodified sources.

* *Bugs often only occur in a special environment.* That is because
Linux is mostly drivers and can be used in a multitude of ways.
Developers often do not have a matching setup at hand -- and therefore
frequently have to rely on bug reporters for isolating a bug's cause and
testing proposed fixes.

* *The kernel has hundreds of maintainers, and all-rounders are
extremely rare.* This is also due to the multitude of drivers and
features, which is why many know little about areas related to their
code and even less about unrelated.

* *It is hard finding where to report issues to, among others, due to
the lack of a central bug tracker.* This is something even some kernel
developers dislike, but that's the situation everyone has to deal with
currently.

* *Stable and longterm kernels are primarily maintained by a dedicated
'stable team', which usually is forbidden to fix bugs just there that
happen in mainline, too.* The team thus will almost always want to know
if mainline is also affected when someone reports a bug, say, using
Linux 6.1.2: if it already happened in 6.1 and still occurs with
6.2-rc1, it is best left to the regular developers, as they know the
area best.

* *Kernel developers are free to solely focus on the latest mainline
kernel.* Some developers, therefore, ignore or react coldly to reports
about bugs in, say, Linux 6.1 when 6.2-rc1 is already out; a similar
reaction might occur when it comes to reports with 6.1.1 or 6.1.2, as
the stable team might have caused the breakage.

* *There might be nobody to help.* That can happen due to the lack of
hardware documentation -- for example, when a driver was built using
reverse engineering or taken over by spare-time developers when the
hardware manufacturer left it behind. Other times there is nobody to
even report bugs to: when maintainers move on without a replacement,
their code often remains as long as it's useful.

Some of these aspects could be improved to facilitate bug reporting --
many Linux kernel developers are well aware of this and would be glad if
a few individuals or an entity would make this their mission.

Powered by blists - more mailing lists