openstack/tempest
Code Issues Proposed changes

Update REVIEWING docs with fast-track approval process

Browse Source 
This patch set follows through on discussion related to fast
tracking changes in Tempest that are required to unblock other
project gates. So, the "When to approve" section of the REVIEWING
documentation has been expanded to include a fast track
provision: that 1 core reviwer can +2 a change and approve it,
provided that the core reviwer belonging to the project with
the failing gate +1's the change, too.

Change-Id: Iafb9de650cd79b3c72b03e20690dd80a95308b5b
This commit is contained in:
Felipe Monteiro 2018-09-16 11:13:39 -06:00
parent 5d96f65d98
commit 6fe405dc61
1 changed files with 29 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
REVIEWING.rst
View File

@ -159,8 +159,32 @@ fix it. When it will happen, we will deal with it on a case-by-case basis.
When to approve
---------------
* Every patch needs two +2s before being approved.
* It's ok to hold off on an approval until a subject matter expert reviews it
* If a patch has already been approved but requires a trivial rebase to merge,
you do not have to wait for a second +2, since the patch has already had
two +2s.
* It's OK to hold off on an approval until a subject matter expert reviews it.
* Every patch needs two +2's before being approved.
* However, a single Tempest core reviewer can approve patches without waiting
for another +2 in the following cases:
* If a patch has already been approved but requires a trivial rebase to
merge, then there is no need to wait for a second +2, since the patch has
already had two +2's.
* If any trivial patch set fixes one of the items below:
* Documentation or code comment typo
* Documentation ref link
* Example: `example`_
.. note::
Any other small documentation, CI job, or code change does not fall under
this category.
* If the patch **unblocks** a failing project gate, provided that:
* the project's PTL +1's the change
* the patch does not affect any other project's testing gates
* the patch does not cause any negative side effects
Note that such a policy should be used judiciously, as we should strive to
have two +2's on each patch set, prior to approval.
.. _example: https://review.openstack.org/#/c/611032/