incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gav..." <>
Subject RE: [libcloud] Removal of the Java bindings
Date Wed, 08 Dec 2010 21:53:57 GMT
I'm just replying to this part:

"... 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..."

I don't see anything in any documentation that states 'code' has to be ready
for TLP status.

This frankly is a load of crap, we are deciding whether the 'community' is
ready to go TLP, the state of the code is not in question. Not all of the
code has to be prime time polished and released perfect code to go to TLP

Leave the code where it is, discuss the community. The Java Bindings have
nothing to do with being TLP and will not affect any vote of such.

(If you later decide to fork/remove it for whatever reason, fair enough, but
don't mix it in with the current talks.)


> -----Original Message-----
> From: Schwartz, Philip Marc (LNG-BCT)
> []
> Sent: Wednesday, 8 December 2010 2:57 AM
> To:
> Subject: RE: [libcloud] Removal of the Java bindings
> My other message tied to this chain so not missed.
> 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
> -----Original Message-----
> From: Jed Smith []
> Sent: Tuesday, December 07, 2010 11:52 AM
> To:
> Subject: [libcloud] Removal of the Java bindings
> Good morning,
> Monitoring ant's concerns with our incubator graduation, I'd like to
> start by addressing the first one. (This message is intended to address
> two,
> actually: the Java port and, indirectly and subtly, committers not
> participating.)
> I somewhat agree with ant that we've been in a holding pattern with the
> Java bindings to libcloud.
> Allow me to preface this message by reiterating that Eric's
> contribution is valued and really great. It's good to see that libcloud
> could become more than a specific language's bindings; it could become
> a contract for a developer to work with clouds, regardless of
> implementation language. I would like to see development on this front,
> and I have ideas on how to do so. The timing simply isn't right, until
> we can put thought into how best to handle this - it's more
> documentation instead of outright code. Such development would
> ultimately change the vision of libcloud from a Python library to a
> metalibrary, and I don't want to approach that lightly.
> I move for the removal of the Java bindings from libcloud pending a
> plan for dealing with such alternate bindings. The development is
> welcome to continue outside of the umbrella of libcloud as it stands
> today; I believe a name change would be requisite, but I do not know
> the best way to handle that (Eric?). If Eric would like to take it in a
> different direction altogether once separated from us, I would actually
> encourage that as open source should never be restrained, it should be
> allowed to flourish.
> Regardless of whether this severance is positive or not, I know that
> the libcloud community wishes Eric the best of luck. Based upon Eric's
> posts, I believe he will see that this is good for both of us, too - I
> certainly don't intend any ill will or malice or hard feelings! If
> Eric's Java port became a freestanding project of its own with its own
> community, I'd be pleased as punch. In the future, perhaps we can
> formulate a plan to reintegrate, and I know that we'd like that.
> Thoughts?
> /me pushes the ball down the hill
> --
> Jed Smith
> 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