On bug trackers...

My relation with bug trackers is full with disappointments. Or maybe unmatched expectations.

Bugzila, Trac, RT, Redmine, FogBugz, all of them where courted in some form or another. But I'm still a bachelor.

As any successful marriage, there are some things that your partner will bring to the table (organization, perfect memory) and somethings that you need to be happy (the ability to integrate with my workflow). And so far, all of them failed to make me happy.

I think I can blame darcs and git, as they reminded me that version control can be fun. I wonder: are DVCSs my mistresses?

As soon as I tried darcs, I was hooked on distributed version control systems, and the workflows they allowed (in particular off-line work), and both CVS and Subversion lost any sex appeal they had right there. Its like those two lost two thirds of their IQ. With git, the passion that started with darcs turned into a workable happy marriage: no more waiting for her to take hours to get ready for a simple dinner.

So now I can work seamlessly between several computers, and my new partner git keeps my source code sane and consistent.

But this new found freedom makes the bug tracking system I used the weak link. They stick to the old ways, of a central place where everything is done, and lack the flexibility to just hop on the car, drive somewhere nice and keep on working.

What I wanted was the same kind of love that I got from the distributed nature of the others. The ability to work anywhere and have my tickets right there, locally, with fast access and keep on working, even if the network is not.

There are some cute new systems around, bug trackers that use a DVCS as a backend. But I have a problem with them: the explicit need to pull/push the ticketing branch.

The problem derives from a misconception: if you use a DVCS for code, with an occasional pull, integrate, push cycle, it shouldn't be a problem to use the same workflow for tickets, with an occasional pull, fix conflicts, push. They look similar, but actually they are not.

But tracking and ticketing are essential for team communication and should be as close to real-time as possible. If I create a new ticket or add a new comment or change ticket meta-data, it would be very useful to propagate that to all the replicas of my ticketing database.

Of course, the change could cause a conflict, but you can work in "apply until you get a conflict"-mode, and then, when you have the attention of the user, say "hey buddy, I have some changes here that need some work from you".

In reality, if most replicas are online most of the time, conflicts should be rare, because each person will be working with fresh, up-to-date world view.

The main difference is that DVCSs are always offline and occasional go online to synchronize. A distributed ticketing system should be always online, with occasional offline periods, during which you queue up changes to publish later.

And this would allow a "just close the laptop and go"-kind of workflow. The local ticket database has all the updates from everybody, and it will synchronize with others when you are back online.

So far I haven't found a system with all this features. The last couple of months I have been playing with two systems to see if they are solution (completely or partially) to this problem.

The first one is CouchDB. It is not a ticketing system, but it is a document-oriented database with a nice HTTP-based synchronization protocol, and a interesting way to deal with conflicts.

Although I think you could make it work, it lacks any kind of security for now (should be available in the 0.9 release) and the use of HTTP for synchronization makes it hard for peer-to-peer synchronization.

I came across the second system last week. Its called Prophet, and it is written by the same people who wrote RT, Best Practical.

Prophet is actually a distributed database. On top of it, they wrote SD (simple defects) that is able to do most of what I'm looking for.

I've read through the docs and parts of the code, and it has a very nice design.

Synchronization is field-based, not document based, so you can have two different persons editing two different fields and don't generate a conflict. Of course, real-world is more complicated than that, and certain field combinations might be invalid, but it seems (still checking) that the conflict resolution code is pluggable so you might be able to have some code that validates the document after any field changes and generates a conflict in those cases.

On the negative side, it still requires a pull, resolve, push cycle. It also seems to bundle the fetch and merge into a single operation, so a always-on-fetch and occasional merge might require some coding.

I guess I still haven't found the ticketing system of my life, but peer-to-peer database synchronization is starting to see some real work, so the basis of a system like that should be available soon.