Re: [VOTE][ANN] Qpid M2 Release

[Rajith Attapattu]

Thanks Kevan.
Appreciate your help in reviewing and helping us through the licensing
issues.

Regards,

Rajith

On Nov 20, 2007 6:54 PM, Kevan Miller <[EMAIL PROTECTED]> wrote:

>
> On Nov 20, 2007, at 5:05 PM, Rajith Attapattu wrote:
>
> Hi All,
>
> We have resolved the licensing issues and updated the NOTICE and LICENSE
> files.
> The the new release candidates are available at the same location.
> The keys and svn tag can be accessed using the same URL's as well.
>
>
> Hi Rajith,
> The new binaries look good to me. Here's my +1
>
> --kevan
>
>
>
> Regards,
>
> Rajith
>
> On Nov 16, 2007 1:42 PM, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
>
> > Hi Kevan,
> >
> > We rebuild the java RC after cleaning up the dependencies.
> > Since there are no code changes (except for one file which removed
> > references to commons logging) and only POM changes, we decided to restart
> > the vote on incubator list. We have also communicated the message to the
> > qpid list.
> >
> > Here are the details.
> >
> > The signed artifacts for the M2 final release is available at
> > http://people.apache.org/~rajith/qpid-release/M2/Final/
> > 
> >
> > The keys are located at,
> > https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/KEYS
> >
> > All artifacts can be downloaded as a single tar file at,
> > http://people.apache.org/~rajith/qpid-release/M2/Final/final.tar.gz
> >
> > The release artifacts can be built using the following tag,
> > https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/
> >
> > Regards,
> >
> > Rajith
> >
> >  On Nov 14, 2007 10:07 AM, Kevan Miller <[EMAIL PROTECTED]> wrote:
> >
> > > Hi Rajith,
> > > Where is the license information for artifacts included in your
> > > binaries?
> > > Your notice files refer to non-apache licenses for a number of your
> > > artifacts. I would expect to see these licenses included in your
> > > distribution. You don't give any license info for a few jars (e.g. msv
> > > and servlet-api jars). If servlet-api is a Sun jar, then I think you
> > > probably have an issue...
> > >
> > > Here's my -1 until the above issues are resolved.
> > >
> > > --kevan
> > > On Nov 12, 2007, at 12:33 PM, Rajith Attapattu wrote:
> > >
> > > > Folks,
> > > >
> > > > The Qpid PPMC is happy to notify the completion of the vote for the
> > > > Qpid M2
> > > > release.
> > > > We would appreciate if the incubator PMC could ratify the release.
> > > >
> > > > There were 12 binding votes in total, including 3 mentor votes.
> > > > The following is the vote thread.
> > > >
> > > http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/200711.mbox/browser
> > > >
> > > > Here are the details pertaining to the vote.
> > > >
> > > > The signed artifacts for the M2 final release is available at
> > > > http://people.apache.org/~rajith/qpid-release/M2/Final/
> > > < http://people.apache.org/%7Erajith/qpid-release/M2/Final/
> > > > >
> > > >
> > > > The keys are located at,
> > > > https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/java/
> > > > KEYS
> > > >
> > > > All artifacts can be downloaded as a single tar file at,
> > > > http://people.apache.org/~rajith/qpid-release/M2/Final/final.tar.gz
> > >  > >
> > > > >
> > > >
> > > > The release artifacts can be built using the following tag,
> > > > https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/
> > > >
> > > > Regards,
> > > >
> > > > Rajith Attapattu
> > > > Red Hat
> > > > Blog http://mutlix.blogspot.com/
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> >
> > Rajith Attapattu
> > Red Hat
> > Blog http://mutlix.blogspot.com/
> >
>
>
>
> --
> Rajith Attapattu
> Red Hat
> Blog http://mutlix.blogspot.com/
>
>
>


-- 
Rajith Attapattu
Red Hat
Blog http://mutlix.blogspot.com/

Re: [VOTE][ANN] Qpid M2 Release

[Kevan Miller]

On Nov 20, 2007, at 5:05 PM, Rajith Attapattu wrote:


Hi All,

We have resolved the licensing issues and updated the NOTICE and  
LICENSE files.

The the new release candidates are available at the same location.
The keys and svn tag can be accessed using the same URL's as well.


Hi Rajith,
The new binaries look good to me. Here's my +1

--kevan




Regards,

Rajith

On Nov 16, 2007 1:42 PM, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
Hi Kevan,

We rebuild the java RC after cleaning up the dependencies.
Since there are no code changes (except for one file which removed  
references to commons logging) and only POM changes, we decided to  
restart the vote on incubator list. We have also communicated the  
message to the qpid list.


Here are the details.


The signed artifacts for the M2 final release is available at
http://people.apache.org/~rajith/qpid-release/M2/Final/

The keys are located at,
https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/KEYS


All artifacts can be downloaded as a single tar file at,
http://people.apache.org/~rajith/qpid-release/M2/Final/final.tar.gz

The release artifacts can be built using the following tag,
https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/

Regards,

Rajith

On Nov 14, 2007 10:07 AM, Kevan Miller <[EMAIL PROTECTED]> wrote:
Hi Rajith,
Where is the license information for artifacts included in your
binaries?
Your notice files refer to non-apache licenses for a number of your
artifacts. I would expect to see these licenses included in your
distribution. You don't give any license info for a few jars (e.g. msv
and servlet-api jars). If servlet-api is a Sun jar, then I think you
probably have an issue...

Here's my -1 until the above issues are resolved.

--kevan
On Nov 12, 2007, at 12:33 PM, Rajith Attapattu wrote:

> Folks,
>
> The Qpid PPMC is happy to notify the completion of the vote for the
> Qpid M2
> release.
> We would appreciate if the incubator PMC could ratify the release.
>
> There were 12 binding votes in total, including 3 mentor votes.
> The following is the vote thread.
> 
http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/200711.mbox/browser
>
> Here are the details pertaining to the vote.
>
> The signed artifacts for the M2 final release is available at
> http://people.apache.org/~rajith/qpid-release/M2/Final/< 
http://people.apache.org/%7Erajith/qpid-release/M2/Final/
> >
>
> The keys are located at,
> https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/java/
> KEYS
>
> All artifacts can be downloaded as a single tar file at,
> http://people.apache.org/~rajith/qpid-release/M2/Final/ 
final.tar.gz >
>
> The release artifacts can be built using the following tag,
> https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/
>
> Regards,
>
> Rajith Attapattu
> Red Hat
> Blog http://mutlix.blogspot.com/


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




--

Rajith Attapattu
Red Hat
Blog http://mutlix.blogspot.com/



--
Rajith Attapattu
Red Hat
Blog http://mutlix.blogspot.com/

Fwd: [VOTE][ANN] Qpid M2 Release

[Kevan Miller]

Oops. Accidentally sent this to Rajith directly, rather than to  
[EMAIL PROTECTED]


--kevan

Begin forwarded message:


From: Kevan Miller <[EMAIL PROTECTED]>
Date: November 19, 2007 5:15:50 PM EST
To: Rajith Attapattu <[EMAIL PROTECTED]>
Subject: Re: [VOTE][ANN] Qpid M2 Release


On Nov 16, 2007, at 1:42 PM, Rajith Attapattu wrote:


Hi Kevan,

We rebuild the java RC after cleaning up the dependencies.
Since there are no code changes (except for one file which removed  
references to commons logging) and only POM changes, we decided to  
restart the vote on incubator list. We have also communicated the  
message to the qpid list.


Here are the details.

The signed artifacts for the M2 final release is available at
http://people.apache.org/~rajith/qpid-release/M2/Final/

The keys are located at,
https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/KEYS

All artifacts can be downloaded as a single tar file at,
http://people.apache.org/~rajith/qpid-release/M2/Final/final.tar.gz

The release artifacts can be built using the following tag,
https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/

Regards,

Rajith

On Nov 14, 2007 10:07 AM, Kevan Miller <[EMAIL PROTECTED]>  
wrote:

Hi Rajith,
Where is the license information for artifacts included in your
binaries?
Your notice files refer to non-apache licenses for a number of your
artifacts. I would expect to see these licenses included in your
distribution. You don't give any license info for a few jars (e.g.  
msv

and servlet-api jars). If servlet-api is a Sun jar, then I think you
probably have an issue...

Here's my -1 until the above issues are resolved.


Hi Rajith,
Apologies for the slow response.

I still don't see licenses for a number of projects which seem to be  
included in your binary distribution. For instance, the following is  
taken from NOTICE.txt in the DOTNET binary:


This product also includes software developed by:

 - The SAXON XSLT Processor from Michael Kay distributed under the  
Mozilla

   Public License v1.0, which is available for download at
   http://saxon.sourceforge.net/

 - The nunit library, Copyright © 2002 James W. Newkirk, Michael C.  
Two,
   Alexei A. Vorontsov or Copyright © 2000-2002 Philip A. Craig.  
Available

   under terms based on the zlib/libpng licence. Available from
   http://www.nunit.org/

 - The Mentalis Security Library, Copyright © 2002-2006, , The  
Mentalis.org Team
   under tterms based on the BSD license (http://www.mentalis.org/site/license.qpx 
).

   Available from http://www.mentalis.org/soft/projects/seclib/

These licenses should be reproduced in your source and binary  
distributions.


--kevan

Buildr, Ruby license and packaging

[Matthieu Riou]

Hi,

The Buildr podling which entered incubation recently needs to address the
problem of releasing Ruby code under the ASF. There are basically two
questions that we'll need to answer before being able to do any release:

   1. As most Ruby libraries reuse the Ruby license [1], in which category
(A, B or X) does the Ruby license fall according to the third-party licenses
draft policy [2].

   2. Does the license of third-party software matters for Ruby given that
they're only used as Gems (the Ruby packaging system, see later for more)
and never distributed. As an example, Buildr uses a LGPL library although
none of that code is ever distributed with Buildr. Would that dependency
need to be removed?

For the first question, Sam seemed to think that the Ruby license would fall
in category B (see a thread I've posted some time ago on legal-discuss [3]).
That means we would just need to warn our users so that they don't
unknowingly create a derivative work. What would be an acceptable way to do
that in a Ruby distribution? Would the NOTICE file be enough? An additional
warning in the download section? Another idea?

The packaging system for Ruby is called RubyGems, it's very similar to what
exists in the *nix world and installs eventual dependencies for you. A
standard Ruby software is bundled in this package called a gem that includes
a descriptor with all the dependencies. When you ask RubyGems to install a
gem for you, it will ask whether you want to download each of its
dependencies and download and install them locally. Or do nothing if you
happen to already have the dependencies installed. So when you distribute a
Gem, you're usually only distributing your own code and the rest could be
considered part of the environment.

Apparently the problem would be in the fact that gems are exploded when
installed (see [3] again) but I fail to see how that would make a difference
with the licenses we're worried about (say GPL and LGPL, v2 and v3). Any
hint?

To get back to Buildr's specific case, we only have one LGPL dependency that
wouldn't be too hard to remove. It would penalize performance a bit so it
would still be nice to be able to use it but we could make it an option and
do without it for the default setup. But we have quite a few Ruby licensed
dependencies that we wouldn't be able to do without.

Thanks!
Matthieu

[1] http://www.ruby-lang.org/en/LICENSE.txt
[2] http://people.apache.org/~rubys/3party.html
[3]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200708.mbox/[EMAIL 
PROTECTED]

Re: [VOTE][ANN] Qpid M2 Release

[Rajith Attapattu]

Hi All,

We have resolved the licensing issues and updated the NOTICE and LICENSE
files.
The the new release candidates are available at the same location.
The keys and svn tag can be accessed using the same URL's as well.

Regards,

Rajith

On Nov 16, 2007 1:42 PM, Rajith Attapattu <[EMAIL PROTECTED]> wrote:

> Hi Kevan,
>
> We rebuild the java RC after cleaning up the dependencies.
> Since there are no code changes (except for one file which removed
> references to commons logging) and only POM changes, we decided to restart
> the vote on incubator list. We have also communicated the message to the
> qpid list.
>
> Here are the details.
>
> The signed artifacts for the M2 final release is available at
> http://people.apache.org/~rajith/qpid-release/M2/Final/
> 
>
> The keys are located at,
> https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/KEYS
>
> All artifacts can be downloaded as a single tar file at,
> http://people.apache.org/~rajith/qpid-release/M2/Final/final.tar.gz
>
> The release artifacts can be built using the following tag,
> https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/
>
> Regards,
>
> Rajith
>
> On Nov 14, 2007 10:07 AM, Kevan Miller <[EMAIL PROTECTED]> wrote:
>
> > Hi Rajith,
> > Where is the license information for artifacts included in your
> > binaries?
> > Your notice files refer to non-apache licenses for a number of your
> > artifacts. I would expect to see these licenses included in your
> > distribution. You don't give any license info for a few jars (e.g. msv
> > and servlet-api jars). If servlet-api is a Sun jar, then I think you
> > probably have an issue...
> >
> > Here's my -1 until the above issues are resolved.
> >
> > --kevan
> > On Nov 12, 2007, at 12:33 PM, Rajith Attapattu wrote:
> >
> > > Folks,
> > >
> > > The Qpid PPMC is happy to notify the completion of the vote for the
> > > Qpid M2
> > > release.
> > > We would appreciate if the incubator PMC could ratify the release.
> > >
> > > There were 12 binding votes in total, including 3 mentor votes.
> > > The following is the vote thread.
> > >
> > http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/200711.mbox/browser
> > >
> > > Here are the details pertaining to the vote.
> > >
> > > The signed artifacts for the M2 final release is available at
> > > http://people.apache.org/~rajith/qpid-release/M2/Final/
> > < http://people.apache.org/%7Erajith/qpid-release/M2/Final/
> > > >
> > >
> > > The keys are located at,
> > > https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/java/
> > > KEYS
> > >
> > > All artifacts can be downloaded as a single tar file at,
> > > http://people.apache.org/~rajith/qpid-release/M2/Final/final.tar.gz
> >  > > >
> > >
> > > The release artifacts can be built using the following tag,
> > > https://svn.apache.org/repos/asf/incubator/qpid/tags/M2/Final/
> > >
> > > Regards,
> > >
> > > Rajith Attapattu
> > > Red Hat
> > > Blog http://mutlix.blogspot.com/
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
>
> Rajith Attapattu
> Red Hat
> Blog http://mutlix.blogspot.com/
>



-- 
Rajith Attapattu
Red Hat
Blog http://mutlix.blogspot.com/

Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement

[Eelco Hillenius]

> I would agree with reviewing committers at graduation, but how do we
> implement that?

I would say that this depends on the judgment of the mentors, and it
is probably more important to evaluate the role they would be playing
in the project once it is over to Apache, than what happened before
entering incubation.

> Would you kick out people during graduation, if they don't show
> sufficient merit?

I don't think you can make rules for that. Imho it's simple. The
project has to prove it can behave the Apache way, and the project's
members are responsible for this. People not functioning well in a
project can be a reason to reject incubation, so the members better
make sure that doesn't happen.

> Or re-elect all committers before graduation?

That might be a good idea actually.

Eelco

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

Re: [PROPOSAL] Shindig, an OpenSocial Container

[Brian McCallister]

I'll update the proposal for changes from the discussion thus far and  
bing it to a vote ASAP.


Meanwhile, initial (and gnarly, following bad is good for open  
source ;-) seeder code:

http://people.apache.org/~brianm/shindig.tgz

-Brian

On Nov 9, 2007, at 10:03 AM, Brian McCallister wrote:


Shindig Proposal
--

= Abstract =

Shindig will develop the container and backend server components
for hosting OpenSocial applications.

= Proposal =

Shindig will develop a JavaScript container and implementations of
the backend APIs and proxy required for hosting OpenSocial  
applications.



= Background =

OpenSocial provides a common set of APIs for social applications
across multiple websites. With standard JavaScript and HTML,
developers can create social applications that use a social network's
friends and update feeds.

A social application, in this context, is an application run by a
third party provider and embedded in a web page, or web application,
which consumes services provided by the container and by the
application host. This is very similar to Portal/Portlet technology,
but is based on client-side compositing, rather than server.

More information can be found about OpenSocial at
http://code.google.com/apis/opensocial/

== Rationale ==

Shindig is an implementation of an emerging set of APIs for client- 
side

composited web applications. The Apache Software Foundation has
proven to have developed a strong system and set of mores for
building community-centric, open standards based systems with a
wide variety of participants.

A robust, community-developed implementation of these APIs will
encourage compatibility between service providers, ensure an excellent
implementation is available to everyone, and enable faster and
easier application development for users.

The Apache Software Foundation has proven it is the best place for
this type of open development.


= Current Status =

This is a new project.

= Meritocracy =

The initial developers are very familiar with meritocratic open
source development, both at Apache and elsewhere. Apache was chosen
specifically because the initial developers want to encourage this
style of development for the project.

=== Community ===

Shindig seeks to develop developer and user communities during
incubation.


= Core Developers =

The initial core developers are all Ning employees. We hope to
expand this very quickly.

= Alignment =

The developers of Shindig want to work with the Apache Software
Foundation specifically because Apache has proven to provide a
strong foundation and set of practices for developing standards-based
infrastructure and server components.

= Known Risks =

== Orphaned products ==

Shindig is new development of an emerging set of APIs.

== Inexperience with Open Source ==

The initial developers include long-time open source developers,
including Apache Members.

== Homogenous Developers ==

The initial group of developers is quite homogenous. Remedying this
is a large part of why we want to bring the project to Apache.

== Reliance on Salaried Developers ==

The initial group of developers are employed by a potential consumer
of the project. Remedying this is a large part of why we want to
bring the project to Apache.

== Relationships with Other Apache Products ==

None in particular, except that Apache HTTPD is the best place to
run PHP, which the server-side components Ning intends to donate
have been implemented in.

==  A Excessive Fascination with the Apache Brand ==

We believe in the processes, systems, and framework Apache has put
in place. The brand is nice, but is not why we wish to come to
Apache.

= Documentation =

Google's OpenSocial Documentation:
   http://code.google.com/apis/opensocial/

Ning's OpenSocial Documentation:
   http://tinyurl.com/3y5ckx

= Initial Source =

Ning, Inc. intends to donate code based on their implementation of
OpenSocial. The backend systems will be replaced with more generic
equivalents in order to not bind the implementation to specifics
of the Ning platform.

This code will be extracted from Ning's internal development, and
has not been expanded on past the extraction. It will be provided
primarily as a starting place for a much more robust, community- 
developed

implementation.

= External Dependencies =

The initial codebase relies on a library created by Google, Inc.,
and licensed under the Apache Software License, Version 2.0.

= Required Resources =

Developer and user mailing lists

A subversion repository

A JIRA issue tracker

= Initial Committers =

   Thomas Baker<[EMAIL PROTECTED]>
   Tim Williamson  <[EMAIL PROTECTED]>
   Brian McCallister   <[EMAIL PROTECTED]>
   Thomas Dudziak  <[EMAIL PROTECTED]>
   Martin Traverso <[EMAIL PROTECTED]>

= Sponsors =

== Champion ==

   Brian McCallister   <[EMAIL PROTECTED]>

== Nominated Mentors ==

   Brian McCallister   <[EMAIL PROTECTED]>
   Thomas Dudziak  <[EMAIL PROTECTED]>
   Santiago Gala   <[EMAIL P

Re: RAT set up [WAS Re: [RESULT] [VOTE] RAT to enter incubator]

[Robert Burrell Donkin]

On Nov 19, 2007 11:23 PM, Craig L Russell <[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> On Nov 19, 2007, at 3:14 PM, Robert Burrell Donkin wrote:
>
> > On Nov 18, 2007 11:44 PM, Craig L Russell <[EMAIL PROTECTED]>
> > wrote:
> >> Just one question. Why are you not a mentor for this project? I don't
> >> see anything in the rules against it, and I believe it will be easier
> >> all around if you can also wear the mentor hat.
> >
> > it would probably be easier but i thought that independent mentors
> > would be healthier and the experience might be educational
>
> I'd say we were conflating the two roles played by mentors:
>
> Mentoring the podling
>
> Providing infrastructure support for the podling

+1

infrastructure approval should probably rest with the IPMC in general
rather than the mentors specifically

> > i'll go with my original plan and email the mentors
>
> I have no issue with you doing infrastructure for the rat project...

it's something i really should have done anyway

- robert

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

Re: Karma to commit IP Clearance form

[Jeremias Maerki]

Cameron,

the directory for the IP clearance forms seems to be restricted to
members, PMC chairs, the apsite group and the incubator projects. You
can also just send the XML file to me and I'll handle it.

Nevertheless, I think it would make sense to open at least the
"ip-clearance" directory to all committers. That makes it easier for
everyone to help with necessary evils like IP clearance.

Jeremias Maerki



On 20.11.2007 12:32:18 Cameron McCormack wrote:
> Hi incubator PMC.
> 
> Could I please have karma to commit an IP clearance form to SVN.
> 
> Thanks,
> 
> Cameron
> (username cam)
> 
> -- 
> Cameron McCormack, http://mcc.id.au/
>   xmpp:[EMAIL PROTECTED]  ▪  ICQ 26955922  ▪  MSN [EMAIL PROTECTED]


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

Karma to commit IP Clearance form

[Cameron McCormack]

Hi incubator PMC.

Could I please have karma to commit an IP clearance form to SVN.

Thanks,

Cameron
(username cam)

-- 
Cameron McCormack, http://mcc.id.au/
xmpp:[EMAIL PROTECTED]  ▪  ICQ 26955922  ▪  MSN [EMAIL PROTECTED]

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

Re: [DISCUSS] Community diversity: current concerns and suggestions for improvement

[Bertrand Delacretaz]

On Nov 19, 2007 8:05 PM, Craig L Russell <[EMAIL PROTECTED]> wrote:

> ...Some of the discussion here to me seems to be backward: adding
> constraints to the entry of a podling to the incubator...

Agreed, we shouldn't add more constraints than needed.

> ...A couple of additional comments below...
>
> On Nov 19, 2007, at 9:05 AM, Jukka Zitting wrote:
> > ...IMHO we should allow
> > everyone who is actively involved with the codebase to follow the code
> > as a committer within the incubating project.
>
> I agree. How can we exclude folks who are already active on a project?...

Totally agreed, we want to include the members of an existing
community when a podling enters incubation.

But currently we are not asking if these people are actually members
of an existing community, that's a simple question that we could add:
indicate what role this committer has had in the project before it
entered incubation.

It is currently too easy to add someone to the list of initial
committers, you just need to put their email address, without any
"meritocracy filtering". And with our process, these people stay on
the list when the project graduates (more about that below).

I'm not saying we have any such committers at the moment, but our
process does not prevent that scenario.

> ...So I have no issue with anyone becoming a committer on a podling,
> given that all of the podling committers are reviewed at graduation
> to make sure they've demonstrated their commitment to the project...

I would agree with reviewing committers at graduation, but how do we
implement that?

Would you kick out people during graduation, if they don't show
sufficient merit?

Or re-elect all committers before graduation?

-Bertrand

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