I'm a fan of c), where the "officialness" is tied to a committed organization or team that is keeping the code up-to-date and tested. I'd also be a fan of making that a per-release designation, with an easy renewal if the commitment is still in place.
Generally, a smaller core with a "supported" status for satellite projects is my favorite model, for much of OpenStack development. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com "Oh, Westley, we'll never survive!" "Nonsense. You're only saying that because no one ever has." On Wednesday, May 2, 2012 at 3:02 PM, Vishvananda Ishaya wrote: > We discussed the policy on third party apis this week at the PPB meeting. We > decided to take it to the mailing list for discussion so we can get to some > reasonable things to vote on in next weeks meeting. > > tl; dr > > How do third party apis fit in OpenStack? > > Background > > This was inspired by the current proposals for OCCI and CDMI into nova and > swift and the upcoming work and proposals for CIMI for nova. The basic > question is: does this code belong in the core repositories and if not, where > does it go. I see a number of groups with interest in this. I'm going to > outline the major players and give my (biased) opinion on what they want > > a) Core Developers: would prefer to have these apis outside of core. It is > already a burden to maintain the existing apis, so separating these into > separate projects would be beneficial. > > 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. > > c) Deployers/Distributors: want an easy way to know that these external > plugins work well. This can be accomplished by testing/etc. Probably don't > really care too much about the new apis unless they get specific customer > requests > > d) Users: some users (scientific community) would love to have access to > these other apis. From a user perspective, the more apis the better, as long > as they are stable and all work. > > Current Proposals > > a) ppb doesn't care and the projects decide individually > > b) third party apis are not part of openstack core, and we focus on building > a strong ecosystem where these apis could exist as proxies or external > plugins. It is up to deployers to decide which ecosystem projects to include > in their distributions > > c) just like b, but there is additionally a process by which these third > party tools could become 'official' in some sense or be 'recommended' for > inclusion by the distros. > > d) third party standards are vetted for inclusion by the ppb and are added to > core projects assuming they can pass certain testing requirements > > e) we have our own api, so we shouldn't be encouraging 3rd party apis at all. > Tney are on their own. > > f) ??? > > Please discuss, > Vish > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack-poc > Post to : [email protected] > (mailto:[email protected]) > Unsubscribe : https://launchpad.net/~openstack-poc > More help : https://help.launchpad.net/ListHelp > > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack-poc Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
