Ant had valid concerns for not having libcloud go TLP and I feel we need to 
discuss them along with a few other things that I feel are holding the project.

Lets start with the project participation. Yes, Ant is right in the fact that 
90% of all interaction is handled by Paul at the moment and I think this is 
something that should be discussed and a clear plan of action should be 
outlined. Most other OSS projects I work with you see things a set listing of 
project members and responsibilities along with a voting community of core 
developers working on the project for all actions and review of committed 
code/tagging.

I think this should be our first course of action, vote in the community for 
yearly rotating positions for things like overall project management, code 
management, documentation management, etc. This would probably clear up most of 
Ant's concerns in its self. (also defining set roles for the project that 
follow the Apache way would be good, ex: http://ant.apache.org/bylaws.html).

The second part of this should be a set meeting schedule that could be done in 
irc where we can get as many of the community using and developers working on 
the project together to discuss the motion of the project and goals for each 
release, Monthly 30 min to 1 hour irc meetings might be more then enough for 
this.


Outside of project participation, there is one other topic that I think need 
further discussion. This is the Java portion of libcloud which is clearly not 
ready for TLP status. I would move for this to be removed from the libcloud 
project for its own project.

In the past Paul has stated that libcloud is a reference spec with an example 
implementation in Python. I think this is far from the case as all of the 
specification comes from the current Python code base. At this time it is more 
beneficial for libcloud to be a Python cloud library and not a reference 
specification. Yes, this makes things a little hairy for things based on what 
libcloud does, but that is why they are based on libcloud and not part of 
libcloud which I think has been missed in hindsight with the java code.

I would now move that for future development and needs for graduation, we 
should discuss redefining libcloud as a python library only so we can more 
finely focus on a defined library api that can be adapted for other projects 
such as a java implementation to be based on.

Thank You,
Philip Schwartz
Software Engineering
LexisNexis RIAG
O - 561 999 4472
C - 954 290 4024

This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and is protected by law.  If 
you are not the intended recipient, you should delete this message.  Any 
disclosure, copying, or distribution of this message, or the taking of any 
action based on it, is strictly prohibited.

Reply via email to