Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla blues"

[Steven Rostedt <rostedt@goodmis.org>]

On Sun, 2 Oct 2022 12:49:04 +0000
"Artem S. Tashkinov" <aros@gmx.com> wrote:

> Let's subscribe the past six months of developers using git commits and
> if someone doesn't like getting emails they go to the website and
> unsubscribe _once_ which takes a minute. This is a non-issue I've no
> clue why we're dwelling on it.

As one of the few kernel maintainers that actually likes bugzilla and I
do not mind being subscribed to it, I too find the above an awful idea
(and I agree with all those that explained why it is so).

This really comes down to a manpower issue, which is common among most
open source projects. Remember it is commonly said that the only
warrantee you get from open source projects is that if it breaks, you
get to keep the pieces.

The issue is that the users of the Linux kernel mostly got it for free.
And if they did pay for it, it is highly unlikely that they paid the
kernel maintainer that owns the subsystem that they are having issues
with. That means, for the maintainers to triage these bug reports, they
are essentially doing it for free.

Some projects are better at this, and there are developers that are
happy to give free work, but there are also other projects that have
companies actively backing the work to debug these issues.

If you are using fedora, go bug Red Hat, Ubuntu then Canonical. And
again, it comes down to if you have a paid subscription or not if you
are going to get anywhere with it.

Can this be annoying, sure. But that's how the open source ecosystem
works.

If someone is not able to figure out how to use the mailing lists, it
is unlikely that they will be able to be useful in working with the
maintainer to solve their issue. As Ted mentioned, when asked to do
something to help analyze the issue, many times there's no response
from the reporter. Maybe because the reporter had no idea what the
maintainer wanted them to do. Most kernel bugs requires a constant back
and forth between the reporter and the developer. If you don't have
that, then there's no reason to bother with trying to fix the issue.

Ideally, someone (you?) would want to be a middle man and triage the
bugzilla reports and find those that look promising to get a fix
completed, and then be the liaison between bugzilla and the kernel
maintainer, then I think that could work. But the issue comes back to
manpower. Who's going to do that?

-- Steve