Add review criteria for stable-branch maintenance

As we've discussed on IRC, document the criteria used to perform reviews on
the stable branches to help facilitate more core reviewers on those stable
branches.

Change-Id: I99d2566614a3cd85428c396faa4a6f58cd5ba9be
This commit is contained in:
Matthew Thode 2017-05-25 12:04:55 -05:00
parent eecccf8940
commit 7cb64a0a15
No known key found for this signature in database
GPG Key ID: 64A37BEAAE19A4E8
1 changed files with 31 additions and 0 deletions

View File

@ -157,6 +157,37 @@ Entries in all requirements files will have their versions updated to match
the entries listed in the global requirements. Excess entries will cause
errors in hard mode (the default) or be ignored in soft mode.
stable-branch maintenance
-------------------------
Upper-constraints
+++++++++++++++++
Most of the work is done by stable-maint in the releases project. The releases
project ensures valid stable releases (little to no API level changes, bugfix
only, etc). Once released, the new version is requested to be updated in
requirements. The following restrictions are in place to help ensure stable
branches do not break.
- In stable branches, we usually only update constraints for projects managed
within the OpenStack community. Exceptions are made for other projects when
there are gate issues. Those updates must be proposed by hand.
- The requirements team also verifies the new version's requirements changes
line up with the requirements in the stable branch (GR and UC).
Global-requirements
+++++++++++++++++++
These should be few and far between on stable branches, mainly masking known
bad versions or in extreme adding a maximum version allowable for a package.
We work to remove these caps as well.
New requirements
++++++++++++++++
In nearly all cases this is not allowed.
generate-constraints
--------------------