[libcloud] Project needs for TLP.

["Schwartz, Philip Marc (LNG-BCT)" <Ph...@lexisnexis.com>]

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.

RE: [libcloud] Project needs for TLP.

["Schwartz, Philip Marc (LNG-BCT)" <Ph...@lexisnexis.com>]

I guess from here, the first thing needed is documentation for our release and svn procedures, along with commiting guide lines/coding standards. From there, we can start discussions on release periods and scheduling so we can try and focus the community on common goals.


Thank You,
Philip Schwartz
Software Engineering
LexisNexis RIAG
O - 561 999 4472
C - 954 290 4024

-----Original Message-----
From: Jerry Chen [mailto:jerry@3rdengine.com] On Behalf Of Jerry Chen
Sent: Tuesday, December 07, 2010 5:28 PM
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.
>
> 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)"
> <Ph...@lexisnexis.com> 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.
>>


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.

Re: [libcloud] Project needs for TLP.

[Jerry Chen <je...@apache.org>]

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)"
> <Ph...@lexisnexis.com> 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.
>> 

Re: [libcloud] Project needs for TLP.

[Upayavira <uv...@odoko.co.uk>]

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.

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.

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. 

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

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!

Upayavira 

On Tue, 07 Dec 2010 11:55 -0500, "Schwartz, Philip Marc (LNG-BCT)"
<Ph...@lexisnexis.com> 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.
> 

Re: [libcloud] Project needs for TLP.

[Matt Hogstrom <ma...@hogstrom.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Since the measure of a podling's readiness to graduate is the community and the PPMCs ability to deal with this kind of situation as an IPMC member I'd like to see this resolved and then the vote be taken again.  I don't particularly care if Java is accepted or not, I'm more interested to see if the community handle's itself in a respectful manner.  So far, so good.



On Dec 7, 2010, at 12:04 PM, Jed Smith wrote:

> All valid points.
> 
> Before we graduate, I'd like to see all of this taken care of. I'd almost
> reverse my vote to -1 in the graduation vote based on some of these
> revelations, but that is done. I do not, however, feel that we are ready to
> graduate without more participation and project direction from consensus
> instead of a single person. (That isn't negative to Paul in the slightest,
> as he's gotten us this far: I think we need feet to start running with,
> though.)
> 
> 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
>> ).
>> 
> 
> I don't know if we have enough of a committer base to perhaps to go Ant's
> level just yet, but I'm all for a bit more structure in decision making and
> consensus. We need documentation on what our goals are, how Paul does what
> he does, and a light structure for decision-making and voting.
> 
> 
>> 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 raced you with a message on this very point. I fully support it for the
> reasons given there.
> 
> 
>> I would now move that for future development and needs for graduation, we
>> should discuss redefining libcloud as a python library only
> 
> 
> I agree, but only *for now*. I would like to see Paul's vision (which I
> somewhat share) become more than a wispy dream before 1.0. This is part of
> the roadmap and long-term vision that I'd like to see put in place.
> 
> In short: let's organize before we even think about 0.5.0 and I believe that
> will definitely make us more ready for graduation.
> 
> -- 
> Jed Smith
> jed@jedsmith.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iEYEARECAAYFAkz/2vEACgkQMsHW7w8UO8HBAACgh66a78+EiNZ30uKXNa23d3D2
gssAmwfZ+HPIW01SXGCUM9qnat5xbO+7
=B0Gl
-----END PGP SIGNATURE-----

Re: [libcloud] Project needs for TLP.

[Jed Smith <je...@jedsmith.org>]

All valid points.

Before we graduate, I'd like to see all of this taken care of. I'd almost
reverse my vote to -1 in the graduation vote based on some of these
revelations, but that is done. I do not, however, feel that we are ready to
graduate without more participation and project direction from consensus
instead of a single person. (That isn't negative to Paul in the slightest,
as he's gotten us this far: I think we need feet to start running with,
though.)

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

I don't know if we have enough of a committer base to perhaps to go Ant's
level just yet, but I'm all for a bit more structure in decision making and
consensus. We need documentation on what our goals are, how Paul does what
he does, and a light structure for decision-making and voting.


> 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 raced you with a message on this very point. I fully support it for the
reasons given there.


> I would now move that for future development and needs for graduation, we
> should discuss redefining libcloud as a python library only


I agree, but only *for now*. I would like to see Paul's vision (which I
somewhat share) become more than a wispy dream before 1.0. This is part of
the roadmap and long-term vision that I'd like to see put in place.

In short: let's organize before we even think about 0.5.0 and I believe that
will definitely make us more ready for graduation.

-- 
Jed Smith
jed@jedsmith.org