Current state

1 files changed, 272 insertions, 0 deletions

diff --git a/_posts/distributed-issue-tracking-2013-07.rst b/_posts/distributed-issue-tracking-2013-07.rst
new file mode 100644
index 0000000..58918b7
--- /dev/null
+++ b/_posts/distributed-issue-tracking-2013-07.rst
@@ -0,0 +1,272 @@
+title: Current State of the Distributed Issue Tracking
+date: 2010-06-29T21:42:00
+tags:
+  - computer
+categories:
+  - Fedora
+  - DVCS
+  - issue tracking
+  - bugs
+---
+
+
+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:: https://luther.ceplovi.cz/matej/images/blog/Verdun-landscape.jpg
+    :scale: 66%
+    :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://luther.ceplovi.cz/git/ditz-trac.git/
+
+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 http://luther.ceplovi.cz/git/git-issues.git 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