openstack/releases
Code Issues Proposed changes

clean up reviewers guide

Browse Source 
There were a few typos and other small changes mentioned in the review
of https://review.openstack.org/#/c/579019. This patch fixes those.

Change-Id: I928e8f0930c4fb405d6947d82883fa48a5185dfc
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This commit is contained in:
Doug Hellmann 2018-06-29 11:46:00 -04:00
parent 1c07b10131
commit bd50d262be
1 changed files with 7 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
doc/source/reference/reviewer_guide.rst
View File

@ -29,15 +29,16 @@ For the stable series we have an arrangement with the
`stable-maint-core
<https://review.openstack.org/#/admin/groups/530,members>`_ team that
if a deliverable has the ``stable:follows-policy`` tag we don't
approve it until they have had a chance to review it. Things that do
not have that governance tag can be approved at any time.
approve it until they have had a chance to review it (usually the
Monday after the request is submitted). Releases for deliverables that
do not have that governance tag can be approved at any time.
Releases from master can be approved with a single reviewer.
Code changes and doc changes and other things like that need 2
reviewers.
Releases from someone other than the PTL or liaison must be
Releases from someone other than the PTL or release liaison must be
acknowledged by one of them with a +1 vote in gerrit.
Review Checks
@ -71,7 +72,7 @@ support human reviewers. It writes the report to
run as ``tox -e list-changes`` locally.
Reviewers should read this log file for every review. It includes all
of the information that needed to evaluate a release.
of the information needed to evaluate a release.
At the top of the file we get the release model, which tells us things
like when releases are allowed, what version numbers are allowed, etc.
@ -138,7 +139,7 @@ exception to the SemVer rules is applied:
* Projects tagging a regular release (not a "pre-release" like an
alpha, beta, or rc) need to increment at least the Y part of their
version number when they minimum version of a dependency changes or
version number when the minimum version of a dependency changes or
when a new dependency is added.
The report shows the changes to the test requirements as the second
@ -175,7 +176,7 @@ text fails for some reason this job will fail and the reno input files
can be fixed instead of having the announce job fail.
The final part of the output is a list of projects that have the
current deliverable being released in their one of their dependency
current deliverable being released in one of their dependency
lists. That section is useful for evaluating the impact of a late
release when we're in the freeze period.