Yes, I vote Option C. Regards, Vikram Hosakote IRC: vhosakot
From: Michał Jastrzębski <inc...@gmail.com<mailto:inc...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, September 15, 2016 at 9:57 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable Option C will be best, but I guess we almost have enough votes for it?:) I vote for C. On 15 September 2016 at 06:45, Mauricio Lima <mauricioli...@gmail.com<mailto:mauricioli...@gmail.com>> wrote: Option c. 2016-09-15 8:25 GMT-03:00 Eduardo Gonzalez <dabar...@gmail.com<mailto:dabar...@gmail.com>>: Option C On Thu, Sep 15, 2016, 1:23 PM Dave Walker <em...@daviey.com<mailto:em...@daviey.com>> wrote: Option C Thanks On 15 September 2016 at 12:10, Ryan Hallisey <rhall...@redhat.com<mailto:rhall...@redhat.com>> wrote: Option c. - Ryan > On Sep 15, 2016, at 4:33 AM, Paul Bourke > <paul.bou...@oracle.com<mailto:paul.bou...@oracle.com>> > wrote: > > 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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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
