Call for volunteers

Mike Stump mrs@wrs.com
Thu Jun 3 15:15:00 GMT 1999


> To: egcs@egcs.cygnus.com
> From: mark@codesourcery.com
> Date: Sun, 23 May 1999 21:54:07 -0700

> I, too, have a folder full of bug reports from egcs-bugs.  I go
> through it every now and then as well, often duplicating work that
> others have done in verifying the state of bugs, because it's too hard
> for me to track the reports Jeff, Martin, et. al. post.

> If someone with experience using GNATS, or an equivalent, would be
> willing to set up a bug-tracking system for EGCS, I think that would
> be most noble.

I did this for years...  Haven't in a while.  What I found was, it was
easiest for me to run the mailing list into elm, do incs every now and
then into a flat file database of emails (one file per email), and
then expose those via ftp or the web (see
ftp://ftp.cygnus.com/pub/g++/g++-bugs/ for the last state of it).  The
I would remove things that were fixed, and invite others to update and
respond to stuff.  As they did this, I would ask them to send up
updates to the database, as remove '<message-id>', or refile
'<message-id>' category, and then I `ran' the updates and repushed the
database.  (it was outside the firewall in later years) These commands
mapped well into preexisting elm commands, so that I didn't actually
have to write anysoftware, and it featured good reliability.

This method worked well for me.  Low overhead, retained high
compatibility with email and so on.

If the web interface was extended to allow a mark as fixed bit, and
allow certain people to mark bug reports as fixed, then... this could
be another way (a better way) to do it.

My feeling was that PRMS (GNATS) was too big and hairy to use at the
time.

Anyway, I found it useful for g++, and by having a directory full of
categorized bug reports allowed me to have visibility into what needed
fixing the most, what worked well, and where to spend time on fixing
things.  When one works in a category, like say EH, one could go to
the eh folder and read and have a nice overview of the problem area to
work on.

Also, this allows one to never drop a bug report, and to eventually
fix them all...  :-)  I loved emailing people three or four years after
the bug was reoprted, telling them that the bug was fixed.

A good approach would be to work with all the free software people and
all the open source people and standardize on a system together that
works well for everyone...  and then use it instead of an ad hoc
approach.

Anyway, it can be done, has been done, and my experience is that it
doesn't take too much effort and work.

I can say more, if you want, just ask.


More information about the Gcc mailing list