Nice to see this on the front page. I wrote a Masters thesis about
distributed issue tracking using darcs' patch theory[0]. You can read
it here[1].
Although the initial goal of the project was to build a working issue
tracker that can integrate with darcsden[2], it later evolved mostly
into a playground for playing with dependent types in Agda. So, sadly
I don't have anything I can show HN yet. I do have a tiny little
private prototype which I haven't gotten around to finishing yet
because of other commitments. Maybe this is just the push I need to
get it working.
I love the idea of BugsEverywhere but the project has languished since I started using it (August of 2013). I've got a faithful reproduction in Java (with the goal of creating an Eclipse plugin) but I've given up on BE ever really taking off.
In any case, I love the idea that I'm committing my issues changes with my code changes!
There is a directory that gets stored in the repository which has all the bug information. There are also email and HTTP server integrations you can set up to have issues be automatically created in a central repository.
In 2013 I did something similar. Unfortunately the state of the art didn't seem to advance any between 2008 and 2013. Perhaps the third time distributed bug tracking flares up in the global discussion it'll stick around and make progress.
It's unpopular currently, mostly because most of the distributed bug trackers mentioned use vcs-based storage without a public-facing frontent. Even as a developer, it's nice to being able to see/report bugs without having to fiddle with VCS commands.
But don't dismiss them.
Fossil, which is not strictly a distributed tracker but rather an entire source-control system, is still maintained and very active. Several popular projects use it. And you do get distributed issue tracking for free.
BE is actually pretty mature. Development has stalled, but you have an email and web interface along with a pretty extensive bug manager which is certainly more advanced than Github issues. When configured with git, it's easy to chose where bug storage should be in-branch or use a dedicated branch.
Using the VCS itself to store data has its advantages. As the early proliferation of projects showed, implementing a distributed bug tracker on top of a distributed VCS is almost trivial. The truth is that if github added support to embed issues in BE format under a dedicated branch, BE would become massively popular.
Then you also have SimpleDefects (SD), which actually implements his own distributed database, web interface (which I'm using) and a bi-directional syncronization plugin system. Way harder to implement, and it's not surprising that SD is less mantained than BE, even though it would hold much more promise (a github issues sync plugin exists, but has bitrotted).
SD, in its current state, is also more featured than github issues.
Give these projects a spin. Contributing to BugsEverywhere in particular is not hard.
The article I wrote was really just documenting all I had learned while researching distributed bug trackers and, when I didn't find any existing distributed bug trackers I liked, writing one myself[0]. I certainly don't dismiss distributed bug trackers and am quite happily using one on a regular basis.
My big question is why distributed bug trackers aren't more popular considering the popularity of distributed version control and the general weakness of the bug trackers on sites like github or bitbucket.
I think bugs have to be on a central place. That's the only way you can track them reliably. What if someone record a bug, commit his/her own repo, but can't/don't push? Bugs might "lost" this way.
This is a non-issue. Issue tracking would work the same way git forks do: there's at any one time, always a "reference" repostory, implicit or explicit.
This same repository will also hold the reference state of bugs. It's really that simple.
The thing is, with a distributed bug tracker you can now also record local bugs which are pertitent with your fork only, while also keeping track of the reference with minimal effort.
I agree. I wrote a clone of Bugs Everywhere in 2010 [0]. Since then I have come to the conclusion that an issue tracker is meant to be central. Per-repo issue tracking is ok for personal projects, but then a TODO.txt probably works just as well.
There is one other place for bugs: The testsuite. Then your test runner needs to have some concept of "expected to fail" though.
Yes ... the BE system creates a .be folder in your Git (or other DVCS) project and you commit changes to your local copy to the server. Issues are text files and binary attachments, so merges behave the same way they would for your code.
Fossil integrates all the aspect of source control into one: source versioning, issue tracking, wikis/documentation, and a self-contained web inferface which is actually pretty nice.
The timeline of fossil's web view has IMHO one of the best visualizations currently[1] when working with multiple branches. It's roughly what gitk/github network graph/git log --graph does, except it's so much better and understandable I wished git developers would catch on.
My current problem with fossil is that it's not so efficient when it comes with large repositories, and I actually like git's staging area. Otherwise, the entire scm is solid, and the UI (web and cli) is definitely superior to git and mercurial.
BugsEverywhere, in constrast, just uses the current repository as a storage for bugs. You can use BugsEverywhere with git, mercurial, bzr, darcs... even with "cvs" if you wanted to.
"You may also send merge requests via the mailing list or using Gitorious."
Since issues are tracked in your local copy, adding an issue to the list and then sending a merge request will add your new bug to the list maintained on the server. If you check out the project, you'll find a .be folder next to the .git folder - this is where the magic happens.
Although the initial goal of the project was to build a working issue tracker that can integrate with darcsden[2], it later evolved mostly into a playground for playing with dependent types in Agda. So, sadly I don't have anything I can show HN yet. I do have a tiny little private prototype which I haven't gotten around to finishing yet because of other commitments. Maybe this is just the push I need to get it working.
[0] http://hub.darcs.net/vikraman/thesis
[1] http://vikraman.org/thesis.pdf
[2] http://hub.darcs.net/simon/darcsden