On 11/07/2011 03:12 PM, John Dickinson wrote: > > 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.
Awesome. I agree with everything that you have said. Thanks! Monty _______________________________________________ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
