I'd love to see openstack-common get off the ground, so I'm all in favor of this.
One question: why do you feel that you need such strong backwards compatibility? If someone makes a change in openstack-common and makes simultaneous changes in all OpenStack projects to match, isn’t that sufficient? Ewan. > -----Original Message----- > From: openstack-bounces+ewan.mellor=citrix....@lists.launchpad.net > [mailto:openstack-bounces+ewan.mellor=citrix....@lists.launchpad.net] > On Behalf Of Mark McLoughlin > Sent: 03 January 2012 08:58 > To: openstack@lists.launchpad.net > Cc: Jason Koelker > Subject: [Openstack] openstack-common > > Hey, > > As Jason says - another year, another openstack-common thread! :-) > > I've just written up the plan Jason and I have for openstack-common: > > http://wiki.openstack.org/CommonLibrary > > (also pasted below to make it easier to reply to) > > I guess what we're trying to do is quickly get this thing into good > enough shape to do a first release. Even if that release only contains > a > handful of APIs, but they meet the criteria below, then we'll have a > really solid foundation to build on. > > Thoughts? > > Cheers, > Mark. > > The openstack-common project intends to produce a python library > containing > infrastructure code shared by OpenStack projects. The APIs provided by > the > project should be high quality, stable, consistent and generally > useful. > > The existence of an API in openstack-common should be indicitative of > rough > consensus across the project on that API's design. New OpenStack > projects should > be able to use an API in the library safe in the knowledge that, by > doing so, > the project is being a good OpenStack citizen and building upon > established > best practice. > > To that end, a number of principles should be adhered to when > considering any > proposed API for openstack-common: > > 1) The API is generally useful and is a "good fit" - e.g. it doesn't > encode > some assumptions specific to the project it originated from, it > should > follow a style consistent with other openstack-common APIs and > should > fit generally in a theme like error handling, configuration > options, > time and date, notifications, WSGI, etc. > > 2) The API is already in use by a number of OpenStack projects > > 3) There is a commitment to adopt the API in all other OpenStack > projects > (where appropriate) and there are no known major blockers to that > adoption > > 4) The API represents the "rough consensus" across OpenStack projects > > 5) There is no other API in OpenStack competing for this "rough > consensus" > > 6) It should be possible for the API to evolve while continuing to > maintain > backwards compatibility with older versions for a reasonable > period - e.g. > compatibility with an API deprecated in release N may only be > removed in > release N+2 > > There have been several attempts at kick-starting openstack-common, > each attempt > beginning with moving a number of existing APIs from Glance or Nova > into a new > repository. None of these attempts have quite managed to reach the > point where > they were ready for other OpenStack projects to depend on the library. > > This proposal marks the beginning of yet another attempt. The idea is > to create > a new openstack-common repository, seed it with Jason Kölker's > excellent > infrastructure from his repository[1] and begin importing individual > APIs while applying the principles above during the review process for > each proposed API. > > [1] - https://github.com/jkoelker/openstack-common > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp