[openstack-dev] What should openstack-specs review approval rules be ?
thierry at openstack.org
Wed Jan 28 13:25:41 UTC 2015
When we first introduced the cross-project specs (specs for things that
may potentially affect all OpenStack projects, or where more convergence
is desirable), we defaulted to rather simple rules for approval:
- discuss the spec in a cross-project meeting
- let everyone +1/-1 and seek consensus
- wait for the affected PTLs to vote
- wait even more
- tally the votes (and agree a consensus is reached) during a TC meeting
- give +2/Worflow+1 to all TC members to let them push the Go button
However, the recent approval of the Log guidelines
(https://review.openstack.org/#/c/132552/) revealed that those may not
be the rules we are looking for.
Sean suggested that only the TC chair should be able to workflow+1 to
avoid accidental approval.
Doug suggested that we should use the TC voting rules (7 YES, or at
least 5 YES and more YES than NO) on those.
In yesterday's meeting, Sean suggested that TC members should still have
a -2-like veto (if there is no TC consensus on the fact that community
consensus is reached, there probably is no real consensus).
There was little time to discuss this more in yesterday's TC meeting, so
I took the action to push that discussion to the ML.
So what is it we actually want for that repository ? In a world where
Gerrit can do anything, what would you like to have ?
Personally, I want our technical community in general, and our PTLs/CPLs
in particular, to be able to record their opinion on the proposed
cross-project spec. Then, if consensus is reached, the spec should be
This /could/ be implemented in Gerrit by giving +1/-1 to everyone to
express technical opinion and +2/-2 to TC members to evaluate consensus
(with Workflow+1 to the TC chair to mark when all votes are collected
and consensus is indeed reached).
Other personal opinions on how you'd like this repository reviews to be
Thierry Carrez (ttx)
More information about the OpenStack-dev