On 09/04/2014 04:51 PM, Murray, Paul (HP Cloud) wrote: > > > On 4 September 2014 14:07, Nikola Đipanov <[email protected]> wrote: > > 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). > > > > > > I believe you brought this up as one of your justifications for the FFE. > When I read your statement it does sound as though you want to put > experimental code in at the final release. I am sure that is not what > you had in mind, but I am also sure you can also understand Sean's point > of view. His point is clear and pertinent to your request. > > > > As the person responsible for Nova in HP I will be interested to see how > it operates in practice. I can assure you we will do extensive testing > on it before it goes into the wild and we will not put it into practice > if we are not happy. >
That is awesome and we as a project are lucky to have that! I would not want things put into practice that users can't use or see huge flaws with. I can't help but read this as you being OK with the feature going ahead, though :). N. > > > Paul > > > > Paul Murray > > Nova Technical Lead, HP Cloud > > +44 117 312 9309 > > Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks > RG12 1HN Registered No: 690597 England. The contents of this message and > any attachments to it are confidential and may be legally privileged. If > you have received this message in error, you should delete it from your > system immediately and advise the sender. To any recipient of this > message within HP, unless otherwise stated you should consider this > message and attachments as "HP CONFIDENTIAL". > > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
