Ú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
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 .
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 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?)
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.
DITrack – Distributed Issue Tracker
http://www.ditrack.org/ ... SVN based
This is the granddaddy of all issues-in-separate-branch systems.
Looks like yet another bugs-stored-in-hidden-directory issue tracker. Also, it is dead (last commit is four years old).
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.
http://www.mrzv.org/software/artemis/ ... Mercurial extension, doesn’t work with git.
Completely dead projects
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.
Just to acknowledge that there also other reviews of this area:
- Distributed Issue Tracking with Git
- Wikipedia category “Distributed bug tracking systems”
- LWN article on Distributed bug tracking
- Distributed Bug Tracking and Distributed Bug Tracking - Again
- Distributed issue tracking – the next big thing
- LinuxMafia take on the issue trackers
- DVCS and Bug Tracking (mostly about Fossil)
- dist-bugs and dist-bugs software overview
- evan_tech on distributed bug tracking
- General article on DIT, mainly considering ditz
- Distributed Bug Tracking (as of April 2012).