Brian A. Seklecki wrote: > >> 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 > > Right -- you close those tickets as "wont fix" or "not a bug". Just > don't do it for real bugs -- like the PHP people do. >
That costs manhours though, so the tracker would need a moderator of sorts. >> 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 > > Assign a steward. Generate weekly reports. I'll be the whipping boy > for the first 6-9 months. > Excellent. One problem solved then ;-) > >> a second developer, or a group of developers, asking for a tracker >> so they can coordinate their work. > > That's an overall project organization issue that is beyond my mandate > to comment on. If more developers are needed, a call for developers > should me made publicly. > > I can tell you that a PR system will certainly appeal to potential > developers. It adds structure and credibility .. "panache" :) > >> 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). > > Wow. Well. Its a bit different in a small business. I call them > customers. But I generally agree with your assessment. I'm what > Barrack calls "A bitter Pennsylvanian" > :D >> 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. > > Right. I agree. > > So we might as well give it a shot? Set it up for 6-8 months, evaluate > the progress and based the impact and results of releases during that > period. > There's still the issue of getting Ethan on board though. > As a trial run, for initial population, your best resources would be the > Ports/Package maintainers at the various projects (*BSD, Debian, Gentoo, > Fedora, OpenSolaris, Fink, etc.). Have them feed any outstanding > patches back upstream. I think that you'll find that group be > disciplined in the practice of using a PR/ITS properly to their > advantage. > Definitely. That'd be a good starting place. -- 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
