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 UI, integration
git-issue 2020 independent of your code's VCS files stored in its own separate git repo CLI, import/export with gitlab/github
git-bug 2020 git
  • reference
  • A bug is a branch.
  • A state transition is a commit.
  • A commit contains JSON files, and metadata stored in filenames of empty files.
CLI, terminal UI, web UI, push/pull bridge to gitlab/launchpad/JIRA/github
git-dit 2020 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.
 CLI
Fossil 2020 Fossil is a VCS, bug tracker and wiki integrated SQLite CLI, web UI
ikiwiki 2020 git, Mercurial, Darcs, svn, bzr, monotone, tla, cvs The wiki can be used as an issue tracker (see ikiwiki or git-annex) web UI, markdown files
PyDitz 2019 git PyDitz maintains an issue database directory on disk, with files written in a line-based and human-editable format. This directory can be:
  • under version control in-branch alongside project code
  • under version control on a separate branch
  • optionally excluded from version control
 CLI, html export
Artemis 2018 Mercurial, git
  • Individual issues are stored each as a Maildir in an .issues subdirectory.
  • Comments and state transitions are emails chained by In-Reply-To headers.
CLI, issues can be viewed in a Maildir-compatible mail UI
sit 2018 git, (vcs agnostic others TBD) Items (issue and other artifacts) are file(s) under .sit dir. File format(s) and user-editability TBD. CLI, web UI
BuGit 2016 git Each issue is a Git branch. Git takes care of 99% the merging job CLI, web view (CGI, read-only)
TicGit-ng 2014 git
  • git branch with tree of files
  • one directory per status
  • one directory per bug
  • one text file per metadata attribute, one text file per comment
CLI, web view (read-only)
Bugs Everywhere 2013 git, bzr, Mercurial, RCS, tla Issues stored in the relevant branch in the repository, supports merging issues. CLI, web UI, email, TortoiseGit/Svn/etc
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?
cli
Ditz
Git Issues 2008
git-case
Nitpick
Stick

Using distributed publishing / messaging networks

Name Active (last active) Supported VCS's Data Format
git-ssb-web /
git-ssb /
ssb-issues 		2017 git
  • ssb-issues structured messages on the Secure Scuttlebutt (SSB) distributed social network
  • open/closed status
  • rich text messages (a markdown) that can refer to and be referred to from git pushes and normal SSB messages

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