incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Schwartz, Philip Marc (LNG-BCT)" <>
Subject [libcloud] Project needs for TLP.
Date Tue, 07 Dec 2010 16:55:52 GMT

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:

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.

View raw message