Open Stack

----- Original Message -----
> From: "Chris Friesen" <chris.friesen at windriver.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Friday, March 27, 2015 4:48:52 PM
> Subject: Re: [openstack-dev] [nova] how to handle vendor-specific	API	microversions?
> 
> On 03/27/2015 01:40 PM, Steve Gordon wrote:
> > ----- Original Message -----
> >> From: "Chris Friesen" <chris.friesen at windriver.com>
> 
> >> 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?
> 
> Whoops...I had meant to link to "https://review.openstack.org/163060" and
> managed to miss the last character.  My bad.  The API change I was talking
> about
> has now been split out to "https://review.openstack.org/168418".

That makes a little more sense :).

> I haven't proposed any features (with spec/blueprint) for kilo or earlier.
> I'm
> planning on proposing some for the L release.  (Some are already in for
> review,
> though I realize they're not going to get attention until Kilo is out.)
> 
> I may be making invalid assumptions about how long it takes to get things
> done,
> but if so it's coloured by past experience.
> 
> Some examples:
> 
> I proposed a one-line trivial change in April of last year and it took almost
> 2
> months before anyone even looked at it.
> 
> I reported "https://bugs.launchpad.net/nova/+bug/1213224" in 2013 and it
> hasn't
> been fixed.
> 
> I opened "https://bugs.launchpad.net/nova/+bug/1289064" over a year ago,
> proposed a fix (which admittedly had flaws), then handed it off to someone
> else,
> then it bounced around a few other people and still isn't resolved.
> 
> I opened "https://bugs.launchpad.net/nova/+bug/1284719" over a year ago and
> it's
> not yet resolved.
> 
> I opened "https://bugs.launchpad.net/nova/+bug/1298690" a year ago and it
> hasn't
> been touched.
> 
> 
> Chris

I'm not going to pick these apart one by one but at a high level I guess fundamentally the expectation of a vendor that needs a fix to resolve a customer issue is they would drive resolution of it in the community directly, which means not just filing the bug but also owning the creation of patches and iteration in response to review feedback (and also backporting to stable if necessary/appropriate) etc.. It's not immediately clear if this was the case in the bugs listed above (or even a subset thereof), rather it seems like they were raised for the broader community to resolve at their leisure relative to everything else in the queue and handled accordingly. 

That's not to say raising bugs to track issues identified in downstream testing isn't helpful in and of itself, but if the desire is to ensure fast resolution then there is a deeper investment in terms of contributing to writing and reviewing code required.

Thanks,

Steve