As I mentioned earlier, Zendroid uses git. After I started as the third developer at the startup, we needed to establish real (scalable) development practices. I started looking at different open source issue trackers. Two systems that are implemented as git plugins are ticgit and git-issues, the latter being a python clone of the former ruby program.

Both projects are still in their infancy and quite unpolished, but still managed to seem promising. They track tickets that can be assigned, prioritized, commented and solved. However, they do this by using something akin to git-shelve to store ticket information in a separate branch.

This just doesn't work. Git can only operate on one branch at a time. Pushing and pulling changes to the issues branch require checking it out (involving much copying and losing changes made to the working tree (unless git-stash is used)). Also, a single commit can not both fix a bug and mark it as fixed. Of course one could keep a separate working copy with the issues branch checked, which is again not at the level of integration we would want. The tools could (quite easily) provide an interface for syncing the issue branches but although git-issues has such a thing documented, neither project implements it.

This leads to the other gripe I have with these two pieces of software. Both were inadequately documented and often threw backtraces instead of error messages. Somehow both have gotten stuck at the proof-of-concept stage, possibly because of the cumbersome separate branch model. We started looking at alternatives, briefly considering the all-so-trendy Lighthouse and totally not considering trac.

Ditz to the rescue. I had heard of the project previously but had thought it as something simple like devtodo. Not so. Ditz offers all the features git-issues and ticgit do and more. One can group tickets into bundles (releases) and annotate, comment and query them in all thinkable ways. Additionally the tickets are stored in a separate directory in the same branch as the code they refer to, and are formatted as YAML (yay!), making merging very easy and pleasant. Ditz is also well-documented and actively developed. The only problem we have bumped into is that a ticket that someone has claimed can not be "stolen" without hand-editing the ticket files.

So, that sorts out the technology side. On the human side of things we schedule tasks with dated releases. All the issues grouped into a certain release are meant to be cleared before the set date. In addition we have larger releases that roughly correspond to milestones. Ideally, all work done should be related to a ticket claimed by the developer and marked as "started". Changes to tickets are propagated in sync with code changes.

Update 2008-10-06: Git actually uses hardlinks when changing branches, so performance isn't the problem. In any case the semantic load (and ugliness) remains.

Also: I forgot to mention that we have a separate review project that contains code-review tickets.