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
>
>
>
>
