Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <466069ED.3040109@apache.org>
Date: Fri, 01 Jun 2007 11:48:13 -0700
From: Doug Cutting <cutting@apache.org>
User-Agent: Thunderbird 1.5.0.10 (X11/20070403)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: Lucene 2.2 soon?
References: <466049C6.8080205@gmail.com>
 <932AB051-85D0-4EFA-A56D-DBD80BC1C75B@apache.org>
In-Reply-To: <932AB051-85D0-4EFA-A56D-DBD80BC1C75B@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org