Merge "doc: update release cycle tasks"

This commit is contained in:
Zuul 2021-01-28 04:29:17 +00:00 committed by Gerrit Code Review
commit 0fe910f130
3 changed files with 204 additions and 12 deletions

View File

@ -0,0 +1,121 @@
.. _cinder-groups:
=====================================
Cinder Groups in Gerrit and Launchpad
=====================================
Cinder-related groups in Launchpad
==================================
.. list-table::
:header-rows: 1
* - group
- what
- who
- where
* - "Cinder" team
- not sure, exactly
- an "open" team, anyone with a Launchpad account can join
- https://launchpad.net/~cinder
* - "Cinder Bug Team" team
- can triage (change status fields) on bugs
- an "open" team, people self-nominate
- https://launchpad.net/~cinder-bugs
* - "Cinder Drivers" team
- Maintains the Launchpad space for Cinder, os-brick, cinderlib,
python-cinderclient, and cinder-tempest-plugin
- Anyone who is interested in doing some work, has a Launchpad
account, and is approved by the current members
- https://launchpad.net/~cinder-drivers
* - "Cinder Core security contacts" team
- can see and work on private security bugs while they are under embargo
- subset of cinder-core (the OpenStack Vulnerablity Management Team
likes to keep this team small), so even though the PTL can add people,
you should propose them on the mailing list first
- https://launchpad.net/~cinder-coresec
Cinder-related groups in Gerrit
===============================
The Cinder project has total control over the membership of these groups.
.. list-table::
:header-rows: 1
* - group
- what
- who
- where
* - cinder-core
- +2 powers in Cinder project code repositories
- cinder core reviewers
- https://review.opendev.org/#/admin/groups/83,members
* - cinder-specs-core
- +2 powers in cinder-specs repository
- cinder-core (plus others if appropriate; currently only cinder-core)
- https://review.opendev.org/#/admin/groups/344,members
* - cinder-tempest-plugin-core
- +2 powers on the cinder-tempest-plugin repository
- cinder-core plus other appropriate people
- https://review.opendev.org/#/admin/groups/2088,members
The Cinder project shares control over the membership of these groups. If you
want to add someone to one of these groups who doesn't already have membership
by being in an included group, be sure to include the other groups or
individual members in your proposal email.
.. list-table::
:header-rows: 1
* - group
- what
- who
- where
* - cinder-stable-maint
- +2 powers on backports to stable branches
- subset of cinder-core (subject to approval by stable-maint-core) plus
the stable-maint-core team
- https://review.opendev.org/#/admin/groups/534,members
* - devstack-plugin-ceph-core
- +2 powers on the code repo for the Ceph devstack plugin
- cinder-core, devstack-core, manila-core, qa-release, other appropriate
people
- https://review.opendev.org/#/admin/groups/1196,members
* - devstack-plugin-nfs-core
- +2 powers on the code repo for the NFS devstack plugin
- cinder-core, devstack-core, other appropriate people
- https://review.opendev.org/#/admin/groups/1330,members
* - devstack-plugin-open-cas-core
- +2 powers on the code repo for the Open CAS devstack plugin
- cinder-core, devstack-core, other appropriate people
- https://review.opendev.org/#/admin/groups/2082,members
NOTE: The following groups exist, but I don't think they are used for anything
anymore.
.. list-table::
:header-rows: 1
* - group
- where
* - cinder-ci
- https://review.opendev.org/#/admin/groups/508,members
* - cinder-milestone
- https://review.opendev.org/#/admin/groups/82,members
* - cinder-release
- https://review.opendev.org/#/admin/groups/144,members
* - cinder-release-branch
- https://review.opendev.org/#/admin/groups/1507,members
How Gerrit groups are connected to project repositories
-------------------------------------------------------
The connection between the groups defined in gerrit and what they
can do is defined in the project-config repository:
https://opendev.org/openstack/project-config
* ``gerrit/projects.yaml`` sets the config file for a project
* ``gerrit/acls`` contains the config files

View File

@ -60,6 +60,7 @@ Managing the Development Cycle
:maxdepth: 1
releasecycle
cinder-groups
Documentation Contribution
--------------------------

View File

@ -10,9 +10,36 @@ 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)
The PTGbot will generate a list of etherpads at some point that will
be named according to the convention::
https://etherpad.openstack.org/p/<release-name>-ptg-cinder
(You can use a different name, but following the convention makes it
easy to locate the etherpad for any project for any release. Something
we've done in the past is to do the planning on an etherpad named::
https://etherpad.openstack.org/p/<release-name>-ptg-cinder-planning
and then move the topics over to the "real" etherpad when the team has
decided on what to include and the ordering. Do whatever works for
you. Just make sure the team knows where the planning etherpad is and
give everyone plenty of reminders to add topics.
#. Add any Cinder-specific schedule information to the release calendar
as soon as it's available. Example patch:
https://review.opendev.org/c/openstack/releases/+/754484
* We used to wait to do this until after proposed deadlines were discussed
at the PTG, but recently people have been getting antsy about what the
deadlines are as soon as the stable branch for the previous release is cut
(which is roughly a month before the PTG). So you may want to go ahead
and post the patch early and announce the dates at a Cinder meeting so
that people can point out conflicts. Or do it the old-fashioned way
and work it out at the PTG. Either way, the point is to make sure you
don't forget to add Cinder-specific dates to the main release schedule.
#. Review the :ref:`cinder-groups`.
Between Summit and Milestone-1
==============================
@ -21,9 +48,6 @@ Between Summit and Milestone-1
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.
@ -47,6 +71,13 @@ Milestone-1
Between Milestone-1 and Milestone-2
===================================
#. cinderlib is a "trailing" deliverable type on a "cycle-with-intermediary"
release model. That means that its release for the *previous* cycle hasn't
happened yet. The release must happen no later than 3 months after the
main release, which will put it roughly one week before Milestone-2 (check
the current release schedule for the exact deadline). Example patch:
https://review.opendev.org/c/openstack/releases/+/742503
#. Review stable backports and release status.
#. Watch for and respond to updates to new driver patches.
@ -99,11 +130,27 @@ Between Milestone-3 and RC1
#. Add cycle-highlights in the releases deliverable file.
#. Make sure the maximum microversion is up-to-date in the version history
file ``cinder/api/openstack/rest_api_version_history.rst``
* Any patch that bumped the microversion should have already
included an entry in this file; you need to add "(Maximum in
<release-name>)" to the last (highest) entry.
* This file is pulled into the api-ref by the documentation build
process.
#. Check the "Driver Removal History" section (bottom) of
``doc/source/reference/support-matrix.rst`` to make sure any drivers
removed during the cycle are mentioned there.
#. Check the upgrade check tool ``cmd/status.py`` to make sure the
removed drivers list is up to date.
RC1 week
========
#. Propose RC1 release for cinder or watch for proposal from the release team.
Include stable/$series branching request with the release.
Include ``stable/$series`` branching request with the release.
#. Finalize any cycle-highlights for the release cycle.
@ -146,12 +193,8 @@ Post-Final Release
==================
#. Make sure at least three SQLAlchemy-Migrate migrations are reserved
for potential backports (https://review.openstack.org/#/c/649436/).
#. Update the ``cinder/api/openstack/rest_api_version_history.rst`` file to
denote the maximum API microversion so the new cycle docs reflect what
version was the last one available in the previous release. See
https://review.opendev.org/#/c/724137/ for an example.
for potential backports. Example patch:
https://review.opendev.org/c/openstack/cinder/+/649436
#. Unblock any new driver submission patches that missed the previous
release cycle's deadline.
@ -159,3 +202,30 @@ Post-Final Release
#. 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.
#. The oldest active stable branch (that is, the oldest one you can still
release from) will go to Extended Maintenance mode shortly after the
coordinated release. Watch for an email notification from the release
team about the projected date, which you can also find in the "Next
Phase" column for that release series on https://releases.openstack.org
* Prioritize any open reviews that should get into the final stable
release from this branch for all relevant cinder deliverables and
motivate the cinder-stable-maint cores to review them.
* Propose a final release for any deliverable that needs one. Example
patch: https://review.opendev.org/c/openstack/releases/+/761929
* The release team will probably propose a placeholder patch to tag
the stable branch for each deliverable as <release>-em (or if they
haven't gotten around to it yet, you can propose it yourself).
Verify that the hash is at the current HEAD for each deliverable
(it may have changed if some last-minute stuff was merged).
Example patch: https://review.opendev.org/c/openstack/releases/+/762372
* After the "transition to EM" patch has merged, update the zuul jobs
for the cinder-tempest-plugin. We always have 3 jobs for the active
stable branches plus jobs for master. Add a new job for the most
recent release and remove the job for the stable branch that just
went to EM. Example patch:
https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/756330