Oops; accidentally sent to general-subscribe: --- On Tue, 4/7/09, Matt Benson <gudnabr...@yahoo.com> wrote:
> From: Matt Benson <gudnabr...@yahoo.com> > Subject: Commons Incubator proposal > To: "incubator-general" <general-subscr...@incubator.apache.org> > Cc: priv...@commons.apache.org > Date: Tuesday, April 7, 2009, 10:10 AM > > Below is the proposal to be found at > http://wiki.apache.org/incubator/CommonsIncubatorProposal > . For example, this would (subject to community > approval, of course) be an acceptable avenue for incubation > in Commons of the JEHA project proposed in the past few > days. Commons is more or less unable to accept > components of external origin until this proposal or a > suitable alternative is adopted. Please voice any > concerns or propose any such alternatives. > > Thanks, > Matt > > ========================== > > 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 7, 2009 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: private-unsubscr...@commons.apache.org > For additional commands, e-mail: private-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
