A probably incomplete list of distributed BTS software.

Using Version Control

These store the bugs in a version control system (VCS), along with the software that has the bugs. This allows bugs to be closed when a commit is made, and in some cases allows bug status to follow branches and merges.

These are distributed in the sense that the VCS is often a distributed VCS; the VCS is used as the transport.

Name Active (last active) Supported VCS's Data Format
git-dit 2017 git
  • An issue is a tree of messages.
  • Each message is stored as the message of an empty commit.
  • Metadata is stores as trailers/git-tags in the message.
  • The tree is hung by references in a namespace.
BuGit 2016 Git Each issue is a Git branch. Git takes care of 99% the merging job
Fossil 2015 N/A Fossil is a VCS
ikiwiki 2015 Git, Mercurial, Darcs, svn, bzr, monotone, tla, cvs
TicGit-ng 2014
Bugs Everywhere 2013 Git, Bazaar, Mercurial, RCS, Arch
  • Issues stored in the relevant branch in the repository, supports merging issues.
Artemis 2012 Mercurial
  • Individual issues are stored in directories in an .issues subdirectory (overridable in a config file
cli
Ditz
Git Issues 2008
git-case
Nitpick
Stick
git-pull-request 2012 Git Take the below with a pinch of salt, it's gleaned from a brief look at the bash script:
  • Pull requests are pairs of branches in a special namespace.
  • One branch holds the actual commit to be merged, one holds metadata.
  • Metadata can include attachments.
  • Comments are commit messages on the metadata branch.
b 2012 Mercurial Bugs stored with code. Index in .bugs/bugs, each bug is a file in .bugs/details/SHA1-id.txt
.bugs/bugs has timestamps on each line; Can Mercurial use this to automatically resolve conflicts, like git-annex does in its metadata branch?

Multi-BTS (data replicating) Systems

These systems allow bugs to be tracked in multiple (non-distributed) BTSs, synchronising state between them.

  • Simple Defects (SD) (built on top of the Prophet disconnected replicated database; can pull/push to RT, Hiveminder, Trac, GitHub, and Google Code issue trackers)

Multi-BTS (non-replicating) Systems

Systems in this list don't actually replicate state and history between different systems, they just provide linkage between systems.

  • The CVE ID system creates essentially a distributed BTS, with each vendor's BTS using CVE IDs to link back to the central problem definition, which in turn links to other affected systems that use the same CVE ID. It is limited to security holes, and an essential difficulty is ensuring that CVEs are both unique and well-specified.
  • RDF profiles of bugs integrated into the BTS (either by content negociation or by inclusion like with RDFa) can help "tag" bugs at different places with same standard properties from compatible ontologies. URI of bugs are then their IDs and eventually resolve to canonical URLs of these in a master bugtracker. Bugs can become part of LinkedOpenData.

Hosted and Commercial Solutions

Uncategorized