Bryce McKinlay wrote:
Mark,
Could we get an exemption from the freeze rules for low-risk, runtime
only libgcj fixes as determined by the libgcj maintainers?
I don't think we want to do that.
First, we're close to a release. We've been waiting on one fix since
Friday, and Jeff Law has promised to fix it today.
Second, the whole point of freezes is to ensure stability. We're going
to RC3 on this release because we've found bad problems in RC1 and RC2.
If a change were to be checked in, for whatever reason, happens to
break something, then we need an RC4, and everybody loses.
Alternatively, could we rethink our release policy to ensure that the
duration of freezes is minimized in the future? I do think that a hard
freeze in the days leading up to a release is useful and important, but
keeping it in place for weeks just because a couple of bugs remain
unfixed doesn't seem helpful.
Obviously, I'd like to have a shorter freeze period. This is the
longest pre-release freeze I can remember since I've been running
releases. That reflects the fact that a lot of critical problems were
uncovered in 4.0.0, including some during the 4.0.1 release process.
The way to get a shorter freeze period is to have fewer bugs and to fix
them more quickly. I think that this release is somewhat exceptional in
that after we released 4.0.0, a lot of people started using a lot of new
technology, and, unsurprisingly, there are more bugs in 4.0.0 than in
the average release.
Please hang in there.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
