Hmmm. Your link distinguishes 3 cases, out-of-tree (such as
in a github bug tracker), off-branch (which appears to be what
you are suggesting, right?), and on-branch (part of the sources
in the Axiom scheme).
He raises the question of merging bugs where systems might
have custom software to do things like maintain state (fixed?
diagnosed? open?). In the abstract this is a simple task that
really doesn't need much automation. The github-style out-of-tree
systems seem to have the most (and incompatible) automation.
He also raises issues of distributed bug tracking where there are
multiple sites and/or multiple VCS. This tends to undermine
things like bug state since it is not universal. So any system
that is multiple sites/VCS such as Axiom runs into the state
problem. If there are 3 states on one site and 7 on another,
how are bugs classified?
He raises the problem of a GUI, potentially two versions,
one local and one remote. If there are multiple sites he raises
the distributed database issue. More code, more work, less gain.
Books don't need a GUI, just a PDF reader.
For most of its life Axiom stored bugs in the mailing list.
These were collected into a single "buglist" file a couple years
ago. The recent discussion caused a revisit of the buglist and
made it "first-class" as a literate source, enabling the features
I previously mentioned. Now it is a live object, not just a list of
bug reports and comments.
Axiom's literate version is "on-branch", uses no special state code,