c) Split the repository shortly after tagging 3.0.0 – creating a kolla-ansible deliverable for Ocata.

On 15/09/16 07:12, Steven Dake (stdake) wrote:
Core Reviewers:



The facts:

We have roughly 250 bugs in rc2.  Of those, I suspect over half can just
be closed out as dupes, fixed, wontfix, or the like.

The core reviewer team has had various discussions around splitting the
repository at various times but has not come to a concrete conclusion
via a vote.

Once RC1 is tagged, the stable/newton branch will be created automatically.

All rc2 bug fixes will require bug IDs and backports to stable/newton to
enable the ability to manage the release of rc2 and 3.0.0.

There is an expectation for core reviewers to do the work of backporting
to stable/newton – only our backports team typically does this work –
however during release we really need everyone’s participation.



My understanding of general consensus beliefs:

We believe splitting out the Ansible implementation into a separate
repository will produce a better outcome for both Kolla-Ansible and
Kolla-Kubernetes

We have been unable to achieve consensus on the right timing for a repo
split in the past but generally believe the timing is right at some
point between rc1 and Summit or shortly thereafter, if we are to do the
repo split during Newton or very early Ocata.)



This vote is a multiple choice (one choice please) vote.  Feel free to
discuss before making a decision.



Please vote:

a)       Do not split the repository between rc1 and Summit or shortly
thereafter at all, keeping the Ansible implementation intact in Ocata

b)       Split the repository shortly after tagging RC1 – creating of a
kolla-ansible deliverable for Ocata.

c)       Split the repository shortly after tagging 3.0.0 – creating a
kolla-ansible deliverable for Ocata.



Voting is open for 7 days until September 21^st , 2016. Please do not
abstain on this critical vote.  Remember, no veto vote is available in
roll-call votes.  If a majority can’t be reached on any one choice, but
there is a majority around B & C, (which are the same idea, but
different timing) a second vote will be triggered around when to split
the repository.  The implication there is if you vote for b or c, your
voting for a repository split.  If you vote for A you are voting for no
repository split.  I hate to overload voting in this way.  It is only an
optimization to speed things up as execution may need to happen now, or
can be pushed out a month, or may not be needed at this time.



Regards

-steve



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to