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 <
[EMAIL PROTECTED]> 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* < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> 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
> >
> >
> >
> >
>
>
