incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gudnabr...@yahoo.com
Subject Re: [PROPOSAL] Commons Incubator
Date Sat, 11 Apr 2009 15:21:48 GMT


--- On Sat, 4/11/09, Torsten Curdt <tcurdt@apache.org> wrote:

> From: Torsten Curdt <tcurdt@apache.org>
> Subject: Re: [PROPOSAL] Commons Incubator
> To: general@incubator.apache.org
> Date: Saturday, April 11, 2009, 5:44 AM
> > My view, and I believe Torstens
> view is that to become a committer means to
> > join the dev lists, send in patches, be part of the
> community, gain trust
> > with the project members and then after a while be
> voted in as a committer.
> > Now if someone has a nice great big chunk of code, or
> even a whole
> > mini-subproject to donate, then they should so just
> that, donate the code
> > and if they wish to continue working on that code then
> send in patches to
> > the list or issue tracker. Eventually you'll get
> commit access, will have
> > learnt the Apache Way and all is dandy.
> >
> > The 'other' view is I believe mainly Company
> orientated. Company X pays
> > person Y to work on code that they want to be
> 'donated' to Project Z (which
> > just happens to have come from Company X in the first
> place.) The last thing
> > they want is for person Y to go through the Apache Way
> initiation ceremony
> > that could last months, they want him/her in there
> carrying on committing to
> > it as usual. Hence we have the 'here's some code,
> here's a new committer or
> > two to go with it'.
> 
> Just to clarify. The proposal is to find a middle ground
> between these
> two approaches.
> 

I'd like to verbally probe each approach now.  It would seem that approach B (advocated by
Gavin) subjects the donor(s) of the code to an endurance trial whereby he/they earn the right
to work directly with their own creation.  I think most of us would agree that in this position
we would simply go to sf.net, google code, or wherever.  I will go further and say that any
"outsider" willing to go this route is likely salivating over "the Apache Brand" which is
discouraged as a prospective podling's primary reason for incubating, IIUC.  These factors
force me to a conclusion that approach B yields "no externally contributed Commons components"
(what we have today), or, at best, "parasites."  Note that we have tried this approach before
in Commons (although I am not sure whether the original donors actually intended to contribute
beyond the initial grant); the CSV component has languished in the sandbox, more or less "withering
on the vine."  The lesson
 learned by the community was new components without accompanying committers don't work.

Returning to approach A (advocated by Niclas), the Commons PMC are collectively not comfortable
with granting free run of Commons' numerous components (the privilege of Commons committers)
to newcomers _before_ they have demonstrated their understanding of The Apache Way.  But if
it is the collective opinion of the Incubator PMC that we can choose to do such if we like,
I would take that to mean that the Commons PMC should modify its charter to provide for appropriate
handling of "outsider" sandbox (or whatever distinction we may decide upon) committers, process
IP clearances as normal, and go our merry way.  This would satisfy the intent of our proposal
while allowing us to be satisfied that we have not sidestepped any procedures.

-Matt


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



      

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


Mime
View raw message