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 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.
There's no "code freeze" per se on ASF projects. The release manager decides what changes should make it into a release. Good info for the httpd project gets referenced by many: http://httpd.apache.org/dev/release.html > Let's repeat that: an impending release can not affect development of the > project. It is the RM's responsibility to identify what changes should make > it into the release. The RM may have an intermediate tag, so the RM can merge > in or reject changes as they are committed to the repository's HEAD. > > Committers may voluntarily refrain from committing patches if they wish to > ease the burden on the RM, but they are under no obligation to do so. This is > one reason why we recommend that the RMs have plenty of time on their hands - > they may have to deal with a rapidly changing target. It's not an easy job. I just get a little worried when I hear the words "code freeze". I think a better phrase would be "target date". After that date developers can continue developing and it's up to the release manager to include that work (or not). -jean
