April 20th, 2008On this day in different years

  • evan

distributed bug tracking

Distributed bug tracking is the natural extension of distributed version control. Aside from the normal benefits of distributed version control, like being able to interact with bugs database while offline, there also seems to be a trend of making the interface to them work via the command line instead of annoying web-based systems. And, like with Trac, the integration of issue tracking with the source is pretty natural: when you've fixed a bug on a branch you can mark the bug as fixed in that branch, and when that branch lands on your "main" tree that tree's bug state is also merged as a natural consequence of how merges work.

It seems like there isn't dominant software for this yet. Here's my five-minute take on the software I can find:
  • Fossil is its own full version control system that integrates a bug tracker as well
  • bugs everywhere -- perhaps abandonware, last commit was July 2007
  • DITrack -- subversion only, "planning to be backend agnostic" (not sure how svn matches up with distributed, but ok)
  • DisTract -- only a web interface using Firefox-specific Javascript to write to disk(?), requires monotone, latest news August 2007
  • TicGit -- just learned about it five minutes ago so not sure yet; seems a bit janky to keep bugs in a separate branch
  • Ditz -- seems the most appealing to me except that it's all of three weeks old, has emacs integration*, last commit last week
For whatever reason these all seem to involve the most obscure technologies available: in the above list I see fossil, bazaar, monotone, and even Haskell.

From reading through these I find a surprising variety of models. Here's what seems to me to be the simplest and sanest model: the bugs live in a normal top-level directory in your tree alongside "src" or whatever other directories you have; each issue is in its own file; comments are modifications of the per-issue file.

But more generally, I'm not even sure if distributed is the appropriate model. The action of recording a new bug modifies the current version of a branch but the bug's existence usually is older than the most recent commit (for example, it often belongs in older branches that have branches off before the bug was added). So if a new bug is fixed in an older branch, there's no way to merge that new bug into the older branch without merging the entire state of the newer branch in. Is that sensible? I'm not sure. The alternatives all seem to involve tracking bugs separately from branches and trying to match them up after you commit (like when commit messages mention bug numbers) which always feels like a failure of technology.

The other issue that's I'm unsure about is how to integrate a sane web-based frontend for casual users who want to be able to query and report bugs without checking out the code. Some systems have web frontends but it seems to me conflicts could be hard to resolve. Maybe if you make sure a modification to an issue is always appends, and then add some smarts that auto-merges simultaneous adds by some textual timestamp included in the add.

Needs more thought. Sorry for the braindump.

* I'm a vim user, and don't really care about editor wars, so I mention it only to note that emacs integration isn't as useful for me.