commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [ALL] Accepting codebases
Date Mon, 27 Apr 2009 23:37:14 GMT
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 ;)
> 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
>  * 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.
> 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).   The bar that I think we do need to set 
is that there are engaged committers coming with the code.  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.
> 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
>  * 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. 

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

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

View raw message