I was positively surprised to see Hubert Figuière write about decentralising bug tracking yesterday. This is something I’ve thought about and discussed vividly with friends over the past year, and his excellent write-up gave me an opportunity to organise my own thoughts on the matter.
In my career I’ve yet to come across a good system for bug tracking. The available options are usually, with some notable exceptions, behemoths of the last century. Putting it bluntly, there’s been little or no real innovation on this front over the last 15 years, approximately since when Mozilla first released Bugzilla in 1998.
Available and existing bug tracking software are simple web applications featuring a page to look up bugs, a form to file new issues, some search functionality, and comment functionality. The more complex alternatives bake in resource tracking and time management. More fundamentally, however, they are all hosted applications with traditional server-client setups backed by a standard create-read-update-delete SQL database.
Other pieces of our technology stack have received significantly more attention. The Linux kernel, being one of the bigger free software projects of its day, started reconsidering the server-client relationship for sharing changesets amongst developers early on, and switched to BitKeeper, one of the pioneering distributed revision control softwares. Instead of requiring users to talk to a central server, you let changesets be synchronised amongst individual users. This is done by the users pulling in eachother’s changes. Admittedly you still need canonical servers to ease the initial checkout, but it is a novel concept that makes the server just another node in the grid.
Distributed version control used to be a novelty, but soon led to a myriad of different implementations. Amongst the more popular ones we find git and hg. Combined, these power the vast majority of new software projects in the open source world. There appears to be general agreement that distributed computing systems, and distributed versioning control in particular, are effective ways to collaborate and get things done in a day and age where team- and individual contirbutors are geographically displaced.
Indeed, users are finding these systems generally useful
to also have other practical applications.
Centralised hosting providers such as
Github are offering
gh-pages branch of repositories.
It is also interesting to note
how repositories are beginning to incorporate
things that traditionally used to live on hosted servers elsewhere;
code, web content, wiki, containers, images, configuration;
and becoming self-hosted and distributed entities,
which in essence makes one less dependent on a single remote.
What if we were to take this idea and apply it to bug tracking? An in-repository branch may hold bug issues backed by a program to manipulate issues and add comments. Not totally dissimilar to the way Maildir works. mu is a great example of a program to interact with that format. This needn’t mean that we couldn’t have centralised web interfaces on hosted servers anymore; in fact they would be much easier to clone and host. With a load balancer and individual syncing in the backend they should also be able to more easily cope with heavy load, which is an absolute requirement today.
One could also envision local browsing of issues,
either through spinning up a local web server
or through a more traditional gitk or gitg UI.
In fact Mercurial already does this through
that spins up a local HTTP server for browsing files, changesets, and more.
For a distributed bug tracking system
one could foresee using this as a possible interface to search,
add comments, and triage bugs in.
Because it might sit in the same repository as your code,
you might get much tighter integration with the program code
than you’d normally get in traditional BTSes.
The prospect of this opens up for interesting correlation
and connections not easily achivable in traditional bug tracking software.
Is the time ripe for rethinking bug tracking? I think so. A successful solution needs to be simple to understand from a technical perspective, e.g. no complicated backend for storing the data. It needs to implicitly deal with conflicts that would probably be quite hard to achieve. It needs to have a great toolchain to make it easy to adopt and integrate with. And it needs to rely on proven technical solutions instead of reinventing the wheel at every opportunity.
Thanks to Berge Schwebs Bjørlo for valuable feedback. The styling and wording of this document was updated in March 2016.
Andreas Tolfsen works for Mozilla on the code used to automate and help develop Gecko and Firefox. He is the author of several WebDriver implementations, including Marionette and OperaDriver. Previously he led the core infrastructure team at Opera. He also holds a BA in Musicology from the University of Oslo.