----- Original Message -----
> From: "Chris Friesen" <chris.frie...@windriver.com>
> To: openstack-dev@lists.openstack.org
> 
> On 03/27/2015 12:44 PM, Dan Smith wrote:
> >> To quote John from an earlier email in this thread:
> >>
> >> Its worth noting, we do have the "experimental" flag:
> >> "
> >> The first header specifies the version number of the API which was
> >> executed. Experimental is only returned if the operator has made a
> >> modification to the API behaviour that is non standard. This is only
> >> intended to be a transitional mechanism while some functionality used
> >> by cloud operators is upstreamed and it will be removed within a small
> >> number of releases.
> >> "
> >>
> >> So if you have an extension that gets accepted upstream you can use the
> >> experimental flag until you migrate to the upstream version of the
> >> extension.
> >
> > Yes, but please note the last sentence in the quoted bit. This is to
> > help people clean their dirty laundry. Going forward, you shouldn't
> > expect to deliver features to your customers via this path.
> >
> >> That is *not* what I would call interoperability, this is exactly what
> >> we do not want.
> >
> > +1.
> 
> So for the case where a customer really wants some functionality, and wants
> it
> *soon* rather than waiting for it to get merged upstream, what is the
> recommended implementation path for a vendor?

Well, before all else the key is to at least propose it in the community and 
see what the appetite for it is. I think part of the problem here is that we're 
still discussing this mostly in the abstract, although you provided some high 
level examples in response to Sean the only link was to a review that merged 
the same day it was proposed (albeit in 2012). I'm interested in whether there 
is a specific proposal you can link to that you put forward in the past and it 
wasn't accepted or was held up or whether you are working on a preset 
assumption here?

Thanks,

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

Reply via email to