hI’ve been thinking a lot more about Distributed Bug Tracking. I’ve even gone so far as to write up a spec for a new system of handling distributed tickets that could be implemented in any Distributed Version Control system, but I haven’t gone so far as to actually implement it (although it wouldn’t be hard) because of one simple problem: existing systems.

Distributed Version Control is nice because you can sneak it in the back door. It doesn’t matter if your company / coworkers are using a centralized version control system you can always branch from it with your distributed system of choice and then merge back in to their centralized system when you’re done. It doesn’t really matter that people can’t see what’s going on in your personal branches because they’re your personal branches. But tickets aren’t like that. Tickets are all about visibility. The whole point of a ticket system is to give visibility to issues, be they bugs or feature requests. So, while you could easily write a centralized ticket system that was designed to work well with distributed ticket system (my spec makes sure to keep that in mind), I’ve yet to come up with a way to make a distributed ticket system work well with any existing centralized system. The existing centralized systems simple don’t take into account which branch a bug exists in, and they’re all so wildly different under the covers that even if they did you’d still have to write a driver for each one.

The great thing about sneaking Distributed Version Control in through the back door is that when the process and the tools finally manage to get enough recognition by large companies to actually come up for contemplation the ground troops of engineers can stand up and say “Yeah, we know, we’ve been doing it for years, and yes it actually works with our codebase(s).” But I’m just not seeing a good way to do that with distributed ticket tracking.

Two questions have arisen for me, and I’d really appreciate your thoughts on them. Both are predicated upon the assumption that someone’s written a viable distributed ticket system that works with your favorite distributed version control system:
1) In order for distributed ticket tracking to catch on do we need to be able to work with existing centralized ticket system that don’t have a clue about branches, like Bugzilla in order to get people to start using distributed ticket systems, or would convincing the few projects that largely eschew centralization be enough?
2) If we do need / want to get traction in existing projects that use centralized ticket trackers what functionality is required to create an infrastructure that can work with whatever ticket system a project happens to have chosen and how can we minimize the amount of work required to build drivers for them?

The greatest problem distributed ticket systems will have is visibility. The second greatest problem is data complexity. For any ticket system to succeed people need a place where they can go to see all the tickets that affect a project no matter what branches they do or do not exist in. I believe this problem is entirely solvable but once we have done so we will be faced the the problem of complexity. A distributed ticket tracking system prevents people from continuing to pretend that the state of bugs (and other tickets) is some global binary, where it’s either present or it isn’t. Distributed ticket systems expose Scrodingers Bug to the light of day. We exist in a world where bugs are both live and dead and you don’t know which until you observe the branch it’s in and the wave-form collapses. Any system that allows visibility into the tickets of each branch is going to have to expose those various states and doing so without confusing non-geeks is going to be a tricky UI problem.

I am currently of the belief that until people can use a distributed
ticket tracking system in their day to day work any implementation, no
matter how good, is largely academic. Furthermore it will continue to
be so until the developers of the world have begun to truly understand
and embrace the benefits of distributed version control, and judging by
the many smart geeks I talk with who still have no real knowledge of
them we’ve got a long ways to go on that front.