Bugs Everywhere

by luu • 11 years ago

71 22 11 years ago

smoyer3• 11 years ago

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• 11 years ago

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

michaelmior2• 11 years ago

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.

kr0• 11 years ago

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

smoyer3• 11 years ago

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

michaelmior2• 11 years ago

There is also an Web interface which can be used to file bugs. However, but reporting by email is still relatively popular for a lot of projects.

mintplant• 11 years ago

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.

smoyer3• 11 years ago

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.

evmar2• 11 years ago

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

http://evan-tech.livejournal.com/248736.html

travisb2• 11 years ago

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

evmar2• 11 years ago

Your post is much better than mine! I am glad that I commented if only to cause you to paste the link!

namarkiv2• 11 years ago

You might be interested in my comment:

https://news.ycombinator.com/item?id=9633394

tenfingers3• 11 years ago

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.

namarkiv2• 11 years ago

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

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

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

Walkman• 11 years ago

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.

qznc• 11 years ago

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.

[0] http://beza1e1.tuxen.de/articles/later_bug_tracker.html

stephenr• 11 years ago

By that logic, decentralised version control doesn't work, because the developer might commit some code but not push it.

tenfingers3• 11 years ago

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.

zeeed• 11 years ago

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

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

Rexxar• 11 years ago

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

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

tenfingers3• 11 years ago

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

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.

Bugs Everywhere

Related Stories