[openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable

Steven Dake (stdake) stdake at cisco.com
Thu Sep 15 06:12:16 UTC 2016


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 21st, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160915/7b8f739b/attachment.html>


More information about the OpenStack-dev mailing list