Open Stack

----- Original Message -----
> From: "Chris Friesen" <chris.friesen at windriver.com>
> To: openstack-dev at 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