Marc Powell wrote: > On Jun 25, 2008, at 3:14 PM, Jay R. Ashworth wrote: > >>> Oh, I'm all for ticketing systems... as long as they aren't giving >> people the impression that work is likely to be done which will not in >> fact ever be done. Have you looked at The Original Bugzilla >> lately? ;-) > > Has anyone bothered to ask Ethan why he has chosen not to use the SF > bugtracker?
There are tons of reasons not to use the SF bugtracker (it sucks). I think I can answer why he's not using *any* bugtracker, drawing from memories of an email thread way way back when someone wanted a single bugtracker (and got quite vehemant about it towards the end). A bugtracker is a fire-and-forget kind of sink where users are supposed to be able to add bugs, feature-requests and patches. Since the options boil down to a) Random users have "add bug" access to the tracker. b) Someone manages the bugtracker. The problem with a) is that the data in the tracker quickly gets a very poor signal-to-noise ratio, where people post RTFM issues, minor annoyances and duplicate bug reports (these things happen because most people are lazy retards). The use of the tracker quickly deteriorates to the point where some people moan about there being issues in the tracker that are 2+ years old and nobody cares about them. The problem with b) is that it requires additional effort from the developer(s) (one extra place to check for bugs) and, if such a one is present, the tracker manager. Otherwise it's devs again. You'll still have to have the mailing list for pooling ideas and random chitchat, so everything that should have gone to the tracker has a chance of ending up on the mailing list instead, where someone has to move it to the tracker and then get to work on it. An extra step = bad. We're talking about people working pro bono here, so there's no way of forcing anyone to do anything, which means noone will do the boring parts, ie. copy-paste stuff from the mailing list to the tracker. As things stand today, Ethan is pretty much the only one fixing bugs and adding features to Nagios, so he can manage his own little todo list any old way he wants. I'm guessing he's not willing to change his workflow without some significant benefit for himself, such as a second developer, or a group of developers, asking for a tracker so they can coordinate their work. Personally, I wouldn't care very much for users wanting a bugtracker, because they wouldn't be the ones using it (except to report bugs, but on average people do that so poorly they might as well not bother). I *would* care if some proven developers stepped up and said "hey, we've got x active bugs and y feature-requests, but we have no idea of knowing who's doing what without constantly talking to each other. I've set up this tracker here and added all the current issues to it, and I'm gonna be using that, so check there if you want to know what you can leave for me". It's the difference between saving time and wasting it. > > p.s. IMHE, there are not a lot of bugs related to nagios-stable and > any real, verified bugs get fixed relatively quickly. Could be my rose- > colored glasses though. > It's not just your rose-colored glasses. Ethan's got a very good sense of priority and he's very keen on keeping a good track-record. Besides, if there are ever real show-stopper bugs in Nagios, I know that I would at least be instantly assigned full-time to fixing it, and I think many other companies have similar priorities if it ever gets close to affecting their customers. -- Andreas Ericsson [EMAIL PROTECTED] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Nagios-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
