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
