views:

337

answers:

5

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.

+1  A: 

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.

Neil Santos
+3  A: 

If you develop for Windows then Artifacts might work for you. It's a "bug-tracker in version control". Works with any version control. But its UI is tightly integrated with Visual Studio.

Fyodor Sheremetyev
Thanks for the reply. However, we're pretty much a *nix-only shop. The integration looks pretty slick, though. I'd definitely take a look at Artifacts, if/when the opportunity arises.
Neil Santos
+2  A: 

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.

Murph
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
The very real problem in this case is that I suspect that there aren't a lot of people with meaningful experience )-:
Murph
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
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
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
Chicken and egg problem - it has to be sufficiently reliable/useable for people to trust their work to it (though note that that last does not necessarily imply a particularly good user experience c.f. git...).
Murph
Hrm... I wouldn't mind a buggy bug tracker, as long as it's not *too* buggy and I could work on improving it a little bit. Although I can see how not a lot of people would see it the same way I do.
Neil Santos
Oh I think it can be buggy and useable (-: rather depends on the nature of the bugs - as long as they aren't the "eat all my work" variety you're going to be fine!
Murph
+1  A: 

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.

Neil Santos
Bugs Everywhere looks interesting! I may play with that with my personal stuff just because I can!
Murph
LOL; I'd say that's more than enough reason to try it out. :D
Neil Santos
+1  A: 

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.

Stephen