Now a days, Tempest does not have much active core reviewers due
to that merging the incoming code change is taking too much time.
As you can see we have lot of backlogs in open review ~400
If situation improve in future and we have more Core review
then we can change the policy back to two +2 requirement.
Discussion in QA office hour:
We discussed in Denver PTG to make plugins
sanity jobs as voting which will help to mantain
the active plugins and blacklist the faulty plugins.
But when we get faulty plugins this job which will
be voting after https://review.opendev.org/#/c/641188/
can block the Tempest gate. So adding the process of
single core approve policy for mergin the patches which
will fix or remove the faulty plugins to unblock the gate.
 L196 https://etherpad.openstack.org/p/qa-train-ptg
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.
This patch set corrects some misleading documentation under "Unit
Tests" section in REVIEWING.rst.
It currently claims that service clients do not require unit test
coverage -- but this is false. This is because Tempest now places
all of its service clients in tempest.lib. And as per
is required to add unit tests for all service client interfaces.
Thus this makes the documentation language clear that service clients
require unit tests.
This patch set adds information on test removal, relocation,
renaming to REVIEWING because it is important that such
actions do not break interop. Interop is closely tied to
Tempest because it directly references Tempest tests that
are not only expected to exist, but to also work.
The same is true of breaking blacklist/whitelist
references to Tempest tests, this is also included
in the new documentation section.
It is important that there be REVIEWING guidelines
in place to assist reviewers understand this importance.
Also references are included for defcore/interop to help
users find more information on these topics.
Currently interop is only mentioned in 1 place in Tempest 
and yet there is little information about it. This patchset
aims to make it easier to find more information about it
for reviewers and users alike.
Reviewing the REVIEWING.rst of tempest,
I noticed a plural mistake.
The word "APIs" is plural and it shouldn't add 'a' in the front.
And there is an extra "that" before "which".
So I fix it.
Most of them can still be visited through http, but the following
one is necessary to update, so I change them all by this chance.
$ git clone http://git.openstack.org/openstack/tempest
I've been reading our entire documentation to see where it could
be improved. It's guide good actually. While reading I've fixed
some typos, added some capitalization to project names, mostly
What's worth reviewing is the 2 paragraphs I added to the REVIEWING
This commit adds a deprecated code review guideline. We have some
deprecated code (e.g. stress test) now. And we sometimes wonder whether
we should review a patch for deprecated code or not. So this patch tries
to clear up the situation.
This commit adds a brief section about ensuring release notes are
present to the reviewing doc. This should hopefully make it more
clear to reviewers when we need to include release notes.
This commit adds an additional section to the reviewers guide to
elaborate on the policy around configuration options. We already
documented part of it in the plugin interface documentation, but this
should make the policy around it a bit more clear.
This commit fixes a few things in the tempest docs. First it fixes all
of the sphinx warnings and enables fail on warn to ensure we're using
valid sphinx everywhere. It also adds a link from the configuration
guide to the sample config file.