On 3/8/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 3/8/07, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Niall Pemberton <[EMAIL PROTECTED]> wrote:
>
> > On 3/7/07, Matt Benson <[EMAIL PROTECTED]> wrote:
> [PARAPHRASED: a bunch of stuff about
> morph.sourceforge.net coming into the ASF, potentially
> under the Jakarta umbrella]
> [SNIP]
> >
> > As others have said ASF policy is for externally
> > developed codebases
> > to go through incubation. AFAIK though there are two
> > possible routes -
> > the "full incubation" route, or a "short form" to
> > bring code straight
> > into an existing project. This is what Commons Math
> > did recently with
> > the Mantissa contribution:
> >
> > http://incubator.apache.org/ip-clearance/index.html
> >
> > Whether this is appropriate for Morph is another
> > question. As a
> > general observation (and occasional BeanUtils
> > committer) it seems to
> > me that many of these types of libraries such as
> > Commons BeanUtils[1],
> > OGNL[2], Commons JEXL[3], Commons EL[4], Commons
> > Convert[5] fail to
> > attract a developer community larger than 1 or 2 and
> > as such are
> > always precariously only ever one step away from
> > being inactive
> > projects. Morph with 2 developers faces a similar
> > challenge. Now maybe
> > if you go for "full incubation" you'll attract a
> > large enough
> > community to prove this wrong and go TLP. I have to
> > say I think its
> > doubtful - since IMO these kind of libraries people
> > want to use - but
> > not work on. Jakarta Commons seems to have overcome
> > to a certain
> > extent the problem of getting 3 votes on projects
> > with only 1 or 2
> > developers - with developers from other components
> > "pitching in" to
> > help get releases out.
> >
> > If you feel that Morph has a reasonable chance by
> > going the "full
> > incubation" route (and by that I mean meeting the
> > "community" exit
> > criteria) then most of the above is irrelevant. If
> > you don't think it
> > does then maybe the "short form" route into
> > somewhere like Commons is
> > worth exploring.
>
> In the light you put it, the "big project composed of
> smaller components" structure of the commons does
> sound like a good safety net for all these
> library-style components.  Maybe you're right that
> most developers don't like building relatively small
> but essential utility code (I can't imagine why not;
> it takes all kinds I guess).  Anyway, this short form
> route, of which I was unaware, does indeed sound like
> a worthwhile avenue of inquiry.  Also, this seems to
> be the same thing Danny Angus said later--thanks
> Danny!
>
> >
> > One last point - the "short form" is just about code
> > (not
> > developers/community) - but with the Math Mantissa
> > contribution Luc
> > (the author) was voted in shortly after the code.
> > I'm sure if Commons
> > accepted Morph, then they would be equally keen to
> > see Matt join as
> > well to continue work on it.
>
> I assume you were referring to "the other Matt":
> Sgarlata, as I myself am a (recently added) Jakarta
> committer... but wanted to clarify for the benefit of
> our readers... ;)

Yes sorry - too many Matts :-)

> So to recap, ASF policy allows for the import of
> externally developed code into an existing project (in
> contrast with accepting a codebase as a full-fledged
> project for incubation).  As Jakarta is a
> project-with-subprojects, the IP clearance policy in
> question is somewhat of a back door:  the imported
> code may (or may not) remain self-sufficient (as can
> any Jakarta subproject) but technically falls under
> this policy.  I suppose this would apply doubly for a
> prospective commons component as it would be
> considered a subproject of the commons subproject of
> the Jakarta TLP.  I don't believe I am exposing any
> secret loophole here:  I would think it would be
> expected that a PMC operate however it sees fit within
> the limits of ASF policy.

I didn't know whether this had been done before in Commons - but seems
that it has for the Commons CSV component back in December 2005:

http://incubator.apache.org/ip-clearance/jakarta-commons-csv.html

Niall

> The above can be considered a test of my grasp of this
> policy; as such confirmation, contradiction, or
> clarification is welcome.

The way Jakarta Commons operates is that any ASF commiter (such as
yourself) can start a new Commons component in the Sandbox. In the
case of seeding that component with an external code base such as
Morph - this short form ensures that all the usual Incubator checks
(e.g. IP, CLA's etc) are done so that there are no issues with
bringing the code into the ASF.

Once the incubator checks are done and the code is in the Commons
Sandbox, you still then need to meet meet the usual criteria to exit
the Sandbox and become a proper Commons component. I think the
downside of going this route will be the way it differs for Matt
Sgarlata - since hes not an ASF commiter. In the "full incubator"
route he would enter the incubator with the code. This way he would
need to be voted in in the usual way - so theres likely to be some
time where he can only work on his code by submitting patches - which
may not be acceptable to him as the original author.

> With all that said, this, again, does sound like a
> possibly more promising line of investigation than
> full-on incubation.  But what's next?  :o

I'm not expert in these things, but perhaps the following:

- check if Matt Sgarlata would be happy with this route
- raise it on the Incubator list outlining what you want to do and see
if they think it acceptable
- see if there is support/objections to this in Commons

Niall

> br,
> Matt
>
> >
> > Niall
> >
> > [1] http://jakarta.apache.org/commons/beanutils/
> > [2] http://www.opensymphony.com/ognl/
> > [3] http://jakarta.apache.org/commons/jexl/
> > [4] http://jakarta.apache.org/commons/el/
> > [5]
> > http://jakarta.apache.org/commons/sandbox/convert/
> >
> > > br,
> > > Matt
> > >
> > > >
> > > > Niall
> > > >
> > > > > Thanks,
> > > > > Matt


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to