From b96470467b55aed30d58851d60b50ea03c151283 Mon Sep 17 00:00:00 2001 From: Sean McGinnis Date: Fri, 19 Apr 2019 09:31:58 -0500 Subject: [PATCH] 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 --- doc/source/contributor/index.rst | 9 +- doc/source/contributor/releasecycle.rst | 156 ++++++++++++++++++++++++ 2 files changed, 164 insertions(+), 1 deletion(-) create mode 100644 doc/source/contributor/releasecycle.rst diff --git a/doc/source/contributor/index.rst b/doc/source/contributor/index.rst index 186cc6179f2..8dd082f4e0f 100644 --- a/doc/source/contributor/index.rst +++ b/doc/source/contributor/index.rst @@ -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:: diff --git a/doc/source/contributor/releasecycle.rst b/doc/source/contributor/releasecycle.rst new file mode 100644 index 00000000000..19fe2b45f14 --- /dev/null +++ b/doc/source/contributor/releasecycle.rst @@ -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.