Current State of the Distributed Issue Tracking ############################################### :date: 2010-06-29T21:42:00 :category: computer :tags: Fedora, DVCS, issue tracking, bugs, git 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`_ .. image:: {filename}/images/Verdun-landscape.jpg :scale: 50% :align: center :target: http://www.edinburghwargames.com/Modern%20Images/WW1/Verdun-landscape.jpg :alt: 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. .. _`the old issue of The Git Minutes`: http://episodes.gitminutes.com/2013/04/gitminutes-04-marius-mathiesen-on.html .. _`the Battle of Verdun`: https://en.wikipedia.org/wiki/Battle_of_Verdun 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_ . .. _some: http://www.ericsink.com/entries/dbts_fossil.html 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?) .. _example: https://github.com/glogiotatidis/gitissius .. _improvements: https://github.com/mcepl/gitissius 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. .. _Rubyforge homesite: http://ditz.rubyforge.org/ .. _Launchpad: https://bugs.launchpad.net/ubuntu/+source/ditz .. _email list: http://rubyforge.org/pipermail/ditz-talk/ .. _ditz-trac: https://gitlab.com/mcepl/ditz-trac cil --- `Presentation`_ and `code`_ .. _Presentation: http://wellington.pm.org/archive/200806/andy- cil/index.html .. _code: https://github.com/chilts/cil 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. .. _`link to the code`: http://git.eharning.us/cgi-bin/gitweb.cgi?p=stick.git 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. .. _Prophet: http://syncwith.us/ .. _discussion by Lars Wirzenius: http://blog.liw.fi/posts/experiences- with-sd/ 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. .. _DisTract: http://www.distract.wellquite.org/ .. _Linuxmafia article: #linuxmafia Other overviews --------------- 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). .. _Distributed Issue Tracking with Git: http://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/ .. _Wikipedia category “Distributed bug tracking systems”: https://en.wikipedia.org/wiki/Category:Distributed_bug_tracking_systems .. _LWN article on Distributed bug tracking: https://lwn.net/Articles/281849/ .. _Distributed Bug Tracking - Again: http://erlangish.blogspot.cz/2007/06/distributed-bug-tracking-again.html .. _Distributed issue tracking – the next big thing: http://blog.fealdia.org/2008/10/18/distributed-issue-tracking-the-next-big-thing/ .. _LinuxMafia take on the issue trackers: http://linuxmafia.com/faq/Apps/trouble-ticket.html .. _DVCS and Bug Tracking (mostly about Fossil): http://www.ericsink.com/entries/dbts_fossil.html .. _dist-bugs: http://dist-bugs.branchable.com/ .. _dist-bugs software overview: http://dist-bugs.branchable.com/software/ .. _evan_tech on distributed bug tracking: http://evan-tech.livejournal.com/248736.html .. _General article on DIT, mainly considering ditz: http://nullprogram.com/blog/2009/02/14/ .. _Distributed Bug Tracking: http://www.tychoish.com/rhizome/supporting-distributed-bug-tracking/ .. vi:wrap:tw=0