[openstack-dev] [Nova][FFE] Feature freeze exception for virt-driver-numa-placement

Nikola Đipanov ndipanov at redhat.com
Thu Sep 4 13:07:24 UTC 2014


On 09/04/2014 02:31 PM, Sean Dague wrote:
> On 09/04/2014 07:58 AM, 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).
> 
> This statement bugs me. It seems kind of backwards to say we should
> merge a thing that we don't have a good upstream test plan on and put it
> in a release so that the testing will happen only in the downstream case.
> 

The objective reality is that many other things have not had upstream
testing for a long time (anything that requires more than 1 compute node
in Nova for example, and any scheduling feature - as I mention clearly
above), so not sure how that is backwards from any reasonable point.

Thanks to folks using them, it is still kept working and bugs get fixed.
Getting features into the hands of users is extremely important...

> Anyway, not enough to -1 it, but enough to at least say something.
> 

.. but I do not want to get into the discussion about software testing
here, not the place really.

However, I do think it is very harmful to respond to FFE request with
such blanket statements and generalizations, if only for the message it
sends to the contributors (that we really care more about upholding our
own myths as a community than users and features).

N.



More information about the OpenStack-dev mailing list