[Starlingx-discuss] DRAFT release policy

[Seiler, Glenn]

Bruce, Release team;
Thank you for putting this in writing.
I have to admit I find the basic strategy statements confusing:


1-     We need to move away from time-based releases

2-     We need to do twice a year releases.  This stmt, by definition, implies a time-gated release. Maybe it isn't a specific date, but it is still time-gated.

As a nascent project, I think we need to show gradual and consistent progress.
I did listen to much of the release team meeting today, and realize the trade-offs between big-rocks and timing are very difficult.

Given the difficult choice of functionality versus timing, I personally think we need to show progress in getting to Stein and a container based distribution as major milestones in 1H and perhaps defer the Distributed Cloud capability to a 2H release.

I don't see anything intrinsically wrong with moving a specific date out; it happens all the time. But I also think a release should have some gate; i.e. we don't move out of 1H. And if some functionality isn't ready, then we move the functionality to another release in 2H.

Anyway, that would be my vote, if I have one.

From: Jones, Bruce E [mailto:bruce.e.jones at intel.com]
Sent: Thursday, March 28, 2019 12:49 PM
To: starlingx-discuss
Subject: [Starlingx-discuss] DRAFT release policy

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/219689ed/attachment.html>