Take the 2-minute tour ×

We've pretty much licked the whole distributed thing for version control at this point. I'm not saying everything's perfect, but, from hereon out, it's mostly just a matter of continuing what has already been started.

Distributed bug tracking, though, is in its infancy stage, IMHO. It's rather inconvenient, not being able to work with an issue tracker on the road, especially since I have a tendency to forget what my changes over the past two hours were for. Yes, I know, I could just keep a log on the road and update a traditional tracker as soon as I get on the net again, but still... Keeping my options open and all that. :P

Currently, I only know of Bugs Everywhere and Ditz-- those, and the one that comes with Fossil. Of these, I think Fossil is the farthest along, which is not suprising, considering how tightly it's integrated with the version control side of the equation. I've had to jump through quite a few hoops to get my co-devs to even look at something other than SVN, but, if Fossil really is all that, I wouldn't mind doing it again.

Before I do, however, I want to ask older and wiser heads than mine: Do you have experience with these three? What do you think of them? Do you know of others? Please link to them, and let me know how they fared.

share|improve this question
add comment

4 Answers

Fossil works as an 'easy to setup' Distributed Bug tracker , and has a nice autosync facility that lets developers share their bugs without intervention.

to get started,

  1. Download the fossil binary of your choice
  2. fossil new bugs.fossil
  3. fossil ui bugs.fossil (runs the server)

your developers do the same

  1. Download the fossil binary of your choice
  2. fossil clone
  3. fossil ui bugs.fossil
  4. set up a cron job to 'fossil sync ...' so the bugs propagate to all users as the fossil self-hosting repositories demonstrate

There is not much more to it than that.

Edit - take a look at Customizing The Ticket System too.

share|improve this answer
add comment

Because I wanted (well, needed, really) a solution that could probably (maybe, hopefully) work right now, we went with the following setup:

It may not be the perfect setup, nor even a particularly acceptable one to some, but it meets the criteria of working right now. I still would like to learn more from others; maybe I'm missing a not-so obvious trait of other solutions that would cause me to become fanatic enough that I'd bug my co-devs to switch.

Anyway, if anyone uses this, or a similar, set of tools, please let me know how it's worked out so far for you, what your circumstances are, etc. Right now, this solution of ours is all of three days old, so I really don't have much data to share as of yet.

share|improve this answer
Bugs Everywhere looks interesting! I may play with that with my personal stuff just because I can! –  Murph Dec 13 '09 at 11:44
LOL; I'd say that's more than enough reason to try it out. :D –  Neil Santos Dec 14 '09 at 14:11
Well, it's almost been a year, and I'm looking at the same problem... So how has this worked out for you? –  Mike DeSimone Nov 10 '10 at 19:48
Didn't get much of a chance to strain the arrangement; the "team" got reduced to just myself after a couple of weeks (downsizing; what're you gonna do? :P). Currently, I just have a list of design issues in Zim, though I fully intend to figure out a good-enough solution for bug-tracking at some point. –  Neil Santos Dec 21 '10 at 9:05
add comment

Eric Sink has some sensible thoughts on the subject here - he's clearly given it more thought than me but he does make one key point which is that you have a different paradigm when dealing with features and bugs to when dealing with development, particularly with respect to bugs.

share|improve this answer
Agreed; sensible it is. However, it's more of a paper on what a distributed bug tracker ought to be and do-- what I'm hoping for is more of a discourse on other people's experience with the aforementioned tools and the others I'm sured I missed. Good reading, though. –  Neil Santos Dec 7 '09 at 11:11
The very real problem in this case is that I suspect that there aren't a lot of people with meaningful experience )-: –  Murph Dec 7 '09 at 11:37
I suspect you're right. :P That, and the tools aren't really ready yet. Except they won't ever be ready until people use them. Sweet catch-22. :P –  Neil Santos Dec 13 '09 at 0:24
Sooner or later someone will go lock themselves away for a month and churn out something that is a) useable and b) will go viral... this reflects the vocational programmer's inherent response to being unable to find a tool that works just as they need and certainty that they can do better! –  Murph Dec 13 '09 at 11:40
You're giving me an idea. :D Honestly, though, I wouldn't mind one that went viral before it was usable. It's better to have a buggy program that a lot of people use and/or work on, rather than a 'perfect' one that nobody else knows about. –  Neil Santos Dec 14 '09 at 14:12
show 3 more comments

Additional information for people like me who're interested in the subject, but can't pull up enough relevant info through Google (either they're not there, or my Google-fu is severely lacking):

  • Just branched Bugs Everywhere again. bzr log --limit 1 shows the last commit to be from early October 09. The development is slow, but it's there. I haven't yet dived in to see just what exactly be offers. Documentation is severely lacking. There isn't even a quick-start guide on the site.
  • Ditz, using a clone of its mainline git repo just utterly fails for me. Google indicates the 1.9 releases of Ruby breaks it. Supposedly, there are git clones that fix it, but I'd really rather not mess with git.
  • Fossil has at least one relevant question here on SO: What do people think of the fossil DVCS? (it even has an answer from the author!). Much respect for D. Richard Hipp (author of SQLite and Fossil, as well other insanely cool things I can only use and read about on Wikipedia), but I'd like feedback from other mortals, as well.

Still not enough for me, though. There has to be at least a couple of people who've used either be or ditz for a non-trivial project-- at least, enough to be able to give an informed opinion.

I don't care about the technical side-- either the project documents it on its Web site, or I could just look at the source. What I'm looking for is real-world experience: What were the hurdles to its adoption? What is a particular project lacking? What would you add, that you really need, given maybe two years of paid time to work on it? Stuff like that.

share|improve this answer
Some may find my Bugs Everywhere GUI useful (nedprod.com/programs/Win32/BEurtle), though it's Windows only. This works around the lack of BE documentation problem :) –  Niall Douglas Jul 20 '12 at 14:18
add comment

Your Answer


