> > There are tons of reasons not to use the SF bugtracker (it sucks). I
Of course. Need get one of the big shops to volunteer some hardware and facilities to host a real one. Maybe the IBM/HP/Cisco guys can ante up and make a donation? We'll (Collaborative Fusion, Inc.) host it if need be. Its a minor logistical problem. > 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. > 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. > 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 Just like every other project, if people _really_ want a bug fixed, they will take the time to submit the PR with all of the details. You get out what you put in. > 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 Safe to postulate. > 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" > 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. 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. ~BAS ------------------------------------------------------------------------- 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
