The SD distributed bug tracker

On last week's Development page we looked at the Fossil version control system, with one of its distinguishing features being the inclusion of distributed bug tracking as part of the tool. Another distributed bug tracker has recently come to our attention, and that is Simple Defects, or SD for short. There are a number of different distributed bug trackers out there, with Bugs Everywhere seeming to hold the role of "leader of the pack", but a brief introduction to SD seems in order.

So far, distributed bug tracking (DBT) hasn't taken off quite like distributed version control systems (DVCS) did, but there is still a fair amount of interest in the idea. In some ways, it feels like the DBT communities are still feeling their way, much like the pre-2005 DVCS world, and that at some point, the right combination of features will come about in one or more projects (much like the broadly similar feature sets of Git, Mercurial, and Bazaar did). Once that happens, DBT may find its way into more and more projects.

The basic idea of DBT is that centralizing bug tracking on one system makes it difficult for disconnected developers to easily handle editing bugs while they are fixing the code. There are (at least) two ways to approach the problem, either by somehow keeping the bug reports and code in the same repository (which is Fossil's approach) or by having a separate repository for bugs that can be synchronized in ways similar to that of a DVCS (the approach of SD and Bugs Everywhere). The latter approach has the advantage of being able to work with multiple version control systems, but it has the disadvantage of requiring developers to manage their code and bug repositories separately.

SD is written in Perl to sit atop the Prophet distributed database. Both Prophet and SD are available on the Comprehensive Perl Archive Network (CPAN), but the developers recommend getting them from the Git repositories if possible due to the rapid development pace. The development logs seem to bear that out as there hasn't been a release since Prophet and SD 0.7 in August 2009—though there seem to be more recent CPAN updates—while the Git logs show progress as recently as early March.

One thing that can't be said for SD (or Prophet) is that they are overly burdened with documentation. That may tend to chase away potential users, but the terse Using SD page does cover many of the topics that users are likely to be interested in. The basics should be familiar to anyone who has used a DVCS, as you clone a ticket repository with:

    $ sd clone --from http://example.com/path/to/sd

or initialize a new repository with:

    $ sd init

As with Git et al., you synchronize from a remote repository with a pull sub-command, and update remotes using publish (instead of Git's push). Bug tickets are created with the unsurprisingly named:

    $ sd ticket create

command, which opens your text editor with a template to create the bug. There are, of course, various commands to search and update bugs, as well. The browser sub-command will put SD into server mode and start up a web browser to search and edit bugs. SD also provides ways to synchronize its bugs with other systems like Trac, GitHub, Google Code, Hiveminder, RT, and others.

Overall, it seems like an interesting system for projects that are looking for a simple DBT that doesn't combine code and bugs into a single repository. That is one of the advantages of SD, at least for Lars Wirzenius, who made the blog post that introduced us to SD. He also notes that it seemed to him to be the most mature of DBT systems currently, which is a little surprising given the status of Bugs Everywhere. The ability to handle bugs from the command line is another advantage that he cites.

The lack of documentation is somewhat intimidating, and overall the projects could use a bit of work on their web sites. The wiki is largely a placeholder, and the project pages have just the bare essentials. In fact, for Prophet, even the bare essentials appear to be lacking, which is unfortunate as the description sounds intriguing: "Prophet is a new kind of database designed for the post Web-2.0 world. It's made to let you collaborate with your friends and coworkers without needing any kind of special server or internet provider." It sounds like something that might prove useful to projects like the Freedom Box.

While SD and Prophet may still have quite a ways to go before being ready to handle larger projects or ones with different needs, they do currently work for some projects. For Perl programmers with an interest in DBT (or a distributed database), they might provide a nice opportunity as a project to contribute to. For others who just want a simple DBT to use, its probably worth taking a peek at SD.

---

to post comments