Hi, I'm following this with interest, how is libcloud defined by the implementation language?
Right now we seem to have some people who would prefer not to add further language bindings beyond python (for pragmatiic/no-time, don't want to have distractions beyond getting the current implementation through incubation etc). There is a proposal of submitting a java version of libcloud to be under the same umbrella project as the current implementation. I don't see how adding a different language binding is going to cause a fragmented community, or prevent development going forward. Part of going through the incubation process is the fact that there will be more participants, with wider points of view and these will conflict. Resolving the conflicts allows teh gestalt community to form and this community then makes the decisions on how things progress within the project. Based on the correct way of resolving conflict in apache projects - I propose a vote - this removes all ambiguity and prevents accusations of back room deals etc. http://www.apache.org/foundation/voting.html libcloud is a python project and should remain purely python throughout incubation YES [ ] NO [ ] libcloud is a an abstraction interface for various cloud hosing service providers, the current implementation happens to be python, but other bindings for Java etc will make libclouds more convenient YES [ ] NO [ ] And for what it's worth, my (non-binding vote) libcloud is a python project and should remain purely python throughout incubation YES [ ] NO [x] (and by implication -0, I won't stand in the way and I will help with the python version even if the rest of the developers decide that this should be the only version of apache libclouds) libcloud is a an abstraction interface for various cloud hosing service providers, the current implementation happens to be python, but other bindings for Java etc will make libclouds more convenient to the userbase YES [x] (and by implication +1 - I'm happy to help provide alternative language versions of libcloud - my preferences being ruby/erlang/c) NO [ ] Thanks, Kev
