V3: SPARC bug and tree freeze

[Robert Dewar]

<<glibc is too big to use as a check-in criteria.  However, it should be
part of the release testing process, and nightly jobs to test
substantial programs (like glibc) are a Good Thing.
>>

Is that really true with modern fast computers. In the GNAT world, the
checkin criterion for even the tiniest "can't-possibly-affect-anything"
modification is to run the entire internal regression suite (about 7000
test cases, about 7 million lines of code). The way we do it is with
a robot that accepts the patch as a message and runs the suite 
automatically. It takes a few hours of running time on a fast machine.
Certainly testing glibc sounds like something that could be done quite
quickly.