It is not a hold up to TLP status, but without more support and drive for a java interface, there will always be a lack of community for it other then you Eric. That is not meant as any disrespect as you have been a strong driving factor in aspects of libcloud as a whole, but in order to gain ground and more support, I feel we need to focus on a singular system that can have a strong community. By no means should we get rid of your code, but I think a second project libcloud-java for example (yes, bad name) that would stay as an incubator project and be based on libcloud would be best for the community as a whole.
I know the original drive was for a standard api spec that can be used from any language, but I feel that is out of the scope for an Apache project and we should maybe even look to RFC it as a standard spec while libcloud focuses on a set implementation. At this time, this would be the Python implementation, not because it is a Python over java thing, but because of the level of competition of the Python code. I have no objections to having collaboration between the 2 projects, but I feel it would hold back the community at this time. What I purpose is the following. 1. Move the java implementation into a separate incubator project with a strong understanding that it is a implementation of an api spec as being developed by the libcloud project. 2. Get a spec complete that we can share with anyone on the web that would be interested in use. This will be more help in the long run along with having our goals as a standard out there for other projects to follow and even purpose RFC spec changes for as needed. RFC authoring guidelines: http://tools.ietf.org/html/rfc2223 3. Finish working out community participation and support issues as discussed earlier this week allowing for a new vote for TLP status unless the previous was sufficient. Thank You, Philip Schwartz Software Engineering LexisNexis RIAG O - 561 999 4472 C - 954 290 4024 -----Original Message----- From: Eric Woods [mailto:[email protected]] Sent: Thursday, December 09, 2010 9:59 AM To: [email protected] Subject: Re: [libcloud] Removal of the Java bindings I certainly don't want to hold up the graduation of libcloud to a TLP. I support libcloud's graduation. Libcloud's graduation is not a question of the code's readiness as much as it is the community's readiness. I do not think the Java work is doing harm by remaining in the sandbox, an approach the community previously came to consensus on. As Gav said, if we decide to remove the Java work in separate thread, that's fair enough, but libcloud's graduation should not be the driving force. It's the common model that is the strength of libcloud, not Python. The cloud industry is in need of common and interoperable way of interacting with various cloud resources, something libcloud has made great strides in defining & implementing. By removing the Java work, you will be eliminating a reference implementation in leu of a stand-alone Python project. By removing the Java implementation, this community will have one less diversified committer and will lose the prospect of a Java community. I do not think the Java project has a chance of being sustainable by itself; it's so tightly coupled with the Python implementation, both in design and in API. This is really the best place to keep the code as it can leverage libcloud's Python community to gain traction. It's also the logical place to keep the code to stay in sync with libcloud's API and design decisions. So, my preference is that the Java work remains a part of libcloud and to develop a clear roadmap of co-existance. With that said, if consensus is reached that the work should be removed, I will respectfully bow out. Kind regards, Eric On Dec 8, 2010, at 4:53 PM, Gav... wrote: > 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 status. > > 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.) > > Gav... >> -----Original Message----- >> From: Jed Smith [mailto:[email protected]] >> Sent: Tuesday, December 07, 2010 11:52 AM >> To: [email protected] >> 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 >> [email protected] >> >> 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. > > 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.
