[Starlingx-discuss] DRAFT release policy

[Jones, Bruce E]

We've been working on a draft release policy in the Release team.  Please review and share your comments, feedback or suggestions in the etherpad or on this thread.

The draft is located at https://etherpad.openstack.org/p/stx-release-policy-draft

The current text is below.

      Brucej


Release Policy
===========

The StarlingX project determines release schedules based on when the release content is ready to be released.  We should explicitly move away from the idea of time based releases.  We should continue our current twice per year release cycle
*         We should consider changing our release naming convention to something that doesn't include dates.

The Release team, together with the Test team TLs/PLs, shall make a recommendation to the community and TSC that a release is ready to go.  Upon TSC approval, the release branches are tagged and the release documented.

That recommendation should be based on:
1.        Whether or not all anchor features in the release are complete, as per the input of the team(s) implementing the features and the results of Test team testing of the features
?  Assumption: The TSC will create a list of approved features during the release planning process, and that some (or all) of these features will be identified by the TSC as "release gating" or "anchor" features that would block a release if not complete.
?  Assumption: We are planning our releases at the PTG meetings every 6 months.
2.        The results of formal Testing performed by the Test team, measured by the percentage of planned tests attempted and the test pass rate
?  Proposal: 100% test cases attemped and 95% test cases passing in all configurations
3.        The severity and number of bugs open against the release
?  Proposal: No open Critical or High severity bugs against the release candidate.  Or maybe 1-3 Highs if we have a clear resolution plan (and a plan to release a patch against the release?)
?  See Bug Severity definitions below.

We should discuss the option of doing a mid-cycle "bug fix" release against the latest release - allowing key defects to get fixed more rapidly.  In such a case, the release team would make a recommendation to the TSC to approve the release plan and content.  If approved by the TSC, the fixes shall be cherry-picked or merged into the release branch and a new build tested (and managed as per this policy).

Bug Severity
==========

Critical: The software does not operate as intended (e.g. the software fails to install,  does not run, crashes, etc...).  Or the issue is a Securty/CVE issue with a rating of Critical or High.  In Launchpad this is "Fix as soon as possible"

High: An important feature of the software does not operate as intended (e.g. live migration, fault reporting, etc...).  Or the issue is a Security/CVE issue with a rating of Medium or lower.  In Launchpad this is "Fix soon".

Medium: A minor feature of the software does not operate as intended or there is an intermitant failure.  In Launchpad this is "Fix when convienent or schedule to fix later".

Low: A bug that does not impact normal operation of the software.  In Launchpad this is "Fix when convienent".


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20190328/69d957b2/attachment-0001.html>