Hi Mike,
Some responses follow. Regards-Rick
Mike Matrigali wrote:
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 was hoping that only bug fixes would go into the branch and that each
release candidate would just roll up those bug fixes. The release
candidates would be snapshots of the branch at the time the candidates
are cut. I hope this is reasonable.
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?
I need to start compiling this list. Fortunately, Kathey is already
forging ahead, raising the priority of suspect bugs. I have been putting
off this task until we reach consensus about the date for branching.
