[PROPOSAL] Commons Incubator

[Matt Benson]

Note: Resending due to my having neglected the [PROPOSAL] subject line earlier.

==========================

Commons Incubator Proposal

ABSTRACT

The Commons Incubator would act as a "perpetual podling" or "mini-Incubator" overseeing the influx of components to be adopted into Apache Commons.


BACKGROUND

Apache Commons, a conglomerate of smallish Java libraries, lacks a good procedure for importing preexisting codebases.


RATIONALE

  The typical ASF top-level project (TLP) absorbs code donations by means of a software grant.  Clearly delineated subprojects (usually partially or completely dependent on the TLP) often enter instead through the Incubator.  Commons, as a project that has no code other than that of its subprojects, is essentially a microcosm of the ASF itself.  Commons has long offered a
sandbox area for the development of new ideas, similar to the approach now taken in Apache Labs.  With regard to the creation of new subprojects from preexisting codebases, however, the PMC is in agreement that procedures similar to those in practice in the ASF Incubator are more appropriate
than the software grant approach, given that the Incubator has already formalized much the same process as would need to be taken to guarantee the acceptability of donated code.  Unfortunately the processes of the Incubator proper are not a perfect fit.

  With regard to community exit requirements, a typical podling requires a heterogenous community of three or more developers.  Commons is an open community in the sense that all Commons committers have karma to all components, thus any component to graduate into Commons proper inherits an existing, diverse community.  This greatly mitigates any component's risk of orphanhood.  The PMC envisions Commons' incubator space as functioning in a manner similar to that in which its development sandbox currently operates:  all ASF committers are welcome to participate in the Commons sandbox, and would be welcome to contribute to incubating components, subject to a natural consensus-building process.  Active contributors to graduating components would be accepted into the project as full Commons committers with shared karma.

  Another aspect of existing Incubator practices that is suboptimal for Commons' requirements is the fact that, a Commons component being a relatively small entity, it is difficult to justify expending the
same effort to set one up as would typically be required for a normal-sized podling.  For this reason it would be advantageous to keep incubating Commons components under a single Subversion tree, and as subcomponents of a single JIRA project.  Finally, the existing Commons communications lists could be utilized.  Component setup would thus be minimal.

  Having established that setting up a Commons Incubator separate from the Apache Incubator would be counterproductive and quite a duplication of effort, Commons would like to see established on its behalf a "special case" podling or miniature Incubator whose exit criteria parallel those Commons uses to gauge the propriety of a sandbox component's promotion to "proper" status, namely:

  * The component is ready for its first ASF release.
  * At least three people are available for development/maintenance.
  * All Incubator legal checks have been passed.


INITIAL GOALS

  Prove/hone the Commons Incubator approach on several candidates that have been proposed as new Apache Commons subprojects, and for which a PMC vote indicates willingness to incubate.


CURRENT STATUS

  (Applicable at incubating component level)

Meritocracy:

Community:

Core Developers:

Alignment:


KNOWN RISKS

  (Where applicable, at incubating component level)

Orphaned Products:

  N/A

Inexperience with Open Source:

Homogenous Developers:

  N/A

Reliance on Salaried Developers:

  N/A

No Ties to Other Apache Products:

A Fascination with the Apache Brand:


DOCUMENTATION

  (Applicable at incubating component level)


INITIAL SOURCE

  (Applicable at incubating component level)


EXTERNAL DEPENDENCIES
  Optimally any non-optional dependencies for Commons components will be other Commons
  components.  Failing that, normal ASF third-party licensing policies to be enforced.


REQUIRED RESOURCES

Mailing Lists:
  Commons lists

Subversion Directory:
  Umbrella under Commons or Incubator

Issue Tracking:
  JIRA project with subcomponents to be managed by Mentors a la Commons Sandbox


INITIAL COMMITTERS

  (Applicable at incubating component level)


AFFILIATIONS

  (Applicable at incubating component level)


SPONSORS

Champion:  Henri Yandell

Nominated Mentors:  Henri Yandell, Matt Benson(, need volunteer/s)

Sponsoring Entity:  Commons PMC


April 9, 2009


     

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

[Justin Erenkrantz]

On Thu, Apr 9, 2009 at 9:23 AM, Matt Benson <gudnabrsam@...> wrote:
> The Commons Incubator would act as a "perpetual podling" or "mini-Incubator" overseeing the influx of components to be adopted into Apache Commons.

-1 (vote, not veto).

If Commons PMC wants to import code, then it can file IP clearances.
If it wants to incubate communities, then it needs to follow the rest
of the Incubator procedures.  -- justin

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

[Niclas Hedhman]

On Fri, Apr 10, 2009 at 11:59 AM, Justin Erenkrantz
<justin@...> wrote:
> On Thu, Apr 9, 2009 at 9:23 AM, Matt Benson <gudnabrsam@...> wrote:
>> The Commons Incubator would act as a "perpetual podling" or "mini-Incubator" overseeing the influx of components to be adopted into Apache Commons.
>
> -1 (vote, not veto).
>
> If Commons PMC wants to import code, then it can file IP clearances.
> If it wants to incubate communities, then it needs to follow the rest
> of the Incubator procedures.  -- justin

I'm also thinking like Justin. Incubator is all about community
incubation and 'training' the new group of people the ApacheWay. If
you take that out of the equation, why do you need Incubator at all.
Be a bit more agile in IP Clearances directly into your 'sandbox' and
take it from there...


Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

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

[Torsten Curdt]

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.

cheers
--
Torsten

On Fri, Apr 10, 2009 at 08:59, Niclas Hedhman <niclas@...> wrote:

> On Fri, Apr 10, 2009 at 11:59 AM, Justin Erenkrantz
> <justin@...> wrote:
>> On Thu, Apr 9, 2009 at 9:23 AM, Matt Benson <gudnabrsam@...> wrote:
>>> The Commons Incubator would act as a "perpetual podling" or "mini-Incubator" overseeing the influx of components to be adopted into Apache Commons.
>>
>> -1 (vote, not veto).
>>
>> If Commons PMC wants to import code, then it can file IP clearances.
>> If it wants to incubate communities, then it needs to follow the rest
>> of the Incubator procedures.  -- justin
>
> I'm also thinking like Justin. Incubator is all about community
> incubation and 'training' the new group of people the ApacheWay. If
> you take that out of the equation, why do you need Incubator at all.
> Be a bit more agile in IP Clearances directly into your 'sandbox' and
> take it from there...
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I  live here; http://tinyurl.com/2qq9er
> I  work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
>

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

[Matt Benson]

--- On Fri, 4/10/09, Torsten Curdt <tcurdt@...> wrote:

> From: Torsten Curdt <tcurdt@...>
> Subject: Re: [PROPOSAL] Commons Incubator
> To: general@...
> Date: Friday, April 10, 2009, 5:32 AM
> 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.
>

Thanks Torsten--I think you've pointed out the proverbial Scylla and Charybdis here:

 * IP clearance means reducing the original authors of codebase X to contributor status.  It could be argued that this is a way of teaching them that within the context of the ASF, the direction of "their" code will be determined by the community.  More likely, however, they will simply opt to take their ball and go home.  Surely there are better ways to teach the "Apache way."

 * "full" Incubation sets a small component up for failure to graduate due to not gaining a community large or diverse enough to satisfy Incubator graduation requirements, when, were the same code to begin life in the Commons sandbox, originated by ANY existing ASF committer, it would be subject to somewhat less stringent graduation (to Commons "proper") requirements.

The other problem with full incubation, inordinate effort to set up _n_ relatively tiny podlings, really affects infrastructure more than it affects Commons.

The current state of affairs makes it highly impractical for any codebase that includes IP from a non-ASF-committer to enter Apache Commons.  What we are asking for could be alternately seen as the Incubator's blessing to establish a "decontamination chamber" much like our sandbox but where community members can commit prior to their component being accepted into Commons "proper" and their consequentially becoming "true" ASF committers.  Note that some of my wording reflects a perception on my part that there is a difference between a podling committer and a committer to some TLP (or TLP subproject).  If that is not the case, I'd be interested to know that, but I don't believe it affects the overall argument here either way.  We need an officially sanctioned concept for "Commons podling committer."

[SNIP]
> > On Fri, Apr 10, 2009 at 11:59 AM, Justin Erenkrantz
> > <justin@...>
> wrote:
[SNIP]
> >>
> >> -1 (vote, not veto).

Finally, I'm apparently not familiar enough with incubator procedures to understand "when a -1 is not a veto."  Can anyone provide any more info on that?  :)

Regards,
Matt

[SNIP]



     

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

[Min Cha]

Hi.

I think that Matt have well explained needs for Commons Incubator . In
addition to that, this is a short story from my experience. One month ago, I
introduced my component called as Robust-Task through Commons mailing and
Incubator mailing. There were some opinions for my component and I thought
my component may be suitable for Commons because it is relatively small and
similar to Commons Chain. So, I wanted that my component is incubated by
Commons. However, I saw a point that I don`t commit anymore if I send my
component to Commons Sandbox which seems to be used as incubator in Commons.
I thought that this is not reasonable. This was a difficult problem to me.

With this experience, now I also see a need for Commons Incubator. In my
opinion, Commons Incubator aims at resolving a new problem, not an
overlapped problem.

On Fri, Apr 10, 2009 at 11:56 PM, Matt Benson <gudnabrsam@...> wrote:

>
>
>
> --- On Fri, 4/10/09, Torsten Curdt <tcurdt@...> wrote:
>
> > From: Torsten Curdt <tcurdt@...>
> > Subject: Re: [PROPOSAL] Commons Incubator
> > To: general@...
> > Date: Friday, April 10, 2009, 5:32 AM
> > 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.
> >
>
> Thanks Torsten--I think you've pointed out the proverbial Scylla and
> Charybdis here:
>
>  * IP clearance means reducing the original authors of codebase X to
> contributor status.  It could be argued that this is a way of teaching them
> that within the context of the ASF, the direction of "their" code will be
> determined by the community.  More likely, however, they will simply opt to
> take their ball and go home.  Surely there are better ways to teach the
> "Apache way."
>
>  * "full" Incubation sets a small component up for failure to graduate due
> to not gaining a community large or diverse enough to satisfy Incubator
> graduation requirements, when, were the same code to begin life in the
> Commons sandbox, originated by ANY existing ASF committer, it would be
> subject to somewhat less stringent graduation (to Commons "proper")
> requirements.
>
> The other problem with full incubation, inordinate effort to set up _n_
> relatively tiny podlings, really affects infrastructure more than it affects
> Commons.
>
> The current state of affairs makes it highly impractical for any codebase
> that includes IP from a non-ASF-committer to enter Apache Commons.  What we
> are asking for could be alternately seen as the Incubator's blessing to
> establish a "decontamination chamber" much like our sandbox but where
> community members can commit prior to their component being accepted into
> Commons "proper" and their consequentially becoming "true" ASF committers.
>  Note that some of my wording reflects a perception on my part that there is
> a difference between a podling committer and a committer to some TLP (or TLP
> subproject).  If that is not the case, I'd be interested to know that, but I
> don't believe it affects the overall argument here either way.  We need an
> officially sanctioned concept for "Commons podling committer."
>
> [SNIP]
> > > On Fri, Apr 10, 2009 at 11:59 AM, Justin Erenkrantz
> > > <justin@...>
> > wrote:
> [SNIP]
> > >>
> > >> -1 (vote, not veto).
>
> Finally, I'm apparently not familiar enough with incubator procedures to
> understand "when a -1 is not a veto."  Can anyone provide any more info on
> that?  :)
>
> Regards,
> Matt
>
> [SNIP]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
>

--
Min Cha, Dreaming Developer
Task Framework :
http://code.google.com/p/robust-coupe/wiki/RobustTaskIntroduction
English : http://minslovey.blogspot.com
Korean : http://minslovey.tistory.com

[Niclas Hedhman]

On Fri, Apr 10, 2009 at 6:32 PM, Torsten Curdt <tcurdt@...> 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.

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.

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.

Either there is a community in Commons, or there is not. If the
latter, then normal Incubation is the way forward.

IMHO, the Commons community MUST step up and be the oversight
required, i.e. train the committers as well as assist in releases and
make sure that the legal oversight is in place. IFF that can be
assured, _I_ see no problems at all making people committers out of a
'bulk contribution'. IF it can NOT be assured, and each subproject is
left on its own, then Commons have a larger problem...
And, if you so decide, you can always stick things into the sandbox
first and make sure that people behave, that legal requirements are in
place and what not, before making the final step.


Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

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

[Niclas Hedhman]

On Fri, Apr 10, 2009 at 10:56 PM, Matt Benson <gudnabrsam@...> wrote:

> The current state of affairs makes it highly impractical for any codebase that includes IP from a non-ASF-committer to enter Apache Commons.

I think this is a self-imposed constraint. Many other projects have no
problem bringing in 'bulk' via IP Clearance and taking in one or two
committers with it.


Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

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

[Torsten Curdt]

On Sat, Apr 11, 2009 at 10:22, Niclas Hedhman <niclas@...> wrote:

> On Fri, Apr 10, 2009 at 6:32 PM, Torsten Curdt <tcurdt@...> 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.

cheers
--
Torsten

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

[Torsten Curdt-2]

> I think this is a self-imposed constraint.

Indeed it is.

> Many other projects have no
> problem bringing in 'bulk' via IP Clearance and taking in one or two
> committers with it.

Well, some do :) That's why now there is the proposal I guess ;)

cheers
--
Torsten

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

[gavin-105]

> -----Original Message-----
> From: tcurdt@... [mailto:tcurdt@...] On Behalf Of Torsten
> Curdt
> Sent: Saturday, 11 April 2009 7:26 PM
> To: general@...
> Subject: Re: [PROPOSAL] Commons Incubator
>
> On Sat, Apr 11, 2009 at 10:22, Niclas Hedhman <niclas@...> wrote:
> > On Fri, Apr 10, 2009 at 6:32 PM, Torsten Curdt <tcurdt@...>
> 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@...
> For additional commands, e-mail: general-help@...
>
>
>
> --
> 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@...
For additional commands, e-mail: general-help@...

[Torsten Curdt]

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

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

[Matt Benson]

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

> From: Torsten Curdt <tcurdt@...>
> Subject: Re: [PROPOSAL] Commons Incubator
> To: general@...
> 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@...
> For additional commands, e-mail: general-help@...
>
>



     

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

[robert burrell donkin-2]

On Sat, Apr 11, 2009 at 10:56 AM, Gavin <gavin@...> wrote:
>> -----Original Message-----
>> From: tcurdt@... [mailto:tcurdt@...] On Behalf Of Torsten

<snip>

>> The incubator approach just doesn't work well for projects that have a
>> very small scope and user base IMO.

+1

the smaller the code base, the more problems the incubator has with it

micro-libraries are particularly difficult

>> The current incubator is about
>> establishing a project. We rather would to like to have something that
>> helps integration into an existing project.

from the incubator perspective, IMO the effort that the incubator has
had to put into small code bases has been totally out of proportion
and this energy would have been much better invested into stopping
some of the larger, higher profile failures. it's time to acknowledge
that the incubator only has a certain level of energy and the IPMC
should be investing it where the risks and gains are highest.

the commons has established an excellent track record in understanding
how to develop micro-libraries as a community. if the commons can
supply the energy required to create a specialist section for small
code bases then this will allow the IPMC to focus it's efforts on the
larger code bases.

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

this required enculturalisation of close code bases was a major
driving factor behind the setting up of the incubator. the incubator
has been successful at doing this.

the incubator has been less successful with existing openly developed
FOSS projects, and IMO it's few successes have a lot more to do with
the qualities of the incoming projects than the effectiveness of it's
methods.

the incubator has not enjoyed success with small code bases. commons
has a wealth of expertise with these kinds of projects.

from an IPMC perspective, i think we need to grab this chance to get
some help on this. however, IMHO i'm not sure that we can hit upon the
right set of rules straight away, and i'm also not sure whether the
current proposal is the right approach. i do think we should approve
the principle of a specialist incubator for small codebases staffed by
experts from the commons.

- robert

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

[Bernd Fondermann-2]

On Sat, Apr 11, 2009 at 21:24, Robert Burrell Donkin
<robertburrelldonkin@...> wrote:

> On Sat, Apr 11, 2009 at 10:56 AM, Gavin <gavin@...> wrote:
>>> -----Original Message-----
>>> From: tcurdt@... [mailto:tcurdt@...] On Behalf Of Torsten
>
> <snip>
>
>>> The incubator approach just doesn't work well for projects that have a
>>> very small scope and user base IMO.
>
> +1
>
> the smaller the code base, the more problems the incubator has with it
>
> micro-libraries are particularly difficult
>
>>> The current incubator is about
>>> establishing a project. We rather would to like to have something that
>>> helps integration into an existing project.
>
> from the incubator perspective, IMO the effort that the incubator has
> had to put into small code bases has been totally out of proportion
> and this energy would have been much better invested into stopping
> some of the larger, higher profile failures. it's time to acknowledge
> that the incubator only has a certain level of energy and the IPMC
> should be investing it where the risks and gains are highest.
>
> the commons has established an excellent track record in understanding
> how to develop micro-libraries as a community. if the commons can
> supply the energy required to create a specialist section for small
> code bases then this will allow the IPMC to focus it's efforts on the
> larger code bases.
>
>> 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)
>
> this required enculturalisation of close code bases was a major
> driving factor behind the setting up of the incubator. the incubator
> has been successful at doing this.
>
> the incubator has been less successful with existing openly developed
> FOSS projects, and IMO it's few successes have a lot more to do with
> the qualities of the incoming projects than the effectiveness of it's
> methods.
>
> the incubator has not enjoyed success with small code bases. commons
> has a wealth of expertise with these kinds of projects.
>
> from an IPMC perspective, i think we need to grab this chance to get
> some help on this. however, IMHO i'm not sure that we can hit upon the
> right set of rules straight away, and i'm also not sure whether the
> current proposal is the right approach. i do think we should approve
> the principle of a specialist incubator for small codebases staffed by
> experts from the commons.

I sympathize with the general desire to be able to grow small code
bases at Apache. (We had this discussion in the labs list a short
while ago.) And for sure the Common's people have know-how how to
handle small projects.

But, establishing "Commons Labcubator" within the Incubator doesn't
seem like the right approach to me. Either it's a Commons project,
then it should grow in Commons, or it's another project's small code
base, then it should be nurtured there, or it's something completely
different, then it should grow in Labs (which is language agnostic,
BTW).

I'd like to re-iterate though, that dealing with (developing and
releasing) independent small code bases (in terms of contributors and
code) is not easily possible at the ASF at the moment. This is why we
lost the Orthrus Lab to Google Code. The more projects and products we
host, the more difficult (or impossible) it gets to spot the
interesting ones.

So this is not only a Commons-specific issue. It also applies to other
"regular TLP"s and Labs as well.

  Bernd

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

[Niall Pemberton-2]

On Sat, Apr 11, 2009 at 9:22 AM, Niclas Hedhman <niclas@...> wrote:

> On Fri, Apr 10, 2009 at 6:32 PM, Torsten Curdt <tcurdt@...> 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.
>
> 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.
>
> 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.

You're insinuating too much here. Simply put the commons PMC would
want to see committers in action before making them full blown Commons
committers. This is no different from any of the other incubations
that then graduate into an existing TLP. There are no boundaries
between components in Commons - all committers have svn access to all
components.

The key points AIUI of Matts proposal
  - make it "perpetual" so that the resources don't have to be set up
every time for every little component
  - use the existing Commons mailing lists - so that the interactions
of prospective components take place within the normal commons
environment

Niall

> Either there is a community in Commons, or there is not. If the
> latter, then normal Incubation is the way forward.
>
> IMHO, the Commons community MUST step up and be the oversight
> required, i.e. train the committers as well as assist in releases and
> make sure that the legal oversight is in place. IFF that can be
> assured, _I_ see no problems at all making people committers out of a
> 'bulk contribution'. IF it can NOT be assured, and each subproject is
> left on its own, then Commons have a larger problem...
> And, if you so decide, you can always stick things into the sandbox
> first and make sure that people behave, that legal requirements are in
> place and what not, before making the final step.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I  live here; http://tinyurl.com/2qq9er
> I  work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
>

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

[Niclas Hedhman]

On Sun, Apr 12, 2009 at 5:55 AM, Niall Pemberton
<niall.pemberton@...> wrote:

> You're insinuating too much here. Simply put the commons PMC would
> want to see committers in action before making them full blown Commons
> committers. This is no different from any of the other incubations
> that then graduate into an existing TLP. There are no boundaries
> between components in Commons - all committers have svn access to all
> components.

Ok, I just deleted a long elaboration over the Open Participation
Software for Java (www.ops4j.org) community experiment, but I don't
think it would be appreciated. Instead, I say this;

Letting everyone have write access to all Commons sub-projects, is not
an ASF requirement. You may distinguish between the sandbox and the
rest. And you may give people coming in with the code, commit rights
to sandbox while observing and teaching them what Apache is all about.
And you may have a unspoken rule of no releases from sandbox, as an
incentive of people to sharpen up.

Although I generally agree with Robert's sentiment, I don't think the
Comcubator will lessen the burden on the Incubator PMC. Not
necessarily by intent, but that there will be individuals who will
want to help out, that are currently helping out on Incubator, thus
thinning time for everything else.


Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

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

[Santiago Gala-4]

El sáb, 11-04-2009 a las 11:28 +0200, Torsten Curdt escribió:

> > I think this is a self-imposed constraint.
>
> Indeed it is.
>
> > Many other projects have no
> > problem bringing in 'bulk' via IP Clearance and taking in one or two
> > committers with it.
>
> Well, some do :) That's why now there is the proposal I guess ;)
>

I think, like Niclas, I guess, that what is not functional is the
Commons practice, and that having a kludge on the whole incubator won't
really fix any problem, while adding complexity to what is already the
most complex part of the ASF.

Regards
Santiago

> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>


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

[Santiago Gala-4]

El sáb, 11-04-2009 a las 19:56 +1000, Gavin escribió:

>
> > -----Original Message-----
> > From: tcurdt@... [mailto:tcurdt@...] On Behalf Of Torsten
> > Curdt
> > Sent: Saturday, 11 April 2009 7:26 PM
> > To: general@...
> > Subject: Re: [PROPOSAL] Commons Incubator
> >
> > On Sat, Apr 11, 2009 at 10:22, Niclas Hedhman <niclas@...> wrote:
> > > On Fri, Apr 10, 2009 at 6:32 PM, Torsten Curdt <tcurdt@...>
> > 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

Non sequitur, and I think not the case under discussion. *My* other view
is a person (definitely not a BigCo) that has developed a small code
chunk (library, etc.) that would fit nicely in a given project. The code
is taken and the person is granted commit rights.
a) code changes can be undone in case of error, this is what scm is for
b) there is -1 (veto) on technical decisions, that helps settling the
community after the addition
c) the person does not feel that her code is stolen, etc.

Obviously I don't mean a policy cast in stone, but a judgement call on
the given PMC. If they feel there can be any problems, there are several
ways forward:
- have the prospect committer donate the code and  send patches for a
while (as Gavin proposes) without being committer
- have the prospect committer "refactor" the code in a sandbox, where
s/he can be watched, as learning process
- ...

Regards
Santiago

> 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@...
> > For additional commands, e-mail: general-help@...
> >
> >
> >
> > --
> > 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@...
> For additional commands, e-mail: general-help@...
>

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

[Santiago Gala-4]

El dom, 12-04-2009 a las 12:35 +0800, Niclas Hedhman escribió:

> On Sun, Apr 12, 2009 at 5:55 AM, Niall Pemberton
> <niall.pemberton@...> wrote:
>
> > You're insinuating too much here. Simply put the commons PMC would
> > want to see committers in action before making them full blown Commons
> > committers. This is no different from any of the other incubations
> > that then graduate into an existing TLP. There are no boundaries
> > between components in Commons - all committers have svn access to all
> > components.
>
> Ok, I just deleted a long elaboration over the Open Participation
> Software for Java (www.ops4j.org) community experiment, but I don't
> think it would be appreciated. Instead, I say this;
>
> Letting everyone have write access to all Commons sub-projects, is not
> an ASF requirement. You may distinguish between the sandbox and the

And there are *social* barriers too. For instance, in portals.apache.org
every committer, by design, has access to the whole portals repository,
i.e., to pluto/jetspeed/common... repositories, but a, say, jetspeed
committer arriving from nowhere to commit code in pluto would surely
face -1. Even myself arriving from inactivity to patch something would
get extra scrutiny and would have to justify carefully what I did unless
I commit some really obvious small fix to a bug, and even so.

Regards
Santiago

> rest. And you may give people coming in with the code, commit rights
> to sandbox while observing and teaching them what Apache is all about.
> And you may have a unspoken rule of no releases from sandbox, as an
> incentive of people to sharpen up.
>
> Although I generally agree with Robert's sentiment, I don't think the
> Comcubator will lessen the burden on the Incubator PMC. Not
> necessarily by intent, but that there will be individuals who will
> want to help out, that are currently helping out on Incubator, thus
> thinning time for everything else.
>
>
> Cheers

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