Test suite regressions

Mon Mar 19 16:03:00 GMT 2001

On 19 Mar 2001, Tom Tromey wrote:
> I think we should adopt a rule whereby we don't check in any change
> that causes a test suite regression.

That'll clearly improve stability, except for the patches that break other
targets.
> At the very least this is what we should do on the gcc3 branch.

What do you think about just delaying commits to the branch, maybe by a
day or so? That would give at least some opportunity for feedback.
FWIW I've been regularly building the 3.0 branch w/ java and submitting to
gcc-testresults so there is at least some data. I could do the same on
the mainline if it were worthwhile.
> I'm guessing that Mark won't hold up
> the gcc3 release just because Java is broken. This means we must be
> careful to ensure it is working at all times.

Of course no release is imminent, but that will change (hopefully) soon.
Suppose you pick a date and call for a freeze. If there is any volunteer
time available, post the important bugs and divide them. Sort of what GCC
is doing as a whole.
These are just ideas off the top of my head. There has been no talk about
release methodology on this list that I can recall. Does anyone think a
little planning would be helpful? Any other suggestions?
I have my own incentive to see a useable and stable 3.0 release, a
little time to spend, and lots spare of machine cycles... how can we put
these to good use?
BTW projects.html is getting a little out of date.
Jeff