Grant Ingersoll wrote:
What say people about my suggestion of implementing a "code freeze" for 1-2 weeks prior to a release
The process we're using on Hadoop is to have a feature freeze at a specified date. Trunk is branched at that point. Only blocker issues are permitted to be applied to the branch. We then generally apply patches for blockers first to trunk and then merge them to the branch from trunk. Then, once there are no blockers, we can build a candidate release to vote on. Note that new features can be added to trunk, but they'll not be merged to the branch, so trunk development need not stall. We use Jira's "Fix Version" to determine whether a patch is intended for the branch or only for trunk.
I note that http://wiki.apache.org/jakarta-lucene/ReleaseTodo doesn't yet incorporate voting. In the past, we've not always voted on release artifacts, but that's Apache policy. A release should not be made unless its binary file has at least 3 +1 votes from PMC members. I recently added this to Hadoop's wiki (http://wiki.apache.org/lucene-hadoop/HowToRelease).
wherein we work on documentation and cleaning up JIRA? Perhaps we _strive_ to have every committer (and others are welcome) to try to javadoc a set of files or to clean up some spot on the wiki or the main site? Not saying this should be a show stopper, but it would really benefit all of us, I would think. Is this too much of a burden? Anyone have other ideas that can help shore up our docs? In theory, better docs lead to fewer questions which leads to more time to work on new features!
Probably, in addition to blockers, documentation patches should be permitted after the feature freeze. And taking some time out to examine the documentation is certainly a good idea.
Doug --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
