I personally would like to avoid promoting things to core that aren't implementations of an abstraction - I know we've got DNS stuff that doesn't have an abstraction in core, but, again, personally, I don't much care for that. I'd be in favor of holding off on moving trove from labs->core until there's a "cloud db" abstraction a la compute/blobstore for RDS/trove to implement.
A. On Mon, Jul 29, 2013 at 1:13 PM, Matt Stephenson <[email protected]>wrote: > It sounds like a primary motivator is to widen the audience. We have many > providers and apis in labs that are more widely adopted. Historically this > hasn't been a major barrier to adoption overall. > > The goal of labs was to provide a place to release software that we still > feel is in flux overall. How stable is the overall API for this if we've > not really done much work on RDS lately to ensure that a unified API > between the two (long term) is possible without changing the api into the > trove provider? > > > On Mon, Jul 29, 2013 at 1:08 PM, Everett Toews > <[email protected]>wrote: > > > On Jul 29, 2013, at 2:03 PM, Matt Stephenson wrote: > > > > > We currently have an outstanding set of pull requests for this, prior > to > > us > > > discussing this on dev. I'm personally not in favor of promoting it at > > > this time because I feel it's a bit too immature at this time. > > > > Software gains maturity by being released to a wider audience and by > being > > used. And what we have here is more than a minimum viable product. It's > > complete, working support for the OpenStack Trove/Rackspace Cloud > Databases > > API. > > > > > We still > > > have a good deal of other apis that there is more demand for to be > > promoted > > > up. > > > > It's not an either/or situation amongst the APIs. If an API is complete, > > it can be promoted. > > > > > What value do we gain by promoting this as the only api of it's kind > into > > > jclouds now? > > > > We gain a wider audience. We gain the experience of seeing how people use > > it and what problems they run into. We gain the insights and experience > > that are necessary to create higher level abstractions. All of those > things > > that helps software mature. > > > > Just because an implementation from another provider isn't ready, doesn't > > mean we should hold back on releasing software. We need to start > somewhere. > > > > In general, the value of jclouds increases for our users because we'll > > have complete and maintained support for another cloud API. > > > > > Who in the community is using this in labs today? > > > > Naturally we (Rackspace) are. There are also examples and doc ready to > go. > > Having a "labs" label on something will prevent many from adopting it. > > > > > How comfortable are we as a community in supporting this and working on > > > issues related to it? > > > > I can say with complete conviction that, as a part of this community, > > Zack, Jeremy, and myself are 100% committed to supporting it and working > on > > issues related to it. > > > > Regards, > > Everett >
