db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajesh Kartha <karth...@gmail.com>
Subject Re: Planning the 10.2 release
Date Wed, 15 Feb 2006 06:22:36 GMT
Yes. The first round of testing should  begin when all the features and
proposed bug fixes (for currently open ones) are reviewed, committed and
available in the code.

> Once the final patches are committed (end of April?), we cut a  release
>     branch. Feature work for 10.3 resumes in the trunk.

So based on your suggested schedule the first round of testing can be
expected to begin around end of April.

Also I think,  creating the release branch should atleast wait till the
first round of testing is complete and bugs found then are resolved. We can
minimize the porting of fixes to trunk that way.

Regards,
Rajesh

On 2/14/06, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
>
> Hi Rajesh,
>
> Thanks for this advice. Does your first round of testing correspond with
> what I'm calling the trashathon (beating up the code immediately after
> the last feature commits and we cut a release branch)?
>
> Regards,
> -Rick
>
> Rajesh Kartha wrote:
>
> > Hi Rick,
> > > At that point interested members of the community can beat up the
> > software in the release branch, looking for bugs.
> >
> > Maybe you have already thought about this, but I think it will be
> > useful to have two testing cycles.
> >
> > The release plan could accomodate something like the following:
> > ...
> >  a) Release candidate -1 (initial jars) for the community to do testing
> >  b) Testing for 2 or 3 weeks
> >  c) Resolve/Fix the bugs found in (b)
> >  d) Release candidate - 2 (potential to be the final release)
> >  e) Testing for  2 weeks or less (depending on the amount of fixes
> > made in (c), will allow testing of those fixes too)
> > ...
> >
> >
> > Regards,
> > Rajesh
> >
> >
> >
> > On 2/13/06, *Rick Hillegas* < Richard.Hillegas@sun.com
> > <mailto:Richard.Hillegas@sun.com>> wrote:
> >
> >     Hi Kathey,
> >
> >     I'm imagining the following chronology:
> >
> >     o April 7 - The last feature-laden patches post to JIRA.
> >
> >     o The community spends a couple weeks vetting those final patches.
> >
> >     o Once the final patches are committed (end of April?), we cut a
> >     release
> >     branch. Feature work for 10.3 resumes in the trunk.
> >
> >     o At that point interested members of the community can beat up the
> >     software in the release branch, looking for bugs.
> >
> >     o This goes on for another couple weeks. During this period, bug
> >     fixes
> >     are committed against the release branch and ported to the
> >     mainline trunk.
> >
> >     o Sometime (mid-May?) we declare victory on the release branch. We
> >     throttle changes to it.
> >
> >     o We spend another couple weeks generating and vetting release
> >     candidates.
> >
> >     o Sometime (early June?) we publish the production-quality 10.2
> >     release.
> >
> >     I would define the top two bug priorities as:
> >
> >     Blocker = Intolerable defects which prevent us from publishing a
> >     release. For instance: data corruptions, new problems which have no
> >     workarounds, reintroduced customer-reported bugs which were fixed in
> >     previous releases.
> >     Critical = Serious bugs we intend to fix for 10.2. These include
> wrong
> >     query results and significant, old, unfixed bugs inherited from
> >     previous
> >     releases.
> >
> >     I would like to aim for fixing all Critical bugs. What are your
> >     thoughts?
> >
> >     Regards,
> >     -Rick
> >
> >
> >
> >
> >     Kathey Marsden wrote:
> >
> >     >Rick Hillegas wrote:
> >     >
> >     >
> >     >
> >     >>Would the community support an April 7 code-freeze date? If so,
> >     could
> >     >>you help me by letting me know what you want to submit for this
> >     >>release by that date?
> >     >>
> >     >>
> >     >>
> >     >Is April 7  feature freeze or should all bugs be fixed by that
> >     date? Do
> >     >you have thoughts for what our exit criteria should be for 10.2
> >     in terms
> >     >of quality  and how we should identify  what bugs need to be
> >     addressed?
> >     >I tend to think anything Blocker or Critical should be addressed
> >     before
> >     >releasing 10.2 .  Next would be to define what goes into those
> >     categories.
> >     >
> >     >Kathey
> >     >
> >     >
> >     >
> >     >
> >
> >
>
>

Mime
View raw message