Merge "Update the merge process for Liberty"

This commit is contained in:
Jenkins 2015-06-18 17:07:17 +00:00 committed by Gerrit Code Review
commit 38a98d5a12

View File

@ -21,14 +21,15 @@ The following process should occur:
that they must be proposed before merging. They must have at least
one +1 vote other than the approver and no -1.
2. A changeset which adds a new guideline or to change a guideline
included during the initial project creation must be available for
review in in its near final form for at least 2 working days before
merging. Minor typo/formatting change updates do not reset the
counter. There must be at least four +1 votes and no -1's unless the
concern by the -1 vote has been discussed in an API WG
meeting. Once the matter has been discussed there should be no more
than 20% (of votes cast) -1 votes before merging.
2. A changeset which adds a new guideline or makes a substantial change
to an existing guideline must reach consensus within the API WG.
In the guideline review, consensus means the changeset must be available
for review in its near final form for at least 2 working days. Minor
typo/formatting change updates do not reset the counter. There must be at
least four +1 votes and no -1's unless the concern by the -1 vote has been
discussed in an API WG meeting. Once the matter has been discussed there
should be no more than 20% (of votes cast) -1 votes.
Note that discussion on Gerrit should be encouraged as the first
response and summaries from discussions on IRC meetings should be
@ -36,20 +37,50 @@ The following process should occur:
meetings. However we recognise that sometimes higher bandwidth, low
latency discussions can help break deadlocks.
3. A changeset which substantially changes the meaning of an existing
guideline which has been voted on must be available for review in
its near final form for at least 3 working days before
merging. Minor typo/formatting changes do not reset the
counter. There must be at least four +1 votes and no -1's unless
the concern by the -1 vote has been addressed in an API WG
meeting. Once the matter has been discussed there should be no more
than 20% (of votes cast) -1 votes.
3. Once a changeset meets the requirements of #2, the `Cross Project Liaisons
<https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Working_Group>`_
for the API WG should be engaged on various channels.
4. Anyone who is listed on the `API Group Wiki
1. Review. The CPLs must be added as reviewers to any changeset that has
reached consensus.
2. The openstack-dev mailing list. An email must be sent to the
openstack-dev mailing list with the subject "[all][api] New API
Guidelines ready for cross project review". The email will contain links
to all of the guidelines that have reached consensus.
3. The `Cross Project Meeting
<https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting>`_. An
agenda item should be added to the Cross Project Meeting which
reads "New API Guidelines ready for cross project review" followed by a
link to the email above from the `openstack-dev archives
<http://lists.openstack.org/pipermail/openstack-dev/>`_. The Cross Project
Meeting should be attended by an API WG member to highlight the agenda
item.
4. Once a changeset meets the requirements of #2, it should be frozen by
setting Workflow -1 to prevent an accidental merge during the CPL review
period.
5. Once a changeset meets the requirements of #2, #3, and #4, the CPLs have
1 week to review it. If there is no review by a CPL, lazy consensus is
assumed. If there is a -1 review by a CPL that requires an update to the
changeset, it does not reset the 1 week the CPLs have to review it. Once
consensus it achieved, the changeset is mergable.
6. Once a changeset meets the requirements of #5, it can be merged.
An email must be sent to the openstack-dev mailing list with the subject
"[all][api] New API Guidelines finalized". The email will contain links
to all of the guidelines that have have been merged. The finalized
guidelines should be buffered such that a maximum of one announcement
email is sent per week.
7. Anyone who is listed on the `API Working Group Wiki
<https://wiki.openstack.org/wiki/API_Working_Group>`_ by
18/12/2014 (K1) can vote during the Kilo development cycle.
25/5/2015 (L1) can vote during the Liberty development cycle.
5. Before an official version of the guidelines can be released the
8. Before an official version of the guidelines can be released the
following has to occur:
* An 80% (of votes cast) majority vote on the document as a whole