incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gavin" <ga...@16degrees.com.au>
Subject RE: [PROPOSAL] Commons Incubator
Date Sat, 11 Apr 2009 09:56:05 GMT


> -----Original Message-----
> From: tcurdt@vafer.org [mailto:tcurdt@vafer.org] On Behalf Of Torsten
> Curdt
> Sent: Saturday, 11 April 2009 7:26 PM
> To: general@incubator.apache.org
> Subject: Re: [PROPOSAL] Commons Incubator
> 
> On Sat, Apr 11, 2009 at 10:22, Niclas Hedhman <niclas@hedhman.org> wrote:
> > On Fri, Apr 10, 2009 at 6:32 PM, Torsten Curdt <tcurdt@apache.org>
> wrote:
> >> Well, the point is: we are  talking about small libraries.
> >>
> >> Imagine there is library X which was developed by only 2 developers.
> >> They want to bring this code to Commons. What to do? IP clearance is
> >> one thing. But what about the 2 developers? Just make them committers
> >> while they have no clue about Apache? Doesn't sound like a good idea.
> >> Just accepting their code and make them send patches until we feel
> >> they are ready? Feels not appropriate since they are the authors of
> >> the code. On the other hand going through the "normal" incubator is a
> >> bit over the top for a project that is so small that it is not
> >> targeting to become it's own project. Building a community is not
> >> really that applicable in this case. It's rather about integrating it
> >> into an existing community.
> >
> > Careful now, you are sinking your own proposal with your arguments.
> 
> Not at all. You are mixing things up :)
> 
> > 1. The proposal says that there is no need to build a community, since
> > the entire Commons community is there to make sure everything is Ok.
> 
> Indeed that is the case.
> 
> > 2. You say that you can't just make them committers, insinuating that
> > the Commons community will NOT be there to make sure everything is Ok.
> 
> No - that is just you saying that :)
> 
> There is a difference between having oversight and training people in
> the Apache way. This is not the same thing.
> 
> If other projects get new committers through bulk contributions and
> train them later... Well, then that is suboptimal from my perspective.
> Any future committer has to learn the Apache way "the hard way". Just
> throwing some code at us doesn't make them understand. And this is
> were this approach falls down for us.
> 
> I personally have not experience with such contributions "thanks for
> the code *magic wand* now you are also a committer". Either the new
> people have been around long enough so making them a committer soon
> after the code contribution was a non-problem or they sent patches
> until we felt they are ready. But hey - might have been differently
> for other projects ...not that I would be very happy about it.
> 
> The incubator approach just doesn't work well for projects that have a
> very small scope and user base IMO. The current incubator is about
> establishing a project. We rather would to like to have something that
> helps integration into an existing project.

I understand both points of view here. Unfortunately however different
circumstances of the code 'donations' are getting differing treatment.

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

The 'other' view imho is wrong and just bypasses what we are about. Every
now and then someone has to remind us, we are a group of individuals
belonging to a community that works on code. Company Z and all the other
Companies out there need to understand this, especially when considering
employing someone and paying them to work on open source projects. (Can't
you just tell I don’t work for a Company Z)

In Company Z defence, the ASF has benefitted greatly and is greatly enhanced
by projects that have been brought in by these Company types. Many projects
would not have even got off the ground if it wasn’t for them. In return
however there have been willing volunteers jumping in and joining these
projects and providing their own free volunteer time and coding expertise
that advantage mainly Company Z because they sell services that use the
projects product.

In summary I don’t agree with a Commons Incubator, just get the code cleared
and accepted, get the developers to join the ranks of patch makers until you
feel they are ready for committer-ship (which is much more than just code,
and who knows they may grasp the concept quickly and be ready in a couple of
months).

Gav...

> 
> cheers
> --
> Torsten
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.557 / Virus Database: 270.11.51/2052 - Release Date:
> 4/10/2009 6:39 AM


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


Mime
View raw message