Re: Test suite regressions

[Jeff Sturm <jsturm at one-point dot com>]

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