Rick Hillegas wrote:
Thanks, Kathy. I think I'm getting the message that the following would
be an acceptable and more traditional schedule:
August 10 : Last feature work commits
August 11 : First release candidate generated
August 24 : Second release candidate generated
September 7: Third and hopefully last release candidate generated
September 15: Targetted end of voting on release candidates
Is this a realistic schedule or is it still too aggressive?
Thanks,
-Rick
What kind of changes are you going to include in each of the
release candidates (ie. all checkins to the branch, or some subset
of those changes -- I think in the past andrew has used either)?
The above seems reasonable assuming that
the only changes are bug fixes addressing regressions shown
up by testing. I assume it is reasonable to accept all additional
tests during the release testing period.
I believe some of the features were already originally planning on
an august 15 or later date, and have adjusted to an august 10 date.
Some definitely won't make it with an earlier code freeze.
What is the assumption about bug fixing of outstanding bugs
known before august 10th? Maybe there is a published list of
bugs that need to be fixed for a successful release?
