Distributed bug tracker to go with DVC

Question

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.

Answer 1

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.

Answer 2

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

• Bazaar-NG as the VCS
• Bugs Everywhere as the bug tracker
• Zim as wiki

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.

Answer 3

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.

Answer 4

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.