Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)

[Paul Querna]

On Tue, Nov 29, 2011 at 2:00 PM, Neha Narkhede  wrote:
> Hi,
>
> The context for this is the discussion here -
> http://markmail.org/message/rsxjgrrufc6khlqy?q=overhead+list:org.apache.incubator.general
>
> This was a long discussion with no clear answers.
>
> We would like to know if it is OK to either -
>
> 1. shorten the release VOTE for change to one non-code file
> 2. run 72 hour vote in parallel on the dev list as well as on general@
>
> What we would like to know is if any member would "-1" the vote if we
> choose to do either of the above ?

You can most definitely run the votes in parallel.  I did this for
almost all of the Libcloud releases while it was in incubator.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [Proposal]: Libcloud to become a TLP

[Paul Querna]

+1, I think Libcloud has sufficiently demostrated its understanding of
the Apache world,

Thanks

Paul

(A mentor of libcloud)

On Sat, May 14, 2011 at 5:35 PM, Tomaz Muraus  wrote:
> Hello all,
>
> Apache Libcloud developers and community thinks we are ready to graduate and
> become a top level project.
>
> Libcloud (http://incubator.apache.org/libcloud/) has entered the incubator
> in late 2009 and so far we have had multiple releases.
>
> The last version (0.4.2) was released in January. We are currently working
> towards 0.5.0 which is planned to be released in the upcoming week. This
> release is considered as a big one since it will include multiple new
> features (storage & load balancer API), new provider drivers and a lot of
> improvements.
>
> We have also built a healthy and a diverse community around our project. So
> far we have received (and continue to receive) multiple contributions from
> them.
>
> Community voting has passed with ten (10) +1's, zero (0) 0's and zero (0)
> -1's. Thread with the results can be found at
> http://mail-archives.apache.org/mod_mbox/incubator-libcloud/201105.mbox/browser
>
> Our status file can be found at
> http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/projects/libcloud.xmland
> the resolution is included bellow.
>
> <http://mail-archives.apache.org/mod_mbox/incubator-libcloud/201105.mbox/browser>
> Thanks,
> Tomaz
>
> Establish the Apache Libcloud Project
>
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software related to abstracting differences
> between cloud providers for distribution at no charge to
> the public.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Libcloud Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache Libcloud Project be and hereby is
> responsible for the creation and maintenance of software
> related to software providing a standard interface to the
> cloud provider APIs; and be it further
>
> RESOLVED, that the office of "Vice President, Apache Libcloud" be
> and hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair
> of the Apache Libcloud Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Libcloud Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Libcloud Project:
>
>  * Eric Woods (wood...@apache.org)
>  * Jed Smith (j...@apache.org)
>  * Jeremiah Orem(or...@apache.org)
>  * Jerry Chen (je...@apache.org)
>  * Roman Bogorodskiy (rbogorods...@apache.org)
>  * Tom Davis (t...@apache.org)
>  * Tomaz Muraus (to...@apache.org)
>  * Paul Querna (pque...@apache.org)
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Tomaz Muraus
> be appointed to the office of Vice President, Apache Libcloud, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification,
> or until a successor is appointed; and be it further
>
> RESOLVED, that the initial Apache Libcloud PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Libcloud Project; and be it further
>
> RESOLVED, that the Apache Libcloud Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Libcloud podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Libcloud podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [libcloud] Re: [VOTE] Release Apache Libcloud 0.4.2

[Paul Querna]

Poke to general@ people, we need more IPMC votes for this release to happen :(

On Mon, Jan 10, 2011 at 10:00 PM, Jerry Chen  wrote:
> Hi all,
>
> With 6x +1 votes (including 2 binding), and no -1 votes, the vote seeks the 
> approval of the IPMC.
>
> Thanks,
> Jerry
>
> On Jan 8, 2011, at 12:10 AM, Jerry Chen wrote:
>
>> Hi all,
>>
>> Test tarballs for Apache Libcloud 0.4.2 are available at:
>> 
>>
>> Please test and place your votes:
>>
>> +/- 1
>> [  ]  Release Apache Libcloud 0.4.2
>>
>> Vote closes on Sunday January 9, 2011 at 10pm PST.
>>
>> This release includes the EC2NodeLocations fix to restore backward 
>> compatibility in the EC2 driver, as well as new drivers, improvements to 
>> deployment capabilities, and libcloud.security module for SSL certificate 
>> verification.
>>
>> For more information on SSL verification:
>> 
>>
>> For the full list of changes, see:
>> 
>>
>> Cheers,
>> Jerry
>
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Libcloud 0.4.0

[Paul Querna]

With 9x +1s, (at least 3 binding), and no -1s, vote passes, I'll push
the tarballs to the mirrors and plan on the announcement email
tomorrow.

Thanks everyone,

Paul

On Wed, Oct 6, 2010 at 1:36 PM, Paul Querna  wrote:
> Test tarballs for Apache Libcloud 0.4.0 are available at:
>  <http://people.apache.org/~pquerna/dev/libcloud-0.4.0/>
>
> Please test and place your votes please;
>
>  +/- 1
>  [  ]  Release Apache Libcloud 0.4.0
>
> Vote closes on Monday October 11, 2010 at 10am PST.
>
> This is our first release of the 0.4 and trunk for a couple months, it
> includes many bug fixes, a few new features, and removal of the
> dependency on Zope.Interface.
>
> It is based upon this tag:
>  <https://svn.apache.org/repos/asf/incubator/libcloud/tags/0.4.0>
>
> Thanks,
>
> Paul
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Release guidelines for python and php libraries?

[Paul Querna]

On Thu, Oct 7, 2010 at 9:40 AM, Nick Burch  wrote:
> Hi All
>
> Does anyone happen to know of some pre-existing release guidelines for
> python or php libraries, either in an apache TLP or a podling? For Chemistry
> we've got the docs sorted for maven-based releases of the java codeline, and
> now we're looking to sort something similar for our python and php
> codebases.
>
> Any tips, references and best practices to avoid reinventing the wheel would
> be most handy!

For libcloud, we use python's native setup tools to do everything.

Things to look at...

release.sh: this invokes setup.py to build out source tarballs and
then uses the hash/sign script to make the gpg/asc/sha1/md5s:


setup.py: contains lots of metadata about the project, where it is,
license, etc:


After a release vote is successful, I've also been uploading the
tarballs to PyPi:


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Libcloud 0.4.0

[Paul Querna]

On Wed, Oct 6, 2010 at 1:36 PM, Paul Querna  wrote:
> Test tarballs for Apache Libcloud 0.4.0 are available at:
>  <http://people.apache.org/~pquerna/dev/libcloud-0.4.0/>
>
> Please test and place your votes please;
>
>  +/- 1
>  [  ]  Release Apache Libcloud 0.4.0
>
> Vote closes on Monday October 11, 2010 at 10am PST.

FTR, +1 from me.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Release Apache Libcloud 0.4.0

[Paul Querna]

Test tarballs for Apache Libcloud 0.4.0 are available at:
  

Please test and place your votes please;

 +/- 1
 [  ]  Release Apache Libcloud 0.4.0

Vote closes on Monday October 11, 2010 at 10am PST.

This is our first release of the 0.4 and trunk for a couple months, it
includes many bug fixes, a few new features, and removal of the
dependency on Zope.Interface.

It is based upon this tag:
  

Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator proposal template

[Paul Querna]

On Sat, May 29, 2010 at 2:05 PM, Joe Schaefer  wrote:
>
>
> - Original Message 
>
>> From: Upayavira 
>> To: general@incubator.apache.org
>> Sent: Sat, May 29, 2010 4:58:21 PM
>> Subject: Re: Incubator proposal template
>>
>> On Sat, 2010-05-29 at 08:08 -0700, Joe Schaefer wrote:
>> I really don't see the upshot, because after a while
>> people will mostly be "plagarizing" the earlier answers
>> of others.
>
>> I'd prefer the questions were positively framed, rather than 'how are
>> you going to avoid this pitfall', but I do get the fact that they're
>> likely to soon enough be re-arrangements of previous attempts.
>
> Frankly the whole idea seems misdirected at incoming projects,
> when it should be directed at incoming mentors.  Projects aren't
> expected to grok the Apache Way when they arrive here, they're
> supposed to learn about it over their tenure in the incubator.

Very much agree on this!  Turning proposals into open essays about the
apache way is a waste of the potential project's time -- they either
don't know anything, or the proposal is being written by their
champion anyways.  I would much rather focus on how we can improve the
interaction, and number of active mentors with incubating projects,
than to add another question to the proposal template.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Cross Cloud TLP, was Re: [PROPOSAL] Deltacloud Project

[Paul Querna]

On Wed, May 12, 2010 at 12:16 PM, Craig L Russell
 wrote:
> For me, not so much.
>
> A TLP owns a code base and is responsible for it. While I appreciate the
> sentiment, I don't think it's wise to require that different communities
> with nothing else in common except "cloud" in their name have to be managed
> by the same PMC.
>
> How is "cloud" different from "xml" or "java" or "web" or "database"? We
> have many communities in Apache that share buzzwords yet have different
> approaches.

Right, I think the 3 projects we are talking about can be broken down
into simple lines:

- deltacloud: portable cloud library (with a http interface)
- libcloud: portable cloud library (with a python interface)
- whirr: scripts & tools built on top of the previous two (or other tools)

But my point is not so much about the buzz-wordyness of 'cloud', it
was more about overlapping:
  - committers
  - community concerns:
- cloud portability
- access to APIs and documentation

To me, the set of the community interested in these things will be
similar, and one TLP to wrap them up in that sense makes sense to me,
we have dozens of examples of TLPs with multipe products, and not all
of them are *bad* TLPs.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Libcloud 0.3.1

[Paul Querna]

Vote has ended:
ipmc binding +1 from: ant, matt hogstorm, pquerna, gavin
other +1s from: oremj, polvi, cicero, tdavis, eric woods,
non-binding -1 from sebb

The vote passes. Apache Libcloud 0.3.1 is released. I'm pushing it out
to the dist website now, and will post the announcement email in about
a day once the mirrors sync.

Thanks Everyone,

Paul


On Thu, May 6, 2010 at 4:09 PM, Paul Querna  wrote:
> Test tarballs for Apache Libcloud 0.3.1 are available at:
>  <http://people.apache.org/~pquerna/libcloud-0.3.1/>
>
> Please test and place your votes please;
>
>  +/- 1
>  [  ]  Release Apache Libcloud 0.3.1
>
> Vote closes on Monday May 10, 2010 at 1pm PST.
>
> This release fixes several issues related to the license blocks,
> NOTICE file, and test cases that were noticed in the scrubbed 0.3.0
> release.
>
> It is based upon this tag:
> <https://svn.apache.org/repos/asf/incubator/libcloud/tags/0.3.1>
>
> Thanks,
>
> Paul
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Libcloud 0.3.1

[Paul Querna]

FTR, +1 from me.

On Thu, May 6, 2010 at 4:09 PM, Paul Querna  wrote:
> Test tarballs for Apache Libcloud 0.3.1 are available at:
>  <http://people.apache.org/~pquerna/libcloud-0.3.1/>
>
> Please test and place your votes please;
>
>  +/- 1
>  [  ]  Release Apache Libcloud 0.3.1
>
> Vote closes on Monday May 10, 2010 at 1pm PST.
>
> This release fixes several issues related to the license blocks,
> NOTICE file, and test cases that were noticed in the scrubbed 0.3.0
> release.
>
> It is based upon this tag:
> <https://svn.apache.org/repos/asf/incubator/libcloud/tags/0.3.1>
>
> Thanks,
>
> Paul
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Libcloud 0.3.1

[Paul Querna]

On Sat, May 8, 2010 at 3:41 AM, sebb  wrote:
> On 08/05/2010, sebb  wrote:
>> On 08/05/2010, Paul Querna  wrote:
>>  > On Fri, May 7, 2010 at 6:04 PM, sebb  wrote:
>>  >  > On 08/05/2010, Paul Querna  wrote:
>>  >  >> On Fri, May 7, 2010 at 5:33 PM, sebb  wrote:
>>  >  >>  > On 07/05/2010, Paul Querna  wrote:
>>  >  >>  >> On Fri, May 7, 2010 at 3:48 AM, sebb  wrote:
>>  >  >>  >>  > On 07/05/2010, Paul Querna  wrote:
>>  >  >>  >>  >> Test tarballs for Apache Libcloud 0.3.1 are available at:
>>  >  >>  >>  >>   <http://people.apache.org/~pquerna/libcloud-0.3.1/>
>>  >  >>  >>  >
>>  >  >>  >>  > Where is the KEYS file?
>>  >  >>  >>
>>  >  >>  >>
>>  >  >>  >> http://www.apache.org/dist/incubator/libcloud/KEYS
>>  >  >>  >>
>>  >  >>  >>
>>  >  >>  >>  > The directory structures of the bz2 and zip archives are 
>> different - the file
>>  >  >>  >>  > r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json
>>  >  >>  >>  > is in a different place in the archives. The bz2 archive needs 
>> to be corrected.
>>  >  >>  >>
>>  >  >>  >>
>>  >  >>  >> I don't understand what or why this is a problem.   We use 
>> python's
>>  >  >>  >>  distutils to create both the zip file and the tarbz2 from the 
>> same
>>  >  >>  >>  export of the 0.3.0 source.  The order of a file in a tar-strream
>>  >  >>  >>  compared to a zip shouldn't matter in material way that I can 
>> think
>>  >  >>  >>  of.
>>  >  >>  >>
>>  >  >>  >
>>  >  >>  > It's not the order that is the problem - the directory structure 
>> is different.
>>  >  >>  > The file is in a different directory in the two archives.
>>  >  >>
>>  >  >>
>>  >  >>
>>  >  >> $ find . -name 
>> r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json
>>  >  >>  
>> ./tar/apache-libcloud-0.3.1/test/fixtures/rimuhosting/r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json
>>  >  >>  
>> ./zip/apache-libcloud-0.3.1/test/fixtures/rimuhosting/r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json
>>  >  >>
>>  >  >>  I am unable to reproduce this problem on osx using the command line
>>  >  >>  tar and unzip tools?
>>  >  >>
>>  >  >>  How are you extracting the tarball/zip file?
>>  >  >
>>  >  > Using an Ant script which uses:
>>  >  >
>>  >  >    
>>  >  >    
>>  >  >    
>>  >  >
>>  >  > with the appropriate settings.
>>  >  >
>>  >  > In the expanded bz2 archive, the file is in:
>>  >  >
>>  >  > test\fixtures\rimuhosting
>>  >  >
>>  >  > This is in parallel with
>>  >  > apache-libcloud-0.3.1
>>  >  > under which all the other files appear.
>>  >  >
>>  >  > whereas in the expanded zip archive, the file is in:
>>  >  >
>>  >  > apache-libcloud-0.3.1\test\fixtures\rimuhosting
>>  >  >
>>  >  > I don't know whether it is relevant, but the file name is
>>  >  > significantly longer than any of the others.
>>  >
>>  >
>>  > its a bug in ant:
>>  >  https://issues.apache.org/bugzilla/show_bug.cgi?id=41924
>>
>>
>> Ah - did not know about that.
>>  It seems Winzip 9.0 has the same problem reading the tar file.
>>
>>  Might perhaps be worth renaming the file if that is possible?
>
> Or use a different tool to create the tar - I just tried using Ant to
> create the tar file with  longfile="gnu", and the resulting tar file
> is readable with both Ant and Winzip.
>
> Although using Ant creates an additional dependency, Ant is very commonly 
> used.
> Also, Ant is cross-platform, unlike the current build tool.

libcloud will not be using ant to build its packages.

python distutils are the standard for python projects.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Libcloud 0.3.1

[Paul Querna]

On Fri, May 7, 2010 at 6:04 PM, sebb  wrote:
> On 08/05/2010, Paul Querna  wrote:
>> On Fri, May 7, 2010 at 5:33 PM, sebb  wrote:
>>  > On 07/05/2010, Paul Querna  wrote:
>>  >> On Fri, May 7, 2010 at 3:48 AM, sebb  wrote:
>>  >>  > On 07/05/2010, Paul Querna  wrote:
>>  >>  >> Test tarballs for Apache Libcloud 0.3.1 are available at:
>>  >>  >>   <http://people.apache.org/~pquerna/libcloud-0.3.1/>
>>  >>  >
>>  >>  > Where is the KEYS file?
>>  >>
>>  >>
>>  >> http://www.apache.org/dist/incubator/libcloud/KEYS
>>  >>
>>  >>
>>  >>  > The directory structures of the bz2 and zip archives are different - 
>> the file
>>  >>  > r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json
>>  >>  > is in a different place in the archives. The bz2 archive needs to be 
>> corrected.
>>  >>
>>  >>
>>  >> I don't understand what or why this is a problem.   We use python's
>>  >>  distutils to create both the zip file and the tarbz2 from the same
>>  >>  export of the 0.3.0 source.  The order of a file in a tar-strream
>>  >>  compared to a zip shouldn't matter in material way that I can think
>>  >>  of.
>>  >>
>>  >
>>  > It's not the order that is the problem - the directory structure is 
>> different.
>>  > The file is in a different directory in the two archives.
>>
>>
>>
>> $ find . -name r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json
>>  ./tar/apache-libcloud-0.3.1/test/fixtures/rimuhosting/r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json
>>  ./zip/apache-libcloud-0.3.1/test/fixtures/rimuhosting/r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json
>>
>>  I am unable to reproduce this problem on osx using the command line
>>  tar and unzip tools?
>>
>>  How are you extracting the tarball/zip file?
>
> Using an Ant script which uses:
>
>    
>    
>    
>
> with the appropriate settings.
>
> In the expanded bz2 archive, the file is in:
>
> test\fixtures\rimuhosting
>
> This is in parallel with
> apache-libcloud-0.3.1
> under which all the other files appear.
>
> whereas in the expanded zip archive, the file is in:
>
> apache-libcloud-0.3.1\test\fixtures\rimuhosting
>
> I don't know whether it is relevant, but the file name is
> significantly longer than any of the others.

its a bug in ant:
https://issues.apache.org/bugzilla/show_bug.cgi?id=41924

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Libcloud 0.3.1

[Paul Querna]

On Fri, May 7, 2010 at 5:33 PM, sebb  wrote:
> On 07/05/2010, Paul Querna  wrote:
>> On Fri, May 7, 2010 at 3:48 AM, sebb  wrote:
>>  > On 07/05/2010, Paul Querna  wrote:
>>  >> Test tarballs for Apache Libcloud 0.3.1 are available at:
>>  >>   <http://people.apache.org/~pquerna/libcloud-0.3.1/>
>>  >
>>  > Where is the KEYS file?
>>
>>
>> http://www.apache.org/dist/incubator/libcloud/KEYS
>>
>>
>>  > The directory structures of the bz2 and zip archives are different - the 
>> file
>>  > r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json
>>  > is in a different place in the archives. The bz2 archive needs to be 
>> corrected.
>>
>>
>> I don't understand what or why this is a problem.   We use python's
>>  distutils to create both the zip file and the tarbz2 from the same
>>  export of the 0.3.0 source.  The order of a file in a tar-strream
>>  compared to a zip shouldn't matter in material way that I can think
>>  of.
>>
>
> It's not the order that is the problem - the directory structure is different.
> The file is in a different directory in the two archives.


$ find . -name r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json
./tar/apache-libcloud-0.3.1/test/fixtures/rimuhosting/r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json
./zip/apache-libcloud-0.3.1/test/fixtures/rimuhosting/r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json

I am unable to reproduce this problem on osx using the command line
tar and unzip tools?

How are you extracting the tarball/zip file?

Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Libcloud 0.3.1

[Paul Querna]

On Fri, May 7, 2010 at 3:48 AM, sebb  wrote:
> On 07/05/2010, Paul Querna  wrote:
>> Test tarballs for Apache Libcloud 0.3.1 are available at:
>>   <http://people.apache.org/~pquerna/libcloud-0.3.1/>
>
> Where is the KEYS file?

http://www.apache.org/dist/incubator/libcloud/KEYS

> The directory structures of the bz2 and zip archives are different - the file
> r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json
> is in a different place in the archives. The bz2 archive needs to be 
> corrected.

I don't understand what or why this is a problem.   We use python's
distutils to create both the zip file and the tarbz2 from the same
export of the 0.3.0 source.  The order of a file in a tar-strream
compared to a zip shouldn't matter in material way that I can think
of.

> The XML files under fixtures should have AL headers.
> As far as I can tell, adding such comments does not affect the test cases.

We are not adding license blocks to test case fixtures that are
response bodies from APIs.

> -1
>
> Minor problem:
>
> There is no mention of the dependency on zope.
>
>>  Please test and place your votes please;
>>
>>   +/- 1
>>   [  ]  Release Apache Libcloud 0.3.1
>>
>>  Vote closes on Monday May 10, 2010 at 1pm PST.
>>
>>  This release fixes several issues related to the license blocks,
>>  NOTICE file, and test cases that were noticed in the scrubbed 0.3.0
>>  release.
>>
>>  It is based upon this tag:
>>  <https://svn.apache.org/repos/asf/incubator/libcloud/tags/0.3.1>
>>
>>  Thanks,
>>
>>  Paul
>>
>>  -
>>  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>  For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Release Apache Libcloud 0.3.1

[Paul Querna]

Test tarballs for Apache Libcloud 0.3.1 are available at:
 

Please test and place your votes please;

 +/- 1
 [  ]  Release Apache Libcloud 0.3.1

Vote closes on Monday May 10, 2010 at 1pm PST.

This release fixes several issues related to the license blocks,
NOTICE file, and test cases that were noticed in the scrubbed 0.3.0
release.

It is based upon this tag:


Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Libcloud 0.3.0

[Paul Querna]

On Thu, May 6, 2010 at 2:59 PM, sebb  wrote:
> On 06/05/2010, Paul Querna  wrote:
>> On Thu, May 6, 2010 at 2:24 PM, Paul Querna  wrote:
>>  > On Thu, May 6, 2010 at 2:20 PM, sebb  wrote:
>>  >> On 06/05/2010, Paul Querna  wrote:
>>  >>> The Apache Libcloud project is currently voting on our second release,
>>  >>>  0.3.0.  As required by Incubator policy, we need IPMC approval for
>>  >>>  this release.  There is a concurrent release vote ongoing on
>>  >>>  .
>>  >>>
>>  >>>  The current (passing) RAT output can be seen at:
>>  >>>  <http://ci.apache.org/projects/libcloud/rat-output.txt>
>>  >>
>>  >> Which does not include many of the files in the release archive - e.g
>>  >> none of the fixtures are included.
>>  >>
>>  >> I checked a few of these, and none of the json or XML files had AL 
>> headers.
>>  >
>>  > These are in the .ratignore, because all of these are test fixtures,
>>  > returning raw data from API providers for the test cases, so adding AL
>>  > headers would invalidate the tests.
>>
>
> Is that true of *all* the fixture files?

Yes.  They are all used by our MockHTTPLayer as raw response bodies --
adding license blocks to them would make them different from what the
providers return.

>> To be clear, the tarball doesn't include the .ratignore file, so I'm
>>  not sure running RAT over the generated tarballs will produce the
>>  expected results.
>>
>>  The best test would be to run
>>  svn checkout https://svn.apache.org/repos/asf/incubator/libcloud/tags/0.3.0
>>  libcloud-0.3.0
>>
>>  and run RAT from there.
>>
>>  As documented in HACKING, the actual release tarballs are generated by
>>  dist/release.sh, which doesn't include developer releated files like
>>  .ratignore and .gitignore.
>
> There is still the problem of the incorrect NOTICE file.

I've fixed it in trunk:
http://svn.apache.org/repos/asf/incubator/libcloud/trunk/NOTICE

With just the NOTICE issue, do you maintain a -1 vote?

> Also, I could not run the test suite:
>
>> python setup.py test
> running test
> Traceback (most recent call last):
>  File "setup.py", line 98, in 
>    'Topic :: Software Development :: Libraries :: Python Modules'
>  File "c:\python26\lib\distutils\core.py", line 152, in setup
>    dist.run_commands()
>  File "c:\python26\lib\distutils\dist.py", line 975, in run_commands
>    self.run_command(cmd)
>  File "c:\python26\lib\distutils\dist.py", line 995, in run_command
>    cmd_obj.run()
>  File "setup.py", line 45, in run
>    tests = TestLoader().loadTestsFromNames(testfiles)
>  File "c:\python26\lib\unittest.py", line 613, in loadTestsFromNames
>    suites = [self.loadTestsFromName(name, module) for name in names]
>  File "c:\python26\lib\unittest.py", line 576, in loadTestsFromName
>    module = __import__('.'.join(parts_copy))
>  File "D:\ReleaseCheck\apache-libcloud-0.3.0\test\__init__.py", line
> 19, in 
>    from libcloud.base import Node, NodeImage, NodeLocation
>  File "D:\ReleaseCheck\apache-libcloud-0.3.0\libcloud\base.py", line
> 21, in 
>    from zope import interface
> ImportError: No module named zope

libcloud depends on zope interface for defining and validating that
the python APIs are consistent between drivers:
http://pypi.python.org/pypi/zope.interface
easy_install zope.interface

In addition, to my knowledge, no one actually tests or run libcloud on
windows, so any bug reports there would be great to add to JIRA,

Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Libcloud 0.3.0

[Paul Querna]

On Thu, May 6, 2010 at 2:24 PM, Paul Querna  wrote:
> On Thu, May 6, 2010 at 2:20 PM, sebb  wrote:
>> On 06/05/2010, Paul Querna  wrote:
>>> The Apache Libcloud project is currently voting on our second release,
>>>  0.3.0.  As required by Incubator policy, we need IPMC approval for
>>>  this release.  There is a concurrent release vote ongoing on
>>>  .
>>>
>>>  The current (passing) RAT output can be seen at:
>>>  <http://ci.apache.org/projects/libcloud/rat-output.txt>
>>
>> Which does not include many of the files in the release archive - e.g
>> none of the fixtures are included.
>>
>> I checked a few of these, and none of the json or XML files had AL headers.
>
> These are in the .ratignore, because all of these are test fixtures,
> returning raw data from API providers for the test cases, so adding AL
> headers would invalidate the tests.

To be clear, the tarball doesn't include the .ratignore file, so I'm
not sure running RAT over the generated tarballs will produce the
expected results.

The best test would be to run
svn checkout https://svn.apache.org/repos/asf/incubator/libcloud/tags/0.3.0
libcloud-0.3.0

and run RAT from there.

As documented in HACKING, the actual release tarballs are generated by
dist/release.sh, which doesn't include developer releated files like
.ratignore and .gitignore.

Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Libcloud 0.3.0

[Paul Querna]

On Thu, May 6, 2010 at 2:20 PM, sebb  wrote:
> On 06/05/2010, Paul Querna  wrote:
>> The Apache Libcloud project is currently voting on our second release,
>>  0.3.0.  As required by Incubator policy, we need IPMC approval for
>>  this release.  There is a concurrent release vote ongoing on
>>  .
>>
>>  The current (passing) RAT output can be seen at:
>>  <http://ci.apache.org/projects/libcloud/rat-output.txt>
>
> Which does not include many of the files in the release archive - e.g
> none of the fixtures are included.
>
> I checked a few of these, and none of the json or XML files had AL headers.

These are in the .ratignore, because all of these are test fixtures,
returning raw data from API providers for the test cases, so adding AL
headers would invalidate the tests.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Release Apache Libcloud 0.3.0

[Paul Querna]

The Apache Libcloud project is currently voting on our second release,
0.3.0.  As required by Incubator policy, we need IPMC approval for
this release.  There is a concurrent release vote ongoing on
.

The current (passing) RAT output can be seen at:


--

Test tarballs for Apache Libcloud 0.3.0 are available at:
 

Please test and place your votes please;

 +/- 1
 [  ]  Release Apache Libcloud 0.3.0

Vote closes on Monday May 10, 2010 at 1pm PST.

Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Deltacloud Project

[Paul Querna]

On Thu, May 6, 2010 at 12:53 PM, Mattmann, Chris A (388J)
 wrote:
> Hi Guys,
>
> Question: what¹s the relationship of this proposal to Whirr, which we¹re
> currently voting [1] on?

Whirr would be built on top of Deltacloud or Libcloud -- Whirr is more
about 'end user' scripts and tools to manage products, while
deltacloud and libcloud are both more low level tools and libraries to
build on top of.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Cross Cloud TLP, was Re: [PROPOSAL] Deltacloud Project

[Paul Querna]

On Thu, May 6, 2010 at 12:41 PM, David Lutterkort  wrote:
> Hi,
>
> I would like to propose the Deltacloud API[1] for addition to the Apache
> incubator.

Awesome!

> I have added the initial proposal to the Wiki[2]; it is also included
> below for convenience.
>
> There are a few additional people that have expressed interest in
> becoming initial committers; I am waiting for their express consent to
> list them as committers, and will add them to the Wiki as I get that.
>
> We are looking forward to any and all feedback and/or questions on the
> proposal. We already have two mentors, but would very much welcome
> additional volunteers to help steer Deltacloud through the incubation
> process.

I think Deltacloud can stand on its own, and for purposes of the
voting into the Incubator, should ignore the existing libcloud
project.

Libcloud however is getting closer to being able to Graduate.
(hopefully in may/june?).

I think it does raise the question, should libcloud graduate to a new
TLP, with a more generic task or providing "cross cloud" APIs and
libraries.

Libcloud is already moving a little beyond just APIs, with the current
discussions around a portable image format, and beyond just python
with another discussion of a possible Java port of the library.

Deltacloud does have some overlap in comitter-ship too, and I think
fundamentally both communities share very similar interests, even if
the implementations are different languages.

Thoughts?

Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Approve the release of apache-trafficserver-incubating-2.0.0-alpha

[Paul Querna]

On Mon, Mar 8, 2010 at 4:09 PM, ant elder  wrote:
> I had a look. Unfortunately the main release artifact
> apache-trafficserver-incubating-2.0.0-alpha.tar.bz2 is missing the top
> level LICENSE and NOTICE files. Those are mentioned in the README and
> do look like they're in SVN so maybe there is just a problem with the
> release build, but they are a requirement of every artifact being
> released so i think you'll need a respin to fix that.


http://people.apache.org/~zwoop/apache-trafficserver-incubating-2.0.0-alpha.tar.bz2

Are you sure you got the right file?  I just extracted it and it does
contain the NOTICE and LICENSE files?

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Subversion podling for graduation

[Paul Querna]

On Thu, Feb 11, 2010 at 8:08 PM, Greg Stein  wrote:
> Hello all,
>
> I started a discussion thread a week-ish ago to seek out issues for
> Subversion's graduation. The couple bits that were raised[1] have been
> handled, I believe. So with that said, I am unaware of any potential
> showstoppers, and would like to request a vote for graduating the
> Subversion podling. Should this result in a successful vote, I will
> put a resolution before the Board (for its Feb 17 mtg) to construct a
> new Subversion PMC.
>
> Please vote:
>
> [ ] +1 Graduation
> [ ] -1 Hold, and continue incubating

+1,

thanks,

paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Release Apache libcloud 0.2.0

[Paul Querna]

The Apache Libcloud project is currently voting on our first release,
0.2.0.  As required by Incubator policy, we need IPMC approval for
this release.  There is a concurrent release vote ongoing on
.

The current (passing) RAT output can be seen at:


Test tarballs for Apache Libcloud 0.2.0 are available at:
  

Please test and place your votes please;

 +/- 1
 [  ]  Release Apache Libcloud 0.2.0

Vote closes on Monday February 15, 2010 at 1pm PST.

Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Checking status of "transfer rights" ?

[Paul Querna]

On Mon, Feb 8, 2010 at 8:49 AM, Leif Hedstrom  wrote:
> Hi,
>
> sorry if this is not the right channel for this question, but, I'd like to
> find out if ASF has received any paperworks from Yahoo!, showing that we've
> transfered the rights for Traffic Server code to ASF. If not, is there a
> form that they need to fill out and submit?

There hasn't been a CCLA, but all of traffic servers commits have been
covered by iCLAs of the comitters, so no, Yahoo does not need to do
anything else.

> Also, I know we still need to transfer some TM over to ASF as well, but that
> is still being worked on. I'd assume transfer of these remaining TMs (most
> have expired already, including the one in the US) is a prerequisite for
> doing an official Apache Traffic Server release?

I honestly don't think we should block doing a release on this, if
Yahoo sues us over the TM, well... heh, it just doesn't make sense.

Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Source code dumps via JIRA?

[Paul Querna]

For most projects they just put a URL in the jira, and Joe just  
imports it.



Sent from my iPhone

On Feb 8, 2010, at 9:22 PM, Justin Erenkrantz   
wrote:



For OODT, we think we want to import the prior history of the project
into the podling via a Subversion dump file. However, in:

http://incubator.apache.org/guides/mentor.html#initial-import-code- 
dump


it says:

---
In either case, the code to be imported should be attached to a JIRA
and then imported. It is recommended that the previous version control
system is tagged so that the imported version is precisely known.

A public record MUST be made of the code imported. If the import is
not attached to JIRA then it MUST be committed to version control.
---

I can understand the rationale for having a public record, but I'm not
seeing the reasoning for JIRA.

Can someone please shed some light on this?  Is this really reflective
of actual best practices?

As a counter-example, I'd believe providing a URL to the dump (or
uploading it to people.a.o) and providing a SHA checksum via email
(PGP-signed?) would be sufficient for our purposes.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Switching incubator.apache.org to svnpubsub?

[Paul Querna]

On Thu, Feb 4, 2010 at 10:26 PM, William A. Rowe Jr.
 wrote:
> On 2/4/2010 11:24 PM, Martin Cooper wrote:
>> In that case, +0 from me. We gain the elimination of the p.a.o bit but
>> lose the benefit of the delay, so it's basically a wash, as far as I'm
>> concerned.
>
> After several years of watching incubator site commits, I don't see this
> is a serious problem.  I've been cursed by the delay far more often than
> I've seen folks win from the delay.  That said, I sure could use the
> email delay I had in Eudora that is missing from Thunderbird ;~)

It is possible to run an incubator.staging.apache.org, syncing off a
branch, and the live site off trunk, or vice versa.

(possible, but I wouldn't recommend it, merging html changes like that
is pretty meh)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Publishing api docs for Subversion

[Paul Querna]

On Mon, Dec 7, 2009 at 1:00 PM, Doug Cutting  wrote:
> William A. Rowe Jr. wrote:
>>
>> I suspect that renaming /docs/trunk/ to /docs/dev/ would be sufficient and
>> follow this best practice?
>
> I don't know how much folks look at the URL, but I think I've heard Roy
> indicate that all developer-specific stuff should be under a dev/ URL.
>
> I think it would be better yet not to link to it from the side bar, which
> appears on every page, but rather just from the http://httpd.apache.org/dev/
> page.  If the primary point of posting it is so that developers can refer to
> it without having to build it themselves, it doesn't need to be posted so
> prominently, does it?

But in a way, its still missing a point -- because the other
documentation URL,s, IE for 2.2.x, are direct subversion exports, with
no voting on their contents, so its really a branches/2.2.x/docs
instead of trunk/docs.

I think the stance being taken understandable, but I believe the
burden is being placed completely in the wrong direction.  Make things
easier to do, not harder.

IANAL, but whats so bad from the ASF liability standpoint that
requires voting on website content?  if there is ever a problem, we
pull it.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Publishing api docs for Subversion

[Paul Querna]

On Thu, Dec 3, 2009 at 9:31 AM, Doug Cutting  wrote:
> Paul Querna wrote:
>>
>> httpd and apr have published doxygen of their trunks periodically,
>> they aren't based on any release.
>
> Were these published these on the official public website or in the dev/
> section?
>
> I was under the impression that released documentation should be treated
> similarly to released code.  The convention I've used is that stuff that's
> in trunk, stuff that's intended to be included in releases, is only
> published after release.  Other pages on the website that are not included
> in releases, e.g., the project's home page, are clearly published without a
> release vote.

<http://httpd.apache.org/docs/trunk/>

Which is linked from the sidebar everywhere, and on the docs page:
<http://httpd.apache.org/docs/>

> In particular, I think it's a bad practice to publish automatic nightly
> builds on the official website of content that's otherwise the subject of
> release votes.  Is it forbidden?  Perhaps not, but it's not a practice we
> should encourage in the incubator.  Often documentation includes code.  Do
> we want to publish that code without a vote?

httpd docs don't include code, dunno what projects do :)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Publishing api docs for Subversion

[Paul Querna]

On Wed, Dec 2, 2009 at 10:17 AM, Doug Cutting  wrote:
> Bhuvaneswaran A wrote:
>>
>> We tend to update the api docs generated using doxygen and java doc on
>> a nightly basis.
>
> Unreleased artifacts should be linked only from the developer portion of the
> site and should not be hosted on the official project site.  You might,
> e.g., just link to them on the Hudson server rather than copy them to
> people.apache.org.  Documentation should only be published to the official
> website after it's been included in an Apache release. This is for legal
> reasons: we work hard to ensure that releases have licensing in order, but
> do not in general guarantee that licensing is correct at all times in source
> code repositories.

I'm sorry what?

httpd and apr have published doxygen of their trunks periodically,
they aren't based on any release.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: document translation infrastructure?

[Paul Querna]

(adding d...@httpd cc)

On Tue, Nov 24, 2009 at 10:20 AM, Miles Libbey  wrote:
> Hi folks-
> We have a volunteer to translate our documentation from English into Korean.
>  Any recommendations for translation management/infrastructure? That is-- as
> the english documentation changes, is there any software that can help to
> find out of date or new strings/sections?

I would recommend looking at or copying how the httpd project handles
documentation translation.

  Explains some
of the basics.

For translations, the build keeps track of what subversion revs
changes a english version of the document, and then modifies the
non-english translations with information about the missing revisions.
 On the generated output, it also automatically adds a banner saying
that the file is out of date compared to the english version.

A concrete example:

is the current english version of the bind() docs.'

the meta file keeps track of which translations are outdated:


If you look at the german translation:

You can see it keeps a comment at the top of the file, tracking the
SVN revisions the english version has over the german version:


For the translater, they can then run svn log/diff over that rev range
and update their translation.

This system seems to work pretty well for d...@httpd, and I imagine it
could be adopted to raw HTML.

Someone from d...@httpd could likely explain it better

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Where to add PPMC member additions?

[Paul Querna]

ping? anyone know the answer?

I can't find the file referenced, nor can I find any other file where
PPMCs are supposed to keep their list updated?

On Mon, Nov 16, 2009 at 2:52 PM, Leif Hedstrom  wrote:
> Hi,
>
> reading http://incubator.apache.org/guides/ppmc.html, it says (towards the
> end) to add new PPMC members to this SVN file:
>
>    https://svn.apache.org/repos/private/committers/board/incubator-info.txt
>
>
> but, I get a 404 not found on that URL. Where do I add new PPMC members for
> our project (Traffic Server) ? I'll update our incubator page with the
> committer additions we're making, but I want to make sure I update
> everything as required here.
>
> Thanks,
>
> -- leif
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Review-Then-Commit

[Paul Querna]

On Wed, Nov 11, 2009 at 7:16 PM, Greg Stein  wrote:
> Not a "strong opinion", but I think that RTC hampers the free-flow of
> ideas, experimentation, evolution, and creativity. It is a damper on
> expressivity. You maneuver bureaucracy to get a change in. CTR is
> about making a change and discussing it. But you get *forward
> progress*.
>
> I also feel that RTC will tend towards *exclusivity* rather than the
> Apache ideal of *inclusivity*. That initial review is a social and
> mental burden for new committers. People are afraid enough of
> submitting patches and trying to join into a development community,
> without making them run through a front-loaded process.
>
> I've participated in both styles of development. RTC is *stifling*. I
> would never want to see that in any Apache community for its routine
> development (branch releases are another matter).
>
> My opinion is that it is very unfortunate that Cassandra feels that it
> cannot trust its developers with a CTR model, and pushes RTC as its
> methodology. The group-mind smashes down the creativity of the
> individual, excited, free-thinking contributor.

+1, thanks for writing this all out Greg, your thoughts about RTC for
'trunk' type branches is exactly inline with my own -- it doesn't mean
there should be a decrease in end quality, but it definitely does
stifle several potential aspects of the community.  This is my concern
with regards to Cassandra, based on my own experiences with CTR/RTC at
Apache and other projects.

Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL][VOTE] Subversion

[Paul Querna]

On Wed, Nov 4, 2009 at 12:12 PM, Greg Stein  wrote:
>  Subversion is a version control system.  You probably know it well as
> it is the version control system employed by the Apache Software
> Foundation.

+1, good luck on the incubation :-)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[RESULT] [VOTE] Accept Libcloud proposal for incubation

[Paul Querna]

On Wed, Oct 28, 2009 at 10:39 AM, Paul Querna  wrote:
> Libcloud proposal thread went well, and we added several mentors.  I
> would like to start the vote to incubate Libcloud into the ASF.
>
> The proposal is included below and is also at:
> <http://wiki.apache.org/incubator/LibcloudProposal>
>
> Please cast your votes:
>
> [ ] +1 Accept Libcloud for incubation
> [ ] +0 Indifferent to Libcloud incubation
> [ ] -1 Reject Libcloud for incubation
>
> Vote Closes 72 hours from now.

Vote passes with:
21 +1s.
zero -/+0s
zero -1s.

Thanks,
Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Libcloud Project

[Paul Querna]

On Thu, Oct 29, 2009 at 1:20 PM, Kevan Miller  wrote:
>
> On Oct 27, 2009, at 2:59 AM, Paul Querna wrote:
>
>> Reliance on Salaried Developers
>>
>> The majority, but not all, of the developers are paid by their
>> employer to work on libcloud at this time.
>
> I assume these are cloudkick employees? Will diversity be an issue for
> graduation? Since no affiliations are given, can't tell...

Sure, it might be a blocker for graduation, but shouldn't be for incubation.

Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Accept Libcloud proposal for incubation

[Paul Querna]

Libcloud proposal thread went well, and we added several mentors.  I
would like to start the vote to incubate Libcloud into the ASF.

The proposal is included below and is also at:
<http://wiki.apache.org/incubator/LibcloudProposal>

Please cast your votes:

[ ] +1 Accept Libcloud for incubation
[ ] +0 Indifferent to Libcloud incubation
[ ] -1 Reject Libcloud for incubation

Vote Closes 72 hours from now.

Thanks,

Paul

Libcloud, a unified interface to the cloud

Abstract

libcloud is a pure python client library for interacting with many of
the popular cloud server providers. It was created to make it easy for
developers to build products that work between any of the services
that it supports.

Proposal

* Provide unified API for manipulating servers instances across
many hosting providers who provide an API to manipulate instances.
Current API includes: list, reboot, create, destroy, list images, list
sizes.
* (future) Provide utilities for manipulating and creating server
images in many formats. (See the independent Stacklet project for
ideas)
* (future) Provide unified API for storing large objects on
popular hosting provider storage APIs.

Background

While there are some projects to create open standards for
interoperability within the cloud, most have failed to gain widespread
adoption. Libcloud takes the approach of exposing a unified API to
cover multiple vendor's APIs, and in the future to support standard
APIs, assuming they become prevalent.

Rationale

There is a strong need in the developing cloud infrastructure for a
community supported, high quality, and vendor independent tool set for
managing servers and their resources. When new servers are just an API
call away, traditional infrastructure models are changing quickly.
Having a good library built around Apache's values and tradition will
enable new server infrastructure to evolve much more quickly.

Initial Goals

Libcloud is an existing open source project, with patches from many
different contributors. We view the moving to Apache as a way to
improve this community, and look into future APIs around creating
server images and large object storage.

Current Status

Libcloud is already open source under the ASL 2.0:

   * Libcloud Website <http://www.libcloud.org>
   * Libcloud Mailing Lists <http://groups.google.com/group/libcloud>
   * Libcloud Source Control <http://github.com/cloudkick/libcloud>

Meritocracy

Libcloud has involvement from members of both the ASF and other open
source projects. Communication is driven by both IRC and E-Mail lists.

Community

Currently libcloud has several contributors, but not a large user
community other than a few companies. We would like to increase our
userbase as part of the incubator process.

Core Developers

Alex Polvi who wrote most of the original code is familiar with open
source from working at OSUOSL and at Mozilla. Tom Davis drove much of
the re factoring of the initial code base. Jed Smith, Ivan Meredith,
Jeremy Orem, Jerry Chen and Paul Querna (ASF member) have all
contributed mainly to developing provider specific drivers.

Alignment

Currently there are not many Apache communities involved with cloud
computing or python based infrastructure. We believe introducing such
a community is a good thing for the Apache Software Foundation.

Known Risks

Orphaned products

libcloud is being used actively by Cloudkick to develop services. It
is a core part of Cloudkick's ongoing infrastructure improvements.

Inexperience with Open Source

libcloud was open sourced in July 2009, during OSCON. Core
contributors include former employees of Mozilla and an ASF member.

Homogeneous Developers

Much of the initial development was done by Cloudkick, but much of the
core design was re-factored by the community, and many of the drivers
for each provider have been contributed by 3rd parties.

Reliance on Salaried Developers

The majority, but not all, of the developers are paid by their
employer to work on libcloud at this time.

Relationships with Other Apache Products

Libcloud doesn't share many attributes with existing Apache projects
due to it being in Python and addressing a new need.

A Excessive Fascination with the Apache Brand

Libcloud project seeks to build a last community around cloud API
interoperability, and is not fascinated with any short term gains of
being associated with the Apache Brand.

Documentation

* 
http://www.informationweek.com/cloud-computing/blog/archives/2009/01/the_urgent_issu.html
* http://broadcast.oreilly.com/2009/09/cloud-api-wars---where-is-the.html
* 
http://blogs.gartner.com/lydia_leong/2009/08/27/are-multiple-cloud-apis-bad/
* http://deltacloud.org/

Initial Source

Initial source is contained completely inside the libcloud github repository.

External Dependencies

* zope.interface
* For Python =< 2.5, a JSON Parser such as Simpl

Re: [PROPOSAL] Libcloud Project

[Paul Querna]

On Tue, Oct 27, 2009 at 3:29 PM, Nick Kew  wrote:
>
> On 27 Oct 2009, at 06:59, Paul Querna wrote:
>
>> Hi,
>>
>> I would like to propose incubating the existing Libcloud project to
>> join the ASF:
>
> +1.  Looks interesting!
>
> There seem to be more than enough volunteers to mentor already,
> so I won't put myself forward for that.  But I'll certainly watch with
> interest!
>
> From your POV as king of infra, what uses of this might you
> envisage @apache.org?

>From an ASF Infra POV, cloud computing in the public hosting providers
sense, doesn't make sense for us.  Since we generally only pay for
Hardware, and our BW/Power/Rackspace are all 'free' at most of our
hosting locations, and even amazon's cheapest machines cannot compare
to this.

I do believe there is oppurtunity within our own machines to better
utlitilize resources on many machines, and in the long run it will
make sense to run certain ASF services 'on the cloud', but I don't see
it changing super quickly for the ASF Infrastructure itself.

Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing

[Paul Querna]

On Tue, Oct 27, 2009 at 4:22 AM, Sebastian Wagner  wrote:
> hi,
>
> we would like to propose Openmeetings project to join the incubator.
>
> Full Proposal:
> http://wiki.apache.org/incubator/OpenmeetingsProposal
>
> Quick summary:
> OpenMeetings is Web Conferencing application that fits into educational or
> business sector. You can make conference sessions in different room-types
> with up to 100 peoples in a Room. It contains all main features of Web
> Conferencing: Audio/Video, Whiteboard, Screen Sharing, Chat and Moderation
> System. It is translated into more then 20 languages and its a basic goal of
> OpenMeetings to be easy to embed into existing environments. It already uses
> many of Apache Technologies like Tomcat, Mina, Velocity, Commons, ...
>
> You may find all existing documents and further material on the GoogleCode
> pages: http://code.google.com/p/openmeetings/
>

Sounds cool!

I do have a question about how the project uses Red5 Media Server.
Red5 is licensed under the LGPL, how exactly does OpenMeetings use it?

Thanks,

Paul

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[PROPOSAL] Libcloud Project

[Paul Querna]

Hi,

I would like to propose incubating the existing Libcloud project to
join the ASF:

Proposal  Wiki: <http://wiki.apache.org/incubator/LibcloudProposal>

Libcloud is a unified Python API around many common cloud services
provider, and I believe it could benefit greatly by joining the Apache
Software Foundation.  I also believe the ASF needs more Python
projects, and more projects involved in the developing cloud
infrastructure.  We still need a few mentors, so feel free to signup
:-)

We would appreciate feedback and comments on the proposal.

Full proposal is bellow.

Thanks,

Paul


Libcloud, a unified interface to the cloud

Abstract

libcloud (<http://www.libcloud.org>) is a pure python client library
for interacting with many of the popular cloud server providers. It
was created to make it easy for developers to build products that work
between any of the services that it supports.

Proposal

* Provide unified API for manipulating servers instances across
many hosting providers who provide an API to manipulate instances.
Current API includes: list, reboot, create, destroy, list images, list
sizes.

* (future) Provide utilities for manipulating and creating server
images in many formats. (See the independent Stacklet project for
ideas)

* (future) Provide unified API for storing large objects on
popular hosting provider storage APIs.

Background

While there are some projects to create open standards for
interoperability within the cloud, most have failed to gain widespread
adoption. Libcloud takes the approach of exposing a unified API to
cover multiple vendor's APIs, and in the future to support standard
APIs, assuming they become prevalent.

Rationale

There is a strong need in the developing cloud infrastructure for a
community supported, high quality, and vendor independent tool set for
managing servers and their resources. When new servers are just an API
call away, traditional infrastructure models are changing quickly.
Having a good library built around Apache's values and tradition will
enable new server infrastructure to evolve much more quickly.

Initial Goals

Libcloud is an existing open source project, with patches from many
different contributors. We view the moving to Apache as a way to
improve this community, and look into future APIs around creating
server images and large object storage.

Current Status

Libcloud is already open source under the ASL 2.0:

* Libcloud Website <http://www.libcloud.org>
* Libcloud Mailing Lists <http://groups.google.com/group/libcloud>
* Libcloud Source Control <http://github.com/cloudkick/libcloud>

Meritocracy

Libcloud has involvement from members of both the ASF and other open
source projects. Communication is driven by both IRC and E-Mail lists.

Community

Currently libcloud has several contributors, but not a large user
community other than a few companies. We would like to increase our
userbase as part of the incubator process.

Core Developers

Alex Polvi who wrote most of the original code is familiar with open
source from working at OSUOSL and at Mozilla. Tom Davis drove much of
the re factoring of the initial code base. Jed Smith, Ivan Meredith,
Jeremy Orem, Jerry Chen and Paul Querna (ASF member) have all
contributed mainly to developing provider specific drivers.

Alignment

Currently there are not many Apache communities involved with cloud
computing or python based infrastructure. We believe introducing such
a community is a good thing for the Apache Software Foundation.

Known Risks

Orphaned products

libcloud is being used actively by Cloudkick to develop services. It
is a core part of our ongoing infrastructure improvements.

Inexperience with Open Source

libcloud was open sourced in July 2009, during OSCON. Core
contributors include former employees of Mozilla and an ASF member.

Homogenous Developers

Much of the initial development was done by Cloudkick, but much of the
core design was re-factored by the community, and many of the drivers
for each provider have been contributed by 3rd parties.

Reliance on Salaried Developers

The majority, but not all, of the developers are paid by their
employer to work on libcloud at this time.

Relationships with Other Apache Products

Libcloud doesn't share many attributes with existing Apache projects
due to it being in Python and addressing a new need.

A Excessive Fascination with the Apache Brand

Libcloud project seeks to build a last community around cloud API
interoperability, and is not fascinated with any short term gains of
being associated with the Apache Brand.

Documentation

TODO: links to related material on Cloud APIs/interop (?)

Initial Source

Initial source is contained completely inside the libcloud github repository.

External Dependencies
* zope.interface
* For Python =< 2.5, a JSON Parser such as SimpleJSON is required.

Cryptography

Uses standard Python APIs f

Re: [VOTE] Release cassandra 0.4.0-rc2

[Paul Querna]

On Fri, Sep 11, 2009 at 10:14 AM, Eric Evans  wrote:
>
> The Cassandra community voted on and approved the release of Apache
> Cassandra 0.4.0-rc2. We would now like to request the approval of the
> Incubator PMC for this release.
>
> Cassandra is a massively scalable, eventually consistent, distributed,
> structured key-value store.
>
> Podling vote thread:
> http://www.mail-archive.com/cassandra-...@incubator.apache.org/msg00887.html
> 0.4.0-rc2 artifacts: http://people.apache.org/~eevans
> SVN tag:
> https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.4.0-rc2
> Project home: http://incubator.apache.org/cassandra/
> Incubation status: http://incubator.apache.org/projects/cassandra.html
>
> The vote will remain open for 72 hours (or longer if needed).
>
> There were a number of changes made since RC1 to address concerns raised
> in previous votes. Among them:
>
> * License texts in lib/licenses where removed and incorporated into a
> monolithic top-level LICENSE.txt. CASSANDRA-371
>
> * Attributions for all third-party code was added to the top-level
> NOTICE.txt file. CASSANDRA-371
>
> * Commons javaflow was removed. CASSANDRA-428
>
> * The developers/contributors reference in NOTICE.txt was removed, (as
> was the actual list in pom.xml). CASSANDRA-415
>
> * Missing SVN properties that had crept in were added, and project
> documentation updated. CASSANDRA-429


+1 to release.

Concerns/Issues/general feedback:
 - gen-java as mentioned like Sebb (The generated files included in
the tarball), but not a blocking problem.  We have various generated
bits in httpd's tarbals, I don't think this is a critical issue.
 - The use of SVN Snapshots of projects like Thrift -- This is really
a Thrift problem that the Thrift project needs to fix, but it should
not block Cassandra from releasing.  We have done releases of httpd
that depend on APR svn snapshots before, it sucks, but we've done it.
- Don't know the details of how `ant release` works, but things like
bin/cassandra didn't have +x executable bit on them.
- The BUGS.txt file feels out of place and pretty short, Maybe a
Current Limitations section in a the README.txt, with a link to the
wiki.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: PIWI / PHP Projects in Apache

[Paul Querna]

Christian Grobmeier wrote:

Hi all,

we have developed a web framework in PHP, called PIWI:

- http://piwi.googlecode.com/
- http://piwiframework.de/

Codebase supports very much features right now and only lacks user
documentation and has some open discussions left. Find a feature list
below.

It heavily borrows ideas and concepts from  Apache Cocoon and Apache
Forrest although it is implemented in PHP. Cause of this I think that
Apache would be a good host for this project.

I allready surfed a while through the incubator and found one PHP
project (log4php) which doesn't look very active. Does it make sense
to propose a new PHP project for apache? I really think that apache
would benefit of PHP projects. In my dreams there is a php.apache.org
TLP someday, hopefully hosting it's subprojects PIWI and maybe
log4PHP.


I'm not sure of a TLP called php.apache.org, but having lots of projects 
written in PHP is a good thing :-)




However, please give me your feedback. If somebody is interested in
mentoring us with this project, let me know. If you think it makes no
sense to bring another PHP project to apache, let me know too. Your
feedback is highly appreciated.


I think this would be cool.

-Paul


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [Proposal] Helenus - a Cassandra fork

[Paul Querna]

Roland Weber wrote:

Hello Ian,


I'd like to propose a fork of the cassandra project. Since it was
initially released by FaceBook, It hasn't really grown an active
community around it.
[...]
Several people who plan to use the project in their companies have
banded together and want to fork the project so that they keep the
project alive, and build a community around it to grow it.

I suggested we do this on the incubator, as it has experience building
communities around code.


There seem to be good reasons for attempting a fork of the project.
However, my gut feeling says that this is a very political thing and
should better be started on neutral ground (from an Apache perspective).

Apache is a home for voluntary contributions. If Facebook is the
original source of the codebase, and they don't support the move here
(for example by signing a software grant), then the fork should not
be initiated here.


No, Apache is for individuals who are part of community that want to do 
*something*.


I don't care what "facebook" as a company does or doesn't want to do 
with the code, its open source, and the right to fork is there.


As long as we can create a good community for it, I don't have any 
objections to forking this project, or any project.



I'm not sure how a later move to Apache would be handled. We expect
incoming projects to get approval from all major contributors to their
codebase, if feasible.


I don't think it matters.  We have had lots of overlapping projects 
before, and generally in the long run, one of them turns out better, and 
the community moves over to it.


There isn't any wrong with with projects dying in the long run either, 
it lets different groups of developers take different approaches.


If someone wanted to fork httpd for example, I would ridicule them at 
first, but if they could find 5-10 people to support it in the 
community, then I believe we should let it continue, even as an ASF 
project, and who knows, maybe the mythical Waka server will end up doing 
exactly this.


-Paul



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Abdera Graduation to TLP

[Paul Querna]

Garrett Rooney wrote:

On Thu, Nov 13, 2008 at 10:37 PM, William A. Rowe, Jr.
<[EMAIL PROTECTED]> wrote:

Garrett Rooney wrote:

The discussion included determining the list of people to put on the
final PMC list.  The actual list of Abdera committers was larger, but
many of them had not participated in the project in some time or at
all, or had explicitly left the project.  Since I didn't want to come
right out in a public forum and say "you know, I think committer X
doesn't deserve to be on the PMC" I started the discussion in private.

I'm presuming there was not a dev@ vote yet by the Abdera community itself?
If not, could you please call that vote ASAP in parallel with the general@
vote?  Monday evening is not to late to put this on the board agenda.


There was already a vote on the abdera private list with more than 50%
of the developers voting +1 and none voting -1.  If you're really
concerned that it's not on the dev list I can restart the vote there,
but it seems awfully futile.


seems like a waste of time for all involved to run yet another vote.

-Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Abdera Graduation to TLP

[Paul Querna]

Garrett Rooney wrote:

After some brief discussion here and a vote on the Abdera private
list, it seems everyone is in favor of this, so I'd like to propose
that we ask the board to make Abdera a new TLP.  It's been quite the
long incubation process (started in May 2006!), but I think the Abdera
community, while small, is now diverse enough that I have no question
as to its ability to survive as its own Apache project.

So please vote away.  A +1 vote is for sending the following motion to
the board for its approval.


+1



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: On incubating releases

[Paul Querna]

Jukka Zitting wrote:

Hi,

On Fri, Sep 26, 2008 at 3:05 PM, Upayavira <[EMAIL PROTECTED]> wrote:

 * Do we want users to have easy access to these releases, or to make
  it difficult? Users need to know about the fact that Apache does not
  yet vouch for the community behind these releases. How do we go
  about ensuring that they do know and understand?


I think the concerns are quite similar to what a TLP might have when
making an alpha or beta release, the "we won't vouch for this" aspect
is just technical instead of social. Such cases are typically handled
by disclaimers in the release notes. But we don't (and can't!) require
downstream projects to explicitly notify their users that they bundle
an alpha dependency.



Simple, C programmer speaking here, projects just should have less 
dependencies.


They also should have a very shallow dependency tree depth on the 
dependencies that they must have.  :-)


But downstream consumers bundling Alpha/Beta versions of a release 
should be severely looked down upon -- if some linux distro took an 
alpha version of APR-Util and included it in their subversion builds, I 
imagine both the svn and apr developers would have a fit, this doesn't 
seem to be true for all communities.


Why can't culture, communities and long rants on why shipping alpha 
version dependencies 'fix' this issue?


Related to this, perhaps our labeling of 'incubating' is not effective.

Why not just call all releases from incubator 'alpha'?

The 'incubating' tag doesn't seem to set expectations correctly in the 
wider open source communities.


Thanks,

-Paul


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Paul Querna]

William A. Rowe, Jr. wrote:

Henning Schmiedehausen wrote:

So you assume that that www.apache.org can not be hacked? What if a
signing key *IS* in KEYS but not signed by anyone (because the developer
has never attended an Apache key signing event)?


No, I answered your question.

W.r.t. www.apache.org/dist/{tlp}/KEYS, we have a serious issue to address,
because it's not https: accessible so cannot be trusted.  Yes, it's quite
possible to fetch https://svn.apache.org/repos/asf/{tlp}/{code}/trunk/KEYS
but that's not what we suggest, and suboptimal to boot.


Open an infrastructure JIRA ticket and I'll figure out getting https:// 
on www.apache.org sooner or later.


Thanks,

Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository

[Paul Querna]

-1, (Binding).

(For the reasons explained by Craig and Justin in this Thread)

Thanks,

Paul

Craig L Russell wrote:

-1

I believe that allowing incubating releases to be treated as full Apache 
releases diminishes the Apache brand and makes incubation disclaimers moot.


With Maven, it is too easy to depend on a release with transitive 
dependencies on incubating releases without even knowing it. When the 
incubating release subsequently is abandoned, blame will be cast widely, 
including Apache itself.


Considering that dependencies on incubating releases can be resolved by 
explicitly adding an incubating Maven repository into your settings, I 
don't think that wide, mirrored, distribution is warranted.


Craig

On Sep 9, 2008, at 11:34 PM, Jukka Zitting wrote:


Hi,

We've had a number of long discussions about the incubating projects
using the central Maven repository to distribute their releases. The
current policy is that incubating releases should not go to there. The
related discussion threads have died with no consensus but the issue
still exists and affects many podlings. I would like to finally
resolve the issue one way or another by calling the Incubator PMC to
vote on the matter.

In INCUBATOR-82 I have prepared a patch (also attached below) that
changes the policy document to explicitly _allow_ extra distribution
channels like the central Maven repository for incubating releases.
Note that the proposed patch allows any such channels instead of
focusing just on the Maven repository. Also, any releases must still
be approved, comply with the disclaimer and naming rules, and be
primarily distributed through the official
http://www.apache.org/dist/incubator/ channel.

Please vote on accepting or rejecting this policy change! This
majority vote is open for a week and only votes from the Incubator PMC
members are binding.

[ ] +1 Yes, allow extra release distribution channels like the central
Maven repository
[ ] -1 No, keep the current policy

My vote is +1

BR,

Jukka Zitting

Patch from https://issues.apache.org/jira/browse/INCUBATOR-82:

Index: site-author/incubation/Incubation_Policy.xml
===
--- site-author/incubation/Incubation_Policy.xml(revision 692094)
+++ site-author/incubation/Incubation_Policy.xml(working copy)
@@ -489,6 +489,8 @@

Releases for podling MUST be distributed 
through

http://www.apache.org/dist/incubator/podling.
+In addition, the Podling MAY choose to distribute approved releases 
through

+other channels like the central Maven repository.

  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] Do we really need an incubator?

[Paul Querna]

Jukka Zitting wrote:

Hi,

On Wed, Jul 9, 2008 at 8:46 PM, Paul Querna <[EMAIL PROTECTED]> wrote:

Noel J. Bergman wrote:

[...] Until the Maven PMC stops abrogating its responsibility and addresses
the issues, there does not appear to be anything that we can do about
Maven's flaws short of banning use of the public Maven repositories entirely.

+1.

If this was how debian ran packages or freebsd managed the ports collection,
there would of already been an exploit incident.

We are running on borrowed time, and I don't understand why the PMC
continues to promote features with a completely broken security model.


Frankly I don't see what's so "completely broken" about the Maven
repository. Lack of automatic signature checking?

For comparison: CPAN has been available for well over a decade and it
has had signature checking for less than three years now. And the
feature is still optional, disabled by default.


However, AFAIK, CPAN doesn't allow every CPAN author to overwrite the 
files of every other CPAN author.  Thats the situation we are in now 
with the Maven Repository, because we just use the filesystem on 
people.apache.org as the pristine copy.


To me there are two main flaws with how we manage the repository today:

1) No Authenticated Modifications to the Repository.
2) No Automated Signature Checking Enabled by Default.

To address #1, we are looking at using a Subversion repository, instead 
of the file system on people.apache.org.


By using a subversion repository, all modifications of the repo could be 
tracked via email and revision histories, and the mirrors ran by infra 
would just be exported copies.



So, while I do appreciate the enthusiasm, I think cries about Maven
security being broken and the use of the repository being
irresponsible are IMHO greatly exaggerated. Having automatic signature
checking in Maven would be nice, but it's not a bit enough itch that
I'd personally want to scratch that and IMHO certainly not serious
enough that I'd for example consider not using the Maven repository in
projects I'm involved with.


You are saying you trust all 1600+ shell accounts on people.apache.org?

That not one of them is hacked, or will be hacked at some point?

Thats not a risk I believe we should expose ourselves to.  Moving to a 
subversion based repository would be a first good step, adding real 
signature checking should also be done, but I can live with just getting 
the repository moved off a central machine.


-Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] Do we really need an incubator?

[Paul Querna]

Noel J. Bergman wrote:

Roy T. Fielding wrote:


There is no reason for a separate repository.  [A separate repo] does not
help protect "users" from incubator code, since users don't set the Maven
configs that define which repos to use and which modules are dependencies.
 At best, what it does is add an irrelevant incubator layer on top of all

Maven

repo requests that masks the "normal" repo path from developers,

introduces

another way to inject insecure code, and wastes our bandwidth sending 404
responses to automated build requests.



the user never makes a decision regarding incubator code in the Maven

repo.

The user is either going to pull the incubator release directly and then

build it

using Maven with the provided pom, or some other project is going to make

a

decision to add the artifact (with incubator in its name) as a dependency.

The

Maven repo path is irrelevant to the user's decisions



Yes, it would be nice if Maven was more secure, properly checked

signatures,

and properly delegated namespaces so that third-parties would be unable to
add artifacts within other org's trees.  None of those issues are specific

to incubator.

I am forced to agree with Roy on these points.  Until the Maven PMC stops
abrogating its responsibility and addresses the issues, there does not
appear to be anything that we can do about Maven's flaws short of banning
use of the public Maven repositories entirely.



+1.

If this was how debian ran packages or freebsd managed the ports 
collection, there would of already been an exploit incident.


We are running on borrowed time, and I don't understand why the PMC 
continues to promote features with a completely broken security model.



Given that I consider promoting Maven's insecurre, uncontrolled, and
unmanaged repositories to be at the height of irresponsibility, I would vote
in favor of such a ban -- ASF-wide, not limited to the Incubator -- until
Maven's flaws were addressed, but unfortunately, I doubt that there is a
consensus to do so.  At least not until there is an actual exploit in the
wild, at which point the Maven PMC might finally open its eyes in panic.


I'm not involved in Maven at all, I can understand a project skimping on 
more complicated security issues early on -- but at this point Maven 
seems like a well established project that isn't just an experiment -- 
people will be using it in mass for years to come.  For the security 
infrastructure to be completely missing, to me, is completely unacceptable.



However, the Maven repository situation has little to do with the need for
an Incubator.


I agree :-)

-Paul



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] Do we really need an incubator?

[Paul Querna]

Noel J. Bergman wrote:

Roy T. Fielding wrote:


There is no reason for a separate repository.  [A separate repo] does not
help protect "users" from incubator code, since users don't set the Maven
configs that define which repos to use and which modules are dependencies.
 At best, what it does is add an irrelevant incubator layer on top of all

Maven

repo requests that masks the "normal" repo path from developers,

introduces

another way to inject insecure code, and wastes our bandwidth sending 404
responses to automated build requests.



the user never makes a decision regarding incubator code in the Maven

repo.

The user is either going to pull the incubator release directly and then

build it

using Maven with the provided pom, or some other project is going to make

a

decision to add the artifact (with incubator in its name) as a dependency.

The

Maven repo path is irrelevant to the user's decisions



Yes, it would be nice if Maven was more secure, properly checked

signatures,

and properly delegated namespaces so that third-parties would be unable to
add artifacts within other org's trees.  None of those issues are specific

to incubator.

I am forced to agree with Roy on these points.  Until the Maven PMC stops
abrogating its responsibility and addresses the issues, there does not
appear to be anything that we can do about Maven's flaws short of banning
use of the public Maven repositories entirely.



+1.

If this was how debian ran packages or freebsd managed the ports
collection, there would of already been an exploit incident.

We are running on borrowed time, and I don't understand why the PMC
continues to promote features with a completely broken security model.


Given that I consider promoting Maven's insecurre, uncontrolled, and
unmanaged repositories to be at the height of irresponsibility, I would vote
in favor of such a ban -- ASF-wide, not limited to the Incubator -- until
Maven's flaws were addressed, but unfortunately, I doubt that there is a
consensus to do so.  At least not until there is an actual exploit in the
wild, at which point the Maven PMC might finally open its eyes in panic.


I'm not involved in Maven at all, I can understand a project skimping on
more complicated security issues early on -- but at this point Maven
seems like a well established project that isn't just an experiment --
people will be using it in mass for years to come.  For the security
infrastructure to be completely missing, to me, is completely 
unacceptable in an ASF Project.



However, the Maven repository situation has little to do with the need for
an Incubator.


I agree :-)

-Paul




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Thrift Status?

[Paul Querna]

Back in Febuary, the vote to accept Thrift into the Apache Incubator was 
successful:




But since then, I haven't seen any movement... on anything.

Does anyone know what is going on?

Thanks,

-Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Subversion vs other source control systems

[Paul Querna]

Daniel Kulp wrote:

On Monday 18 February 2008, Paul Querna wrote:

in a private list does not accord with *our way of
working*, I think. And I don't think there is any need to use a
private, unarchived list for discussions on infrastructure
improvements.

infrastructure is open to all committers.
infrastructure-dev is open to all committers.
infrastructure-private is open to all members.

All of them are archived.



None of them are available to see at:
http://mail-archives.apache.org/mod_mbox/

Thus, they look pretty private to me. 


They are not available on the public web interface, the archives are 
available to all committers on people.apache.org.


"private" is an interesting choice of words, but I personally don't 
consider them very private with 1600++ committers having access.


Should some or all of them be available on the web interface? I'm not 
sure, but bring it up on the infrastructure lists.


-Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Subversion vs other source control systems

[Paul Querna]

Santiago Gala wrote:

El dom, 17-02-2008 a las 19:02 -0500, Noel J. Bergman escribió:

No.  This is the wrong forum.  What we've said here is that there won't be any 
deviation from the ASF infrastructure for source control; changing ASF 
infrastructure is out of scope for the Incubator.


I already tried to move the discussion to [EMAIL PROTECTED], where I
think it belongs, but people insists on answering here. Making requests
to a closed team


"Infrastructure" isn't a closed team by any means, and I am tired of 
people propagating that bullshit.  Come help, and karma comes.



in a private list does not accord with *our way of
working*, I think. And I don't think there is any need to use a private,
unarchived list for discussions on infrastructure improvements.


infrastructure is open to all committers.
infrastructure-dev is open to all committers.
infrastructure-private is open to all members.

All of them are archived.

HTH,

-Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] as to Thrift Proposal

[Paul Querna]

On Jan 23, 2008 9:07 PM, Mark Slee <[EMAIL PROTECTED]> wrote:

Hi all,

We've just posted the Apache Incubator proposal for Thrift onto the
Wiki:
http://wiki.apache.org/incubator/ThriftProposal


+1

-Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Releases By Retired Podlings

[Paul Querna]

Robert Burrell Donkin wrote:

On Jan 14, 2008 3:29 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:

i've been searching for releases by retired podlings in order to
archive them but can't locate releases for any of them
anyone have any ideas about what happend to them?

Examples?


Agila
AltRMI
Axion
Depot
Heraldry
Kabuki
Lucene4c
TSIK
wadi


Is it possible that there were none?


yes

but it's good to check

i had a poke around but i've only found stuff in
people.apache.org/dist/incubator


This is another reason we should only use the 'real' dist on 
www.apache.org, since all of that is automatically put into archive:

http://archive.apache.org/dist/incubator/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Including snapshot dependencies from other ASF projects

[Paul Querna]

John O'Hara wrote:
> I don't think its the same as releasing another projects code.
> A good example is when SubVersion included APR as part of its code
> base.  No
> one would have confused that as a release of APR, and it was patched and
> modded, and the APR team were kept in the loop.

For the most part, in the more-recent past, Subversion shipped with the
version of APR that HTTPD shipped with, which sometimes was a SVN
snapshot, and sometimes as release.

In the most-recent past, Subversion has only been shipping with real APR
releases, unpatched. HTTPD now also only ships with real APR releases,
unpatched.

-Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [discussion] Harmony podling to ask for vote for graduation

[Paul Querna]

Niclas Hedhman wrote:

On Wednesday 18 October 2006 10:33, Geir Magnusson Jr wrote:

Will you be satisfied with a vote on posting a snapshot?


I think some Incubator PMC member wants to see a 'full release' artifact for 
review.


I don't.

The podling should select a release manager producing the artifact, 
which the PPMC first ensure is correct and vote upon, before asking the IPMC 
to take a closer look. 


I am not worried about this process (or er, lack of process) in Harmony. 
 They have their NOTICEs, LICENSE, etc done right, and they have enough 
existing apache developers heavily involved that the details of a 
release will be handled correctly in my opinion.


I believe in general, a release is a 'nice to have' for an incubator 
project, and nothing more. It can help some groups who are not familiar 
with what is required of a release, but by no means should it be a 
requirement to graduate from the Incubator.


-Paul




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept Heraldry into the Incubator

[Paul Querna]

Ted Leung wrote:
> It seems like the discussion on Heraldry has died down, so I'd like to
> call for a VOTE on accepting Heraldry into the incubator.
> 
> In keeping with Apache practice, I'd like to allow 72 hours or so for
> the vote to close, so please vote by 11:59PST on Thursday July 13th.
> 
> The current proposal is here: 
> , and I've
> included the full text below.
> 

+1 to accept Heraldry into the incubator.

-Paul


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: atom feeds for projects

[Paul Querna]

robert burrell donkin wrote:
> On 7/2/06, Sam Ruby <[EMAIL PROTECTED]> wrote:
>>
>> robert burrell donkin wrote:
>> > the mailing list archives at apache run on mod_mbox which also supplies
>> > atom
>> > feeds for these lists. i've added the feed from general to the front
>> page
>> > and think it'd be cool to add feeds to the pages in projects as well.
>> since
>> > the focus of  podlings should be recruiting developers (not users) i'm
>> > thinking of adding feeds to the dev lists.
>> >
>> > opinions?
>> >
>> > volunteers?
>>
>> Just be aware that the feeds produced are rarely well formed XML, mostly
>> due to encoding issues.  For example: http://tinyurl.com/h5f7t
>>
>> I tried to submit a patch based on my limited understanding of the code,
>> and was told that my patch wasn't acceptable

To be clear, AFAIK, there was never a patch for mod_mbox -- it was a
Ruby file that only solved part of the problem. Again, AFAIK, no one
ever wrote a patch in C for mod_mbox to attempt to resolve this issue.

>> and that XML parsers that
>> require well-formedness were broken anyway -- despite that being
>> explicitly what the spec requires.

Its unfortunate that the discussion degraded into that.

>> I'd be willing to try again, but only if there was active interest in
>> actually fixing the problem.

Yes, there is active interest in making mod_box better.

> IMO we should fix the feed but i'm not involved with mod_mbox (or httpd).
> anyone who is want to jump in here?

The primary bug is lack of encoding support.  mod-mbox just doesn't even
try to do it.

Someone needs to write something that touches many parts of the code,
using the apr_xlate API to convert the content to utf-8.  (This would
also help it validate as HTML).  Once that is done, we do need to worry
about out of range characters, some of which would be removed, others
possibly HTML encoded.

For future discussion of this please use [EMAIL PROTECTED]

Thanks,

-Paul


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Heraldry Identity Project

[Paul Querna]

General Comments:
Is it possible to put this proposal onto the wiki ( 
http://wiki.apache.org/incubator/ ) for a stable url when there are 
updates/changes?


Recordon, David wrote:
snip
Initial Committers 
--

David Recordon ([EMAIL PROTECTED])
Andy Dale ([EMAIL PROTECTED])
Brad Fitzpatrick ([EMAIL PROTECTED])
Brian Ellin ([EMAIL PROTECTED])
Dan Lyke ([EMAIL PROTECTED])
Dan Quelhorst ([EMAIL PROTECTED])
Drummond Reed ([EMAIL PROTECTED])
Johannes Ernst ([EMAIL PROTECTED])
Jonathan Daugherty ([EMAIL PROTECTED])
Josh Hoyt ([EMAIL PROTECTED])
Les Chasen ([EMAIL PROTECTED])
Matt Pelletier ([EMAIL PROTECTED])
Michael Graves ([EMAIL PROTECTED])
Paul Trevithick ([EMAIL PROTECTED])
Steve Churchill ([EMAIL PROTECTED])
Trotter Cashion ([EMAIL PROTECTED])
Wil Tan ([EMAIL PROTECTED])


My biggest concern right now is that there seems to be a 1 to 1 mapping 
of so many of the initial committers to the individual code bases that 
want to be donated.  It worries me about fragmentation of the project, 
especially since there are at least 4 or 5 different programing 
languages already involved.


-Paul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE-RESULT] Incubator to sponsor and accept Abdera for incubation

[Paul Querna]

Garrett Rooney wrote:

On 6/5/06, Paul Querna <[EMAIL PROTECTED]> wrote:

Garrett Rooney wrote:
> On 6/5/06, Sam Ruby <[EMAIL PROTECTED]> wrote:
>> Sam Ruby wrote:
>>
>> With the following votes cast:
>>
>>   +1 Sam Ruby
>>   +1 Garrett Rooney
>>   +1 Paul Fremantle
>>   +1 Davanum Srinivas
>>   +1 Yoav Shapira
>>   +1 Jim Jagielski
>>   +1 Robert Burrell Donkin
>>   +1 Martin Cooper
>>   +1 Geir Magnusson Jr
>>
>> ... this vote passes.
>>
>> At this point I'd like to ask that the mentors (Garrett Rooney, and 
Paul

>> Querna) create the status file and work with infrastructure to get the
>> necessary mailing lists, repository, and the like set up.
>
> I'd be happy to do so, but I probably won't have time until later this
> week.  If someone beats me to it, more power to them.

Mailing lists:
http://issues.apache.org/jira/browse/INFRA-829

Repository:
https://svn.apache.org/repos/asf/incubator/abdera/

Initial committers:
abdera=eliast,rubys,yoavs

James M Snell and Robert Yates do not have CLAs or accounts.

Bugzilla:
http://issues.apache.org/jira/browse/INFRA-830


Perhaps we should consult the initial project members and see if they
would prefer JIRA to Bugzilla, before we actually start creating
projects and so forth...


I also wouldn't mind Jira, I was just following what was in the proposal :)

-Paul


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE-RESULT] Incubator to sponsor and accept Abdera for incubation

[Paul Querna]

Garrett Rooney wrote:

On 6/5/06, Sam Ruby <[EMAIL PROTECTED]> wrote:

Sam Ruby wrote:

With the following votes cast:

  +1 Sam Ruby
  +1 Garrett Rooney
  +1 Paul Fremantle
  +1 Davanum Srinivas
  +1 Yoav Shapira
  +1 Jim Jagielski
  +1 Robert Burrell Donkin
  +1 Martin Cooper
  +1 Geir Magnusson Jr

... this vote passes.

At this point I'd like to ask that the mentors (Garrett Rooney, and Paul
Querna) create the status file and work with infrastructure to get the
necessary mailing lists, repository, and the like set up.


I'd be happy to do so, but I probably won't have time until later this
week.  If someone beats me to it, more power to them.


Mailing lists:
http://issues.apache.org/jira/browse/INFRA-829

Repository:
https://svn.apache.org/repos/asf/incubator/abdera/

Initial committers:
abdera=eliast,rubys,yoavs

James M Snell and Robert Yates do not have CLAs or accounts.

Bugzilla:
http://issues.apache.org/jira/browse/INFRA-830

-Paul


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ARI, Atom Reference Implementation [Proposal]

[Paul Querna]

Paul Fremantle wrote:

On 5/22/06, Paul Querna <[EMAIL PROTECTED]> wrote:


Possibly even donate
code for a C based parser.



Sounds good. There is also a C version of the Apache Axiom xml model that
the proposed ARI codebase has been written with which should make it 
easier.

The Axiom C code hasn't been split off into a separate project, which was
done for Axiom/Java, but it is modular within the codebase.



I am a little scared of the Axiom C code right now.. Maybe its really 
not that scary to someone who knows it :)


I am currently using the xmlTextReaderRead of libxml2, and it appears 
that Axiom is also using that underneath.


Do you know of an Axiom C tutorial, introduction, or documentation?

Things like the README:
https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/axiom/README

Appear to be empty :)

Thanks,

Paul


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ARI, Atom Reference Implementation [Proposal]

[Paul Querna]

Garrett Rooney wrote:
> On 5/22/06, James M Snell <[EMAIL PROTECTED]> wrote:
>>
>> Hello,
>>
>> The following is a new project incubation proposal. We welcome your
>> feedback and would like to extend a invitation for participation
>> including mentors.
>>
>> The proposal is also located at
>>   http://wiki.apache.org/incubator/AriProposal
>>
>> The initial source for the project is available at:
>>   http://www.snellspace.com/public/ari.tar.gz
> 
> I would be interested in helping to mentor this project, and perhaps
> eventually working on C implementations of some of its functionality.

I am also interested in helping mentor the project, and to work on a C
implementation of its functionality.  Possibly even donate
code for a C based parser.

Paul Querna


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OFBiz Marketing and Services

[Paul Querna]

Yoav Shapira wrote:

Hola,
Sure, but J Aaron already beat me to it ;)

One other decent page not included in his post is
http://www.apache.org/info/support.cgi of HTTP support providers.  The
text at the top is good.


This one is a really bad example. It hasn't been updated in *years*.

-Paul


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Solr

[Paul Querna]

I would be interested in helping out with Solr.

Next Steps?

Yonik Seeley wrote:

Hello Incubator PMC folks,

I would like to propose a new Apache project named Solr.
http://wiki.apache.org/incubator/SolrProposal
The project is being proposed as a sub-project of Lucene, and the
Lucene PMC has agreed to be the sponsor.

-Yonik


'''Proposal for new project Solr '''

Yonik Seeley -- yonik at apache dot org


'''(0) rationale'''

Solr is a search server based on Apache Lucene and focused on
full-text search, relevancy, and performance.

Some of the server features include:
   * Query and update interfaces over HTTP and XML.
   * Replication based on index snapshots and rsync.
   * A schema allowing declarative specification of fields and their
types, including specification of text analysis filter chains.
   * External configuration for Lucene parameters, stopword lists, and
synonym lists.
   * A web based admin interface with statistics and debugging.
   * An extensive caching framework for filters, queries, documents,
and user caches.
   * Plugins for customizing query handling, caching and many other
server aspects.

Solr is currently an internal CNET project, and is used to power
search and faceted browsing in a number of CNET sites.

'''(0.1) criteria'''

''Meritocracy: ''

Solr's developers are comfortable operating as a meritocracy.

''Community: ''

Establishing an active open source community will be the top priority.

''Core Developers:''

Solr starts with three committers.

''Alignment:''

Solr currently uses the following Apache projects: Ant, Lucene.

'''(0.2) warning signs'''

''Orphaned products: ''

Solr is not an orphan, use within CNET is growing rapidly.

''Inexperience with open source:''

Solr's committers are experienced with open source and have made
contributions to other open source projects.

''Homogenous developers:''

Solr's initial committers are all CNET employees since it's currently
an internal project.

''Reliance on salaried developers:''

Some committers are currently paid to make contributions to Solr.

''No ties to other Apache products:''

Solr has strong ties to Lucene.

''A fascination with the Apache brand:''

The committers respect the Apache brand and feel that Apache is the
right place to generate a strong open source community.

'''(1) scope of the subprojects'''

The scope of the project is to provide a stand-alone full-text search server.
The proposal is that this project become a sub-project of Apache Lucene.

'''(2) identify the initial source from which the subproject is to be
populated'''

CNET will donate the initial source code for this project.

'''(3) identify the ASF resources to be created '''


'''(3.1) mailing list(s) '''

 * solr-dev
 * solr-user

'''(3.2) Subversion or CVS repositories'''

 * https://svn.apache.org/repos/asf/incubator/solr

'''(3.3) Jira '''

 * Solr (SOLR)

'''(4) identify the initial set of committers '''

 * Yonik Seeley, CNET (Lucene committer)
 * Bill Au, CNET
 * Chris Hostetter, CNET

'''(5) identify apache sponsoring individual '''
 * Doug Cutting, Champion
 * Lucene PMC, Sponsor
 (as defined in
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] @domain for Incubator mailing lists

[Paul Querna]

Jochen Wiedmann wrote:

Noel J. Bergman wrote:


We don't support any of those.


Who's "we"? As a user, I still prefer marc over mail-archives a real lot 
and am happy about any Apache project that's available on Marc.


mod_mbox[1] accepts patches. Feel free to help for any part of mod_mbox 
or mail-archives.apache.org.


I really could use some help with integrating Lucene or another method 
to do full text searching of the archives right now.  But help with any 
part is always welcome.


-Paul

[1] http://httpd.apache.org/mod_mbox/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Lucene4c

[Paul Querna]

Garrett Rooney wrote:
I'd like to propose the Lucene4c project for incubation.
+1.  I would love to see Lucene4c take off, and making it part of Lucene 
 would be a great boost to it.

-Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]