Merge "doc: update release cycle tasks"
This commit is contained in:
commit
0fe910f130
121
doc/source/contributor/cinder-groups.rst
Normal file
121
doc/source/contributor/cinder-groups.rst
Normal 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
|
||||
|
||||
|
@ -60,6 +60,7 @@ Managing the Development Cycle
|
||||
:maxdepth: 1
|
||||
|
||||
releasecycle
|
||||
cinder-groups
|
||||
|
||||
Documentation Contribution
|
||||
--------------------------
|
||||
|
@ -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
|
||||
|
Loading…
x
Reference in New Issue
Block a user