[RFC PATCH v1 24/26] docs: reporting-bugs: explain why users might get neither reply nor fix

[Thorsten Leemhuis]

Not even getting a reply after one invested quite a bit of time with
preparing and writing a report can be quite devastating. But when it
comes to Linux, this can easily happen for good or bad reasons. Hence,
use this opportunity to explain why this might happen, hopefully some
people then will be less disappointed if it happens.

Signed-off-by: Thorsten Leemhuis <linux@xxxxxxxxxxxxx>
---
 Documentation/admin-guide/reporting-bugs.rst | 56 ++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst
index 340fa44b352c..8f60af27635b 100644
--- a/Documentation/admin-guide/reporting-bugs.rst
+++ b/Documentation/admin-guide/reporting-bugs.rst
@@ -1402,6 +1402,62 @@ for the subsystem as well as the stable mailing list the `MAINTAINERS file
 mention in the section "STABLE BRANCH".
 
 
+Why some issues won't get any reaction or remain unfixed after being reported
+=============================================================================
+
+When reporting a problem to the Linux developers, be aware only 'issues of high
+priority' (regression, security issue, severe problems) are definitely going to
+get resolved. The maintainers or if all else fails Linus Torvalds himself will
+make sure of that. They and the other kernel developers will fix a lot of other
+issues as well. But be aware that sometimes they can't or won't help; and
+sometimes there isn't even anyone to send a report to.
+
+This is best explained with kernel developers that contribute to the Linux
+kernel in their spare time. Quite a few of the drivers in the kernel were
+written by such programmers, often because they simply wanted to make their
+hardware usable on their favorite operating system.
+
+These programmers most of the time will happily fix problems other people
+report. But nobody can force them to do, as they are contributing voluntarily.
+
+Then there are situations where such developers really want to fix an issue,
+but can't: they lack hardware programming documentation to do so. This often
+happens when the publicly available docs are superficial or the driver was
+written with the help of reverse engineering.
+
+Sooner or later spare time developers will also stop caring for the driver.
+Maybe their test hardware broke, got replaced by something more fancy, or is so
+old that it's something you don't find much outside of computer museums
+anymore. Or the developer stops caring for their code and Linux at all, as
+something different in their life became way more important. Sometimes nobody
+is willing to take over the job as maintainer – and nobody can be forced to, as
+contributing to the Linux kernel is done on a voluntary basis. Abandoned
+drivers nevertheless remain in the kernel: they are still useful for people and
+removing would be a regression.
+
+The situation is not that different with developers that are paid for their
+work on the Linux kernel. Those contribute most changes these days. But their
+employers sooner or later also stop caring for some code and make its programmer
+focus on other thing. Hardware vendors for example earn their money mainly by
+selling new hardware; quite a few of them hence are not investing much time and
+energy in maintaining a Linux kernel driver for something they sold years ago.
+Enterprise Linux distributors often care for a longer time period, but in new
+version often leave support for old and rare hardware aside to limit the scope.
+Often spare time contributors take over once a company leaves some orphan some
+code, but as mentioned above: sooner or later will leave the code behind, too.
+
+Priorities are another reason why some issues are not fixed, as maintainers
+quite often are forced to set those, as time to work on Linux is limited. That's
+true for spare time or the time employers grant their developers to spend on
+maintenance work on the upstream kernel. Sometimes maintainers also get
+overwhelmed with reports, even if a driver is working nearly perfectly. To not
+get completely stuck, the programmer thus might have no other choice then to
+prioritize issue reports and reject some of them.
+
+But don't worry too much about all of this, a lot of drivers have active
+maintainers who are quite interested in fixing as many issues as possible.
+
+
 .. ############################################################################
 .. Temporary marker added while this document is rewritten. Sections above
 .. are new and dual-licensed under GPLv2+ and CC-BY 4.0, those below are old.
-- 
2.26.2