<p dir="ltr">Option C</p>
<br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 15, 2016, 1:23 PM Dave Walker <<a href="mailto:email@daviey.com">email@daviey.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Option C<div><br></div><div>Thanks</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 September 2016 at 12:10, Ryan Hallisey <span dir="ltr"><<a href="mailto:rhallise@redhat.com" target="_blank">rhallise@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Option c.<br>
<span><font color="#888888"><br>
- Ryan<br>
</font></span><div><div><br>
> On Sep 15, 2016, at 4:33 AM, Paul Bourke <<a href="mailto:paul.bourke@oracle.com" target="_blank">paul.bourke@oracle.com</a>> wrote:<br>
><br>
> c) Split the repository shortly after tagging 3.0.0 – creating a kolla-ansible deliverable for Ocata.<br>
><br>
>> On 15/09/16 07:12, Steven Dake (stdake) wrote:<br>
>> Core Reviewers:<br>
>><br>
>><br>
>><br>
>> The facts:<br>
>><br>
>> We have roughly 250 bugs in rc2. Of those, I suspect over half can just<br>
>> be closed out as dupes, fixed, wontfix, or the like.<br>
>><br>
>> The core reviewer team has had various discussions around splitting the<br>
>> repository at various times but has not come to a concrete conclusion<br>
>> via a vote.<br>
>><br>
>> Once RC1 is tagged, the stable/newton branch will be created automatically.<br>
>><br>
>> All rc2 bug fixes will require bug IDs and backports to stable/newton to<br>
>> enable the ability to manage the release of rc2 and 3.0.0.<br>
>><br>
>> There is an expectation for core reviewers to do the work of backporting<br>
>> to stable/newton – only our backports team typically does this work –<br>
>> however during release we really need everyone’s participation.<br>
>><br>
>><br>
>><br>
>> My understanding of general consensus beliefs:<br>
>><br>
>> We believe splitting out the Ansible implementation into a separate<br>
>> repository will produce a better outcome for both Kolla-Ansible and<br>
>> Kolla-Kubernetes<br>
>><br>
>> We have been unable to achieve consensus on the right timing for a repo<br>
>> split in the past but generally believe the timing is right at some<br>
>> point between rc1 and Summit or shortly thereafter, if we are to do the<br>
>> repo split during Newton or very early Ocata.)<br>
>><br>
>><br>
>><br>
>> This vote is a multiple choice (one choice please) vote. Feel free to<br>
>> discuss before making a decision.<br>
>><br>
>><br>
>><br>
>> Please vote:<br>
>><br>
>> a) Do not split the repository between rc1 and Summit or shortly<br>
>> thereafter at all, keeping the Ansible implementation intact in Ocata<br>
>><br>
>> b) Split the repository shortly after tagging RC1 – creating of a<br>
>> kolla-ansible deliverable for Ocata.<br>
>><br>
>> c) Split the repository shortly after tagging 3.0.0 – creating a<br>
>> kolla-ansible deliverable for Ocata.<br>
>><br>
>><br>
>><br>
>> Voting is open for 7 days until September 21^st , 2016. Please do not<br>
>> abstain on this critical vote. Remember, no veto vote is available in<br>
>> roll-call votes. If a majority can’t be reached on any one choice, but<br>
>> there is a majority around B & C, (which are the same idea, but<br>
>> different timing) a second vote will be triggered around when to split<br>
>> the repository. The implication there is if you vote for b or c, your<br>
>> voting for a repository split. If you vote for A you are voting for no<br>
>> repository split. I hate to overload voting in this way. It is only an<br>
>> optimization to speed things up as execution may need to happen now, or<br>
>> can be pushed out a month, or may not be needed at this time.<br>
>><br>
>><br>
>><br>
>> Regards<br>
>><br>
>> -steve<br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>