Open Stack

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 <mauriciolimab at gmail.com> wrote:
> Option c.
>
> 2016-09-15 8:25 GMT-03:00 Eduardo Gonzalez <dabarren at gmail.com>:
>>
>> Option C
>>
>>
>> On Thu, Sep 15, 2016, 1:23 PM Dave Walker <email at daviey.com> wrote:
>>>
>>> Option C
>>>
>>> Thanks
>>>
>>> On 15 September 2016 at 12:10, Ryan Hallisey <rhallise at redhat.com> wrote:
>>>>
>>>> Option c.
>>>>
>>>> - Ryan
>>>>
>>>> > On Sep 15, 2016, at 4:33 AM, Paul Bourke <paul.bourke at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>