Having seen a couple of distributed bug tracking projects: DisTract and DITrack and having read this blog post. I decided it was finally time to put down some of the ideas I've had for a similar system. I decided to focus on a somewhat hybridized system so that one can for example submit bugs directly to a central repository, and not be required to have a complete copy of the repository local. The other major focus is the idea of having a unified interchange format which will be used to transmit bugs between two repositories who can then locally store the bug in whatever way they want. All changes to a bug will be atomized so that it is easier to do merges of the bugs by simply inserting the atomic changes into the history. I'm also curious about playing with the idea of implicit branching of a bug so that if two users submit that they are now working on a bug it will break the bug into two distinct branches where the two users diverged. Certain changes would propogate to both reports and other changes would propogate to only one of the branches. I've written down some notes about how the system will work and I'd like to hear from anyone that might have some ideas to make it better (or some suggestions on what I might have wrong):
Three components:
Interchange is a format that all implementations understand it has two versions a binary and a text version. Interchange is available in both a diff and a full format. Interchange is read in by the client and converted to storage. Storage is any method for storing the atomic changes of a bug operation. Output is a mechanism for displaying the bug information. It can also be used to serialize interchange for clients where implementing interchange is not a suitable option. For example a JSON output might exist which would be used for getting the bugs into javascript instead of implementing an interchange parser in Javascript.
A user will add a bug at which point it will be written to storage, they may then submit bugs to a central bug repository or to another user. The bug is then serialized into interchange and pushed to the other store where it is deserialized and put into storage.
Users are not required to have an entire copy of the bug repository in order to recieve and submit bugs. Nor are they required to use the same storage mechanism as any other repositories they are working with. This way a central server can host the entire repository in a heavy weight database while developers can checkout only bugs related to their personal area of development and store them on the file system.
Adapters are specialized clients which take some sort of parseable format in and convert it to inter- change to be submitted to the central repository. This is used by both the web client and the email client who parse the input into a format which can be submitted. Command line tools also work by con- verting from command line arguments and editor input into interchange. Clients can either submit to a local repository or directly submit to a remote (and potentially central) repository.