From f26a597f8512b18c08b4ad2c09dcef82998a66ca Mon Sep 17 00:00:00 2001 From: "Jay S. Bryant" Date: Tue, 24 Oct 2017 11:22:37 -0500 Subject: [PATCH] [upstream] Add Stable Release info to Release Cycle Slides During the Boston Summit education session there were questions about stable branches during the 'Release Cycle' presentation. We decided it would be good to add slides for this to that presentation. This patch adds those slides. Also, it appears that the way that ReST is processed by the latest tooling is slightly different. If you don't have spaces before and after an indented section it doesn't indent the bullets. This patch fixes that for this set of slides as well. There was also some awkward wording that was caught in review. This fixes those issues as well. Change-Id: I9981f661f4a82b4b4c9a5591f88d5039a3671fc4 --- .../slides/howitsmade-release-cycle.rst | 73 +++++++++++++++++-- 1 file changed, 65 insertions(+), 8 deletions(-) diff --git a/doc/upstream-training/source/slides/howitsmade-release-cycle.rst b/doc/upstream-training/source/slides/howitsmade-release-cycle.rst index 4b454d74..4fd069a6 100644 --- a/doc/upstream-training/source/slides/howitsmade-release-cycle.rst +++ b/doc/upstream-training/source/slides/howitsmade-release-cycle.rst @@ -31,15 +31,20 @@ What makes a release milestones as that is what most students will work with. The other types should be described. - Common cycle with intermediary release: + - Used for components needing more frequent releases. e.g. Oslo Libraries - Intermediary releases can also be used to time releases near the - beginning and end of the release cycle. Horizon plug-ins do this. + beginning and end of the release cycle. Horizon plug-ins do this. + - Trailing the common cycle: + - Projects dependent upon the output of a release, like packaging or - deploying OpenStack follow this model; e.g. Fuel and Kolla + deploying OpenStack follow this model; e.g. Fuel and Kolla + - Independent release model: - - These projects may hold tools used for OpenStack part aren't part of a - production release. + + - These projects may hold tools used for OpenStack but are not part of a + production release. Exercise ======== @@ -172,15 +177,22 @@ Exercise .. note:: - Spec freeze + - Point at which specs must be proposed and reviewed for the release. + - Feature freeze + - Code for new features is no longer accepted. + - String freeze + - Externally visible strings can no longer be changed. Helps translation - activities complete on time. + activities complete on time. + - Requirements freeze - - No longer change requirements to allow downstream packagers time to - pull-in and build dependencies. + + - Requirements cannot be changed to allow downstream packagers time to + pull-in and build dependencies. Release Candidates ================== @@ -200,9 +212,11 @@ Release Candidates .. note:: - Code change during the RC phase is a balancing act + - Need to balance integrating fixes and code churn - Critical fixes have the highest priority while more minor bug fixes may - be safer to hold for the subsequent release. + be safer to hold for the subsequent release. + - Who is able to approve patches during the RC phase is limited. Release candidate process @@ -214,6 +228,7 @@ Release candidate process - Used as-is as the final release - Additional Release Candidates created for critical bugs found during RC testing + - (RC2, RC3, ...) with bugs targeted to it - Repeated as many times as necessary @@ -229,4 +244,46 @@ Exercise - Find the release day for the current release - Find where the currently released code is posted +Stable Branch +============= +- Name for a cycle that has been released +- Projects that follow some form of the 'Common' release + cycle have branches like 'stable/' in their repo +- Support phases + ++------------+-----------------------------+---------------------------------+ +| Phase | Time Frame | Changes Supported | ++============+=============================+=================================+ +| I | First 6 months | All appropriate bug fixes | ++------------+-----------------------------+---------------------------------+ +| II | 6 - 12 months after release | Only critical or security fixes | ++------------+-----------------------------+---------------------------------+ +| III | More than 12 months | Only security fixes accepted | ++------------+-----------------------------+---------------------------------+ + + +Proposing fixes to Stable Branches +================================== +- Fixes to stable must first merge to master and all intermediate branches +- Appropriate backports + + - Low regression risk in stable branch + - Fixes a user visible problem + - Backport is self contained + +- Inappropriate backports + + - Backports of new functionality + - Changes to external HTTP APIs + - Notification, DB Schema or incompatible config file changes + +Stable Branch Reviews +===================== + +- Stable maintenance teams + + - Each project has a subset of cores able to merge stable branch changes + +- Ensure that the stable branch policies are enforced +- Ensure that backports are associated with the patch submitted to master