Feedback sought! -Matt
--- Apache Wiki <[EMAIL PROTECTED]> wrote: > Dear Wiki user, > > You have subscribed to a wiki page or wiki category > on "Commons Wiki" for change notification. > > The following page has been changed by MattBenson: > http://wiki.apache.org/commons/CommonsIncubatorProposal > > The comment on the change is: > Initial proposal for a Commons Incubator > > New page: > 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 considers > itself an open community in 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 in which existing Incubator practices > are suboptimal for Commons' requirements is > 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. Commons > expects this situation would be compounded by the > large number of components currently slated for > incubation. It would be seen as 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 > > (Applicable at incubating component level) > > Orphaned Products: > > Inexperience with Open Source: > > Homogenous Developers: > > Reliance on Salaried Developers: > > 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: > Single Subversion tree under Incubator or Commons > > Issue Tracking: > A single JIRA project with subcomponents to be > managed by Mentors > > > INITIAL COMMITTERS > > (Applicable at incubating component level) > > > AFFILIATIONS > > (Applicable at incubating component level) > > > SPONSORS > > Champion: Henri Yandell (or I will champion if > you're going to be too busy -MJB) > > Nominated Mentors: Henri Yandell, Matt Benson(, > volunteers?) > > Sponsoring Entity: Commons PMC > > > April 10, 2008 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
