openstack
/
project-team-guide
Code Issues Proposed changes

Add need for -stable-maint and -release groups 

Release management assumes that all projects following a
cycle-with-milestones model will use a $PROJECT-release
team to review backports between RC1 and final.

It also assumes that all projects following the stable
policy will use a $PROJECT-stable-maint team.

So let's document that common practice!

NB: All teams already follow this pattern, except Kolla.
Once this merges (and depending on the conclusion of the
discussion around a deploytools-centric stable policy
variant), I'll fix the Kolla exception accordingly.

Change-Id: I3870e8463c6374df17c74579e7332d659ae634ac
This commit is contained in:
Thierry Carrez 2017-10-27 15:07:44 +02:00
parent 661fd0b216
commit 6fe830e43a
2 changed files with 9 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
doc/source/release-management.rst
View File

@ -84,8 +84,11 @@ another milestone tagged that includes the latest translations.
Potential new release critical issues have first to get fixed on the master
branch. Once merged in master, they can be backported to the release branch.
Such backports are approved by the PTL (or release liaison), and once all the
desired backports (and translations updates) are merged, a new release
A specific Gerrit team named PROJECTNAME-release (usually the PTL, release
liaison and other few trusted team members) is tasked with approving such
backports. To that effect, the PROJECTNAME-release team has CodeReview+2 and
Workflow+1 rights on the stable/$series branch until final release. Once all
the desired backports (and translations updates) are merged, a new release
candidate can be produced.
On final release day, the Release Team will take each project's last release

6
doc/source/stable-branches.rst
View File

@ -108,8 +108,10 @@ Project-specific teams
----------------------
Each project with a stable branch will have a project-specific stable
maintenance team, which will be in charge of reviewing backports for a given
project, following the stable branch policy. Originally that group should be
maintenance Gerrit team called PROJECTNAME-stable-maint. This team
will have CodeReview+2 and Workflow+1 rights over the stable branches,
and be in charge of reviewing backports for a given project, following
the rules of the stable branch policy. Originally that group should be
the project Stable Branch Cross-Project Liaison + the stable maintenance core
team. Those groups are managed by the stable maintenance core team, names are
added after the suggestion of the Stable Branch cross-project liaison.