Merge "Update the merge process for Liberty"
This commit is contained in:
commit
38a98d5a12
@ -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
|
||||
|
Loading…
x
Reference in New Issue
Block a user