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.
I’m writing this post to try and build up a community around BE: please check out our wiki and mailing list, and consider hacking on it. It’s the future, honest.
1: Or at least, I do.
Fascinating. I’d heard people talking about things like this before, but I don’t think it clicked until now. Good luck with it!
Looks cool. I’ve watched some of the distributed bug-tracker stuff from afar, waiting for one to materialize. I’m sick of having times I’m disconnected from the ‘net when I can’t do productive work because I don’t have all the relevant data. And I’m also sick of having my work be slowed down in annoying ways even when I do have network connectivity, due to the storage and access methods for that data (i.e. centralized on some server across the world instead of on my harddisk where I can get at it quickly). Distributed VCSes are one part of the solution in my opinion, and I’m convinced distributed bug trackers are the next part.
Sadly, I’m spread too thin and thus will likely only be cheering you on rather than contributing.
We tried BE, but we needed to be able to have a sync between BE and a centralized bug tracker. Individual developers like using BE for their own local branches, but our QA team wanted a centralized Bugtracker (and only dealing with unified/centralized milestone releases). I’m still not sure if we were just “doing QA” wrong, or whether it was legitimate to want to do it hybrid.
Hi Steve,
I don’t think you’re doing it wrong — as I mentioned in the article, I think a centralized bug tracker (implemented as just another client) is entirely compatible with BE. I’d be interested to hear more about your experiences!
A backend to Trac is going to help enormously: once you have a world-class bugtracker able to transparently use BE in a manner compatible with centralized workflow, there’ll be very little reason not to use BE and allow your developers who want its advantages to take them.
Cheers,
Chris.
It’s good seeing BugsEverywhere isn’t left to die. The idea behind it is very interesting – it’s nice to be able to track bugs offline and along with the code branch. However, I didn’t really like the fact that the bug tracker data and source code live in the same tracker.
This is a great idea. I’m really excited about the possibility of working with something like this.
Good luck!
It’s a sweet piece of software.
The best thing about it, is it’s Python based, so hopefully Aaron will add those features he’s promising to add in the near future… Otherwise i’ll start tinkering with it myself 🙂
Looks cool. it seems like something that can really help me out
I just had this great idea of doing distributed bugtracking in Git and went googling to see if anyone else had the same idea. And so, here we are. I really hope be succeeds.