Date:   Sat, 3 Oct 2020 21:03:09 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Thorsten Leemhuis <linux@...mhuis.info>,
        Jonathan Corbet <corbet@....net>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 24/26] docs: reporting-bugs: explain why users
 might get neither reply nor fix

On 10/1/20 1:50 AM, Thorsten Leemhuis wrote:
> 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@...mhuis.info>
> ---
>  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

         on other things.

> +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

                                                                  drop last: some

> +code, but as mentioned above: sooner or later will leave the code behind, too.

                                           later they 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

                                                                        than 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.
> 


-- 
~Randy

Powered by blists - more mailing lists