An uncomfortable but necessary discussion about the Debian bug tracker

Note: this post represents my personal opinions as a Debian maintainer of a single package (Meson). It is not my intention to throw anyone involved in the service under a bus, but some things about it are not good and need to be spoken aloud (in my opinion anyway, other people may disagree and that is fine).

There was a post called Configuring a mail transfert [sic] agent to interact with the Debian bug tracker on Planet Debian. It contained the following statement:

using an email client to create or modify bug reports is not a bad idea per se

Indeed it is not. However, using an email client as the only way of modifying bugs (which is how the Debian bug tracker works) is not only a bad idea, it is terrible idea. To me managing bugs is so awful that it is actively pushing me away from contributing to Debian. The bug statuses on Meson are not kept up to date because I prefer that to having to deal with the bug tracker. I suspect I am not alone in this. In any case it is a major hurdle for new developers and might even cause some people to drop out entirely [1].

Why is it like this?

The Debian bug tracker was originally implemented in 1993 or thereabouts. Pretty much everything IT related was different back then. Manipulating things via email actually made sense at the time. Sadly, the world changed completely but volunteers working on the bug tracker did not have the resources to update it [2]. The end result is a classical legacy system: one that works and does the thing it needs to  do but which no new developer wants to touch.

Notable updates to the system would require major resources, which the project does not have.

FWICT there have been attempts to migrate the tracker to e.g. Bugzilla or Gitlab, but none of those has come even close to succeeding.

Why is the UX bad?

There is no web UI for manipulating bug data. Instead you write an email in a custom format, send that to a specific email address and wait for things to happen.

The main problem here is not the format as such, it is the fact that the user has to do the work of the computer:

• Every time you need to manipulate bugs, you need to open the documentation page to remind yourself what the actual syntax is. A program would get it right automatically every time.
• Get it wrong? Sucks to be you. A program would get it right automatically every time.
• Send it to the wrong email address? Sucks to be you. And the person whose bug you just altered. A computer program would get it right automatically every time.
• And so on.

I suspect most Debian developers who spend a lot of time on this have written their own custom scripts for their use cases. But having hundreds of ersatz tools for common tasks seems suboptimal.

As an extra cherry on the cake, the bug tracker will send you an email every! single! time! you edit or comment on any bug. Not only does the service waste your time by forcing you to write syntactically correct batch processing commands by hand, it also wastes it by forcing you to keep deleting spam [3].

How does security on the system work?

It doesn't. The email interface is 100% open. Anyone can send edit any bug in any way just by sending a suitably crafted email to the control address [3]. If a 4chan script kiddie would want to screw up the entire Debian bug repository, they could do so fairly easily. 

There is an actual term for this approach: security through obscurity. The fact that the main bug tracker of the OS that runs the world does not have strict authentication in place does not fill me with warm fuzzies.

What would be a way forward?

A one-shot conversion to a different bug tracker is out of the question. Instead the situation could be improved incrementally, for example:

1. Create a new web service that parses the existing bug data and displays it in a "rich" format.
2. Update the UI so that registered users can change the state of the bug (close, duplicate, etc).
3. Make the UI send a suitably formatted control email to the backend.
4. Bless the new web service as an official way of editing bugs (hosted under debian.org and all that)
5. Edit the backend service so it only accepts emails from the web UI and registered Debian developers and maintainers
6. Change the backend to something else or improve it for the new UI [optional].

Steps 1 to 3 can be done by a single person or a small team. Since you (probably) don't have access to the backend service, you need to parse the bug state from the current tracker's status page (example here). That is a bit gnarly, but should be doable. If someone is looking for a personal project for the holiday season, this is something to consider.

Steps 4 to 6 would take months or years of full time work. Given that this approach was first suggested almost exactly 25 years ago, it is unlikely that resources for it would materialize out of thin air any time soon.

[1] My speculation.

[2] Also my speculation.

[3] You could use email filtering rules but that is again extra work for every user. A better option is not spamming (one thank-you email for new contributors is fine, more than that is not).

[4] Last time I checked at least. I have personally manipulated all sorts of bugs via email even before I was a Debian maintainer. No registration. No checks. Not even GPG signing.