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
