Women in Technology

Article:		Bug Trackers: Do They Really All Suck?
Subject:		3rd party bug tracking systems do all suck.
Date:		2005-12-12 09:38:35
From:		jeremiah.jahn
We orginally tried to use bugzilla for our bugtracking software. This lasted about 4 hours. We now have one employee who's main function is to handle our bug tracking software (and company web site), but mostly the bug tracking software. We are still lacking any integration with CVS, other than having the programmers be religious about their versioning. Over the past two years, we have taken the ideas of bugzilla and added, workflow, patching and posting of updates, relase management, crm functionality, test management, and voting to the system. What was once based on bugzilla, has become the hub of our entire organization. We handle about 40 different projects, and a few hundred different clients through this system. Recently it even got connected to our fax server. Bugzilla couldn't even come close to handeling our needs. We find that our system is the best example of feature creep we have to deal with. I think that bugzilla [bg], could be a lot better than it is, but having looked at the code behind it, it is an unmaintainable mess. Changes can be made, but no one wants to do them. Yet, every one and their brother seems to use it, and deal with its limitations. I guess my point here, is that the OS world needs better BT software, and the only way to get it is to write it in house to meet your organization's needs. Or someone needs to take BZ and rewrite the damn thing, and make it into a plugable framework for extension. Sorry for the rather rambaling train of thought.

Showing messages 1 through 1 of 1.

• 3rd party bug tracking systems do all suck.
  2005-12-28 12:21:49  ttriche [View]
  
  
  It sounds like you have written better commit hooks (test-on-commit) and better user interfacing (crm, voting, release management) to Bugzilla, taking it to where Trac, FogBugz, etc. are and perhaps beyond.
  
  Have you looked at the other packages out there, and at Subversion? You might be pleasantly surprised to discover that many others have shared your pain and attempted (as you observed) that Bugzilla's complexity made it difficult to maintain without starting from scratch.
  
  Sometimes you have to expect to throw away the prototype :-). Oh, wait, ALL THE TIME you have to expect that (cf. Fred Brooks).
  
  Take a look at the Trac project sometime, it would benefit from your critical eye and your experience. I came from Mantis and promptly began hacking on my Trac installation (right into the core mod_python handler -- I admit it, I like to fix things NOW).
  
  Ideas like AJAX integration (below) and better SVN/DB integration (above, though Trac already is tightly integrated with SVN) are more easily implemented in a decoupled framework. The critical difference I see between Bugzilla and Trac et al. is the decoupling of the latter, more modern systems. Having proper templating (although I find ClearSilver somewhat annoying, it's not hard to eg. add prototype.js to the headers, or use AJFORMS for form processing) is a huge plus.
  
  Consider whether Subversion's changeset-centric versioning model might benefit your organization. It should not be overly difficult to migrate your existing hooks to SVN's hook system (almost trivial in fact), and the Perforce-like changeset notion makes groups of errors easier to track down (per-changeset). "Gee, this started happening around 11/19/05... what changed that day? And who submitted it? (narrows down time window)" ... "Oh for fuck's sake, THAT broke the config?!?"
  
  Anyways. Bugzilla has too much baggage. It was the prototype. I submit to you, that the current generation has built upon its strengths and tried to address its weaknesses, and those who are just starting a project yet want a good OS solution, should consider Trac. You might want to give it a look too, if only to see whether there are any ideas they added that work for your organization's Bugzilla creation.