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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4dda937d-a295-faba-196f-56af3659fb08@gmx.com>
Date:   Fri, 30 Sep 2022 08:52:56 +0000
From:   "Artem S. Tashkinov" <aros@....com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>,
        Thorsten Leemhuis <linux@...mhuis.info>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Cc:     workflows@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        ksummit@...ts.linux.dev
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"



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