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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 10/2/22 18:13, Steven Rostedt wrote:
On Sun, 2 Oct 2022 12:49:04 +0000
"Artem S. Tashkinov" <aros@xxxxxxx> 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).

Good, exactly what I've been advocating for, those who like it and can
help are welcome, others can go unsubscribe in under a minute. No drama.


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.

I perfectly understand it. I've _not_ asked anyone to do anything yet,
except maybe have their email in the bugzilla database, so that people
_could_ CC you.

They will _not_ do it right away. They first have to `git grep` commits,
find the relevant developers and then CC them.


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.

This does not work, period. Most kernel bug reports in Fedora and Ubuntu
bug trackers linger for years, sometimes someone says, "Try the vanilla
kernel and if it's still an issue, please use the kernel bugzilla".

My Fedora kernel bug reports have been dealt with exactly this way.

RedHat does solve kernel issues in the RHEL kernel if you have a paid
subscription and you spend quite some time providing them with a perfect
reproducible test case. This is far outside this conversation.


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.

Mailing lists more often than not do not work, and maybe worked in the
early 90s.

We don't need to resolve the issue right away. We don't have to deal
with it. We just need a place where people could find existing issues
and add their input. That's a lot better than chasing something in emails.

Here's the simplest example.

Person A installs kernel 6.0. They find a regression. They send an email
to maling list X. Not necessarily the relevant one and the email is
simply ignored.

Another person finds the same regression. This person B may not be aware
of the mailing list used earlier. They send a bug report elsewhere.

Now we have two completely disconnected bug reports which if luck allows
could be Googled. Oy, you must know what to google for. Not that many
people have a good Google foo.

Now with bugzilla.

Anyone opens the last seven days of bug reports and instantly sees that
something similar has already been filed and dealt with. Collaboration
ensues. Maybe just maybe some developer will join it and actually offer
a fix. If not, OK, fine, no big deal but at least it's _known_,
_visible_ and can be _found_.

Random unreplied emails God knows where? Good luck with that.


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?

I've already offered myself. The LF has no such position. And more
importantly I'm from a totalitarian country, so I'm unlikely to be ever
employed.

Regards,
Artem




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux