A plan for the kernel Bugzilla

Posted Oct 18, 2022 17:27 UTC (Tue) by marcH (subscriber, #57642)
Parent article: A plan for the kernel Bugzilla

> Being a bugmaster is a thankless job that leads to burnout, regardless of how well you are paid. Everyone is constantly irate at you from both ends -- the users are annoyed because their stuff doesn't work, and the maintainers are annoyed because you keep yanking them to work on dull problems that require a ton of back-and-forth with people who aren't capable of applying patches and booting custom kernels.

> you will still have all the exact same problems as long as nobody is in charge of handling incoming bugs

The choice of the tool does not matter compared to this. For open-source projects it's actually much much worse considering many (most?) reporters do NOT directly pay the corresponding code owner. As soon as you have some kind of business relationship then you automatically have something like a bug tracker because you can't afford to have important information with business impact scattered across random emails. Managers also need some metrics. Often very imperfect metrics but still more acceptable than a complete void. So yes: the lack of a bug/issue/feature tracker happens only when and where developers don't have to answer ("evil"?) managers.

For open-source projects, what matters much more than how you communicate and keep track of bugs is reproduction or in other words: TESTS. If you can communicate a simple sequence of steps that fail then this will almost always get prioritized by someone you don't pay directly over figuring out how to install and configure a complex workload - assuming you can even get access to it in the first place. How that sequence of steps is communicated plays a very secondary role. Note the test can be rejected as "don't do this, works as intended" but even in this case the "bug" will be handled promptly.

Tests and use cases define what a software project is, not bugs (and not paper requirements either). Developers consider their work "done" when the tests are passing.

Granted, some developers don't even test at all but those don't spend time looking at bugs either :-)

A plan for the kernel Bugzilla

Posted Oct 21, 2022 6:40 UTC (Fri) by AdamW (subscriber, #48457) [Link]

I would say the choice of tool still does matter.

It felt kinda odd reading the summary of this discussion, honestly. I don't think I've ever met a software project that doesn't have the "too many bugs, not enough time" problem. Very few of them have a comprehensive triage process. Yet almost all of them aside from the kernel community use a bug tracker, and use it to good effect.

It seems like kernel folks think that having a bug tracker somehow means you have to care about All The Bugs. Well...no. Every (other) major F/OSS project has a bug tracker just brimming with bugs nobody cares about. The thing is, this is *fine*. Of course it'd be great if every bug was cared for, but even if it isn't, that doesn't mean the bug tracker is useless.

A bug tracker - any bug tracker - is so much better than a mailing list for multiple people to collaborate on a problem. As the Fedora QA team lead I do a lot of poking around upstreams trying to figure out whether some bug has been reported, is being worked on, has already been fixed, what the fix was, where it's landed. All of this works *so* much better with projects that have sensible bug trackers, i.e. frickin' all of them except the kernel. I groan every time I have to try and do this for a kernel bug. Of course I'm not going to be subscribed to every single frickin' kernel development mailing list. I'm not a kernel developer. My mail client would explode. But this means if I want to try and find if some issue has been discussed/resolved, I'm left trolling through awful mailing list archive web frontends with useless search functions, usually to no great effect. Even if I can find a discussion, it's way harder to figure out what actually happened in the end on a mailing list than it is on a bug tracker.

The point of a bug tracker isn't to make you fix every single bug. It's to provide some convenient tools and conventions and generally bring some order to the bugs you *do* work on, and help everyone who isn't constantly following the development process find out what's going on if they need to.