Messages in this thread | | | Date | Fri, 30 Sep 2022 08:52:56 +0000 | Subject | Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla blues" | From | "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
| |