lkml.org 
[lkml]   [2022]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla blues"
From


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

\
 
 \ /
  Last update: 2022-09-30 10:54    [W:0.246 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site