Mailing-List: contact libcloud-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: libcloud@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Sender: Jerry Chen <jerry@3rdengine.com>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Jerry Chen <jerry@apache.org>
In-Reply-To: <1291741983.31071.1409125783@webmail.messagingengine.com>
Date: Tue, 7 Dec 2010 16:27:37 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <60370794-5A10-4D5E-AB8F-3C40846DDD06@apache.org>
References: 
 <000901cb92cd$f9284cf0$eb78e6d0$@com.au><1291371821.23375.1408450327@webmail.messagingengine.com><001201cb92d5$4d093710$e71ba530$@com.au><82D13484-1CA8-4587-881E-0845313DF6EE@jaguNET.com><B490F786EDD38649B5CAD696945DF26B044FDC8488@MAILBLDG1.br.seisint.com>
 <B490F786EDD38649B5CAD696945DF26B0450081C22@MAILBLDG1.br.seisint.com>
 <1291741983.31071.1409125783@webmail.messagingengine.com>
To: libcloud@incubator.apache.org
Subject: Re: [libcloud] Project needs for TLP.


On Dec 7, 2010, at 11:13 AM, Upayavira wrote:

> I think you (and Jed) are making interesting points.
>=20
> 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.=20

> 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.=20

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=20

Cheers,
Jerry

> On Tue, 07 Dec 2010 11:55 -0500, "Schwartz, Philip Marc (LNG-BCT)"
> <Philip.Schwartz@lexisnexis.com> wrote:
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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).
>>=20
>> 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.
>>=20
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Thank You,
>> Philip Schwartz
>> Software Engineering
>> LexisNexis RIAG
>> O - 561 999 4472
>> C - 954 290 4024
>>=20
>> 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.
>>=20