diff --git a/doc/upstream-training/source/slides/howitsmade-release-cycle.rst b/doc/upstream-training/source/slides/howitsmade-release-cycle.rst index 7d8d00af..23cea282 100644 --- a/doc/upstream-training/source/slides/howitsmade-release-cycle.rst +++ b/doc/upstream-training/source/slides/howitsmade-release-cycle.rst @@ -9,7 +9,7 @@ OpenStack Release Cycle What makes a release ==================== -- A way to coordinate the development of multiple projects +- Coordinated development of multiple projects - Release process is managed by the Release Management team - Release models @@ -18,32 +18,47 @@ What makes a release - Trailing the common cycle - Independent release model +- A given project cannot follow more than one model + .. note:: - Release management description: http://docs.openstack.org/project-team-guide/release-management.html - The training concentrates on the common cycle with the development - milestones as that is what most students will face with. The other types - should be described with examples. + 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. + - 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 + - Independent release model: + - These projects may hold tools used for OpenStack part aren't part of a + production release. Exercise ======== - Look up the release schedule for the current and past two OpenStack release cycles -- Identify common characteristics of these cycles +- Identify common characteristics of these cycles and discuss them with + your group - Milestones - Deadlines - etc. - Describe a release cycle based on the information you found +- Determine how many OpenStack releases are officially supported + by the community Common cycle with development milestones ======================================== -- A coordinated way for projects to periodically create their deliverables - including testing and documentation +- Project teams create their deliverables, including testing and + documentation, on a coordinated schedule - Every cycle includes - Planning and design activities @@ -62,10 +77,14 @@ Planning - Design - Design activity is a continuous effort - Planning for a release cycle starts at the end of the previous cycle -- It depends on each project how to organize the work at each cycle + + - Face to face planning discussions happen at the Project Teams Gathering + (PTG) which is coordinated with the start of a development new cycle + +- Each project team sets priorities/dates for the release - Spec/blueprint freeze - - Prioritizing items + - Prioritization of items (e.g. testing, documentation, etc.) - Generic intention behind planning @@ -75,13 +94,23 @@ Planning - Design Planning - Discuss ================== -- Prepare your idea for the public +- Prepare your idea for proposal to the community. + + - Discuss with your project team + + - PTG is a good time to propose and discuss features/fixes - - Discuss with your peers - Work on feedback and comments - Capture your idea in a spec/blueprint +.. note:: + + - Whether a change requires just a blueprint or spec and blueprint + depends on the complexity of the change. + - Start with a blueprint and look to the project team's core members + for guidance on whether a spec is needed. + Planning - Target ================= @@ -96,12 +125,14 @@ Planning - Target - Feature proposal freeze - The deadline for proposing new ideas for a release cycle - - The exact date depends on the projects + - The exact date is determined by each project team Exercise ======== - Find feature proposal deadlines in the current release schedule +- Compare the deadlines between two different project teams and discuss the + differences with your group Implementation ============== @@ -110,6 +141,7 @@ Implementation - Push code to Gerrit for review - Upload your code as early as possible in the release cycle + - Code can be uploaded before a blueprint/spec is accepted - Deadlines for the code to get merged @@ -124,20 +156,26 @@ Implementation - Milestone - Milestones are tagged in the repository using b1, b2 and b3 - Overall feature freeze is the third milestone -Implementation - Freezes -======================== +Exercise +======== -- Freeze dates depend on the type of activity -- Feature freeze +- In addition to milestones, there are freeze dates for different activities + in the release - - Code for new features will not be accepted - - Bug fixing activities are still ongoing - - More focus on testing + - Work with your group to find and discuss the different freeze activities -- String freeze +.. note:: - - All externally visible strings must be frozen - - This helps the I18n and Documentation projects + - 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. + - Requirements freeze + - No longer change requirements to allow downstream packagers time to + pull-in and build dependencies. Release Candidates ================== @@ -149,33 +187,41 @@ Release Candidates - Test the code and file bugs - Prioritize bugs / bug triage - - Get critical and high priority bugs fixed on the first place + - Get critical and high priority bugs fixed first - Fix as many bugs as possible - Finalize documentation -Release candidate 1 -=================== +.. note:: -- Cut when all the release-critical bugs are fixed + - 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. + - Who is able to approve patches during the RC phase is limited. + +Release candidate process +========================= + +- Release Candidate 1 (RC1) is cut when all the release-critical bugs are fixed - stable/release branch - master branch is open for development - Used as-is as the final release - -Other release candidates -======================== - -- Regressions and integration issues - - - New release-critical bugs - -- (RC2, RC3, ...), with bugs targeted to it - - - Merged in the master branch first and then cherry-picked to stable +- Additional Release Candidates created for critical bugs found during + RC testing + - (RC2, RC3, ...) with bugs targeted to it - Repeated as many times as necessary Release day =========== -- Last published release candidate +- Last published release candidate from all Project Teams - Published collectively as the OpenStack release + +Exercise +======== + +- Find the release day for the current release +- Find where the currently released code is posted + +