Re: GCC 3.0 Release Criteria

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <20000501122203U.mitchell@codesourcery.com> you write:

>  - A risk that fixing a bug on X will introduce bugs on another
>    platform.  Many fixes will require retesting all the other
>    platforms.  Some fixes may be confined to target-specific files;
>    others may require changes to machine-independent code.

Let me sum that up from my side.

This means that, if I find a show-stopper bug in OpenBSD-gcc 3.0, I
dutifully report it, you will be able to just forge on and say 
`oh, to hell with it, it's not a widely used platform anyway. We can
always fix it in two years time.'

... so that we end up stuck with 2.95.
... so that we risk falling behind in terms of computer tools.
... which may incite people to switch to linux.
... which will render linux even more dominant on the Unix market that
it already is.

Please, give me a break.

I don't specifically want `1st teer status', but I do want some reassurance
at this point, that we are not considered `second rate' for the gcc 3.0
release.

I'm not a good gcc developper, I am not proficient, but I've done my best
to play ball in the past, feeding changes back, avoiding diverging from
the main stream, and even trying contributing to the few parts I understand.
I also argued quite a few hours with other members of the project, and got
most of the heat you never saw when we switched to gcc 2.95, and got a few
minor `problems' that didn't exist in 2.8.1 (like the increased compiler
time, or the new compiler errors).

As I said, we (the OpenBSD project) would like some reassurance.