Start release cycle checklist documentation
This is a start to capturing the activities that need to happen during a typical release cycle to help us track tasks and avoid missing important steps. Change-Id: I137694a460cbefe499231270faa0d1d2e1a11066 Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This commit is contained in:
Sean McGinnis
parent
ad45320e81
commit
b96470467b
|
|
@ -26,7 +26,7 @@ APIs.
|
|||
Programming HowTos and Tutorials
|
||||
--------------------------------
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
:maxdepth: 2
|
||||
|
||||
development.environment
|
||||
testing
|
||||
|
|
@ -43,6 +43,13 @@ Programming HowTos and Tutorials
|
|||
rolling.upgrades
|
||||
groups
|
||||
|
||||
Managing the Development Cycle
|
||||
------------------------------
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
releasecycle
|
||||
|
||||
Documentation Contribution
|
||||
--------------------------
|
||||
.. toctree::
|
||||
|
|
|
|||
|
|
@ -0,0 +1,156 @@
|
|||
===================
|
||||
Release Cycle Tasks
|
||||
===================
|
||||
|
||||
This document describes the relative ordering and rough timeline for
|
||||
all of the steps related to tasks that need to be completed during a
|
||||
release cycle for Cinder.
|
||||
|
||||
Before PTG (after closing previous release)
|
||||
===========================================
|
||||
|
||||
#. Collect topics and prepare notes for PTG discussions in an etherpad.
|
||||
Add a link to the etherpad to the list of PTG etherpads (for example:
|
||||
https://wiki.openstack.org/wiki/PTG/Train/Etherpads)
|
||||
|
||||
|
||||
Between Summit and Milestone-1
|
||||
==============================
|
||||
|
||||
#. Review output from the PTG and set Review-Priority on any high
|
||||
priority items identified from those discussions. Send out recap to
|
||||
the mailing list.
|
||||
|
||||
#. Add any Cinder-specific schedule information to the release calendar
|
||||
(https://review.openstack.org/#/c/509019/)
|
||||
|
||||
#. Focus on spec reviews to get them approved and updated early in
|
||||
the cycle to allow enough time for implementation.
|
||||
|
||||
#. Review new driver submissions and give early feedback so there isn't
|
||||
a rush at the new driver deadline. Check for status of third party CI
|
||||
and any missing steps they need to know about.
|
||||
|
||||
#. Review community-wide goals and decide a plan or response to
|
||||
them.
|
||||
|
||||
Milestone-1
|
||||
===========
|
||||
|
||||
#. Propose library releases for os-brick or python-cinderclient if there
|
||||
are merged commits ready to be released. Watch for any releases
|
||||
proposed by the release team.
|
||||
|
||||
#. Check progress on new drivers and specs and warn contributors if
|
||||
it looks like they are at risk for making it in this cycle.
|
||||
|
||||
Between Milestone-1 and Milestone-2
|
||||
===================================
|
||||
|
||||
#. Review stable backports and release status.
|
||||
|
||||
#. Watch for and respond to updates to new driver patches.
|
||||
|
||||
Milestone-2
|
||||
===========
|
||||
|
||||
#. Propose library releases for os-brick or python-cinderclient if there
|
||||
are merged commits ready to be released. Watch for any releases
|
||||
proposed by the release team.
|
||||
|
||||
Between Milestone-2 and Milestone-3
|
||||
===================================
|
||||
|
||||
#. Review stable backports and release status.
|
||||
|
||||
#. Set Review-Priority for any os-brick changes that are needed for
|
||||
feature work to make sure they are ready by the library freeze prior
|
||||
to Milestone-3.
|
||||
|
||||
#. Make sure any new feature work that needs client changes are proposed
|
||||
and on track to land before the client library freeze at Milestone-3. Ensure
|
||||
microversion bumps are reflected in cinderclient/api_versions.py
|
||||
MAX_VERSION.
|
||||
|
||||
#. The week before Milestone-3, propose releases for unreleased changes
|
||||
in os-brick. Include branch request for stable/$series creation.
|
||||
|
||||
Milestone-3
|
||||
===========
|
||||
|
||||
#. Propose releases for unreleased changes in python-cinderclient and
|
||||
python-brick-cinderclient-ext. Watch for releases proposed by the
|
||||
release team. Include branch request for stable/$series creation.
|
||||
|
||||
#. Set Review-Priority -1 for any feature work not complete in time for
|
||||
inclusion in this cycle. Remind contributors that FFE will need to be
|
||||
requested to still allow it in this cycle.
|
||||
|
||||
#. Prepare "prelude" release notes as
|
||||
summaries of the content of the release so that those are merged
|
||||
before their first release candidate.
|
||||
|
||||
#. Complete the responses to community-wide goals if not already done.
|
||||
|
||||
#. Start assembling cycle-highlights for the team.
|
||||
|
||||
Between Milestone-3 and RC1
|
||||
===========================
|
||||
|
||||
#. Add cycle-highlights in the releases deliverable file.
|
||||
|
||||
RC1 week
|
||||
========
|
||||
|
||||
#. Propose RC1 release for cinder or watch for proposal from the release team.
|
||||
Include stable/$series branching request with the release.
|
||||
|
||||
#. Finalize any cycle-highlights for the release cycle.
|
||||
|
||||
#. Remind contributors that ``master`` is now the next cycle but focus should
|
||||
be on wrapping up the current cycle.
|
||||
|
||||
#. Watch for translation and new stable branch patches and merge them quickly.
|
||||
|
||||
Between RC1 and Final
|
||||
=====================
|
||||
|
||||
#. Propose additional RC releases as needed.
|
||||
|
||||
.. note::
|
||||
|
||||
Try to avoid creating more than 3 release candidates so we are not
|
||||
creating candidates that consumers are then trained to ignore. Each
|
||||
release candidate should be kept for at least 1 day, so if there is a
|
||||
proposal to create RCx but clearly a reason to create another one,
|
||||
delay RCX to include the additional patches.
|
||||
|
||||
#. Watch for translation patches and merge them quickly.
|
||||
|
||||
#. Make sure final RC request is done one week before the final release date.
|
||||
|
||||
#. Watch for the final release proposal from the release team to review and +1
|
||||
so team approval is included in the metadata that goes onto the signed tag.
|
||||
|
||||
Final Release
|
||||
=============
|
||||
|
||||
#. Start planning for next release cycle.
|
||||
|
||||
#. Check for bugfixes that would be good to backport to older stable branches.
|
||||
|
||||
#. Propose any bugfix releases for things that did not make the freeze for
|
||||
final library or service releases.
|
||||
|
||||
Post-Final Release
|
||||
==================
|
||||
|
||||
#. Make sure at least three SQLAlchemy-Migrate migrations are reserved
|
||||
for potential backports (https://review.openstack.org/#/c/649436/).
|
||||
|
||||
#. Unblock any new driver submission patches that missed the previous
|
||||
release cycle's deadline.
|
||||
|
||||
#. Review approved cinder-specs that were merged to the previous cycle
|
||||
folder that did not get implemented. Revert or move those specs to the
|
||||
next cycles's folder.
|
||||
Loading…
Reference in New Issue