Re: Looking for an incubation champion
Oliver Zeigermann [EMAIL PROTECTED] wrote on 07/03/2007 21:31:17: Not if the code is developed outside the ASF (as seems the case here). Hmm, is that so? Looking at the charter http://jakarta.apache.org/commons/charter.html I could not find something like that. It is possbible to take in external projects, James accepted mime4j and jspf. Perhaps you should ask on [EMAIL PROTECTED] d. *** The information from the Student Loans Company Ltd contained in this e-mail is private and privileged. If you have received this e-mail in error be advised that any use is strictly prohibited. Please notify us and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As internet communications are capable of data corruption it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. This footnote also confirms that this email message has been swept for the presence of computer viruses, however we do not accept any liability or responsibility for resultant virus infection. Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. The Student Loans Company Ltd registered office is at 21 St Thomas Street, Bristol, BS1 6JS and it is registered in England Company No. 02401034, VAT No. 556 4352 32. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for an incubation champion
--- 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... ;) 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. 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 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] Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for an incubation champion
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
Re: Looking for an incubation champion
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
Re: Looking for an incubation champion
--- Niall Pemberton [EMAIL PROTECTED] wrote: [SNIP] 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 Actually I knew about this but thought I remembered someone (Henri?) saying later that having gotten the code in this way might not have been the best choice in retrospect. Does that ring any bells with anyone? -Matt 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] Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
