On Dec 7, 2010, at 11:13 AM, Upayavira wrote: > I think you (and Jed) are making interesting points. > > It was difficult for Libcloud to accept the Java port, and difficult for > it not to.
Most eloquently put. > I wonder how much interest there is in the Java code here. Is there > enough to fork into a separate incubator podling? That would leave > libcloud (python) to carry on with its own development at its own rate. I think I've seen a couple of emails from Java Libcloud users but no one has stepped up to the plate for contributing to the Java codebase. > Philip, I think your assessments are reasonable, but some of the > approaches you suggest don't fit too well with an Apache style. We don't > tend to assign roles to individuals (even if they often tend to take > them). What I *would* encourage is folks other than Paul managing > releases. Paul has been great and a driving force, especially for releases, but we do need to empower other committers and contributors with the release procedure. To wit: - procedure/requirements for initiating a vote - tagging release in SVN - properly packaging - updating PyPI, Debian/Ubuntu aptitude - procedure for last-minute, post-release hotfixes > Also, while IRC can be a useful tool, it can be difficult if you happen > to be in the wrong timezone. (I've had times when I've had to join > concalls at 1am because of US and Philippino participation. Not fun). Overall I think increased activity on the mailing list or on IRC will be beneficial to the community. > All it really takes is for other folks in the community to start firing > forwards their ideas for how the project can grow and develop. Everyone > in the community is free to take a lead, with or without a role! +1 > Upayavira Cheers, Jerry > On Tue, 07 Dec 2010 11:55 -0500, "Schwartz, Philip Marc (LNG-BCT)" > <[email protected]> wrote: >> >> 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. >>
