04:35 pm, 20 Apr 08
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:
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.
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
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.
>
> [...] I don't think I understand your second point.
Suppose, I've spotted a bug and report it to my private "repository". In a day or two I have it fixed.
Now. "Upstream" [distributed] BTS knows nothing about my bug. And this makes very little sense for this bug to get committed into upstream repository. That's what I meant...
Any BTS, whether distributed or not, should list outstanding bugs. But the ones discovered somewhere and resolved already... historical garbage to be ignored.
Does this make any sense?
If you were using a centralized BTS, would you report and then close the bug on the centralized system? If so, then syncing your closed bug up to the server is the right thing, or at least the same behavior. Otherwise, you shouldn't have marked the bug locally either.
It's not garbage. It has the same use as all the other bugs that were open for a while and then closed. Do you propose all BTSs should delete closed bugs?
I'd expect my BTS to be able to answer the question: has there ever been a bug in this component with this keyword and what happened to it?
Not garbage at all. A published commit never changes; it’ll always have the previously noted defect. Anyone looking at a historical commit for whatever reason should therefore be able to find out what defects affect it.
Thanks.