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> wrote: > Option c. > > 2016-09-15 8:25 GMT-03:00 Eduardo Gonzalez <dabar...@gmail.com>: >> >> Option C >> >> >> On Thu, Sep 15, 2016, 1:23 PM Dave Walker <em...@daviey.com> wrote: >>> >>> Option C >>> >>> Thanks >>> >>> On 15 September 2016 at 12:10, Ryan Hallisey <rhall...@redhat.com> wrote: >>>> >>>> Option c. >>>> >>>> - Ryan >>>> >>>> > On Sep 15, 2016, at 4:33 AM, Paul Bourke <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?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 >>>> >>>> __________________________________________________________________________ >>>> 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 >> >> >> __________________________________________________________________________ >> 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 > __________________________________________________________________________ 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
