Date:   Sun, 2 Oct 2022 20:14:17 +0000
From:   "Artem S. Tashkinov" <aros@....com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Theodore Ts'o <tytso@....edu>,
        Thorsten Leemhuis <linux@...mhuis.info>,
        Greg KH <gregkh@...uxfoundation.org>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        workflows@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        ksummit@...ts.linux.dev,
        Mario Limonciello <mario.limonciello@....com>
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"



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

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

Powered by blists - more mailing lists