db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@sun.com>
Subject Re: Planning the 10.2 release
Date Tue, 14 Feb 2006 17:13:21 GMT
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