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.
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]
