on bugs

Mr. Erich Schubert thinks that the registration requirement is a significant flaw of bugzilla.^[1] He finds debbugs superior, utterly forgetting that for all intents and purposes, this tracker has the exact same requirement.

The point of registration in bugzilla, like that in disabling anonymous posting in the SourceForge trackers, is to ensure the ability to reach the bug submitter should more information be necessary. In web based trackers such as bugzilla or SourceForge, this is done by the registration requirement. In an email based tracker, such as bugzilla, this is done by the mail server. That is, if the user is not willing to provide you with an email address, they cannot submit a bug.

Both approaches have flaws. debbugs is more attack-able, with no checking on who is closing a bug, and little verification that an email truly comes from that sender, I could attack it in a couple different ways. I could do so by massively closing bugs, or by pretending to be someone else. Both have a fairly high potential for detection however, and based on the traffic debbugs generates, should be reversible. Bugzilla and SF models, on the other hand, are symptomatic of the password proliferation that none of us can keep up with.

Every tracker I have used also has other flaws. Debbugs pretty much requires a custom piece of software for users to report bugs with, such as Debian's reportbug. It would be difficult to port to other projects. Further, it creates a bar to entry not entirely unlike the registration requirement. A frequent Debian contributor might have reportbug and be familiar with it, but the random user would have to find it and then download and install it first. The talk of fake headers in an email client that debbugs is full of is sure to intimidate the average user. Bugzilla has poor search functionality. It also exposes way too much to the user, essentially having only an "advanced" user interface (though the search defaults to a "simple" one), in which users are presented with a myriad of things they cannot change or could, but do not really understand. This sort of configuration overload leads to mistakes even where it does not intimidate. SourceForge also has inadequate search, and compounds this error by insufficient filtering. If your bugs take up more than a few pages to display, users will not find existing reports. Combined with the inability to adequately manage bugs as a developer, and you have a problem system.

In short, there are no easy answers when it comes to bug tracking