The Intersection of Distributed Bug Trackers and End Users

Lately (the past year or so) I’ve been using a tool called Ditz to manage my software issues.  Ditz is a distributed issue tracking system; it stores issues locally in a format that is easy for version control systems to efficiently track.  There are some interesting theories about these sorts of trackers (of which Ditz is but one); for one thing, issues can be branched and merged, which means that each branch can have a different state for the same issue – a feature that most issue trackers lack.  But it is also much easier for developers to use; there’s no network traffic, so it can be used offline, and much more quickly than an online tracker.  And you don’t have to use a web interface.

However, these offline trackers have a disadvantage: they’re offline. Ditz comes with a web interface, but it is static.  There’s a dynamic interface (called Sheila), but it’s a pain to set up and doesn’t have a lot of features.  This makes it difficult to elicit bug reports from users.

On the other hand, you have Trac (and Redmine) which are outstanding issue trackers.  Their only limitation is that they’re entirely online, and I find them awkward – as a developer – to use. 

So, I wrote a Ditz plugin, called ditz-trac, to sync Ditz with Trac.  Admit it… you’re awed by my creative naming scheme.  In any case, it works fairly well, but the experience left me with some reservations, and ruminations.

I’m considering whether some sort of direct offline Trac tool might be lower cost for me.  I like ditz just fine, but I’m not sure that I need my issue tracker to be version controllable – I just need it to be off-line-able, and have a separate DB per project.  The version-controllable nature of Ditz is inspiring, but I haven’t used it yet (I don’t branch a lot), and most projects get by without the feature.  In fact, I’m increasingly convinced from what I’ve seen that software developers have no more – and possibly less – than a 50% stake in issue management; users have the other solid 50%.  As for ease-of-use, ditz-like trackers have a split more like 95/5; web-based trackers split it more 80/20.  The more I think about it, the more I believe that a solid web tracker which can be used off-line and sync’ed is the ideal design.

My experience with ditz-trac has shown me that the XMLRPC interface to Trac simply isn’t sufficient for a robust off-line sync’ing.  It imposes too many limitations on the event log.  What I really need is direct write access to the Trac DB, so that I can manage the events with finer resolution.  If I go down that path, though, then one wonders whether it might not be better to simply copy the sqlite DB, rather than trying to shoe-horn the two differing schemas (Trac/ditz) together.

I’m not sure what the best solution is, here.  The branch-ability of Ditz creates obstacles for synchronization, and there are always going to be troubles while the web tracker doesn’t support the concept of hash IDs (all that I’ve seen rely on sequential integer DB IDs, which play hell with implementing writeable clones).  To really get a good sync solution, I’d have to modify the Trac or Redmine DB, and now the solution becomes more complex and difficult for users to install.

I need to think about this some more, obviously.