Current State of the Distributed Issue Tracking

Út 29 června 2010

While listening to the old issue of The Git Minutes podcast, I was again reminded about the possibility of the distributed issue tracking. Albeit I have grown to be persuaded that the issue tracking has to have available web input (because “normals” won’t file bugs via git) and tried to work with normal Bugzilla (and found it surprisingly simple), I am still intrigued by the idea of the issues data (or metadata?) stored in the repository itself and followed with the git branches. Therefore, I have decided to write this brief overview of the current state (i.e., summer 2013) of the distributed issue trackers (mostly limited to those working with git), and to evaluate whether it would be possible to use some of them.

Generally to introduce whole landscape of the distributed issue trackers let me present you this very old photograph of the landscape after the Battle of Verdun

Landscape after the battle of Verdun, dead bodies and destruction everywhere

Unfortunately, this image really well represents the current situation of the distributed issue trackers. Most of the projects mentioned below are defunct and abandoned even by its original authors.

Generally I would say that the thinking in this area ended up in one of the two camps:

  • Issue tracking data stored as normal data in repository — data are either stored in file or (more often) in a special directory and versioned like any other data. Such solution is obviously very simple and moreover it could be independent of the particular VCS (which used to be interesting, these day almost everybody switched to git or hg). Moreover some reviewers were really excited over binding progress on tickets to particular commits, which is obviously a big deal with some organizations (e.g., for QA purposes). The most developed and alive version of this type of distributed issue tracker is Bugs everywhere which still shows some signs of life and it is IMHO closest to the working program.
  • Issue tracking data stored in a separate git branch — after some time working in the previous model, I got rather unhappy with it and longing for a little bit more centralized model. I have managed to file bugs to incorrect branches and completely loose them, I hated a lot of mess BE did in my commits (because of merging most DIT use plenty of UUIDs and plenty of small files, which then clog all commit messages). And after all, I have decided that issue tracking is something which doesn’t have to bother everybody, but it should be optional. If I want to track issues, I should be able to, and I should be able to share my tickets with others, but if I use DIT for project which has its own upstream tracker (BTW, import and export from/to centralized issue trackers is a problem which not many DIT deal with well if at all), then I shouldn’t bother them with my mess. For this (and certainly other) reasons there is now a class of DITs which store tickets in its own git branch. Obviously such solution is not DVCS independent and hidden writing to the git branch behind the back of the normal code management makes it way more complex to debug, but there are some contenders, the most interesting one being in my opinion gitissius .

Bugs everywhere

http://bugseverywhere.org/

http://gitorious.org/be/be/

Seems like alive project (which is rare), the latest commit on master was just in the October last year (by me, true ;)). Also, written in Python, which is a plus (for me).

gitissius

gitissius is another rare example of the project which is not completely dead yet. Also, I have been working on some improvements , but nothing has been merged in the upstream yet (perhaps, because it is broken?)

Ditz

Rubyforge homesite, also some bugs are listed on Launchpad, and there is (dead) email list

Python clone ... pitz https://github.com/mw44118/pitz

Ditz commander https://code.google.com/p/ditz-commander/

There is also ditz-trac to sync ditz database with Trac. Not working ATM.

cil

Presentation and code

DITrack – Distributed Issue Tracker

http://www.ditrack.org/ ... SVN based

ticgit

https://github.com/schacon/ticgit/wiki declares project as dead and suggests https://github.com/jeffWelling/ticgit

This is the granddaddy of all issues-in-separate-branch systems.

git-issues

https://github.com/jwiegley/git-issues

I have my own version with an attempt to bring a little bit of sanity to the code on https://gitlab.com/mcepl/git-issues but truly, one should use gitissius instead.

git-case

http://dist-bugs.branchable.com/people/bartman/git-case/ and https://github.com/bartman/git-case

Looks like yet another bugs-stored-in-hidden-directory issue tracker. Also, it is dead (last commit is four years old).

stick

http://www.eharning.us/wiki/stick/, unfortunately the link to the code gives 404.

SD

https://lwn.net/Articles/434922/ and http://syncwith.us/sd/

Not part of any DVCS, distributed only the meaning that it is based on the distributed database Prophet. There is a nice discussion by Lars Wirzenius why he believes that’s The Right Thing™ to do, and why bugs shouldn’t be stored in the repository itself.

Artemis

http://www.mrzv.org/software/artemis/ ... Mercurial extension, doesn’t work with git.

Completely dead projects

DisTract Linuxmafia article has this to say about it:

We're all now familiar with working with distributed software control systems, such as Monotone, Git, Darcs, Mercurial and others, but bug trackers still seem to be fully stuck in the centralised model: Bugzilla and Trac both have single centralised servers. This is clearly wrong, as if you're able to work on the Train, off the network and still perform local commits of code then surely you should also be able to locally close bugs too.

DisTract allows you to manage bugs in a distributed manner through your Web browser. Currently only Firefox is supported. The reason for this is that there is no local server used, and so the Web browser must directly (via Javascript) call programs on your local system. I only know how to do this in Firefox. The distribution is achieved by making use of a distributed software control system, Monotone. Thus Monotone is used to move files across the network, perform merging operations and track the development of every bug. Finally, the glue in the middle that generates the HTML summaries and modifies the bugs is written in Haskell.

Other features include the use of Markdown markup syntax for bug descriptions and comments, with live preview via a Javascript implementation of Markdown.

Code is Haskell and Javascript. New BSD licence.

Category: computer Tagged: Fedora DVCS issue tracking bugs git