openstack-poc team mailing list archive

[Joe Heck <Joe.Heck@xxxxxxxxxx>]

The reason I said "c" and not "b" is because there may be something in the future that we see that really, really needs to belong in the kernel of an OpenStack system. 

By choosing "B", categorically it seemed like an assertion that none of these 3rd party APIs (or plugins or whatever) could *ever* become core. And while I don't see that as beneficial now and for the examples we're talking about, I don't want to close down that possibility.

Right now we *do* have option "C" by my view and definitions, even though there's not a formal process. How did we "suddenly" start gating and testing against "devstack"? I don't think anyone here would disagree with it, but it's also not a formal project or process that went through any form of approval, incubation, etc. other than be damned useful on the technical side and providing a very clear value to getting a solid OpenStack product out the door. 

- joe

On May 6, 2012, at 9:01 AM, Jay Pipes wrote:
> On 05/05/2012 08:24 PM, John Dickinson wrote:
>> This is the second message on this thread that has said something to the effect of "there is great benefit to not having 'core' or 'official' or 'approved' parts of the ecosystem" (vs the "core" openstack projects). Yet in both of those messages, option "c" was chosen. How does that work? How is that not option "b"?
> 
> You are correct, John. I had confused c) with b)...
> 
> I am supporting option b):
> 
> "Standards Bodies/Developers: would prefer to have some recognition/discoverability for the new apis, currently the only path forward is to be in core, so they are pushing to be included, but they might be ok with some other type of recognition."
> 
> Best,
> -jay
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack-poc
> Post to     : openstack-poc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack-poc
> More help   : https://help.launchpad.net/ListHelp
>