I can appreciate where if I had more time to devote to the project, I would try reproducing all the bugs in the list of bug reports.  Unfortunately my time is limited and I can't do that.  I'm trying to focus on the efforts that give the highest payoff.

        The "freeglut" library has changed significantly in the past year, and many of the bugs probably fall into one of three categories:

                - It got fixed already and we didn't note it in the bug tracker
                - The user found a way around the problem (or fixed a compatibility issue in the application program) and nobody else has tripped over the bug

                - The user has gone away and nobody else has tripped over the bug.

If a bug is still causing trouble, then I would like to focus on it.  If it isn't, for whatever reason, then I would give it a lower priority.

John F. Fay
-----Original Message-----
From: [] On Behalf Of Richard Rauch

Sent: Thursday, April 28, 2005 3:19 PM
Subject: Re: [Freeglut-developer] Old Bug Reports

On Thu, Apr 28, 2005 at 01:58:03PM -0500, Fay John F Contr AAC/WMG wrote:
> Gentlemen,
>       As you have (I am sure) seen, I have been going over the bug reports
> and will be going over the Requests For Extension list shortly.  Some of the
> bug reports are two years old!
>       I propose to declare all the bug reports from before last January 1
> to be "Out Of Date" and invite the original submitters to re-submit them.
> There are two things at work here:

Speaking here merely as a general commentator:

As a rule, I think that a bug report should be considered valid
until there is reason to believe that it is fixed.  The mere fact
that it is old doesn't mean that it is fixed.  The database is your
record of things that have been KNOWN to be problems in the past,
and for which no one has ever explicitly implemented a fix.

>       - Patches are against old code and I am having trouble implementing
> them.

Patches != bugs.

If the patch no longer applies, I would add a note to the bug report "This
patch no longer applies cleanly."  That doesn't mean that the bug has been

>       - Now that I have CVS access I can do something about them.

Those that you can reproduce and fix, should be fixed.

Those that you think you should be able to reproduce but can't are
possibly fixed; move those to feedback for a while.  Close if there
is no further activity (give a month or so in feedback since
freeglut has been very lax about acting on the bugs database).

Those that appear to be highly sensitive to the user's circumstances
(so you're not sure if you could reproduce them) should probably be
less agressively handled.

If you aren't sure about the status of a bug report, leaving it "open"
will make it easier for other people to find and add additional
information.  Closing it will tend to result in duplicate reports
(possibly with different information) being opened, if the problem
still exists.

Just my opinion, having used bug report databases like this (including
SourceForge's system in particular) from both sides.

  "I probably don't know what I'm talking about."