Re: Beyond GCC 3.0: Summing Up

[Chris and Ann Reedy <c-areedy at erols dot com>]

As a lurker on this list, one thing that has become clear from this
discussion is that GNATS is a problem that needs to be addressed as part
of this new process.

For example, from Alexandre Oliva:

> Me too.  I think it might be reasonable to have Gnats PRs in some new
> category containing patches that may have to be reverted for some
> target to bootstrap, or something.  This would have the benefit of
> giving people who don't look up the Gnats database an extra push to
> attempt to fix the bug, while still giving them the option of finding
> the patch quite easily and reverting it in their own tree, so that
> they can trade the breakage exposed by the patch for the breakage
> fixed by the patch.

and from Robert Dewar:

> One thing we have done in GNAT sometimes is to put a fix that breaks things
> under a debugging switch, so that it can easily be turned on by whoever
> works on understanding and fixing the breaks.

One suggested enhancement: have GNATS track bug dependencies. That way
you could attach a patch to a bug and note that as dependent on another
one that is yet to be fixed.

Another enhancement, you will need tracking of bugs by versions of the
compiler (the version that will contain the fix). This is already a
problem today. It will be a major problem when trying to implement an
aggressive release schedule like the one being proposed.

Finally, I don't know whether this is politically incorrect (give that
this is GNU and not some other open source organization), but have you
considered moving from GNATS to BugZilla. BugZilla has these
enhancements and some more. It would give you the capablities you need
without the development work to improve the bug tracking system.