An uncomfortable but necessary discussion about the Debian bug tracker
57 points by strugee
57 points by strugee
I think the more uncomfortable question is how many Debian developers view the bug tracker's difficulty for newbies as a useful gatekeeping mechanism. I wouldn't claim the Debian bug tracker is a paragon of bug coordination, but unlike with github you rarely need to deal with drive-by comments from outsiders more interested in leaving a snide remark than actually contributing to a bug's resolution.
As a Debian Developer I can say that the bug tracker is gatekeeping me and I avoid using it unless actually necessary, as I have to look up the documentation each time I want to change some bug metadata to figure out the exact magic invocations. I complained about this in my 2017 DebConf presentation, for the MediaWiki package we set up a separate, usable bug tracker as an alternative.
... but unlike with github you rarely need to deal with drive-by comments from outsiders more interested in leaving a snide remark than actually contributing to a bug's resolution.
Instead we get UPS/FedEx/DHL scam spam on issues in the Debian bug tracker because it's email based š
The Debian bug tracker isn't just difficult for "newbies." At one point I was pretty skilled with it but it was still a massive pain to use for the reasons discussed in this post. It, along with Debian's other painful tooling, was the main reason I did not get more involved with Debian. It was also cited by Michael Stapelberg as one of the reasons he stepped away from Debian: https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/#old-infrastructure-bug-tracker
It's probably true that it keeps out unwanted comments (though as the post notes it's actually very vulnerable to malicious actors) but it's also keeping out high quality contributions, which is a very bad tradeoff.
Yeah, that makes sense, Iāve certainly had the experience of āoh this is a Debian bug, but wait when was the last time I even tried to use my mail client? I guess I just wonāt botherā¦ā before.
You could certainty address the drive by comments issue by solving it on purpose with an improved bug tracker instead of on accident by forcing everyone to use email.
This post is missing a mention of the "bts" tool, that enables interacting with the BTS from the CLI (with shell completion). I use that. It does not require a working SMTP setup anymore.
bts makes it fairly easy to interact, thats true. Back in time when i did some mass tests on the debian archive there was an bts2ldap gateway too, storing all bug related stuff in an ldap directory. The SOAP api is there too, and even rust implementations for it exist.
Really glad to see more Debian content on lobsters!
Iāve had a crack at improving the bug experience. I wrote a gui tool to implement a āGTDā like workflow around managing bugs you care about in 2011. Itās long dead now because i couldnāt keep up with the churn rate of GTK+ and friends. At the time the BTS had a SOAP API, possibly read only, which i used.
I think the plan laid out in this post is fairly sound.
Is there a development environment or a sandbox of some sort where you could test the control commands without polluting or affecting the actual tickets?
As well as I understand, Debian bug tracker doesn't check that package name is legit. So just send a bug against non-existing package
The task seems pretty well specified and the interface seems decently documented (even if obscure), an AI tool could probably one shot most of it in not much time. Mailserver + webserver + some generated code that pushes out commands via a bunch of fake email addresses on behalf of users that sign up to the site.
Sounds like a very interesting project for sure. For point (1), something to keep in mind is that designing the new UI so that it's actually better than the old one will take some time. Good UI/UX work is not a simple matter. Non-developers can actually contribute greatly to this.
Steps 1 to 3 can be done by a single person or a small team.
OK, so are you volunteering then? If not, this doesn't seem to add much to the discussion.
A person is not obligated to volunteer their time towards fixing a problem in order to have a moral right to call out the existence of said problem.
This is exactly a form of gatekeeping and you should consider not doing it.
It's not exactly an obscure problem; everyone knows it's bad and everyone knows that no one has had the time/energy to fix it. Nothing wrong with venting, but it's not like it accomplishes anything.
Unfortunately, the likely outcome if someone contributes is that we have a long discussion about it, a few vocal voices will say the existing situation is just fine and threaten to stop working on Debian if anything changes, people will move on, and everyone's time is wasted.
Debian is a do-ocracy only for single packages or new things that does not replace anything. For everything else, you need a consensus that is more likely to never happen (counter examples that validate this point are systemd, usr-move, dgit, and debusine).
Unfortunately, the likely outcome if someone contributes is that we have a long discussion about it, a few vocal voices will say the existing situation is just fine and threaten to stop working on Debian if anything changes, people will move on, and everyone's time is wasted.
Sure! If the post had been saying "here's what's bad, and the reason it's stayed bad all this time is that no one wants to do the work because they feel like they'll just get shot down, so we need to change our attitudes or we'll be stuck with this crap forever" then I think that actually would have been a really useful discussion.
Maybe it's ... implied? in the post as it's written, but if so it's too subtle.
This mentality means that no bug tracker could be allowed to exist unless someone submitted a patch along with the bug.
In the context of a free-software project, that doesnāt sound completely insane. The source is available; every user could fix it if he cared to (albeit with perhaps years of necessary training and experience). Practically, of course, itās useful for folks who donāt know how to fix an issue to report it.
A looser version is appealing: what if the reporter of an issue is required not to resolve the issue but to manage the issueās resolution? That changes him from a mostly-passive reporter to an active contributor. And if an issue is not important enough to the reporter for him to manage, is it important enough to anyone else on the project?
The real topic for discussion is plausibility of the next claim, how much effort it would take to make the solution (one of the) official if it ever existed.