On Nov 7, 2011, at 4:23 PM, Monty Taylor wrote: > >> 2) Why does the PPB need to vote? Actually, what would the PPB be >> voting on (assuming the answer to #1 is "no")? > > Well, it would be effectively promoting several existing projects which > are managed in a few different places (rackspace, 4P, etc) to being more > "official" things that live in the OpenStack gerrit and are replicated > to repos in the openstack github org. I have the physical ability to > just do that - but it kind of felt like something that should get buy in > from someone officially. > >> 3) Why the requirement to have the same release schedule as the >> paired project? I would expect a client binding to change much less >> often than the underlying system (as I have seen with the >> Rackspace-specific swift bindings). > > I guess I'm arguing that proper client libraries are an essential part > of a release. If there isn't much to be done in them, then release day > will be really easy. :) (also, the other projects are adding API > features like gangbusters at the moment, so I think the client libs will > be under active dev at least until those settle down. > > (speaking of - should we grab the rackspace swift bindings and make a > python-swiftclient out of it?) > > On the other hand, we could keep it as it is for the other projects and > allow the PTL to decide. I'd be surprised if folks chose different > cycles for the client libs - but of the things I care about personally, > this is certainly one of the least.
Rackspace doesn't have any swift bindings because Rackspace doesn't sell swift. We have cloud files bindings (in many languages--which gets into another issue altogether), and they should work with most swift installations, but they also have Rackspace product-specific stuff in them. I would expect any other company that offers an full or partial openstack product and offers value-add features to it to offer and maintain their own bindings, too. I am a fan of official binding support as a separate project. My first instinct is that these would need to be managed by the same PTL as the associated project. I would be against one, unified client (although I would support packaging and distributing them together). Overall, I think official bindings are important. Of course they won't fit the needs of everybody, but most people will use them to interact with Openstack projects. I see no reason that each PTL can't make the decision to support one or more language bindings for their own project. Keeping the bindings separate from the core code seems like a good idea too. Seems like this is generally a good idea. I like it, and I think this should stay at the PTL level and doesn't need to involve the PPB. Thanks Monty, Joe, and Jim. --John
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
