Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44A1B5F7.5070100@sbcglobal.net>
Date: Tue, 27 Jun 2006 15:49:27 -0700
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Proposal for 10.2 release schedule
References: <449AEAA7.8030109@sun.com> <44A185B9.8000401@gmail.com>
 <44A18A55.1000702@sun.com> <44A19085.3020604@mtrad.com>
 <44A1965F.5060506@sun.com>
In-Reply-To: <44A1965F.5060506@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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?