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

[Artem S. Tashkinov]

On 9/29/22 15:26, James Bottomley wrote:
> On Thu, 2022-09-29 at 12:22 +0000, Artem S. Tashkinov wrote:
> > Let me be brutally honest here, if you're working on the kernel,
> > specially for a large company such as e.g. Intel, you're _expected_
> > to address the issues which are related to the kernel component[s]
> > you're maintaining/developing otherwise it's not "development" it's
> > "I'm dumping my code because my employer pays me to do that". That
> > also means you're expected to address bug reports.
> >
> > It's correct I've tried to help people with bug reports posted on
> > bugzilla.kernel.org but it's a tough task considering that absolute
> > most kernel developers are not signed up, thus most bug reports are
> > never seen by respective developers.
>
> The never seen/never responded to metric is rather bogus.  The sad fact
> is that a lot of bug reports aren't actionable, meaning the reporter
> can't give a reproducer and also can't easily test patches  sometimes
> by luck the maintainers can work out what the issue is but a lot of the
> time they have no idea.  Then there are ton's of bug reports with
> responses like "I think xxx commit fixes your problem, can you test it"
> for which the conversation dies there.  There's also the thundering
> herd problem: some bugs get reported by many different people (as
> different bug reports) but usually the subsystem only engages with one
> to fix the issue.  In theory bugzilla can mark the latter as dups, but
> that requires someone to spend an enormous amount of time on evaluation
> and admin.

  Not only that, many bug reporters simply report something only not to
ever follow up - you ask them for additional information and it looks
like as if they don't receive emails from bugzilla or don't understand
English despite their report being in English.

> That's not to say we can't improve our process, it's just to set
> expectations that we're never going to approach anywhere near a perfect
> bug process.  Most of the improvements that worked so far involve
> having someone coach bug reporters through the process of either
> testing patches or reproducing the problem in a more generic
> environment ... which I think most people would agree can't really fall
> wholly on maintainers.


  Bug reporting is an intricate process which requires certain
experience and skills and it's far outside the scope of this
conversation. I still absolutely prefer Bugzilla or a similar bug
tracker to stay. There has to be a place where all the bug reports are
congregated together in an easy to search for form. Someone has proposed
alternatives but I know nothing about them. What I'm looking forward  to
from a new bug tracker:

* An ability to CC anyone and everyone
* Preferably an email interface since some developers just love replying
to emails instead of opening a website
* Categories representing major kernel components

To be honest it feels like refreshing Bugzilla is a lot more easier than
migrating to something new. If I'm given access to it, I could certainly
try to do that.

It's been mentioned that the product is "dead" and "unmaintained" but
that's not what I see on bugzilla.mozilla.org - it has become extremely
powerful. Maybe it's not even Bugzilla but something totally new which
looks like bugzilla.

Other major projects continue to use Bugzilla seemingly without big
problems:

* KDE ( https://bugs.kde.org/ )
* GCC ( https://gcc.gnu.org/bugzilla/ )
* Wine ( https://bugs.winehq.org/ )

It feels to me we just need a dedicated Bugzilla maintainer. That's it.
I could probably do it.

Best regards,
Artem