Merge "[upstream] Update release-cycle slides"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
cf102483e0
@ -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
|
||||
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user