Teaching old code new tricks

Posted by Chris Ball Mon, 06 Jul 2009 22:58:00 GMT

ExploreTree

Over the July 4th weekend, I found time to release the tree visualizer that Mad and I wrote for the Processing Time code jam a few months ago. Mad's worked on it some more since the code jam, adding a search function, options for specifying font size and the tree depth shown, and a link from each node to its Wikipedia page. The program's available as an applet now, at:

http://exploretree.org/

Feedback welcome, especially if it doesn't work for you and you're able to figure out why.

Bugs Everywhere

Bugs Everywhere, everyone's favourite distributed bugtracker, has been seeing a decent amount of work lately thanks to some strong efforts:

It's nice to keep momentum going on some small projects. Counter-intuitively, I think it's much easier not to get tired of programming when you're working on code for work and different code outside of work, than when you're just concentrating on the code for work.

Tags , , ,  | no comments

Bugs Everywhere

Posted by Chris Ball Sat, 29 Mar 2008 00:54:00 GMT

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.

Tags , ,  | 8 comments