Bugs Everywhere —
Bugs Everywhere is a neat piece of software implementing distributed bugtracking: it combines a bugtracker and a distributed version control system. I’ve offered to be its new maintainer, taking over from its original author of Aaron Bentley and the folks at Panoramic Feedback. Bugs Everywhere posits that the use of a centralized bugtracker for software is no less inappropriate than the use of a centralized version control system1, and that real programmers work with bugs that exist in complex states of being fixed on some branches, as yet unmerged on others, and trying to keep a mental model of which is which is doomed to failure.
For example, at OLPC we believe in cheap and fast branching, and we have feature branches (e.g. “faster”), development branches (“joyride”), release branches (“update.1”), and production branches (“candidate”, “release”). We have a bugtracker that allows us to describe bugs as being “open” or as being “resolved”, which closes them. This is not cool.
In the Bugs Everywhere world, the same branch that contains your code also contains the bug state for that code. So, as I create my “faster” branch software, I can create/close bugs linked to those commits. When my tree is merged into the next branch up, we not only get the code merged, but the bug state merged as a side-effect. The bug state is not going to become inconsistent with the code.
How does it work? We insert a
.be directory into your repo, and use a command-line interface (“be”), web interface (written in TurboGears) or GUI (written in wxWidgets) to let you perform the dual operation of changing the state of the text files that describe bugs, and committing that change to the underlying VCS. We support Arch, Bazaar, GIT, Mercurial and RCS. BE itself is written in Python. Of course, another benefit of this approach is that the same offline editing advantages that your dVCS gives you apply to your bugtracker.
You might argue that being distributed sounds good, but having a common place for developers and users to go to to query bug state is important too. Having a distributed bug tracker isn’t incompatible with this — the central web interface to the bugtracker becomes just another client performing merges with the master location for the repository.
So, should you drop everything and switch to BE? Well, maybe. One way in which BE currently isn’t suited to OLPC is that we like having a central bugtracker for many projects, even though each project has its own source repository, or even several. BE would be much more suitable if we were just developing a single software project, rather than the complex selection of projects and processes that we currently track. Maybe the way forward is to run a meta-tracker that keeps track of changes in any of the specified source repositories and collates them.
Another current limitation is the web interface support, which was written against an old version of TurboGears, and is still a proof of concept. Noah Kantrowitz is interested in working on a BE backend for Trac, which would offload the web interface awesomeness to Trac.
1: Or at least, I do.