
Bugs Everywhere - luu
http://bugseverywhere.org/
======
namarkiv
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.

[0]
[http://hub.darcs.net/vikraman/thesis](http://hub.darcs.net/vikraman/thesis)

[1] [http://vikraman.org/thesis.pdf](http://vikraman.org/thesis.pdf)

[2] [http://hub.darcs.net/simon/darcsden](http://hub.darcs.net/simon/darcsden)

------
smoyer
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!

~~~
detaro
So how does it work? Does it put files in the repo? a parallel branch
structure? something else?

~~~
michaelmior
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.

------
evmar
I wrote a mini-survey of distributed bug tracking in 2008 here:

[http://evan-tech.livejournal.com/248736.html](http://evan-
tech.livejournal.com/248736.html)

~~~
travisb
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.

[http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTr...](http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTracking2013-04-20)

~~~
tenfingers
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.

~~~
travisb
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.

[0] [https://github.com/travisb-ca/nitpick](https://github.com/travisb-
ca/nitpick)

------
Walkman
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.

~~~
tenfingers
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.

------
mintplant
So how does a user submit a bug? Through a merge request or something? Maybe
I'm just overlooking something, but I couldn't find this on the page.

~~~
smoyer
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.

------
Rexxar
What is the advantage over something like fossile[0] ?

[0] [https://www.fossil-scm.org/](https://www.fossil-scm.org/)

~~~
tenfingers
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.

[https://www.fossil-
scm.org/index.html/timeline?r=trunk&nd&c=...](https://www.fossil-
scm.org/index.html/timeline?r=trunk&nd&c=2015-05-30+21%3A51%3A19&n=200)

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.

------
kr0
I find it odd you have to mail bugs to the developers

~~~
smoyer
"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.

------
zeeed
it would be nice to see how the public facing frontend is organized. sadly it
looks like [http://bugs.bugseverywhere.org/](http://bugs.bugseverywhere.org/)
is down.

is there another place to check it out to get an installation with some actual
data?

