Choosing a Bug Tracker

Unfortunately, I’ve been cramped for time lately, but over the weekend we finally chose a bug reporting system to use. This was a fairly lengthy task, and I reviewed about 8 systems before making a choice. We discounted anything commercial, as usually these don’t have good source-code editing flexibility, or they are licensed per-user, which is bad for community projects.

A quick run-down on what I encountered:

Bugzilla: Overall, a very comprehensive package. The source code is modular and very readable (especially for Perl). Although the default theme is horrible, it is easily editable since it is templated. Unfortunately, its permissions system is extremely basic (despite Mozilla claiming it’s “comprehensive”). Access rights to a task are either all or none, which means we couldn’t let users add comments to tasks without also letting them change priorities/assignees/et cetera. Although Bugzilla’s documentation had an article about altering the permissions source code, it was certainly not a clear-cut job.

eTraxis: A relatively new project with a slick interface. Unfortunately, the interface is also mind-bogglingly confusing, and the documentation is extremely light. We couldn’t figure out how to add a task within a few minutes of playing around and dropped it.

Eventum: By the MySQL team, this looked fairly promising. It has a huge feature set, a detailed interface, and integrates with SVN. However, it seemed to have no option for anonymous viewing, so we dropped it.

Mantis BT: Although 3 years ago it might have been popular to inline HTML into PHP scripts, these days it’s unacceptable, especially with the advent of tools like Smarty. We dropped this one because maintaining it looked like it would be an uphill battle. To its credit, it tries to condense HTML into separate PHP files, but the necessary abstraction isn’t there.

Scarab: This tool did not appear to have any concept of projects. Even stranger, it claimed that this was a “feature,” and used the word “Modules” instead. This silly design decision was bad enough, but we couldn’t see that Scarab had any sort of hierarchy or sub-categorization beyond “Modules.” Our projects tend to have many nested pieces.

Trac: Trac looks excellent for single-project setups. However, we were looking for an integrated environment. Trac doesn’t seem to allow for multiple projects under one hood. On top of that, it comes with a lot of extra baggage that we don’t need (though this can probably be disabled).

Eventually, we ended up choosing Flyspray. The PHP code is fairly easy to read. It is templated properly, thus abstracting design from code. It allows for projects, categories within projects, and categories within categories. It has comprehensive task permissions for both global groups and per-project groups. Users can be a member of a global group and one group in each project. All in all, this perfectly fit our setup, so after doing a quick vBulletin integration, we launched.

If we had more time and more developers, we probably would have chosen Bugzilla or Eventum and done modifications to implement our features. However, Flyspray had exactly what we needed at the right time.

Leave a Reply

You must be logged in to post a comment.