On Thu, Sep 15, 2016 at 11:42 AM, Steven Dake (stdake) <std...@cisco.com> 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 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 > > > __________________________________________________________________________ > 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 >
my vote is for option C. __________________________________________________________________________ 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