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 Tue, 14 Feb 2006 04:52:04 GMT
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> 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