On 09/05/2014 05:20 PM, John Garbutt wrote: > On 5 September 2014 13:59, Nikola Đipanov <ndipa...@redhat.com> wrote: >> Since this did not get an 'Approved' as of yet, I want to make sure that >> this is not because the number of sponsors. 2 core members have already >> sponsored it, and as per [1] cores can sponsor their own FFEs so that's 3. > > While I am no fan of that idea, this was already in the gate, so 2 > cores should be more than enough. > > Mikal has said I could approve FFEs in his absence, but given the > conflict in the thread, I want to leave this approval to him :) >
FWIW - I really don't think there is any conflict in the thread. Not a single person spoke up against it, and if the only argument is that we are adding additional data to the 'compute_node' table, blocking on that at this point would be irrational as the migration that does it is already merged. But I am fine with leaving the final decision on Mikal, to be honest I was rather confused when I saw no feedback from him when I opened my inbox this morning, neither positive or negative. Thanks, N. > I know its 10 patches, but I think we can try resolve the discussion > on the thread, and look to approve this on Monday morning, and still > make it before the deadline. Do shout up if that seems impossible > and/or stupid. > > Thanks, > John > >> [1] >> http://lists.openstack.org/pipermail/openstack-dev/2014-September/044669.html >> >> On 09/04/2014 01:58 PM, Nikola Đipanov wrote: >>> Hi team, >>> >>> I am requesting the exception for the feature from the subject (find >>> specs at [1] and outstanding changes at [2]). >>> >>> Some reasons why we may want to grant it: >>> >>> First of all all patches have been approved in time and just lost the >>> gate race. >>> >>> Rejecting it makes little sense really, as it has been commented on by a >>> good chunk of the core team, most of the invasive stuff (db migrations >>> for example) has already merged, and the few parts that may seem >>> contentious have either been discussed and agreed upon [3], or can >>> easily be addressed in subsequent bug fixes. >>> >>> It would be very beneficial to merge it so that we actually get real >>> testing on the feature ASAP (scheduling features are not tested in the >>> gate so we need to rely on downstream/3rd party/user testing for those). >>> >>> Thanks, >>> >>> Nikola >>> >>> [1] >>> http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/juno/virt-driver-numa-placement.rst >>> [2] >>> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/virt-driver-numa-placement,n,z >>> [3] https://review.openstack.org/#/c/111782/ >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
