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
