From 300353de815129b5bb3232b733f3979a74d0eb4b Mon Sep 17 00:00:00 2001 From: Brian Rosmaita Date: Wed, 7 Oct 2020 08:20:14 -0400 Subject: [PATCH] doc: update release cycle tasks Add info about cinderlib, cinder-tempest-plugin, and transitioning the oldest stable branch to extended maintenance mode. Also add a new doc about maintaining group memberships. Change-Id: I65d63a3add96b1b6589c3704606df2a3d865e272 --- doc/source/contributor/cinder-groups.rst | 121 +++++++++++++++++++++++ doc/source/contributor/index.rst | 1 + doc/source/contributor/releasecycle.rst | 94 +++++++++++++++--- 3 files changed, 204 insertions(+), 12 deletions(-) create mode 100644 doc/source/contributor/cinder-groups.rst diff --git a/doc/source/contributor/cinder-groups.rst b/doc/source/contributor/cinder-groups.rst new file mode 100644 index 00000000000..66492cd7ac4 --- /dev/null +++ b/doc/source/contributor/cinder-groups.rst @@ -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 + + diff --git a/doc/source/contributor/index.rst b/doc/source/contributor/index.rst index 941d336f7be..a3066b72764 100644 --- a/doc/source/contributor/index.rst +++ b/doc/source/contributor/index.rst @@ -60,6 +60,7 @@ Managing the Development Cycle :maxdepth: 1 releasecycle + cinder-groups Documentation Contribution -------------------------- diff --git a/doc/source/contributor/releasecycle.rst b/doc/source/contributor/releasecycle.rst index 15627875c01..c750e7adb15 100644 --- a/doc/source/contributor/releasecycle.rst +++ b/doc/source/contributor/releasecycle.rst @@ -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/-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/-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 + )" 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 -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