Re: [ApacheCon - session] Incubating Open Source Communities
I've seen them always at ApacheCon :-) On 4/6/07, J Aaron Farr [EMAIL PROTECTED] wrote: Matthias Wessendorf [EMAIL PROTECTED] writes: there is a session, called Incubating Open Source Communities by J. Aaron Farr. Is this a similar session, like we did in Austin? Or a *general* session on the Apache Incubator? (there is no link available on the website, therefore the mail...) It's a general session, similar to one I gave at OSCON last year. The intention is to share lessons learned from the Incubator as well as introduce the general policies of ASF Incubation. I did like the Incubator Lightening Talks at Austin though. It'd be nice to see them again. -- jaaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: discussion of release of Apache Wicket 1.3.0-incubating-alpha
On 4/4/07, Craig L Russell [EMAIL PROTECTED] wrote: On Apr 4, 2007, at 1:54 PM, robert burrell donkin wrote: snip IMHO we need to alter the process so that we have an explicit audit when the community feels (by vote) that it has a build process in place. the code doesn't need to be ready but the build does and the codebase needs to be ready for audit. IMHO the current process is fine but needs to be documented better. i agree that we need better documentation but i'm really not getting the cycles ATM. i'd hoped that other people would step up and push it forward since this is vital work. Podlings should be encouraged to release stuff that they think is usable outside their small world of developers who check out from svn and build from source. The incubator is set up to review and approve releases without passing judgement on the usability, just the legality. i've been approaching this problem from the wrong perspective most critical issues i encounter are issues with source. the source can be checked at any time. potential issues with source should be addressed as soon as possible. (and yes, i know henri arrived here long before me.) the best approach would be to run RAT on the trunks of all incubating podlings. unfortunately this means finding the cycles to add the required features to RAT and i'm likely to be very short of energy in the next few months :-/ - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ratify the release of Apache Wicket 1.3.0-incubating-alpha
On Friday 06 April 2007 15:38, robert burrell donkin wrote: (BTW if anyone wants to help out on RAT, it would be really appreciated :-) Before committing to cycles, where is the sources and what features are missing? Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: discussion of release of Apache Wicket 1.3.0-incubating-alpha
On Friday 06 April 2007 15:55, robert burrell donkin wrote: most critical issues i encounter are issues with source. the source can be checked at any time. potential issues with source should be addressed as soon as possible. (and yes, i know henri arrived here long before me.) the best approach would be to run RAT on the trunks of all incubating podlings. So for Maven built projects, this should go into master POM file to be included automatically... Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mentors and members (was: Re: Mentors On IPMC [WAS Re: [Vote] RCF proposal
On Friday 06 April 2007 12:26, William A. Rowe, Jr. wrote: Niclas Hedhman wrote: On Friday 06 April 2007 12:03, William A. Rowe, Jr. wrote: Mentors must be on the iPMC, most iPMC members are ASF members (very rare that it is otherwise, Yes, I have noticed that ;o) But I am one such rare case, so I see the distinction, and since an ASF Member has the right to be member of IPMC, the 'ladder' exist. Now time to define the Required Level of Mentor and whether each Mentor has the same requirement or if there is a Group Requirement for the mentors. howso w.r.t. requirements? What are you meaning here? Some people has assumed that One of the Mentors must be an ASF Member, which means it is a 'group requirement' and not a requirement of each individual mentor. I have no strong opinion about it, just highlighting the distinction and a whether to say we should address it. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] RCF proposal (was: [Proposal] RCF - a rich component library for JSF)
+1 Carsten Omar Tazi wrote: Hi, Based on a positive initial feedback we are calling a vote on the RCF contribution (see proposal below). This proposal is for the donation of a rich component library for the JavaServer Faces technology to the Apache Software Foundation. The live version of the proposal is available at: http://wiki.apache.org/incubator/RCFProposal A vote was held on the Apache MyFaces dev list and we got 15 +1 votes (13 binding) therefore Apache MyFaces is proposed as the sponsoring entity/project. The Champion for the RCF proposal is Manfred Geiler (manolito at apache dot org) and the three mentors are Martin van den Bemt (mvdb at apache dot org), Carsten Ziegeler (cziegeler at apache dot org), and Henning Schmiedehausen (henning at apache dot org). Please cast your votes. Thanks, Omar Tazi - Omar Tazi Chief Open Source Evangelist SOA Evangelist Middleware and Tools Oracle Corporation Work: (650) 506-3216 Cell: (408) 656-5354 Email: [EMAIL PROTECTED] Blog: http://otazi.blogspot.com = RCF, a rich component library for JSF = Abstract -- RCF is a rich (Ajax-style) component set for the JavaServer Faces(tm) 1.2 technology. . Proposal RCF is an Ajax-based component library for the JavaServer Faces technology. RCF comes with very high quality components, and skinning (CSS-based) capabilities. RCF features include: file upload support, client-side conversion and validation, a complete Ajax-integration, data tables, hierarchical tables, color/date pickers, menu tabs/buttons, wizards, popups, toolbars, toolboxes, internationalization and accessibility. This project starts with more than 100 components which have already been documented and thoroughly tested. RCF stands for Rich Client Framework and it means that web applications, using this component set look very similar to a real, native desktop application. The name for this project can be a subject to change. RCF depends on some artifacts, provided by the Apache Trinidad project, such as framework features or Apache Maven plug-ins. Background -- The development of RCF started in 2005 at Oracle Corporation. With the advent of Ajax and requirements for highly interactive rich user experience, Oracle decided to implement a rich/Ajax-style JSF component set. The goal was to advance the already existing ADF Faces product, donated to the ASF in early 2006 (Apache Trinidad). When the development of RCF started, there wasn't any JSF component set that provided similar richness to the user. The RCF components run on any JSF 1.2 compliant implementation. RCF is based on some internal features of the Apache Trinidad project. The JavaServer Faces technology is a key technology for the RCF component set, since RCF requires JSF as its runtime environment. Oracle has a large commitment to both open source and open standards. This proposal illustrates Oracle's commitment to the success of the JSF standard and supporting the open source community by providing a rich component set under a liberal license, the Apache 2.0 license. Rationale - The project is interested in moving to Apache for the following reasons: To provide Apache-licensed implementation of a full-blown Ajax-based JSF component set, to become better integrated with the MyFaces and Shale initiatives, and to build a strong vendor-neutral community that will outlast any one person's or company's participation. Initial Goals - The initial goals of the proposed project are: * Viable community around the RCF code base * Active relationships and possible cooperation with related projects and communities, such as Apache MyFaces (and its subprojects) or Apache Trinidad. Current Status == Meritocracy --- All the initial committers are familiar with the meritocracy principles of Apache, and have already worked on the various source code bases. Some of the initial committers also have experience, undergoing the Apache incubation process. We will follow the normal meritocracy rules also with other potential contributors. Community - The Apache MyFaces project, the Apache Trinidad podling and the JavaServer Faces standard hold great promise. A fully Ajax-based set of user interface components will significantly accelerate their adoption. We strongly believe that RCF will gather significant momentum and enough developers to build a vibrant community of users and contributors. Core Developers --- Four of the initial committers are Oracle employees and all are committers on the Apache Trinidad podling. One of them is a committer at Apache MyFaces and Apache Shale. Four of the initial committers are committers on the Apache MyFaces
Re: Mentors and members (was: Re: Mentors On IPMC [WAS Re: [Vote] RCF proposal (was: [Proposal] RCF - a rich component library for JSF)])
On 4/5/07, robert burrell donkin [EMAIL PROTECTED] wrote: On 4/5/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Well, incubator policy is able to contradict itself on one and the same page: http://incubator.apache.org/incubation/Incubation_Policy.html [...] Acceptance By Incubator [...] * the Mentors, nominated by the Sponsor, who will guide the Candidate through the Incubation Process. At least one nominated Mentor MUST be a member of the Apache Software Foundation. [...] Roles Defined Mentor [...] A Mentor is a role undertaken by a permanent member of the Apache Software Foundation and is chosen by the Sponsor to actively lead in the discharge of their duties (listed above). [...] So what is it? A mentor must be a member or at least one mentor must be a member? i've always assumed that every mentor needed to be a member but IMHO we should really consider what the rule should be and then vote to amend the policy appropriately. Same here. I assumed this myself, however I am beginning to think that this does not necessarily need to be the case. For example we have people on the IPMC that are not members and would be excellent mentors or members for that matter. Alex
Re: [Vote] RCF proposal (was: [Proposal] RCF - a rich component library for JSF)
The vote passes with 5 binding +1, 3 non-binding +1 an 1 +0 votes. The binding votes were: +1 Martin van den Bemt +1 Jukka Zitting +1 Bertrand Delacretaz +1 Ted Husted +1 Carsten Ziegeler The non-binding votes were: +1 Mike Kienenberger +1 Henning Schmiedehausen (mentor) +1 Martin Marinschek The +0 vote was: +1 Niclas Hedhman Thanks for voting! I'll proceed to request the relevant infrastructure and to include RCF in the Incubator books. -Matthias On 4/6/07, Carsten Ziegeler [EMAIL PROTECTED] wrote: +1 Carsten Omar Tazi wrote: Hi, Based on a positive initial feedback we are calling a vote on the RCF contribution (see proposal below). This proposal is for the donation of a rich component library for the JavaServer Faces technology to the Apache Software Foundation. The live version of the proposal is available at: http://wiki.apache.org/incubator/RCFProposal A vote was held on the Apache MyFaces dev list and we got 15 +1 votes (13 binding) therefore Apache MyFaces is proposed as the sponsoring entity/project. The Champion for the RCF proposal is Manfred Geiler (manolito at apache dot org) and the three mentors are Martin van den Bemt (mvdb at apache dot org), Carsten Ziegeler (cziegeler at apache dot org), and Henning Schmiedehausen (henning at apache dot org). Please cast your votes. Thanks, Omar Tazi - Omar Tazi Chief Open Source Evangelist SOA Evangelist Middleware and Tools Oracle Corporation Work: (650) 506-3216 Cell: (408) 656-5354 Email: [EMAIL PROTECTED] Blog: http://otazi.blogspot.com = RCF, a rich component library for JSF = Abstract -- RCF is a rich (Ajax-style) component set for the JavaServer Faces(tm) 1.2 technology. . Proposal RCF is an Ajax-based component library for the JavaServer Faces technology. RCF comes with very high quality components, and skinning (CSS-based) capabilities. RCF features include: file upload support, client-side conversion and validation, a complete Ajax-integration, data tables, hierarchical tables, color/date pickers, menu tabs/buttons, wizards, popups, toolbars, toolboxes, internationalization and accessibility. This project starts with more than 100 components which have already been documented and thoroughly tested. RCF stands for Rich Client Framework and it means that web applications, using this component set look very similar to a real, native desktop application. The name for this project can be a subject to change. RCF depends on some artifacts, provided by the Apache Trinidad project, such as framework features or Apache Maven plug-ins. Background -- The development of RCF started in 2005 at Oracle Corporation. With the advent of Ajax and requirements for highly interactive rich user experience, Oracle decided to implement a rich/Ajax-style JSF component set. The goal was to advance the already existing ADF Faces product, donated to the ASF in early 2006 (Apache Trinidad). When the development of RCF started, there wasn't any JSF component set that provided similar richness to the user. The RCF components run on any JSF 1.2 compliant implementation. RCF is based on some internal features of the Apache Trinidad project. The JavaServer Faces technology is a key technology for the RCF component set, since RCF requires JSF as its runtime environment. Oracle has a large commitment to both open source and open standards. This proposal illustrates Oracle's commitment to the success of the JSF standard and supporting the open source community by providing a rich component set under a liberal license, the Apache 2.0 license. Rationale - The project is interested in moving to Apache for the following reasons: To provide Apache-licensed implementation of a full-blown Ajax-based JSF component set, to become better integrated with the MyFaces and Shale initiatives, and to build a strong vendor-neutral community that will outlast any one person's or company's participation. Initial Goals - The initial goals of the proposed project are: * Viable community around the RCF code base * Active relationships and possible cooperation with related projects and communities, such as Apache MyFaces (and its subprojects) or Apache Trinidad. Current Status == Meritocracy --- All the initial committers are familiar with the meritocracy principles of Apache, and have already worked on the various source code bases. Some of the initial committers also have experience, undergoing the Apache incubation process. We will follow the normal meritocracy rules also with other potential contributors. Community - The Apache MyFaces project, the Apache Trinidad podling and the JavaServer Faces standard hold great promise. A fully Ajax-based set
Re: discussion of release of Apache Wicket 1.3.0-incubating-alpha
On 4/6/07, Niclas Hedhman [EMAIL PROTECTED] wrote: On Friday 06 April 2007 15:55, robert burrell donkin wrote: most critical issues i encounter are issues with source. the source can be checked at any time. potential issues with source should be addressed as soon as possible. (and yes, i know henri arrived here long before me.) the best approach would be to run RAT on the trunks of all incubating podlings. So for Maven built projects, this should go into master POM file to be included automatically... stefan developed an ant task (which ships with RAT) and jochen a maven 2 one the problem is that the reports are hard to interpret ATM RAT needs to read detached audit meta-data before it can conclusively work out whether an anomaly is a real issue or not but doesn't ATM - rboert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ratify the release of Apache Wicket 1.3.0-incubating-alpha
On 4/6/07, Niclas Hedhman [EMAIL PROTECTED] wrote: On Friday 06 April 2007 15:38, robert burrell donkin wrote: (BTW if anyone wants to help out on RAT, it would be really appreciated :-) Before committing to cycles, where is the sources http://code.google.com/p/arat/ it's at google code since i didn't think that there'd be enough development interest to sustain something at apache. if there is then i'd be happy to move it here. i'm liberal with karma. and what features are missing? the minimum to run a check would be: 1 read detached audit data and feed that into the pipe 2 add analytics to the end of the pipe to produce a global pass or fail 3 hack together some gump-style continuous integration to run for every incubator project 4 for each podling, analyse the results and present a list of questions. use the answers to create meta-data. 5 hack together some scripts to email reports to lists when put together this way, it looks reasonably doable :-) there are lots of good-to-haves but this would get us started. once it's up and running, the improved checks and graphical reports could be added as time permits. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding new committers process
Ok, I think that has cleared things up a bit for me I'll send out these requests that I've been sitting on for a few weeks now as we need to get the accounts set up for our new committers. Cheers On 04/04/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jean T. Anderson wrote: huh? The instructions [1] say The project PMC needs to send an email to root. It doesn't say the project PMC chair. Since root can easily verify pmc members from committee-info.txt [2], I don't see why any member of the PMC cannot submit the request. Whoops :) The *board* only ack's new PMC members when they are notified by the PMC chairmain, but I think you may be correct w.r.t. root/svn req's. I may have confused the two :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martin Ritchie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (INCUBATOR-53) Remove references to escalation from Incubation Policy
[ https://issues.apache.org/jira/browse/INCUBATOR-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Russell updated INCUBATOR-53: --- Attachment: incubator-53.patch Please review this patch. I've reverted migrate the svn repo to move the svn repo per Niclas Hedhman's comments (thanks for that). Still looking for one more vote to commit this change. Remove references to escalation from Incubation Policy Key: INCUBATOR-53 URL: https://issues.apache.org/jira/browse/INCUBATOR-53 Project: Incubator Issue Type: Improvement Components: site Reporter: Craig Russell Assigned To: Craig Russell Priority: Minor Attachments: escalate.patch, incubator-53.patch, incubator-53.patch Currently, incubation policy refers to escalation, migration, and graduation when discussing graduation from the incubator to a TLP or a sub-project. This proposal standardizes on the terminology graduation to refer to this process. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE][HOTFIX] Approve the release of hotfix-1 for Apache UIMA 2.1.0-incubating
This vote has been open for 72 hours, and has received +1's from Noel Bergman, Davanum Srinivas, Ken Coar, Niclas Hedman, Jean T. Anderson, and Robert Burrell Donkin. At least 3 of these are binding votes (Noels, Ken's and Robert's), the others I think are also binding. No other votes were received. Therefore, the vote passes. Thanks, everyone, for your speedy review :-) -Marshall Schor Marshall Schor wrote: The Apache UIMA community has voted to release org.apache.uima.desceditor.2.1.0.incubating-hotfix-1.zip . We would now like to ask the Incubator PMC to approve this hotfix release. This release consists of 1 zip file containing a replacement for one of the Eclipse plugins included in the current release, that corrects several problems documented in the Jira issue http://issues.apache.org/jira/browse/UIMA-364. This is a temporary fix until we do our next full release. This artifact was built from the SVN branch used for the 2.1.0 release, already out. It includes no other changes from the main trunk. Besides the code changes needed for Jira issue UIMA-364, the only other changes that were done were 1) to modify the MANIFEST and Maven pom files to give the created artifact a new name appending the hotfix-1 string. 2) to modify the build for this zip to include the LICENSE, DISCLAIMER, and NOTICES file that are normally packaged with the top level zip file of the whole distribution, 3) to add a README-HOTFIX-1 file describing how to apply this fix, to the zip. The intent is to put this hot-fix package with the same instructions as in the README-HOTFIX-1 on our download site, if this is approved. This is a temporary fix until we do our next full release. The artifact is located in http://people.apache.org/~schor/org.apache.uima.desceditor.2.1.0.incubating-hotfix-1.zip; this is a binary deployable object usable by UIMA users directly, after unzipping into the Eclipse plugins directory. The release was signed by Marshall I Schor, acting as the release manager for this hot fix. His public key is available here: http://svn.apache.org/repos/asf/incubator/uima/uimaj/trunk/uimaj-distr/src/main/readme/KEYS as well as at the MIT public key repository http://pgp.mit.edu/ . The detached signatures are located here: http://people.apache.org/~schor/ http://people.apache.org/%7Eschor/ The changes for this hotfix are confined to only of one Eclipse Plugin project; this project (uimaj-ep-configurator) was tagged in SVN: https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-ep-configurator-2.1.0-hotfix-1-RC1/uimaj-ep-configurator Here is a link to our vote thread on the uima-dev list: http://www.mail-archive.com/uima-dev@incubator.apache.org/msg02705.html We've not run the RAT utility because the changes involved only minor code updates in one module. For reference (if needed) the previous reports for version 2.1.0-incubating, along with our own comments, are posted here: http://people.apache.org/~alally/uima-2.1.0-incubating/RAT/RAT-src.txt http://people.apache.org/~alally/uima-2.1.0-incubating/RAT/RAT-bin.txt The original unedited RAT reports are also posted: http://people.apache.org/~alally/uima-2.1.0-incubating/RAT/RAT-src-full.txt http://people.apache.org/~alally/uima-2.1.0-incubating/RAT/RAT-bin-full.txt We ask that you please vote to approve this hotfix release: [ ] +1 Approve the release of the hotfix artifact: org.apache.uima.desceditor.2.1.0.incubating-hotfix-1.zip [ ] -1 Recommend against releasing at this time (identify issues you consider showstoppers) Thanks! - The Apache UIMA team - 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]
Re: [VOTE] Ratify the release of Apache Wicket 1.3.0-incubating-alpha
On 3/30/07, Martijn Dashorst [EMAIL PROTECTED] wrote: snip However, in light of our incubation progress we feel the urge to get confirmation that we resolved our legal issues and are able to come together and build a release. We kindly request the Incubator PMC to approve this release. questions The library for dragging the AJAX debug dialog has the following notice: distributed under commons creative license 2.0 - this is potentially problematic since it's a family of licenses some of which are open source compatible, some of which are not. what are the details? major issues --- niclas already noted the missing headers from threadtest (major due to number and copyright) DISCLAIMER but is missing LICENSE and NOTICE from: * wicket-1.3.0-incubating-alpha-javadoc.jar * wicket-auth-roles-1.3.0-incubating-alpha-javadoc.jar * wicket-datetime-1.3.0-incubating-alpha-javadoc.jar * wicket-examples-1.3.0-incubating-alpha-javadoc.jar * wicket-extensions-1.3.0-incubating-alpha-javadoc.jar * wicket-jmx-1.3.0-incubating-alpha-javadoc.jar * wicket-objectsizeof-agent-1.3.0-incubating-alpha-javadoc.jar * wicket-spring-1.3.0-incubating-alpha-javadoc.jar * wicket-spring-annot-1.3.0-incubating-alpha-javadoc.jar (all artifacts MUST have LICENSE and NOTICE) minor issues --- (more judgement calls these ones) src/release.sh looks to me like it's creative enough to need a header IMHO many of the examples in src/main/java/wicket/examples are creative enough to deserve a license header. it's reasonably common for people to derive works from examples so licensing is important. comments in general the MANIFEST.MF could be improved: missing the attributes recommended by sun. not particularly important (adhering to the standard doesn't really do any tangible good) but looks professional and easy to do with maven. i'd recommend creating release notes (but i hope that these are missing since this is only an audit release). usual comments about using the same content for announcements to appropriate mailing lists ([EMAIL PROTECTED] is on topic but remember to subscribe first; best practice to sign these announcements) and download link page. BTW i see the current namespace is http://wicket.sourceforge.net/. do you plan to change this upon (sometime)? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE][HOTFIX] Approve the release of hotfix-1 for Apache UIMA 2.1.0-incubating
On 4/6/07, Marshall Schor [EMAIL PROTECTED] wrote: This vote has been open for 72 hours, and has received +1's from Noel Bergman, Davanum Srinivas, Ken Coar, Niclas Hedman, Jean T. Anderson, and Robert Burrell Donkin. At least 3 of these are binding votes (Noels, Ken's and Robert's), the others I think are also binding. indeed all are binding :-) see http://incubator.apache.org/whoweare.html (but Niclas has only recently been added and the list needs regenerating) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mentors and members (was: Re: Mentors On IPMC [WAS Re: [Vote] RCF proposal (was: [Proposal] RCF - a rich component library for JSF)])
On 4/5/07, robert burrell donkin [EMAIL PROTECTED] wrote: i've always assumed that every mentor needed to be a member but IMHO we should really consider what the rule should be and then vote to amend the policy appropriately. At one time, there was only one mentor, and now there are three, and the discrepancy probably crept in during that state change. For mentors, I'd suggest every Mentor be a ASF Member or a iPMC Member. Nearly all iPMC members are ASF members anyway, and any who are not are probably should be. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
