openstack/training-guides
Code Issues Proposed changes

[upstream] Update release-cycle slides

Browse Source 
This patch pushes up changes to the howitsmade-release-cycle.rst
slides.  The goal of the patch is clean-up wording on a number of
slides, tie in the idea of the Project Teams Gathering and add
more exercises to get the class looking up the information on their
own.  Also good opportunities for the class to talk in their groups.

I have also improved notes on a number of slides to provide more
guidance to the presenter and consolidated some of the wordier slides.

Change-Id: I7632c2e855844e6d8aa0b7c75734c6be3f5ae9e1
This commit is contained in:
Jay S. Bryant 2017-04-17 11:39:26 -05:00
parent 925fef8e06
commit f9bce56013
1 changed files with 83 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

120
doc/upstream-training/source/slides/howitsmade-release-cycle.rst
View File

@ -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