Re: [Jakarta Wiki] Update of "Carolina+Coast+" by NathanBubna
Never mind--with the current barrage I see that this is apparently a Moin convention. :) -Matt --- Matt Benson <[EMAIL PROTECTED]> wrote: > Hi Nathan, > Is this an officially sanctioned (by the ASF) text > for > deleted wiki pages? > > Thanks, > Matt > > --- Apache Wiki <[EMAIL PROTECTED]> wrote: > > > Dear Wiki user, > > > > You have subscribed to a wiki page or wiki > category > > on "Jakarta Wiki" for change notification. > > > > The following page has been changed by > NathanBubna: > > http://wiki.apache.org/jakarta/Carolina+Coast+ > > > > The comment on the change is: > > delete spam > > > > > -- > > - spam deleted > > + deleted > > > > > > > - > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > Take the Internet to Go: Yahoo!Go puts the Internet > in your pocket: mail, news, photos & more. > http://mobile.yahoo.com/go?refer=1GNXIC > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of "Carolina+Coast+" by NathanBubna
Hi Nathan, Is this an officially sanctioned (by the ASF) text for deleted wiki pages? Thanks, Matt --- Apache Wiki <[EMAIL PROTECTED]> wrote: > Dear Wiki user, > > You have subscribed to a wiki page or wiki category > on "Jakarta Wiki" for change notification. > > The following page has been changed by NathanBubna: > http://wiki.apache.org/jakarta/Carolina+Coast+ > > The comment on the change is: > delete spam > > -- > - spam deleted > + deleted > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
IIRC Torsten had already added himself to the proposal, then after emails in which T. indicated his willingness to act as chair, Henri updated the wiki accordingly. -Matt --- "Daniel F. Savarese" <[EMAIL PROTECTED]> wrote: > > In message <[EMAIL PROTECTED]>, Roland > Weber writes: > >Rory Winston - was added by Daniel Savarese > >Torsten Curdt - was added as chair by Henri Yandell > > Rory voted for the proposal so I saved him the time > and redundancy > when I added myself after voting for the proposal. > I assume Henri > did the same for Torsten. > > daniel > > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Morph as Jakarta-sponsored podling WAS Morph proposal
--- Simon Kitching <[EMAIL PROTECTED]> wrote: > I'm definitely interested. BeanUtils tries to do too > many things in one > lib, and besides it is really ugly internally. So > something like Morph > would be very useful to have. To be honest, Morph currently does probably as much as or more than BeanUtils. However, its functionality areas are fairly well compartmentalized so that a Morph @ ASF could be easily "digested" into smaller components over time. This is what I actually hope to see, FWIW... -Matt > > For a commons-digester 2.x (if it ever occurs) I > would definitely like > to get rid of the existing BeanUtils dependency, and > that means finding > some alternative. > > However I don't personally have the time necessary > to work on this at > the moment. > > Regards, > > Simon > > On Tue, 2007-04-03 at 07:16 -0700, Matt Benson > wrote: > > Just wanted to confirm the complete lack of > interest > > here. Unless I hear differently, I'll assume > that's > > lazy [-0]s all around and let the matter drop. > > > > Thanks, > > Matt > > > > --- Matt Benson <[EMAIL PROTECTED]> wrote: > > > > > Morph's incubation proposal follows, sent here > first > > > in an effort to gain the sponsorship of Jakarta, > and > > > possibly to attract mentors as well. :) > Thanks! > > > > > > Morph defines a comprehensive API for performing > > > object-to-object conversions in > > > Java. > > > > > > PROPOSAL > > > > > > > > > BACKGROUND/RATIONALE > > > > > > As information flows through an application, > it > > > undergoes multiple transformations. While the > most > > > prevalent examples of this in the J2EE space are > > > well-known (e.g. HTTP request parameters to > > > domain/data transfer objects, DTOs to domain > > > objects) > > > the overall problem space is characterized by > the > > > lack > > > of a simple, well-known, conveniently extensible > > > solution. At least one JSR (295) describes such > a > > > facility as a dependency. Having identified the > > > basic > > > commonalities among the best known application > > > operations requiring object conversion, Morph > > > consolidates these into a single API which, > along > > > with > > > various bundled implementation classes, seeks to > > > achieve the oft-repeated software development > goal > > > of > > > making "the simple things easy, and the hard > things > > > possible" with regard to its problem domain. > > > > > > > > > CURRENT STATUS > > > > > > Meritocracy: > > > The Morph team is eager to invest more fully > in > > > the > > > meritocracy approach taken by the ASF. To date, > > > however, Morph's development team has been > > > accumulated > > > by a sort of "meritocracy-on-spec" approach: > Matt > > > Benson was originally given > > > commit rights solely on the basis of his ideas; > only > > > later did his work vindicate that decision. [If > > > sponsored by Jakarta: This is a similar > approach > > > to that taken in the Jakarta community: a > community > > > member simply announces his desire to work on a > > > component, then proceeds with the community's > > > blessing.] > > > > > > Community: > > > It is somewhat difficult to gauge the size of > > > Morph's community. There have been modest but > > > consistent downloads of the project since its > > > initial > > > prerelease: these average 21/month over 28 > months. > > > The traffic on its user and developer lists is > > > similarly light, but several bug fixes and > > > enhancements have resulted from the input of > Morph's > > > users. An additional possible benefit of > > > Morph's joining the Apache community is that > > > increased > > > cooperation with and buy-in from other ASF > projects > > > may increase its user and/or developer > communities. > > > > > > Core Developers: > > > Matt Sgarlata is Morph's founding architect > and > > > developer. He has been a member of the Jakarta > and > > > Struts user communities for some years. Matt > Benson > > > is a member of the Apache Ant PMC
[proposal] Morph as Jakarta-sponsored podling WAS Morph proposal
Just wanted to confirm the complete lack of interest here. Unless I hear differently, I'll assume that's lazy [-0]s all around and let the matter drop. Thanks, Matt --- Matt Benson <[EMAIL PROTECTED]> wrote: > Morph's incubation proposal follows, sent here first > in an effort to gain the sponsorship of Jakarta, and > possibly to attract mentors as well. :) Thanks! > > Morph defines a comprehensive API for performing > object-to-object conversions in > Java. > > PROPOSAL > > > BACKGROUND/RATIONALE > > As information flows through an application, it > undergoes multiple transformations. While the most > prevalent examples of this in the J2EE space are > well-known (e.g. HTTP request parameters to > domain/data transfer objects, DTOs to domain > objects) > the overall problem space is characterized by the > lack > of a simple, well-known, conveniently extensible > solution. At least one JSR (295) describes such a > facility as a dependency. Having identified the > basic > commonalities among the best known application > operations requiring object conversion, Morph > consolidates these into a single API which, along > with > various bundled implementation classes, seeks to > achieve the oft-repeated software development goal > of > making "the simple things easy, and the hard things > possible" with regard to its problem domain. > > > CURRENT STATUS > > Meritocracy: > The Morph team is eager to invest more fully in > the > meritocracy approach taken by the ASF. To date, > however, Morph's development team has been > accumulated > by a sort of "meritocracy-on-spec" approach: Matt > Benson was originally given > commit rights solely on the basis of his ideas; only > later did his work vindicate that decision. [If > sponsored by Jakarta: This is a similar approach > to that taken in the Jakarta community: a community > member simply announces his desire to work on a > component, then proceeds with the community's > blessing.] > > Community: > It is somewhat difficult to gauge the size of > Morph's community. There have been modest but > consistent downloads of the project since its > initial > prerelease: these average 21/month over 28 months. > The traffic on its user and developer lists is > similarly light, but several bug fixes and > enhancements have resulted from the input of Morph's > users. An additional possible benefit of > Morph's joining the Apache community is that > increased > cooperation with and buy-in from other ASF projects > may increase its user and/or developer communities. > > Core Developers: > Matt Sgarlata is Morph's founding architect and > developer. He has been a member of the Jakarta and > Struts user communities for some years. Matt Benson > is a member of the Apache Ant PMC and a Jakarta > committer, so is familiar with (and fond of) the > consensus and transparency encouraged in ASF > development. > > Alignment: > Morph currently contains interoperability code for > commons-beanutils, commons-chain, and Velocity. > Because it is Morph's secondary purpose to provide > implementations of common conversions, code that > facilitates Morph's use with well-known libraries in > easily anticipated ways is considered in-scope. As > has already been implied, it is expected that > citizenship at the ASF would facilitate cooperation > with existing projects to mutal benefit. Finally, > precedent demonstrating the desirability of such a > project at Apache exists in the form of Jakarta > commons-convert (this component ultimately failed to > achieve maturity). Morph's original design > specifications are actually the generic > subset of those drafted on the commons-dev mailing > list as a next-generation implementation of this > project. > > > KNOWN RISKS > > Orphaned Products: > The Morph developers are part of its user base. > Object conversion may be relevant to any of various > components of a basic Java application. The risk of > "itch cessation" is therefore minimized; Morph > should > continue to be an applicable technology at low risk > for being abandoned by its developers. > > Inexperience with Open Source: > As previously indicated, one of the initial > committers has some years of experience as a > committer > and PMC member at the ASF. Additionally, Morph has > always been open-source software, with its evolution > being directly guided by user input and developer > consensus in similar fashion to other Apache > projects. > > Homogenous Developers: > On the plus si
Morph proposal
Morph's incubation proposal follows, sent here first in an effort to gain the sponsorship of Jakarta, and possibly to attract mentors as well. :) Thanks! Morph defines a comprehensive API for performing object-to-object conversions in Java. PROPOSAL BACKGROUND/RATIONALE As information flows through an application, it undergoes multiple transformations. While the most prevalent examples of this in the J2EE space are well-known (e.g. HTTP request parameters to domain/data transfer objects, DTOs to domain objects) the overall problem space is characterized by the lack of a simple, well-known, conveniently extensible solution. At least one JSR (295) describes such a facility as a dependency. Having identified the basic commonalities among the best known application operations requiring object conversion, Morph consolidates these into a single API which, along with various bundled implementation classes, seeks to achieve the oft-repeated software development goal of making "the simple things easy, and the hard things possible" with regard to its problem domain. CURRENT STATUS Meritocracy: The Morph team is eager to invest more fully in the meritocracy approach taken by the ASF. To date, however, Morph's development team has been accumulated by a sort of "meritocracy-on-spec" approach: Matt Benson was originally given commit rights solely on the basis of his ideas; only later did his work vindicate that decision. [If sponsored by Jakarta: This is a similar approach to that taken in the Jakarta community: a community member simply announces his desire to work on a component, then proceeds with the community's blessing.] Community: It is somewhat difficult to gauge the size of Morph's community. There have been modest but consistent downloads of the project since its initial prerelease: these average 21/month over 28 months. The traffic on its user and developer lists is similarly light, but several bug fixes and enhancements have resulted from the input of Morph's users. An additional possible benefit of Morph's joining the Apache community is that increased cooperation with and buy-in from other ASF projects may increase its user and/or developer communities. Core Developers: Matt Sgarlata is Morph's founding architect and developer. He has been a member of the Jakarta and Struts user communities for some years. Matt Benson is a member of the Apache Ant PMC and a Jakarta committer, so is familiar with (and fond of) the consensus and transparency encouraged in ASF development. Alignment: Morph currently contains interoperability code for commons-beanutils, commons-chain, and Velocity. Because it is Morph's secondary purpose to provide implementations of common conversions, code that facilitates Morph's use with well-known libraries in easily anticipated ways is considered in-scope. As has already been implied, it is expected that citizenship at the ASF would facilitate cooperation with existing projects to mutal benefit. Finally, precedent demonstrating the desirability of such a project at Apache exists in the form of Jakarta commons-convert (this component ultimately failed to achieve maturity). Morph's original design specifications are actually the generic subset of those drafted on the commons-dev mailing list as a next-generation implementation of this project. KNOWN RISKS Orphaned Products: The Morph developers are part of its user base. Object conversion may be relevant to any of various components of a basic Java application. The risk of "itch cessation" is therefore minimized; Morph should continue to be an applicable technology at low risk for being abandoned by its developers. Inexperience with Open Source: As previously indicated, one of the initial committers has some years of experience as a committer and PMC member at the ASF. Additionally, Morph has always been open-source software, with its evolution being directly guided by user input and developer consensus in similar fashion to other Apache projects. Homogenous Developers: On the plus side, the initial committers are united only by their common interest in Morph (and their coincidental first names and middle initials). However, both hail from the United States, and acknowledge this as a less-than-optimal level of diversity. As Java Locale support is a key strength of Morph's transformation API, wider geographical dispersal would be a boon. The inevitable input of the ASF's diverse community could only be of positive influence in this regard. Reliance on Salaried Developers: The core developers use Morph in their own paid development jobs, but are not paid to develop Morph per se. Withdrawal of support is not an issue from this perspective. No Ties to Other Apache Products: As described in the Alignment section, this library already has ties to many Apache products. Additionally, Morph'
Re: Looking for an incubation champion
--- Nathan Bubna <[EMAIL PROTECTED]> wrote: > On 3/9/07, Matt Benson <[EMAIL PROTECTED]> wrote: > > Apologies for the top post. This puts us back to > > square one, with noone, at least from Jakarta, > > apparently interested in being champion, rendering > the > > whole discussion moot. ;) Is there an > appropriate > > next step other than simply forgetting about > > incubating? > > No need to forget it if you don't find a champion > soon. Patience and > continued development of the project and the > community around it can > pay off. More interest may come in time. For > instance, i've no time > to take up the cause of a project that i'm not using > at work, but > you've piqued my curiousity about the project. When > next i need > conversion support such as it provides, i'll be sure > to investigate > Morph more deeply as an alternative to just > BeanUtils. Then, schedule > permitting, i might be willing to help with > incubation, as it would be > more in my interest. I wouldn't be surprised if > others are thinking > much as i am here. > Thanks for chiming in with that. :) I do intend in any case to continue to help Morph develop to the point of being the serious contender that it deserves to be; I just would rather do it in the setting of the ASF. br, Matt [SNIP] Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for an incubation champion
Apologies for the top post. This puts us back to square one, with noone, at least from Jakarta, apparently interested in being champion, rendering the whole discussion moot. ;) Is there an appropriate next step other than simply forgetting about incubating? -Matt --- Niall Pemberton <[EMAIL PROTECTED]> wrote: > On 3/9/07, Martin van den Bemt <[EMAIL PROTECTED]> > wrote: > > > > Niall Pemberton wrote: > > > On 3/9/07, Martin van den Bemt <[EMAIL PROTECTED]> > wrote: > > >> > > >> Matt Benson wrote: > > >> > --- 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? > > >> > > >> Yep that rings a bell and going down that route > again, is not > > >> something that has my support for > > >> *new* components (which this is). If the code > is destined for an > > >> existing codebase, we could do the > > >> IP route, else I would like to see some level > of incubation (besides > > >> handling ip). See the > > >> discussion on not-yet-commons ssl. > > > > > > I'm wondering why? Seems to me that this is a > slightly different > > > situation to either CSV or the SSL situations > since one of the > > > developers is an existing ASF and Commons > committer. > > > > There are new committers involved. With CSV Henri > is a committer (not talking karma here) (and me > > too, although we are both not very active). I > think when new people are involved incubation > (besides > > legal) should occur (even though the community > import isn't that big, compared to similar situation > > like activemq, servicemix, etc, where the core > developers are actually ASF Members) > > > > In case of this scenario (and ssl) I "envision" > this for incubation : > > > > - Get the people on board as a committer on the > initial proposal > > - Have them *show* that they are here to stay for > an x amount of time > > - Ideally have the normal exit criteria, although > I can imagine for commons a slightly weaker exit > > strategy may be adapted (don't think the incubator > thinks that eg 3 committers on a project is a > > vibrant community, although within commons it > definitely will be!). > > - Get a release out. > > > > If someone starts hacking on code in the sandbox I > am ok with that, but rather not see new code > > again hitting the sandbox, since we "don't" accept > new committers on sandbox components and it > > doesn't have the ability to have a release > (disclaimer : I became committer in Jakarta because > of a > > sandbox component, ahum). > > > > I highly prefer that incubating commons components > to use the commons-dev and commons-user list, > > since to do development however, since it would be > quite a cultural shock when moving from incubator > > specific lists to the commons ones. > > > > Disclaimer : this is just a brain dump and I would > love to see some new projects at Jakarta, but I > > think we also need to figure out how we should > handle that in a constructive way and prevent > > feedparser and csv situations. > > OK, good explanation - sounds reasonable to me. > You're right going the > incubator route would bring Matt Sgarlata in with > the code which would > be more desirable. > > Niall > > > Mvgr, > > Martin > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > - > 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
--- 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]
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
--- Oliver Zeigermann <[EMAIL PROTECTED]> wrote: > 2007/3/7, Rahul Akolkar <[EMAIL PROTECTED]>: > > On 3/7/07, Oliver Zeigermann > <[EMAIL PROTECTED]> wrote: > > > Hi Matt! > > > > > > I understand you already are a Jakarta Commons > commiter, right? > > > Wouldn't it be the easiest way to add the > project to the Commons > > > sandbox, make it ready for a release and promote > it to the proper > > > section quickly. > > > > > > AFAIK all Commons committers are allowed to > create projects in the > > > sandbox. This would mean you do not need any > champion, but could do it > > > yourself. > > > > > > Niall, others, isn't that correct? > > > > > > > > > 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. You're right AFAICT, but I would bet the explanation would involve ASF-wide policy regarding IP clearances, etc. wrt existing codebases trumping the commons charter. ;) -Matt > > Oliver > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html - 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: > > @Members: > > I have recently joined the development > > team of an OSS project, Morph, that captures the > > spirit of Jakarta commons-convert but where the > > convert project stagnated, Morph is a > well-evolved, > > though still not 100% complete, library whose > > development I feel would benefit greatly from The > > Apache Way and would make a worthy ASF project. > > Object conversion seems to be a woefully > under-served > > subject in the Java OSS space, despite the > ubiquity of > > the need for it (however well-hidden it may tend > to > > be) in enterprise Java development. I have > contacted > > a few of you personally already, but having > received > > no bites as yet I am widening my audience one last > > time before giving up on this. > > > > You can learn more about this library at: > > > > http://morph.sourceforge.net > > From looking at the "roles" document for incubator > the champion needs > to either be a member or on the Sponsoring PMC. Just > out of interest > do you have a plan for which PMC will sponsor - > incubator or maybe > Jakarta? Although you don't have to decide this > before entering the > incubator do the Morph developers have a preferred > destination if/when > they exit the incubator - e.g. their own TLP or part > of a project such > as Jakarta? Hi Niall-- Since having joined the Morph team I would consider myself to be its secondary-but-currently-most-active developer, with the primary developer being content for the time being to let me take the reins on the issue of incubation @ ASF. I go into this level of detail here so it will be clear that this answer is mine, but that I feel I am justified in giving an answer I am coming up with as I go along. Obviously some thought has already gone into what might become of Morph after a successful incubation. My feeling is that as a replacement for/significant evolution beyond commons-convert, the Jakarta commons might indeed be an appropriate home. Because Morph's feature set extends somewhat beyond the original scope of commons-convert, however, I could foresee that some might consider it more appropriate as a direct Jakarta subproject. In either case jurisdiction would belong to the same PMC, IIUC, so I think "under Jakarta" is a sufficiently detailed answer for the moment, subject of course to the approval of the Jakarta community. This explains my posting to general@ rather than [EMAIL PROTECTED] Additionally, I was operating from the perspective that a final destination is moot until a champion is found, though I did realize on some level that the likely destination within Apache could to some degree dictate the likely championship candidates. br, Matt > > Niall > > > Thanks, > > Matt > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for an incubation champion
--- Rahul Akolkar <[EMAIL PROTECTED]> wrote: > On 3/7/07, Oliver Zeigermann > <[EMAIL PROTECTED]> wrote: > > Hi Matt! > > > > I understand you already are a Jakarta Commons > commiter, right? > > Wouldn't it be the easiest way to add the project > to the Commons > > sandbox, make it ready for a release and promote > it to the proper > > section quickly. > > > > AFAIK all Commons committers are allowed to create > projects in the > > sandbox. This would mean you do not need any > champion, but could do it > > yourself. > > > > Niall, others, isn't that correct? > > > > > Not if the code is developed outside the ASF (as > seems the case here). This was my understanding as well. But nice try! ;) -Matt > > -Rahul > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for an incubation champion
Thanks for the reply, Martin. BTW, and not to derail my own topic, but what is "Mvgr?" :) -Matt --- Martin van den Bemt <[EMAIL PROTECTED]> wrote: > I've already have a promise to help out Julius with > incubation and am currently am mentor for > Trinidad, so I don't think it is wise for me to add > another effort to my list. > > Mvgr, > Martin > > Matt Benson wrote: > > @Members: > > I have recently joined the development > > team of an OSS project, Morph, that captures the > > spirit of Jakarta commons-convert but where the > > convert project stagnated, Morph is a > well-evolved, > > though still not 100% complete, library whose > > development I feel would benefit greatly from The > > Apache Way and would make a worthy ASF project. > > Object conversion seems to be a woefully > under-served > > subject in the Java OSS space, despite the > ubiquity of > > the need for it (however well-hidden it may tend > to > > be) in enterprise Java development. I have > contacted > > a few of you personally already, but having > received > > no bites as yet I am widening my audience one last > > time before giving up on this. > > > > You can learn more about this library at: > > > > http://morph.sourceforge.net > > > > Thanks, > > Matt > > > > > > > > > > > > > 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] > > > > > > > > - > 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]
Looking for an incubation champion
@Members: I have recently joined the development team of an OSS project, Morph, that captures the spirit of Jakarta commons-convert but where the convert project stagnated, Morph is a well-evolved, though still not 100% complete, library whose development I feel would benefit greatly from The Apache Way and would make a worthy ASF project. Object conversion seems to be a woefully under-served subject in the Java OSS space, despite the ubiquity of the need for it (however well-hidden it may tend to be) in enterprise Java development. I have contacted a few of you personally already, but having received no bites as yet I am widening my audience one last time before giving up on this. You can learn more about this library at: http://morph.sourceforge.net Thanks, Matt 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: Opening up the PMC
--- Henri Yandell <[EMAIL PROTECTED]> wrote: > On Tue, 8 Aug 2006, Matt Benson wrote: > > > Henri, out of sheer curiosity, where is it > documented > > that a commons committer doesn't have a binding > vote? > > The only thing I could find in the charter [1] was > a > > link to the Jakarta guidelines [2], which in turn > > links to a "Decision Making" page [3], which > states > > that "the only binding votes are those cast by a > > Committer" (the next sentence is pretty > interesting as > > well, though unrelated). > > http://www.apache.org/foundation/how-it-works.html#roles > > Our Decision Making page is dated in that respect, > probably worth deleting > and making sure that the foundation pages have > something with the > core important parts of it in them. Since your link was Apache-specific, and my link was Jakarta-specific, my assumption would be that Jakarta trumps the ASF in its grant of a vote to committers rather than PMC only. Ant does this as well; actually some changes are a vote of committers and some are PMC only, the specifics being outlined in the project bylaws. The alternative interpretation is that no project has the right to grant a binding vote beyond the PMC, thereby overruling the ASF guidelines you linked. But this interpretation would indicate a large upheaval: a quick look shows that the ASF "flagship" (HTTP server) grants committers a vote. Gump takes an Ant-like approach (not surprising since Gump's originators had worked on Ant). The XML TLP also says committers have a vote. IMHO it still looks as though Jakarta committers do have a binding vote unless the privilege granted at http://jakarta.apache.org/site/decisions.html is explicitly rescinded. FWIW, Matt > > Hen > > - > 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]
Re: Opening up the PMC
--- Henri Yandell <[EMAIL PROTECTED]> wrote: > > Being on a PMC means two actionable things. Firstly, > you get a binding > vote; and secondly, you can subscribe to > [EMAIL PROTECTED] - a list which > should be pretty quiet (mostly it's just vote > results now - would be nice > to move those to this list). Henri, out of sheer curiosity, where is it documented that a commons committer doesn't have a binding vote? The only thing I could find in the charter [1] was a link to the Jakarta guidelines [2], which in turn links to a "Decision Making" page [3], which states that "the only binding votes are those cast by a Committer" (the next sentence is pretty interesting as well, though unrelated). Thanks, Matt [1] http://jakarta.apache.org/commons/charter.html [2] http://jakarta.apache.org/site/guidelines.html [3] http://jakarta.apache.org/site/decisions.html > > The purpose of the binding vote is that that allows > you to perform > oversight on behalf of the foundation - it's not me > making a release, it's > the foundation. > > That's all there is. It's nothing special, just that > we can yay or nay > something. There's not even any paperwork beyond the > board ack email. > Given that - why do we have committers and pmc > members? Why do we have > people in our community who have been accepted as > committers and are > happily churning code, but are not allowed a binding > vote? It's definitely > not because we have an enormously low bar of entry > to being a committer. > > My view is that we shouldn't keep wasting our time > on such a separation. > There is no danger at all (given our size) to having > a new committer > immediately join the PMC, and there are notable > benefits in that we don't > have to keep remembering to add people to the pmc > (which we really suck at > doing) and we'll have a more open environment (which > we all like right?). > Also we won't have second class citizens who have to > yet again sit and > wait while their elders remember to nominate them as > an elder. > > What do people think to the following: > > 1) Every existing committer not on the pmc receives > an email asking if > they would like to join the pmc. Once that email is > sent they are marked > in a file as having had the email sent and we can > wash our hands until a > reply comes in. > > 2) Every new committer automatically gets added to > the pmc. > > --- > > I bring it up because the concept has cropped up > elsewhere at the ASF and > given our large non-pmc to pmc ratio I think we'll > have a lot of strong > views on the subject. > > Hen > > (Yeah, I recognize that the above is flamebait if we > have any strong > opinions out there. Hopefully it'll stay > constructive :) ) > > - > 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]
