commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [ALL] Accepting codebases
Date Wed, 29 Apr 2009 21:53:52 GMT
On Mon, Apr 27, 2009 at 7:37 PM, Phil Steitz <> wrote:
> Rahul Akolkar wrote:
>> So the Sanselan discussion more broadly triggers a few thoughts in my
>> mind, but this thread is not meant to be Sanselan specific.
> Still an hour or so left to VOTE ;)

Caliberating still with this thread :-)

>> Understanding that not all decisions are objective, I still haven't
>> convinced myself that I have a reasonable set of somewhat objective
>> criteria that I can iterate over in determining the suitability of
>> codebases (and communities by association) proposed for addition to
>> Commons. This is in turn about two viewpoints (assumed reasonable):
>>  * We want the Commons community to grow and prosper, we want Commons
>> code to do new and interesting things
> +1
>>  * We want Commons to sustain growth and (a) not become too fragmented
>> or (b) not become an umbrella
> +0 - I want the community to remain healthy.  Not so much "growth" as
> continuous renewal.  +1 on trying to avoid fragmentation.

Yup, agreed.

>> In terms of growth, theres a couple of models and we haven't had many
>> M&A style scenarios -- i.e. once seeded, we've more or less had
>> organic growth with few exceptions.
>> In terms of the Apache Incubator, there is a potential of having other
>> podlings reach Sanselan's status-quo. With the existing metric we
>> would be hard pressed to not accept any of those (which in turn leads
>> to the concerns in the second bullet above). Another approach, for
>> example, would be for interested Commons committers to actually engage
>> with the podling community first, and then propose addition to Commons
>> (i.e. instead of saying we'd like 3 committers working on the code,
>> its 3 -- or 2 -- existing Commons committers interested/working on
>> code).
> If people have the cycles to do this, great.  If not and the component comes
> with some existing ASF committers (as Sanselan does), then I am personally
> OK with continuing our tradition of welcoming ASF committers with their
> code.  A graduating Incubator podling with ASF committers working on it is
> not dissimilar,  IMO, to a component spun off from another project (e.g.
> runtime).

OK, so I spotted the difference. The two cases were dissimilar to me
(and still are).

The latter is seeding code in the sandbox. So, using [runtime] as an
example, we are all here observing what mturk is upto and at some
point maybe others will jump in. Maybe not. But there is an extended
interaction between the code and communities leading up to a potential
graduation. IOW, there is a gentler introduction -- my claim is thats
good from the community standpoint.

The former is a podling from the Apache Incubator becoming part of
Commons Proper. None of the Commons committers were involved there
(that I know of) -- there are important differences from the above

>   The bar that I think we do need to set is that there are engaged
> committers coming with the code.

Over on general@iao, when there was talk about Commons potentially
being the "dumping ground", it was clear that wasn't the case as there
would be some filter applied at Commons' discretion. I'm trying to
grasp what that filter is. Obviously, many podlings will have three
committers (actually all since we are counting mentors ;-) so I wonder
if that is any effective at all as a filter.

>  Interest from within the current commons
> community is obviously also a big plus and my references to "committers" is
> really only for bootstrapping - i.e., we welcome all volunteers - we just
> need committers to get a component started.

And to hopefully stay involved, mesh into the larger Commons fabric
and help with mundane Commonsy things.

>> On unrelated notes (though some of this has come up elsewhere before)
>> I'd prefer for all components old and new:
>>  * o.a.c packages
> +1
>>  * use of commons-parent, common-skin etc.
> +1 if maven is the chosen build tool.  I do not think we should require all
> commons components to use maven.

Sure, where applicable.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message