[Fwd: Bug Reporting / Issue Tracking System ?]

Brian A. Seklecki lavalamp at spiritual-machines.org
Sun Jun 29 00:31:05 CEST 2008


> 
> 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
Nagios-users at lists.sourceforge.net
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





More information about the Users mailing list