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
+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.
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
+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.
Phil
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
