Re: OpenOffice.org Apache Incubator Proposal
Hi all - I see that I'm listed as a sponsor. Can you please remove my name and replace with someone else? I never agreed to sponsor this. Sorry about any inconvenience. geir On Jun 1, 2011, at 11:41 AM, Luke Kowalski wrote: The following project is being sent in as an incubator candidate. regards luke Apache OpenOffice.org proposal_june12011.odt - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accepting Kato into the Incubator
as a seed for development. This codebase consists of diagnostic dump readers and the data access API. There are data providers for DTFJ that are specific and proprietary to IBM JVMs; these providers will not be open-sourced. DTFJ is being donated to kick start the project and as a foundation on which to build and develop our ideas. There is no expectation that the final output must resemble this seed offering. Source and Intellectual Property Submission Plan Apache would receive all source and documentation under the Apache Corporate Contributor agreement. IBM is the only license holder. External Dependencies Ant and JUnit are the only external dependencies. Cryptography Required Resources Mailing Lists * kato-private * kato-dev * kato-spec Subversion Directory * [WWW] https://svn.apache.org/repos/asf/incubator/kato Issue Tracking * JIRA : Kato (KATO) Other Resources Initial Committers Steve Poole spoole at uk dot ibm dot com Stuart Monteith monteith at uk dot ibm dot com Carmine Cristello cristallo at uk dot ibm dot com Richard Cole rich dot cole at uk dot ibm dot com Christian Glatschke christian at glatschke dot com Sonal Goyal sonalgoyal4 at gmail dot com Affiliations The initial committers listed are affiliated with IBM and self. Champion Geir Magnusson Jr has agreed to be Champion Proposed Apache Sponsor Incubator PMC Nominated Mentors Geir has volunteered to be a mentor. Ant Elder - 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: JAX-WS TCK and CXF 2.0 release
As long as you mark it as UNTESTED or BETA per the JAX-WS part - IOW, make no claim about compatibility, you're fine. geir On Mar 13, 2007, at 4:14 AM, Bozhong Lin wrote: Hi, Apache CXF team is planning for its 2.0 final release. In benefit of CXF users, we would like to cut 2.0 release sooner without fully passing JAX-WS TCK, and plan to push JAX-WS TCK test into 2.1 release plan. Of course, in CXF 2.0 release note, we will explicitly mention that Apache CXF does NOT claim any JAX-WS compliant yet, like what we did with CXF 2.0 M1 release. Is this plan OK to incubator PPMC from legal standpoint? Any thoughts/ opinion on this would be greatly appreciated. Thanks, Bo - 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]
Notice - Lists for River podling created
All - note that the mail lists for the River podling have been created : The public lists are : [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] and subscribe in the usual way, following the pattern : [EMAIL PROTECTED] See you there. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Re: [VOTE] Incubate new podling, River (nee Braintree, nee..., nee Jini)
I gave it a few more days because of the Christmas holiday and preparations. The results : +1 from Geir, Niclas, Phil, Henri, Bertrand, Jukka, Craig, David W, Richard, Craig, Gianugo, Mark, Robert, Brian, Nigel, Dan C, Bob, Noel, Juan, Justin, Jim H, Bill, Dan R, Jim Jagielski +0 from Yoav No other votes cast. (I hope I didn't miss anyone). As we received an adequate number of +1 votes from Incubator PMC members, this vote passes :) I'll get the necessary infrastructure machinery going, staring with the mail lists. geir On Dec 20, 2006, at 10:46 PM, Geir Magnusson Jr. wrote: It is with great relief and hope that I propose that the Apache Incubator PMC vote to incubate a new podling, to be known as River. You may be familiar with this project as it has been discussed under other names, including Braintree and Jini. I've actually lost track of the Quest for a Name, and actually feel very responsible for this naming mess, for which I apologize. Therefore, please vote on the proposal that follows : [ ] +1 Accept River as a new podling as described below [ ] -1 Do not accept the new podling (provide reason, please) The proposal can be found here : http://wiki.apache.org/incubator/RiverProposal and is included below for archival purposes : RiverProposal *Proposal for new project River* 8 December 2006 (0) rationale Jini technology is a service oriented architecture that defines a programming model which both exploits and extends Java technology to enable the construction of secure, distributed systems consisting of federations of services and clients. Jini technology can be used to build adaptive network systems that are scalable, evolvable and flexible as typically required in dynamic computing environments. Quoting from The Jini Specifications (http://java.sun.com/docs/ books/jini/spec/) book: Jini technology is a simple infrastructure for providing services in a network, and for creating spontaneous interactions between programs that use these services. Services can join or leave the network in a robust fashion, and clients can rely upon the availability of visible services, or at least upon clear failure conditions. When you interact with a service, you do so through a Java object provided by that service. This object is downloaded into your program so that you can talk to the service even if you have never seen its kind before - the downloaded object knows how to do the talking. That's the whole system in a nutshell. Sun Microsystems originally introduced the technology in January, 1999 by providing a Jini Technology Starter Kit (http:// starterkit.dev.java.net/). This includes a contributed implementation of all of the specifications, as well as helpful utilities and tools. The source code was made available through the Sun Community Source License (SCSL) as an attempt to make the code widely available and accessible to both individuals and companies. Sun has continued to innovate throughout the years, releasing many versions of the starter kit. The license associated with the starter kit was changed (http://archives.java.sun.com/cgi-bin/wa? A2=ind0503L=jini-usersO=AP=36217) in March, 2005 to the Apache License, Version 2.0. Since its beginning, there was desire and effort to form a developer community around the technology. This has helped to create an interesting, active, and passionate community - the Jini Community. This global Community has engaged on technology projects, discussions and debates, events, and a decision making process. It has contributed to, and helped influence the direction of the starter kit. Some of the collaborative technology projects have led to key contributions being used by other technology projects as well as commercial products. One example is the Service UI API (http://www.artima.com/jini/serviceui/), which is a way to attach user interfaces to Jini services. Despite the obvious successes of the technology and Community, some changes are in store as outlined in a recent note to the Community: A New Day (http://archives.java.sun.com/cgi-bin/wa? A2=ind0604L=jini-usersF=S=P=4029). The most critical part of the new plan is to find the right place for the future development and advancement of the core Jini technology. We wanted an environment that was synergistic with our exisiting Community culture -- so one that is active, with open communication and collaboration, and a reputation for producing high quality software. We think we've found that place with the Apache Software Foundation. (0.1) criteria /Meritocracy:/ The River project will be meritocractic. The project will follow the guidelines (http://apache.org/foundation/how-it- works.html#meritocracy) of the Apache Software Foundation. In order to achieve this, we plan on proactively recruiting
Re: [VOTE] Incubate new podling, River (nee Braintree, nee..., nee Jini)
Jim, I've updated the proposal in the wiki, hopefully addressing your two concerns - noting that there are no other implementations of Jini technology at the ASF, and noting that committership for the initial committers will be granted upon engagement with the project, as determined by the mentors. I hope this addresses your concerns, and that with your vote on this, we will conclude the vote today. geir On Dec 23, 2006, at 9:28 PM, Jim Jagielski wrote: Noel J. Bergman wrote: Jim, Keep in mind that JINI significantly predates all of the current Web Services efforts, not just here but anywhere. Technically, SOAP at Microsoft *might* predate JINI, but JINI was out and about (in so far as it has ever gained much marketshare) before Web Services as we know them. Thanks for the info, but I didn't need it. Asking that something be addressed/mentioned/explained in a proposal doesn't imply the asker is clueless :) -- == = Jim Jagielski [|] [EMAIL PROTECTED] [|] http:// www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball. - 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] Incubate new podling, River (nee Braintree, nee..., nee Jini)
On Dec 21, 2006, at 9:01 AM, Jim Jagielski wrote: On Dec 20, 2006, at 10:46 PM, Geir Magnusson Jr. wrote: It is with great relief and hope that I propose that the Apache Incubator PMC vote to incubate a new podling, to be known as River. You may be familiar with this project as it has been discussed under other names, including Braintree and Jini. I've actually lost track of the Quest for a Name, and actually feel very responsible for this naming mess, for which I apologize. Therefore, please vote on the proposal that follows : [ ] +1 Accept River as a new podling as described below [ ] -1 Do not accept the new podling (provide reason, please) Could you address the overlap with other ASF projects and podlings which are in similar technology space? There are none doing Jini at this time. Why a new and distinct podling and not joining/helping them? See above :) Also, I'm assuming graduation to TLP (I may have missed that in the proposal)? Oh - whoops. Yes, because we're asking for Incubator PMC as sponsor (rather than another PMC), my expectation is that this will be a TLP. geir - 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] Incubate new podling, River (nee Braintree, nee..., nee Jini)
On Dec 21, 2006, at 11:09 AM, Jim Jagielski wrote: On Dec 21, 2006, at 9:15 AM, Geir Magnusson Jr. wrote: On Dec 21, 2006, at 9:01 AM, Jim Jagielski wrote: On Dec 20, 2006, at 10:46 PM, Geir Magnusson Jr. wrote: It is with great relief and hope that I propose that the Apache Incubator PMC vote to incubate a new podling, to be known as River. You may be familiar with this project as it has been discussed under other names, including Braintree and Jini. I've actually lost track of the Quest for a Name, and actually feel very responsible for this naming mess, for which I apologize. Therefore, please vote on the proposal that follows : [ ] +1 Accept River as a new podling as described below [ ] -1 Do not accept the new podling (provide reason, please) Could you address the overlap with other ASF projects and podlings which are in similar technology space? There are none doing Jini at this time. Why a new and distinct podling and not joining/helping them? See above :) I think that the proposal should at least address that... People see hey another SOA project, architecture for services it's a little different. Jini is an old and I would say fundamental technology for service infrastructure in the java platform, very different from today's SOA. I'll let someone else argue my point, as I have to go christmas shopping. If no one does, I'll do it when I get back. They are fundamentally different (and we always allow competing impls anyway...) and need to know how River is different and unique by anticipating the question :) Yeah. Well, I have a basic understanding of what Jini is, and I never confuse the two. I certainly can understand how someone unfamiliar with it would be confused. Also, one thing that had been discussed is better clarification in proposals regarding the Initial List of Committers and the Initial List of PPMC Members... To avoid the issues that popped up with CXF. We'll argue it out once/if the podling starts, but I was going to suggest that we run it in the fashion of Harmony - that we wait until those that are listed engage and participate, and then give them commit, and have the mentors build the PPMC in parallel based on engagement and participation. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Incubate new podling, River (nee Braintree, nee..., nee Jini)
brand:/ Many of us have been working on advancing Jini technology and developing the Jini Community for many years. We care deeply about it and want the technology and Commutity to continue to flourish. As we considered options for where/how to move Jini technology to an open source development model, our respect and admiration for the work done by the Apache Software Foundation drove us to choose this as our best option. As a Java-based infrastructure for building systems, River fits in well with the other projects at Apache, and the Community we've built shares many philosophies (open communication, fairness, diversity, etc). We believe there are strong synergies here. (1) scope of the project The scope of the River project would be the continued development of Jini technology core infrastructure software, including the implementation of Jini specifications, related utilities and tools. The development would include adding new features and improving performance, scalability, quality, and extensibility. (2) identify the initial source from which the project is to be populated The initial resources would be garnered from: * Jini Technology Starter Kit (https://starterkit.dev.java.net/downloads/jini/2.1/index.html) project on Java.net, * Service UI implementation (http://www.artima.com/jini/serviceui/CodeAccess.html) from Artima.com, * QATests (formerly, a project on Jini.org) (3) identify the ASF resources to be created (3.1) mailing list(s) * river-private (with moderated subscriptions) * river-dev * river-commits * river-user (3.2) Subversion or CVS repositories River would like to use a Subversion repository. (3.3) Jira (issue tracking) Since River would have its own release cycle, it should have its own JIRA project * Project Name: River * Project Key: RIVER (4) identify the initial set of committers * Dan Creswell ([EMAIL PROTECTED]) * Bill Venners ([EMAIL PROTECTED]) * Mark Brouwer ([EMAIL PROTECTED]) * Geir Magnusson Jr ([EMAIL PROTECTED]) * Bob Scheifler ([EMAIL PROTECTED]) * Jim Waldo ([EMAIL PROTECTED]) * John McClain ([EMAIL PROTECTED]) * Brian Murphy ([EMAIL PROTECTED]) * Peter Jones ([EMAIL PROTECTED]) * Juan Ramirez ([EMAIL PROTECTED]) * Frank Barnaby ([EMAIL PROTECTED]) * Fred Oliver ([EMAIL PROTECTED]) * Robert Resendes ([EMAIL PROTECTED] * Vinod Johnson ([EMAIL PROTECTED]) * Ron Mann ([EMAIL PROTECTED]) * Nigel Daley ([EMAIL PROTECTED]) * Jim Hurley ([EMAIL PROTECTED]) (5) identify apache sponsoring individual * Champion * Geir Magnusson Jr. * Mentors * Geir Magnusson Jr. * Phil Steitz * Gianugo Rabellino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Incubate new podling, River (nee Braintree, nee..., nee Jini)
+1 from me Geir Magnusson Jr. wrote: It is with great relief and hope that I propose that the Apache Incubator PMC vote to incubate a new podling, to be known as River. You may be familiar with this project as it has been discussed under other names, including Braintree and Jini. I've actually lost track of the Quest for a Name, and actually feel very responsible for this naming mess, for which I apologize. Therefore, please vote on the proposal that follows : [ ] +1 Accept River as a new podling as described below [ ] -1 Do not accept the new podling (provide reason, please) The proposal can be found here : http://wiki.apache.org/incubator/RiverProposal and is included below for archival purposes : RiverProposal *Proposal for new project River* 8 December 2006 (0) rationale Jini technology is a service oriented architecture that defines a programming model which both exploits and extends Java technology to enable the construction of secure, distributed systems consisting of federations of services and clients. Jini technology can be used to build adaptive network systems that are scalable, evolvable and flexible as typically required in dynamic computing environments. Quoting from The Jini Specifications (http://java.sun.com/docs/books/jini/spec/) book: Jini technology is a simple infrastructure for providing services in a network, and for creating spontaneous interactions between programs that use these services. Services can join or leave the network in a robust fashion, and clients can rely upon the availability of visible services, or at least upon clear failure conditions. When you interact with a service, you do so through a Java object provided by that service. This object is downloaded into your program so that you can talk to the service even if you have never seen its kind before - the downloaded object knows how to do the talking. That's the whole system in a nutshell. Sun Microsystems originally introduced the technology in January, 1999 by providing a Jini Technology Starter Kit (http://starterkit.dev.java.net/). This includes a contributed implementation of all of the specifications, as well as helpful utilities and tools. The source code was made available through the Sun Community Source License (SCSL) as an attempt to make the code widely available and accessible to both individuals and companies. Sun has continued to innovate throughout the years, releasing many versions of the starter kit. The license associated with the starter kit was changed (http://archives.java.sun.com/cgi-bin/wa?A2=ind0503L=jini-usersO=AP=36217) in March, 2005 to the Apache License, Version 2.0. Since its beginning, there was desire and effort to form a developer community around the technology. This has helped to create an interesting, active, and passionate community - the Jini Community. This global Community has engaged on technology projects, discussions and debates, events, and a decision making process. It has contributed to, and helped influence the direction of the starter kit. Some of the collaborative technology projects have led to key contributions being used by other technology projects as well as commercial products. One example is the Service UI API (http://www.artima.com/jini/serviceui/), which is a way to attach user interfaces to Jini services. Despite the obvious successes of the technology and Community, some changes are in store as outlined in a recent note to the Community: A New Day (http://archives.java.sun.com/cgi-bin/wa?A2=ind0604L=jini-usersF=S=P=4029). The most critical part of the new plan is to find the right place for the future development and advancement of the core Jini technology. We wanted an environment that was synergistic with our exisiting Community culture -- so one that is active, with open communication and collaboration, and a reputation for producing high quality software. We think we've found that place with the Apache Software Foundation. (0.1) criteria /Meritocracy:/ The River project will be meritocractic. The project will follow the guidelines (http://apache.org/foundation/how-it-works.html#meritocracy) of the Apache Software Foundation. In order to achieve this, we plan on proactively recruiting individuals in the Community to get involved in the project: specifying work that needs to be done, encouraging bug fixes, enhancements, and advancements, and engaging in discussion on how the code works and is structured. In the end, we are committed to creating an environment to foster a meritocracy. /Community:/ There has been a diverse and active Community built around Jini technology since it was first introduced in January, 1999. The Jini Community consists of a global set of individuals, companies, non-profit organizations, and universities. The Community communicates primarily through various email lists
Re: [VOTE] Incubate new podling, River (nee Braintree, nee..., nee Jini)
Note - this vote will be for 3 days, ending midnight, saturday december 23rd, 2006. Geir Magnusson Jr. wrote: It is with great relief and hope that I propose that the Apache Incubator PMC vote to incubate a new podling, to be known as River. You may be familiar with this project as it has been discussed under other names, including Braintree and Jini. I've actually lost track of the Quest for a Name, and actually feel very responsible for this naming mess, for which I apologize. Therefore, please vote on the proposal that follows : [ ] +1 Accept River as a new podling as described below [ ] -1 Do not accept the new podling (provide reason, please) The proposal can be found here : http://wiki.apache.org/incubator/RiverProposal and is included below for archival purposes : RiverProposal *Proposal for new project River* 8 December 2006 (0) rationale Jini technology is a service oriented architecture that defines a programming model which both exploits and extends Java technology to enable the construction of secure, distributed systems consisting of federations of services and clients. Jini technology can be used to build adaptive network systems that are scalable, evolvable and flexible as typically required in dynamic computing environments. Quoting from The Jini Specifications (http://java.sun.com/docs/books/jini/spec/) book: Jini technology is a simple infrastructure for providing services in a network, and for creating spontaneous interactions between programs that use these services. Services can join or leave the network in a robust fashion, and clients can rely upon the availability of visible services, or at least upon clear failure conditions. When you interact with a service, you do so through a Java object provided by that service. This object is downloaded into your program so that you can talk to the service even if you have never seen its kind before - the downloaded object knows how to do the talking. That's the whole system in a nutshell. Sun Microsystems originally introduced the technology in January, 1999 by providing a Jini Technology Starter Kit (http://starterkit.dev.java.net/). This includes a contributed implementation of all of the specifications, as well as helpful utilities and tools. The source code was made available through the Sun Community Source License (SCSL) as an attempt to make the code widely available and accessible to both individuals and companies. Sun has continued to innovate throughout the years, releasing many versions of the starter kit. The license associated with the starter kit was changed (http://archives.java.sun.com/cgi-bin/wa?A2=ind0503L=jini-usersO=AP=36217) in March, 2005 to the Apache License, Version 2.0. Since its beginning, there was desire and effort to form a developer community around the technology. This has helped to create an interesting, active, and passionate community - the Jini Community. This global Community has engaged on technology projects, discussions and debates, events, and a decision making process. It has contributed to, and helped influence the direction of the starter kit. Some of the collaborative technology projects have led to key contributions being used by other technology projects as well as commercial products. One example is the Service UI API (http://www.artima.com/jini/serviceui/), which is a way to attach user interfaces to Jini services. Despite the obvious successes of the technology and Community, some changes are in store as outlined in a recent note to the Community: A New Day (http://archives.java.sun.com/cgi-bin/wa?A2=ind0604L=jini-usersF=S=P=4029). The most critical part of the new plan is to find the right place for the future development and advancement of the core Jini technology. We wanted an environment that was synergistic with our exisiting Community culture -- so one that is active, with open communication and collaboration, and a reputation for producing high quality software. We think we've found that place with the Apache Software Foundation. (0.1) criteria /Meritocracy:/ The River project will be meritocractic. The project will follow the guidelines (http://apache.org/foundation/how-it-works.html#meritocracy) of the Apache Software Foundation. In order to achieve this, we plan on proactively recruiting individuals in the Community to get involved in the project: specifying work that needs to be done, encouraging bug fixes, enhancements, and advancements, and engaging in discussion on how the code works and is structured. In the end, we are committed to creating an environment to foster a meritocracy. /Community:/ There has been a diverse and active Community built around Jini technology since it was first introduced in January, 1999. The Jini Community consists of a global set of individuals, companies, non-profit organizations
Re: [VOTE] Publish Yoko M1 release
+1 Mosur Ravi, Balaji wrote: Hi, I have fixed all the issues that were raised during the earlier vote and I have uploaded the new release at: http://people.apache.org/~bravi Also, I used the tag https://svn.apache.org/repos/asf/incubator/yoko/tags/yoko-1.0-incubating -M1-release for the release. For the idl grammar license issue, got a confirmation from the apache legal team that it is fine not to include any header in that file but mention it in the License file. http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200610.mbox/% [EMAIL PROTECTED] The Yoko community voted on and has approved a proposal to release Yoko Milestone 1. Pursuant to the Releases section of the Incubation Policy we would now like to request the permission of the Incubator PMC to publish the milestone on the Yoko Download page. Thanks Balaji Proposal: http://mail-archives.apache.org/mod_mbox/incubator-yoko-dev/200609.mbox/ [EMAIL PROTECTED] %3e Vote result: [VOTE] [RESULT] Publish Yoko M1 release http://mail-archives.apache.org/mod_mbox/incubator-yoko-dev/200609.mbox/ [EMAIL PROTECTED] %3e Download from: http://people.apache.org/~bravi Releases section of the Incubation Policy: http://incubator.apache.org/incubation/Incubation_Policy.html#Releases - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE WITHDRAWN] publish openjpa 0.9.6-incubating release
I don't think so. Let the podling come up with what they call 0.9.6, let it give clear information to what that means, and the incubator PMC votes from there. This is getting counterproductive. geir Patrick Linskey wrote: Hi, I agree with Marc that we should continue to iterate on the 0.9.6-incubating release until we get it right. It would only be confusing if we actually publish the incubating release and then publish another 0.9.6. But iterations on the release candidate aren't new releases. Yes, but it is confusing if you look at the thread about voting on 0.9.6. If 0.9.7 isn't available. Can we have 0.9.6.1 as the next iteration of the 0.9.6 release? I don't understand the confusion... 0.9.6 hasn't been released yet; nobody should be confused by a vote for it. Personally, I don't much care what we do at this point, although I'd prefer a 0.9.7 to 0.9.6.1, since there is no 0.9.6 currently and 0.9.6.1 implies that one does. However, I *would* like clear guidance about what to do. Is this going to cause problems with incubator approval of the 0.9.6 vote that's currently running on the OpenJPA mailing list? -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - 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]
[RESULT} Re: [VOTE] Graduate Harmony to TLP status (pending board approval)
Tallying the results (in the order that Thunderbird sorted them), we had
+1 from Geir, Dims, Robert, Noel, Jean, Sanjiva, Greg, Paul, Cliff, Ted,
Tim, Craig, Leo, Yoav, Bill, Ken, Matthias, David, Niall, Roy
Note that Justin and Sam voted in other threads (as well as on the board
vote :). If I left anyone else off of this list, I apologize.
So with that, and with board approval granted, The Incubator PMC
graduates the Harmony podling.
Thanks all for the patience - I do think we have some things to chat
about :)
geir
try {
transaction.begin();
getIncubatorApproval(transaction);
getBoardApproval(transaction);
transaction.commit();
}
catch(RollbackException re) {
continueIncubation();
}
Geir Magnusson Jr. wrote:
The Apache Harmony community has voted to request graduation
from the Incubator as a TLP.
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/
200610.mbox/[EMAIL PROTECTED]
The following votes have been recorded (in order of votes cast) :
+1 Geir Magnusson Jr (Incubator PMC/committer/mentor)
+1 Etienne Gagnon
+1 Gregory Shimansky (committer)
+1 Sam Ruby (Incubator PMC)
+1 Rana Dasgupta
+1 Danese Cooper
+1 Mark Hindess (committer)
+1 Alex Blewitt
+1 Mikhail Fursov
+1 Matthias Wessendorf
+1 Alexei A Fedotov
+1 Jorden Justen
+1 Andrew Zhang
+1 Leo Li
+1 Nathan Beyer (committer)
+1 Naveen Neelakantam
+1 Mikhail Loenko(committer)
+1 Leo Simons(Incubator PMC/mentor)
+1 Paulex Yang (committer)
+1 Tim Ellison (committer)
+1 Salikh Zakirov
+1 Alex Karasulu (Incubator PMC)
+1 Weldon Washburn (committer)
+1 Sergey Soldatov
+1 Nadya Morozova
+1 Robert Burrell Donkin (Incubator PMC)
+1 Richard Liang (committer)
+1 Vladimir Ivanov
+1 Dan Lydick(committer)
+1 Tony Wu
+1 Spark Shen
+1 Rui Hu
+1 Pavel Rebriy
+1 Pavel Ozhdikhin
+1 Jimmy Jing
+1 Xiao-Feng Li
+1 Alexey A Ivanov
+1 Pavel Pervov
+1 Sian January
+1 Pavel Afremov
+1 Alexei Zakharov(committer)
+1 Stefano Mazzocchi (Incubator PMC/mentor)
+1 Davanum Srinivas (Incubator PMC/mentor)
+1 Svetlana Konovalova
+1 Egor Pasko
+1 Stepan Mishura (committer)
+1 Ilya Okomin
Under the Incubator process, Harmony must have a destination prior
to exiting incubation, which means the ASF Board must decide whether or
not create a TLP for Apache Harmony prior to the Incubator vote being
official. However, I suspect that the board would want some indication
that we are ready to graduate first.
So, I am asking for a vote of the Incubator on graduation of Harmony
that is conditional on the board's approval of a TLP for that purpose.
This way we don't have to vote again after the board meeting on
Wednesday (or whenever the board considers the proposal).
Please send in your +1/0/-1 to approve/abstain/disapprove.
Status: http://incubator.apache.org/projects/harmony.html
Site: http://incubator.apache.org/harmony/
List: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/
geir
-
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]
Harmony Vote Ending Tomorrow - Sat, October 28, 2006 - 12:00 Noon, Pacific Time
if you haven't voted and are interested in voting, please do. Thanks geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Any More Unsent Votes? (Re: [VOTE] Graduate Harmony to TLP status (pending board approval))
Anyone else? Mino started processing last night, and I want to give time for people to have a chance to vote... geir Geir Magnusson Jr. wrote: The Apache Harmony community has voted to request graduation from the Incubator as a TLP. http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 200610.mbox/[EMAIL PROTECTED] The following votes have been recorded (in order of votes cast) : +1 Geir Magnusson Jr (Incubator PMC/committer/mentor) +1 Etienne Gagnon +1 Gregory Shimansky (committer) +1 Sam Ruby (Incubator PMC) +1 Rana Dasgupta +1 Danese Cooper +1 Mark Hindess (committer) +1 Alex Blewitt +1 Mikhail Fursov +1 Matthias Wessendorf +1 Alexei A Fedotov +1 Jorden Justen +1 Andrew Zhang +1 Leo Li +1 Nathan Beyer (committer) +1 Naveen Neelakantam +1 Mikhail Loenko(committer) +1 Leo Simons(Incubator PMC/mentor) +1 Paulex Yang (committer) +1 Tim Ellison (committer) +1 Salikh Zakirov +1 Alex Karasulu (Incubator PMC) +1 Weldon Washburn (committer) +1 Sergey Soldatov +1 Nadya Morozova +1 Robert Burrell Donkin (Incubator PMC) +1 Richard Liang (committer) +1 Vladimir Ivanov +1 Dan Lydick(committer) +1 Tony Wu +1 Spark Shen +1 Rui Hu +1 Pavel Rebriy +1 Pavel Ozhdikhin +1 Jimmy Jing +1 Xiao-Feng Li +1 Alexey A Ivanov +1 Pavel Pervov +1 Sian January +1 Pavel Afremov +1 Alexei Zakharov(committer) +1 Stefano Mazzocchi (Incubator PMC/mentor) +1 Davanum Srinivas (Incubator PMC/mentor) +1 Svetlana Konovalova +1 Egor Pasko +1 Stepan Mishura (committer) +1 Ilya Okomin Under the Incubator process, Harmony must have a destination prior to exiting incubation, which means the ASF Board must decide whether or not create a TLP for Apache Harmony prior to the Incubator vote being official. However, I suspect that the board would want some indication that we are ready to graduate first. So, I am asking for a vote of the Incubator on graduation of Harmony that is conditional on the board's approval of a TLP for that purpose. This way we don't have to vote again after the board meeting on Wednesday (or whenever the board considers the proposal). Please send in your +1/0/-1 to approve/abstain/disapprove. Status: http://incubator.apache.org/projects/harmony.html Site: http://incubator.apache.org/harmony/ List: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ geir - 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]
UPDATE - Re: [VOTE] Graduate Harmony to TLP status (pending board approval)
As noted in the vote email : Geir Magnusson Jr. wrote: Under the Incubator process, Harmony must have a destination prior to exiting incubation, which means the ASF Board must decide whether or not create a TLP for Apache Harmony prior to the Incubator vote being official. However, I suspect that the board would want some indication that we are ready to graduate first. So, I am asking for a vote of the Incubator on graduation of Harmony that is conditional on the board's approval of a TLP for that purpose. This way we don't have to vote again after the board meeting on Wednesday (or whenever the board considers the proposal). I'm happy to report that much to my surprise and delight, the board considered and accepted the TLP proposal for Harmony at today's board meeting, so the above condition is satisfied. I look forward to completing this vote. (Some time after Minotaur is revived and personal @apache.org mail flows again...) Thanks geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Comment - (Was [Fwd: [VOTE] REVISED Policy on Initial Committer and PPMC members])
I didn't want to mess up the vote thread... Should this really be Shall? We've been successful in Harmony with a slightly different model, where we didn't just sweep committers in except for the mentors and champion, because we didnt' start with any code. We treated the Initial Committer list as an indication of interest, and just looked for people that followed through once the project got started. geir Original Message Subject: [VOTE] REVISED Policy on Initial Committer and PPMC members Date: Wed, 25 Oct 2006 16:12:19 -0400 From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: general@incubator.apache.org To: general@incubator.apache.org Based upon all of the discussion -- and positive feedback from Dims, Eric Newcomer, Craig Russell, Jason van Zyl, Martijn Dashorst, David Recordon and Nail Pemberton; slight negative feedback from Leo Simons; and no strongly negative feedback that I notice -- this is now put forth for a formal vote: -- The Champion shall work with the incoming community to identify the initial committers. The Champion shall review each with the incoming community to justify each inclusion (active committer, highly desired new committer, etc., but not arbitrary). The proposal does not need to include the justification, although the Champion should share it (and any concerns) with the Incubator PMC. The Champion shall work with the incoming community identify the initial PPMC members*. The Champion shall review each with the incoming community to justify each inclusion.The proposal does not need to include the justification, although the Champion should share it (and any concerns) with the Incubator PMC. The Champion shall include the list(s) in the Project Proposal submitted to the Incubator PMC for voting to accept the project. Upon a successful vote to accept, the proposal as accepted shall determine the initial committer and PPMC lists. *Incubator PMC members have oversight on all Incubator projects, and need not be listed, although Mentors need to be identified when the project is accepted. -- --- Noel - 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: Comment - (Was [Fwd: [VOTE] REVISED Policy on Initial Committer and PPMC members])
Noel J. Bergman wrote: Geir Magnusson Jr. wrote: Should this really be Shall? We've been successful in Harmony with a slightly different model, where we didn't just sweep committers in except for the mentors and champion, because we didnt' start with any code. Yes, it should be a Shall, since it has been made quite clear that the majority of people want a binding list. The work you did on Harmony: We treated the Initial Committer list as an indication of interest, and just looked for people that followed through once the project got started. would have to be done PRIOR to the vote. How? How do you see if the people actually engaged in the community until after it got formed and working? geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comment - (Was [Fwd: [VOTE] REVISED Policy on Initial Committer and PPMC members])
Noel J. Bergman wrote: Geir Magnusson Jr. wrote: Noel J. Bergman wrote: Geir Magnusson Jr. wrote: Should this really be Shall? We've been successful in Harmony with a slightly different model, where we didn't just sweep committers in except for the mentors and champion, because we didnt' start with any code. Yes, it should be a Shall, since it has been made quite clear that the majority of people want a binding list. The work you did on Harmony: We treated the Initial Committer list as an indication of interest, and just looked for people that followed through once the project got started. would have to be done PRIOR to the vote. How? How do you see if the people actually engaged in the community until after it got formed and working? What problem are you trying to solve? Garrett's view is that you basically discarded the Initial Committer list, treated it as advisory, and dealt with Committers after the fact. So a minimal Initial Committer list would be null except for the Mentors. Yes. But having that list of people interested is useful. Maybe the name should change from Initial Committer to something else when there's no code. Anyway, never mind. I was just think that this is a good guideline, but I'm wary of strict procedure for something like this. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comment - (Was [Fwd: [VOTE] REVISED Policy on Initial Committer and PPMC members])
Anyway, I do realize that the discussion was two weeks ago. I just missed it. Apologies. Ignore me :) geir Geir Magnusson Jr. wrote: Noel J. Bergman wrote: Geir Magnusson Jr. wrote: Noel J. Bergman wrote: Geir Magnusson Jr. wrote: Should this really be Shall? We've been successful in Harmony with a slightly different model, where we didn't just sweep committers in except for the mentors and champion, because we didnt' start with any code. Yes, it should be a Shall, since it has been made quite clear that the majority of people want a binding list. The work you did on Harmony: We treated the Initial Committer list as an indication of interest, and just looked for people that followed through once the project got started. would have to be done PRIOR to the vote. How? How do you see if the people actually engaged in the community until after it got formed and working? What problem are you trying to solve? Garrett's view is that you basically discarded the Initial Committer list, treated it as advisory, and dealt with Committers after the fact. So a minimal Initial Committer list would be null except for the Mentors. Yes. But having that list of people interested is useful. Maybe the name should change from Initial Committer to something else when there's no code. Anyway, never mind. I was just think that this is a good guideline, but I'm wary of strict procedure for something like this. geir - 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: Harmony graduation vote on harmony-dev
Greg Stein wrote: The Incubator is about verification, not participation. I think Geir is wrong in trying to lever IPMC members into more project involvement. We are here as volunteers to oversee the process, not participate in the projects. I think this is a topic for honest disagreement, as while it is about verification, the practice of mentoring a community does include participating. We had IPMC members that were engaged (voluntarily) in the project - all I tried to do was have votes over there rather than over here. There clearly is wide disagreement in the utility and legitimacy of this, which I think warrants some discussion, independent of Harmony itself. I'm going to end the vote on -dev and do a canonical one here so we can move on. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Graduate Harmony to TLP status (pending board approval)
The Apache Harmony community has voted to request graduation from the Incubator as a TLP. http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 200610.mbox/[EMAIL PROTECTED] The following votes have been recorded (in order of votes cast) : +1 Geir Magnusson Jr (Incubator PMC/committer/mentor) +1 Etienne Gagnon +1 Gregory Shimansky (committer) +1 Sam Ruby (Incubator PMC) +1 Rana Dasgupta +1 Danese Cooper +1 Mark Hindess (committer) +1 Alex Blewitt +1 Mikhail Fursov +1 Matthias Wessendorf +1 Alexei A Fedotov +1 Jorden Justen +1 Andrew Zhang +1 Leo Li +1 Nathan Beyer (committer) +1 Naveen Neelakantam +1 Mikhail Loenko(committer) +1 Leo Simons(Incubator PMC/mentor) +1 Paulex Yang (committer) +1 Tim Ellison (committer) +1 Salikh Zakirov +1 Alex Karasulu (Incubator PMC) +1 Weldon Washburn (committer) +1 Sergey Soldatov +1 Nadya Morozova +1 Robert Burrell Donkin (Incubator PMC) +1 Richard Liang (committer) +1 Vladimir Ivanov +1 Dan Lydick(committer) +1 Tony Wu +1 Spark Shen +1 Rui Hu +1 Pavel Rebriy +1 Pavel Ozhdikhin +1 Jimmy Jing +1 Xiao-Feng Li +1 Alexey A Ivanov +1 Pavel Pervov +1 Sian January +1 Pavel Afremov +1 Alexei Zakharov(committer) +1 Stefano Mazzocchi (Incubator PMC/mentor) +1 Davanum Srinivas (Incubator PMC/mentor) +1 Svetlana Konovalova +1 Egor Pasko +1 Stepan Mishura (committer) +1 Ilya Okomin Under the Incubator process, Harmony must have a destination prior to exiting incubation, which means the ASF Board must decide whether or not create a TLP for Apache Harmony prior to the Incubator vote being official. However, I suspect that the board would want some indication that we are ready to graduate first. So, I am asking for a vote of the Incubator on graduation of Harmony that is conditional on the board's approval of a TLP for that purpose. This way we don't have to vote again after the board meeting on Wednesday (or whenever the board considers the proposal). Please send in your +1/0/-1 to approve/abstain/disapprove. Status: http://incubator.apache.org/projects/harmony.html Site: http://incubator.apache.org/harmony/ List: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Harmony to TLP status (pending board approval)
+1 Geir Magnusson Jr. wrote: The Apache Harmony community has voted to request graduation from the Incubator as a TLP. http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 200610.mbox/[EMAIL PROTECTED] The following votes have been recorded (in order of votes cast) : +1 Geir Magnusson Jr (Incubator PMC/committer/mentor) +1 Etienne Gagnon +1 Gregory Shimansky (committer) +1 Sam Ruby (Incubator PMC) +1 Rana Dasgupta +1 Danese Cooper +1 Mark Hindess (committer) +1 Alex Blewitt +1 Mikhail Fursov +1 Matthias Wessendorf +1 Alexei A Fedotov +1 Jorden Justen +1 Andrew Zhang +1 Leo Li +1 Nathan Beyer (committer) +1 Naveen Neelakantam +1 Mikhail Loenko(committer) +1 Leo Simons(Incubator PMC/mentor) +1 Paulex Yang (committer) +1 Tim Ellison (committer) +1 Salikh Zakirov +1 Alex Karasulu (Incubator PMC) +1 Weldon Washburn (committer) +1 Sergey Soldatov +1 Nadya Morozova +1 Robert Burrell Donkin (Incubator PMC) +1 Richard Liang (committer) +1 Vladimir Ivanov +1 Dan Lydick(committer) +1 Tony Wu +1 Spark Shen +1 Rui Hu +1 Pavel Rebriy +1 Pavel Ozhdikhin +1 Jimmy Jing +1 Xiao-Feng Li +1 Alexey A Ivanov +1 Pavel Pervov +1 Sian January +1 Pavel Afremov +1 Alexei Zakharov(committer) +1 Stefano Mazzocchi (Incubator PMC/mentor) +1 Davanum Srinivas (Incubator PMC/mentor) +1 Svetlana Konovalova +1 Egor Pasko +1 Stepan Mishura (committer) +1 Ilya Okomin Under the Incubator process, Harmony must have a destination prior to exiting incubation, which means the ASF Board must decide whether or not create a TLP for Apache Harmony prior to the Incubator vote being official. However, I suspect that the board would want some indication that we are ready to graduate first. So, I am asking for a vote of the Incubator on graduation of Harmony that is conditional on the board's approval of a TLP for that purpose. This way we don't have to vote again after the board meeting on Wednesday (or whenever the board considers the proposal). Please send in your +1/0/-1 to approve/abstain/disapprove. Status: http://incubator.apache.org/projects/harmony.html Site: http://incubator.apache.org/harmony/ List: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ geir - 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: JiniProposal - BraintreeProposal
w00t! Jim Hurley wrote: Hi all- Thank you to the 134 folks who participated in the survey to help us determine a new name for the Jini project proposal at Apache. The results are included below. The first preference was for aladin (related to the genie theme), but unfortunately, there are some potential TM issues associated with that name that were uncovered (after the survey). From people far more knowledgeable on trademark policy, different spelling virtually never makes enough difference in trademark circumstances. There is already trademark around aladdin, and therefore, we don't feel like we should choose this name. Going to the next preference (djinn) also uncovered some potential trademark issues. I also looked at variations, including djinni which had similar issues. Given this, it doesn't seem like a good choice for us as well. The third preference (braintree) seems fairly clean, so we are going to go with this name for our project proposal. I will update the wiki today. If we are successful in getting approved as an incubator project, and this name is not resonating, we can always change it during incubation. Thanks, everyone, for your patience and support during this somewhat trying naming period... once we get the Proposal on the wiki updated, I hope we can move forward to an incubator vote. If you have any questions, please let me know. thanks -Jim -- Results of the 134 votes cast, along with percentage numbers for the first 4 preferences. 1) aladin( 28.80%) 2) djinn (18.40%) 3) braintree(16.00%) 4) river(9.60%) 5) bodega 6) codeinmotion 7) kuiper 8) constellation, freejack, jackalope 9) biere, peace, red99, cloudscape 10) jazmin, jinius, jane, genio, particles, jiniache, djs, hydra, ubi, swami, iguana -- - 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] Graduate Harmony to TLP status (pending board approval)
Cliff Schmidt wrote: On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: So, I am asking for a vote of the Incubator on graduation of Harmony that is conditional on the board's approval of a TLP for that purpose. This way we don't have to vote again after the board meeting on Wednesday (or whenever the board considers the proposal). Please send in your +1/0/-1 to approve/abstain/disapprove. +1 Status: http://incubator.apache.org/projects/harmony.html a little strange that the Incubation Status Reports section reads, none yet, but I've seen several of them in Incubator board reports and such a piece of bureaucracy won't change my vote. Yes, we've reported each time it was our turn. I'll put the links in. Thanks for the heads-up geir Cliff - 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: voting was Re: [PROPOSAL] Ivy
Might be nice to leave binding-ness as an accounting detail for the person running the vote, to get rid of the my vote counts, yours doesn't thing that David pointed out. After all, if you get consensus, and it's all +1s. geir Paul Fremantle wrote: David I think you are wrong. Before I saw that syntax I used to assume that I couldn't vote unless my vote was binding. I've seen this model encourage non-PMC members to vote (myself included). Paul On 10/24/06, david reid [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: it's a hint that the voter is a pmc member. *sigh* Really, no, seriously, you're telling me that the PMC can't be trusted to count votes from it's members and others it feels are qualified? Wow... Seriously, pointing out such differences just splits the community. Hey, my vote counts! Yours doesn't! After seeing the people involved in the incubator at AC US, I'm pretty sure they were all past the stage of being impressed by such things. We should get over ourselves. +1 (binding) Forgive my ignorance, but what does +1 (binding) mean? -- david http://feathercast.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- david Have you listened to FeatherCast yet? http://feathercast.org/ Bought the t-shirt? http://www.cafepress.com/feathercast/ - 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: Harmony graduation vote on harmony-dev
Mads Toftum wrote: On Fri, Oct 20, 2006 at 06:34:02PM -0400, Geir Magnusson Jr. wrote: Just so no one misunderstands this - the only way a podling can graduate is if it has enough IPMC votes. The model in mind was that there are IPMC members engaged with the community, so that it's their votes that make it official (not the other community votes). (So come and vote...) I'm sorry, but that just doesn't work for me - you're essentially moving the vote further away from those who have the binding votes. That's very much the wrong direction to go. I'd be fine if you were to hold Harmonys vote about if they should ask for graduation on harmony-dev, but the incubator pmcs vote should be on [EMAIL PROTECTED] I really don't like this one bit - adding extra hoops to make voting more cumbersome for certain people - and don't want to take the thought about historical parallels any further. /rant I'm sorry for the ranting, but I get very annoyed when someone tries to prune out voters up front that may not have the right opinions. I'm sure that it wasn't the direct intention, but it will be the effect. Prune out? I've been criticized for the exact opposite, namely trying to ensure that people have enough information, trying to come to consensus, rather than just calling for a vote and hoping to just get a majority. Adding projects to the ASF is a serious matter (I know, this doesn't add it, but it's a major step), and I am uncomfortable with discussion-less votes for things this important. You'd have a point if it wasn't announced, explained and re-announced. I'm not asking you to travel, register, have government ID, pay a poll tax, fight through a line of protesters, get around roadblocks, get yourself off a list of felons, or wait in line forever because there aren't enough voting machines. Nor is it an attempt to just get by with the few IPMC members that did vote on harmony-dev so far. I'll be very disappointed if we don't get your vote, Greg's vote, Roy's vote, Noel's vote, Bill's vote, everyone's - WHATEVER THAT VOTE IS - on this matter. All this asks is that you put a different string of ASCII characters (harnony-dev vs general) in front of @incubator.apache.org in the To: field of your email when you send your vote for the purpose of having the vote on the mail list of the community upon which you are casting judgment about their fitness to graduate the incubator. I honestly didn't think it would be that much of burden, but would be a harmless experiment in community building and Incubator Process - it was meant to be something positive. Seems like the jury is still out, but I still believe I'm not wrong. I do thank you for being open and forward with your opinion (although I don't like the accusation) and hope to hear from others as well, either with your votes or simply your comments. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Harmony graduation vote on harmony-dev
Justin Erenkrantz wrote: On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'm not trying hold a vote elsewhere - this can only happen if there is a binding vote by the Incubator - it just means you vote over there rather than over here. Um, no. The only votes that are binding from the Incubator PMC are those conducted on general@ or [EMAIL PROTECTED] Roy's point about graduation was that the PPMC should vote for graduation first - that can certainly happen on their list. We're past that. But, the Incubator PMC shouldn't be forced to play hunt the wumpus and be forced to subscribe to yet another mailing list to follow every podling's official graduation vote. I'm sorry, but this is an absolutely horrible precedent to set. -- justin Could be. Maybe even probably. However, it also could be a way to get IPMC members more engaged in the activities over which the board has charged oversight. Clearly having every IPMC member on ever dev list for the life of the project doesn't scale, but I do think we need to rethink the model to get better IPMC engagement in podlings in a scalable way. Honestly, that's what I thought the mentors were for - IPMC members that participate, and make the actions of the podling official. This was a gentle shake of the tree, and it has been informative for me. Maybe the Harmony-dev vote will stand, maybe not. (I'm still waiting - with a feeling of mild dread in my asbestos shorts - for Roy's comments :) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Harmony graduation vote on harmony-dev
Greg Stein wrote: I was happy to give a +1 days ago. But that wasn't put on the table. Ok. I'm going to stick my neck out here, out of my comfort zone. While bringing Harmony out for graduation was never meant to be a vehicle for change, it's clear that there are opportunities where we can explore alternatives to our conventional process. For example, working in interaction between the podling and the greater incubator community, and doing it on home turf for the podling. I keep thinking of something I believe Roy said when we first were getting community incubation and PPMCs formalized - when a community gets organized enough to vote itself out of the Incubator, it's appropriate. After I send this message, I'm going to send a message on harmony-dev, asking for a vote on graduation. I'm encouraging both the full harmony community, and the full incubator community to vote. I'm not trying hold a vote elsewhere - this can only happen if there is a binding vote by the Incubator - it just means you vote over there rather than over here. I'm looking for consensus here - I'm not interested in squeaking by, ramming through, sneaking past, running around, skipping over, digging under... (I ran out of prepositions...). If you think that Harmony should graduate, please vote +1. If you don't think so, please vote -1 and say why so we can fix it. If you have no opinion, please vote 0. Knowing the interest and oversight level is important. The timing is suboptimal, because of the upcoming colo move and consequent mail disruption, and it's a weekend, but given the interest level in the subject, I see nothing to lose. The vote will go on for 72 hours + mail outage time. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Checkpoint on Harmony (Re: [discussion] Harmony podling to ask for vote for graduation)
William A. Rowe, Jr. wrote: Last checkpoint, Has the sponsoring PMC [e.g. Board] voted to accept the project? You have a few hours yet to put a resolution on their plate for next week. And honestly - they would probably table it for review even if you gave them a month lead time, so might as well get that out of the way. Isn't that backwards? The Incubator votes to release from incubation, and then the podling is free to petition the board for TLP with credential from the Incubator PMC re it's community and IP? geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Harmony graduation vote on harmony-dev
Geir Magnusson Jr. wrote: Greg Stein wrote: I was happy to give a +1 days ago. But that wasn't put on the table. Ok. I'm going to stick my neck out here, out of my comfort zone. While bringing Harmony out for graduation was never meant to be a vehicle for change, it's clear that there are opportunities where we can explore alternatives to our conventional process. For example, working in interaction between the podling and the greater incubator community, and doing it on home turf for the podling. I keep thinking of something I believe Roy said when we first were getting community incubation and PPMCs formalized - when a community gets organized enough to vote itself out of the Incubator, it's appropriate. Just so no one misunderstands this - the only way a podling can graduate is if it has enough IPMC votes. The model in mind was that there are IPMC members engaged with the community, so that it's their votes that make it official (not the other community votes). (So come and vote...) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Factors for Graduation (Was Re: [discussion] Harmony podling to ask for vote for graduation)
I'm not dismissing the importance of Greg's concern, and am not trying to take the Harmony conversation down a rat-hole (or different rat-hole in this case...), so I changed the Subject line. --- Let me take a brief side trip here about [Unwritten] Incubator Graduation Requirements Isn't this a bit open ended, in that you can always choose some important and common aspect of Apache project life and ask if the podling has done it? 1) Has the podling shown they can deal with technical dissent on a commit? 2) Has the podling shown they can deal with two competing solutions to a problem? 3) Has the podling shown they can deal with an emergency security patch to a release? 4) Has the podling shown they can deal with a troll on the user list? 5) Has the podling shown they can deal with resignation from the PMC? 6) Has the podling shown they can deal with a downstream consumer abusing the podling name/trademark? 7) Has the podling shown they can deal with a revolutionary fork inside the podling? 8) Has the podling shown they can deal with mistakes in accepting contributions or including 3rd party dependencies? 9) Has the podling been able to work with outside communities in a productive manner that shines a positive light on the ASF? 10) has the podling been able to police itself in terms of ensuring civil and non-personal (other than friendly) discourse among the participants? 11) has the podling been able to demonstrate the ability to work closely and productively with other Apache projects/podlings? 12) Does the podling have an established and well-understood pattern for voting on issues? 13) Has the podling had to deal with legitimate/illegitimate interruption of that standard voting pattern? 14) Has the podling added committers? 15) Has the podling grown the PPMC? FWIW, Harmony has dealt peacefully and successfully with 1, 2 (two math and two RMI impls, we chose based on technical merit), 4, 7-ish (committer had to prove a concept to internal skeptics), 8 (j.u.c went to wrong place in our SVN - it doesn't have cleanroom provenance), 9 (our interaction with MX4J, SableVM), 10, 11 (our engagement with Yoko to provide our CORBA impl - in fact, a Harmony committer also earned commit on Yoko), 12 (in spades) 13 (legit), 14, 15 I think it would be absurd to require a podling to have to check all of these boxes, but they are important things, just as important as a release, and arguably happens far more often than a release. And the skills that help a podling navigate the above list, are the same skills that come into play in a release. What I look for in podlings is a sense of Do I reasonably believe that the community be able to independently deal with things like this (including releases) in their future life as a TLP? And yes, I have and will again make mistakes - it's a judgment call - which is why there are more than one set of eyes on these things... geir Greg Stein wrote: Without question, Harmony knows how to manage its legal bits. Can the community navigate through all those hurdles and processes and other shtuff to actually produce a release? Is this community set up to produce releases, or is it set up to check off legal paperwork? I know there are many individuals participating in Harmony who have done *dozens* of releases of various products here at Apache. But can they get the community to produce a (developer) release of Harmony? For example, I think about all the hell the Tomcat community went through with the whole v3 versus v4 versus v5 debates. Or Geronimo trying to figure out what v1.2 meant. Or Avalon trying to get a release out. Or httpd finding it On 10/19/06, Leo Simons [EMAIL PROTECTED] wrote: On Oct 17, 2006, at 4:30 PM, Daniel Kulp wrote: I don't have a binding vote, but my thought is Harmony has the same issue as Felix: namely they haven't done a release or provided even a test release to the IPMC so the IPMC can be sure the podling knows the proper way to do a release and understands and can correct all the issues such as proper apache licensing, etc...Basically, make sure the podling can get all their Apache Legal Ducks in a Row. This is a good point, and thanks for raising it. I'll now try and take away your concern, and everyone elses, on this point. As one of harmony's mentors, I'm confident that harmony has more legal ducks than most apache projects, and has them more precisely in row that most, and that this is only the case because of a community with outstanding legal awareness. Harmony started with precisely 0 committers, and 6 months of legal talks. Its processes and policies are, IMHO, more secure and safe (paranoid!) than those of any other project at apache. They were like that before we seriously started adding committters. Each committer was added only after a vote on the PPMC. Each person on the PPMC was only added after a vote by the PPMC. Each big outside contribution was
Re: [discussion] Harmony podling to ask for vote for graduation
I made the mistake of not responding publicly, thinking that it was just best to ignore it. I had nothing to do with it - it didn't represent any sentiment that I have, nor was I a participant in any such email conversation, or ever have been. My head has only room for one hat at a time, and it's an Apache hat right now. I thought that this mistake would be ignored, and therefore let it go. I was wrong to do so. I greatly admire Roy, and the Apache values that he's defending. So I'd like to apologize to Roy for my silence, because I *am* in lockstep agreement with him regarding what a podling needs to have to be a successful TLP - I simply respectfully disagree on the ways a podling must/can show it. geir Roy T. Fielding wrote: On Oct 18, 2006, at 1:25 PM, Grote, Judy wrote: He just never seems to give up--like a small child not knowing when to stop. No, more like an old grandpa who sees his grandkids grab a pair of scissors and then asks the parents whether they've taught them not to start running around the room doing acrobatics with scissors. A small child would just delete the repository and say oops. It is something I do by habit, after being exposed to so many clueless twits like yourself. I would like the ASF to survive its growth. Besides, I was about to vote +1. You just changed my vote to -1. Roy - 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]
Checkpoint on Harmony (Re: [discussion] Harmony podling to ask for vote for graduation)
Oh, what a trip this has been. I like consensus. I don't like out-of-the-blue discussion-less votes on big issues (and Incubator graduation is a big issue). I prefer to have a vote as an unambiguous ratification of what was agreed upon beforehand. In retrospect, it might have been procedurally more efficient, but I still think that having this discussion was important. I certainly plan to revisit some of these topics in Incubator when the smoke has cleared around Harmony, whenever that is. I agree with the motivations behind asking for a release, but disagree that a release is the only way to satisfy IPMC's need for information about the health and capability of a podling's future life as a TLP. We've had 4 reports from the 4 mentors of the project, 3 (Stefano, Leo and Dims) that I would argue are arms-length mentors who are not as closely invested in the project as I am, and are well-known for their directness, honesty and openness. I'd like to ask that those who have asked for a release to assuage concerns about community health and capability to please read those 3 testaments from the mentors (ok, in Leo's case, 71 or so...) and please consider withdrawing your request for a release. If we can reach consensus (with the exception of Mads who doesn't want to see Harmony here, and Roy for other good reasons due to my stupidity), I'd like to then move to the ratification vote. geir Leo Simons wrote: Last e-mail on this for the day, promised! :-) Greg -- having many e-mails as threaded responses rather than a single one is useful if you have nested threading and you're only interested in part of a sub-sub-thread. Maybe gmail needs fixing :-P. In any case, here's your overview. On Oct 17, 2006, at 6:44 AM, Geir Magnusson Jr wrote: I believe the active mentors (myself, Stefano, Leo and Dims) will assert that the [harmony] community is healthy and very active. Yup. We'd like to help make this as efficient a process as possible - please let us know if there are any issues that will prevent a successful vote by the PMC on our graduation. If there are no un-addressed issues in the next 3 days, I'd like to call a vote late on Thursday, October 19th, so we can possibly be finished in time for the next Board meeting, October 25th. Issues I saw raised: == should have all legal ducks in a row == Check. Double check. Triple check. Pass. Best student in class. == should not have a language implementation at apache at all since that's too big a project to fit with the rest of the ASF == With a harmony/incubator hat on, I disagree with that (since the stated goal of harmony is to be a language implementation!), and in any case I think it shouldn't be a factor in deciding on graduation. With an ASF member hat on, I do continue to be concerned about the ASF its ever-increasing size, but that's not something that harmony itself can really address or is responsible for. == should have done a release == I disagree with this. The release requirement is a (undocumented as required!) way to gauge that a project's developer community can jump through various hoops and be responsible about managing big issue things. This community has shown so already. I think the fact that harmony has not done a full release cycle is actually a healthy thing for the project. The slowdown inherent to that kind of cycle for harmony will come because of needing to do TCK testing, and that very TCK testing will put more requirements on the project anyway than a normal ASF-style release process. I think the kind of release process that harmony needs to have is very different from most existing ASF projects (for one, it needs a little server cluster to run tests on) and that any comparisons are therefore not very useful. == So, where are we? == I don't think the should have done a release issue has been addressed (since harmony hasn't done one with all the bells and whistles, just snapshots). *I* don't think it needs to be addressed before graduating out of the incubator, in the case of harmony. It's not completely clear what the incubator PMC thinks about that topic (if anything, this shows how hard it is for the IPMC to make up its mind...we really do seem to have a pendulum opinion when it comes to this stuff). Me being me, I would just call a vote and find out. LSD - 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: RAT
Into the incubator, of course ;) geir Noel J. Bergman wrote: Robert, Is this something you would bring over to the ASF, and which we can start promoting around the ASF to use? --- Noel - 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: Checkpoint on Harmony (Re: [discussion] Harmony podling to ask for vote for graduation)
Greg Stein wrote: On 10/19/06, Roy T. Fielding [EMAIL PROTECTED] wrote: On Oct 19, 2006, at 3:32 AM, Geir Magnusson Jr. wrote: ... I'd like to ask that those who have asked for a release to assuage concerns about community health and capability to please read those 3 testaments from the mentors (ok, in Leo's case, 71 or so...) and please consider withdrawing your request for a release. That's silly -- why would people who think a release (or at least the release process) is a useful learning process drop such a *request*? I could understand your concern if it was expressed as a requirement, but it most certainly wasn't. Right. I said it would be useful to see if the community can make it happen. I know that *some individuals* can, but that is different. I didn't vote, I didn't say it was a requirement, just asked: why can't you pull together a *developer* release. Not TCK'd, not for Joe User, but something more formal than here is a snap of Subversion. Something that developers in and around the Incubator can try. Or simply for (Incubator) people to observe how you plan to organize the community to get a release out the door. People can already use the snapshots. We don't really just do a snap - there's discussion about if we believe that the parts are at least stable enough to do it. We break things - what we're doing is pretty hard - so we don't do snaps when we know it's broken. I'm not trying to toot our horn here, but this is pretty hard stuff, and IMO we're just not ready to be putting something out there with even an implied statement of stability or usefulness. This isn't about TCK - we'll start that ASAP, and probably complete it sometime mid next year if all goes well. Look, if incubator people really feel the need to observe that process, that's fine. It's clear the delivered artifact is not what matters, but how the community does it. I can think of a few things that we could do as a single-jar release that would require work to setup, and we can go through the release process to produce. Without seeing that, you could graduate to a TLP that may be fully incapable of producing a release. Ever. I have zero indication that the Harmony community can actually produce releases. Code, yes. Releases, no. I think it unlikely that it couldn't given the amount of decision making the project has already gone through (which is the key thing, IMO), but it's really hard to disprove your assertion - I take you at your word that you have zero indication. What is clear to me is that anything we do now will have little resemblance to what we do to release 1.0, as there are tons of issues that remain to be sorted, such as which platforms to support, how the TCK integrates into our test framework and how we use it, etc. The only thing in common would be how the community works together, votes together and makes decisions together, and as you know, I feel that there is ample evidence to support that those skills have been demonstrated. Don't you think it would be a useful experiment for the Harmony community? While any activity like this with a young community is a useful experiment, I'll point out that we're now literally experimenting on our podlings. :) I personally don't think that it would add any more information than what has been summarized by the mentors and is in 18 months of mail archives. However, that's my personal view, and I've had close contact with the community. It's clear that you haven't come to the same conclusion yet. Roy suggests that unanimity of opinion is just an ideal, but it's one I think it's worth working towards. Or are you viewing it solely as make-work? To be frank, yes, I think it is make-work as it isn't in our plans, although I'm sure that if this is required, we'll be happy to do it. I was hoping that enough info would be provided by mentors to satisfy people's need for information (as it did Justin). Hey, I had to give it a shot, right? :) That you're confident that the Harmony community will not suffer problems that we've seen in other communities around their release processes? The decision is certainly the community's (actually... where are they? why is Geir the only active Harmony person in this conversation?).I'd like to hear the community say, nah. we think that would be busy work with no utility. Fair answer, but I will note that nobody has made a clear statement like that. Talked around the issue, but never directly answered. This is an interesting notion, as I think that this measurement is clearly going to affect the system being measured. If you read the mail lists, the steady state of the project is that we're heads-down on code, working together, happy with snapshots, and working hard to get things integrated and completed. From afar, it's reasonable to assume that we aren't that interested in a release right now because it's never been mentioned. Now, the Giant
Forrest? Trees?
I'm pretty resigned to the fact that we're not going to be able to present a resolution to the board this month for Harmony. I do keep a flicker of hope, mainly because I'm an eternal optimist. I do think it's a shame, because I believe the core values sought and taught in the incubation process are community and IP provenance, and I think Harmony has that in ample quantity. I think that those are the core strengths of any Apache project, the necessary toolset needed by a community. Sure, there are minor nits in a few missing license headers in some scripts or CSS files or whatever, and it's good to point them out because these details are very important, but I think we're missing the bigger picture here. These kinds of things don't reflect any defects in the community IMO - they're buried in the noise. It's just an oversight. Here are some other irrelevant oversights : There is no NOTICE file in /jackrabbit/trunk/textfilters, no license header in /apr/apr-util/trunk/build.conf, inaccurate copyright statement in /maven/maven-1/core/trunk/build-bootstrap.xml, no license header in /tomcat/container/tc5.5.x/catalina/src/conf/server.xml, no license header in /webservices/axis2/trunk/c/autogen.sh, no license header in /spamassassin/trunk/INSTALL . I was just clicking around more or less randomly to find things. I don't think the above oversights matter. I suspect that the projects are happy for the info, and will fix. Anyway, I look forward to getting beyond this issue, and bringing my lessons learned as one on the receiving end of the incubator graduation process back as a member of the IPMC. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RAT
I just wanted to run RAT on RAT ;) geir Justin Erenkrantz wrote: On 10/19/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Is this something you would bring over to the ASF, and which we can start promoting around the ASF to use? To be honest, I don't believe it's a good fit. Not every project needs to be here... -- justin - 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: Checkpoint on Harmony (Re: [discussion] Harmony podling to ask for vote for graduation)
William A. Rowe, Jr. wrote: Sam Ruby wrote: William A. Rowe, Jr. wrote: IMHO - the only reason to have a project (TLP or subproject, no matter) is to release code. Anything prior to a release might be a sandbox, it might be a podling, it might be a lose alliance of the willing. Whatever... [snip] That said ... I don't believe anyone is saying Harmony must release it's entire codebase to graduate. Any working and usable component or part of the harness could be released as 0.1 alpha version, the processes followed, the issues raised and resolved. With a codebase as large as Harmony, I sure don't expect the whole ball of wax to be ready, or at the same level of stability, all at once. Be aware that in the context of J2SE, a release must fulfill some compatibility requirements. Included in this is a requirement not to subset. Understood. This can not be a J2SE release. The question I raised is if there can be part of the 'firmament' beneath the VM released. Yes, I grok that none of this shall be released as a J2SE VM - because the only J2SE VM is a complete VM. Of course, one could simply manufacture a synthetic release for the purposes of satisfying a perceived incubation requirement, but honestly, that seems more like one of the ticky-marks driven processes I tend to see within my day job than anything I would expect to see at the ASF. I certainly hope that the concept of 'releasing the code' isn't just a tick mark - I'd imagined (contrary to other proposals flying around) that it's the end goal of nearly any collaborative effort at the ASF, no? No, because then every project would simply disband after milestone 1 :) [snip] So as much as I admire the enthusiasm of the entire community and know that the vote will disappoint some folks, I'll repeat my root question; how does incubation status interfere with progress of the Harmony project prior to its first release? If you forgive me, let me propose a thought experiment. Why don't we simply dissolve the board, and throw everything back into incubation? What would it hurt? Projects obviously have been holding releases during incubation, many have had multiple releases. I'm failing to see where you are going here, and made your post initially really hard to follow. Ignoring the above... No, that's not a serious proposal. What I am growing increasingly concerned with is that we (collectively) have started to lose sight on what the mission of the incubator is. Yes, not having a release is an indicator, but there certainly are other indicators. No, I'm not advocating that we rush projects out of the incubator. Absolutely, it's gotta be the question. If whatever decisions are made at the incubator don't reflect its mission, well, those decisions are pretty pointless, eh? What I am looking for is a happy medium. In particular, I would like to see is for the rate of disposition (either in a positive or negative manner) of projects in the incubator approximate the rate of creation. More succinctly: I want to see projects that are ready to graduate start graduating, not because it benefits them, but because befits the incubator. +1 to keeping some equilibrium, and I hope all the mentors are watching the ball. The recent request by the board to highlight three of the biggest obstacles might help define this. -1 to simply pushing things out because our plate is full. I'm not going to object if folks start throttling on the front end; please hang on to your proposal, it seems like a worthy effort but the pipeline is too full --- which hopefully leads to a show of hands from a few new ASF members to take on and mentor a few more projects. I'm suggesting new blood/more blood, not bleeding the current volunteers to death. But no one is suggesting that we need to get Harmony out simply to make room for something else. After contemplating for several months now, we thought the time was right. I think requiring a release is losing sight of the basic premises of incubator, which are creating a healthy apache community with a clean codebase. A release is one of many things that a community will grapple with in it's lifetime, and yes, it's a good reference point to *observe* a project in it's natural state when evaluating health. But as I noted earlier, there are many things that are good reference points to observe (deal with a troll, resolve a technical difference, choose among two solutions, deal with an outside project, etc...). I think that the mentors and experienced participants teach. When the mentors (and the podling) agree that graduation is in order, it's up to the rest of us to evaluate the data that's there. Clearly the mentors used some data to make their decision... This is why I pushed back on this - not because a release of some small thing in Harmony isn't possible, but because I think there is ample information to look at and I think we're missing the forest for the trees. I'm
Re: [discussion] Harmony podling to ask for vote for graduation
Roy T. Fielding wrote: On Oct 18, 2006, at 11:14 AM, Don Brown wrote: Agreed. I don't think it is fair to be making up graduation requirements right when a project is about to graduate. The graduation requirement is that a majority of the PMC members agree that a podling should be graduated. Geir asked for a discussion and he got one, so I don't see any justification for complaining about the responses. I would have just explained the current status and asked for a vote. Next time I ask Roy what to do. :) geir Roy - 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: [discussion] Harmony podling to ask for vote for graduation
robert burrell donkin wrote: On 10/18/06, Greg Stein [EMAIL PROTECTED] wrote: You said that you have run Tomcat on top of Harmony. Why can't you produce a release such that I can throw the Tomcat jar at it, too? Sure, it is a developer release, but it let's non-Harmony folks play with your project. i'd like to give harmony a spin as well :-) Go for it. We're really interested in people's feedback. Is there a specific problem with producing a developer release? releases come in many forms :-) it's usual to think of an easy-to-use ready-to-run binary aimed at end users called something like httpd-2.0.59. i agree that harmony isn't ready for something like that nor would the effort of producing something like that be at all worthwhile. but at an essential level, all that's require is to vote, tag the source and create a tarball of the tagged source. harmony already does something similar for daily snapshots. IMHO the next step would be to start cutting milestones each week or two so they can be picked up with a little more certainty than the daily snapshots. perhaps name them after the week they were cut (harmony-M3406, say). i think harmony is more than ready to take this step. I think that the core issue is can the community govern itself in an Apache manner, which is the core driver behind the do a release suggestion. I'm guessing that the do a release suggestion is simply a mechanism for PMC members to get information on which to make a decision. Will you (and others that have questions) be satisfied if other mentors provide similar assessments as I have as to community status and ability to self-govern? geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discussion] Harmony podling to ask for vote for graduation
robert burrell donkin wrote: On 10/18/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: robert burrell donkin wrote: On 10/18/06, Greg Stein [EMAIL PROTECTED] wrote: You said that you have run Tomcat on top of Harmony. Why can't you produce a release such that I can throw the Tomcat jar at it, too? Sure, it is a developer release, but it let's non-Harmony folks play with your project. i'd like to give harmony a spin as well :-) Go for it. We're really interested in people's feedback. i will do once there's something more than a snapshot :-) That's up to you, of course. Is there a specific problem with producing a developer release? releases come in many forms :-) it's usual to think of an easy-to-use ready-to-run binary aimed at end users called something like httpd-2.0.59. i agree that harmony isn't ready for something like that nor would the effort of producing something like that be at all worthwhile. but at an essential level, all that's require is to vote, tag the source and create a tarball of the tagged source. harmony already does something similar for daily snapshots. IMHO the next step would be to start cutting milestones each week or two so they can be picked up with a little more certainty than the daily snapshots. perhaps name them after the week they were cut (harmony-M3406, say). i think harmony is more than ready to take this step. I think that the core issue is can the community govern itself in an Apache manner, which is the core driver behind the do a release suggestion. I'm guessing that the do a release suggestion is simply a mechanism for PMC members to get information on which to make a decision. yep (but i do think harmony should start creating milestones very soon) This is the thing I don't get - Harmony's choices for how and when we do milestones is completely orthogonal to the values of a healthy, meritocratic, collaborative community that the incubator is tasked with creating. The fact that we are making these choices, and not just following a rote procedure, says something to the health and well-being of Harmony, IMO. Will you (and others that have questions) be satisfied if other mentors provide similar assessments as I have as to community status and ability to self-govern? i can speak only for myself. i've been subscribed to harmony for many months and am convinced on both those counts. the source is the heart of any apache release. most issues with releases are actually issues with the source. a community that does not understand how to create source that can be released cannot (in my opinion) graduate. But then you are aware that we always have been very careful about our source. We have created oversight processes specifically tailored to special IP issues we face, and consider this on every contribution, and every third- party dependency we use. personally speaking, (in this case) i'd probably be satisfied to review a snapshot or the tree rather than a sample release but is less convenient and risks the graduation vote becoming messy.so, i think that a vote and tag would be cleaner and easier. i'll try to find some time in the next few days to go through one of the snapshots. I am hoping that the statements from the other mentors will be more than sufficient to convince you and others that have these doubts. Stefano has written one, and I've pinged Dims and Leo to also post their thoughts, whatever they are. You can guess mine, of course :) (You can get a preview of the others by reading the recent harmony-private traffic) I'm not trying to be difficult. I just was trying to indicate that there are other methods - more complete methods IMO - of determining community health, and quite frankly, while releasing properly is very important, I think that the Harmony community has demonstrated that it works together collaboratively, understands issues regarding source licensing and provenance, dependency licensing, and how to play with each other in a positive and productive way. If the mentor statements aren't enough, I'm happy to help the community through a release process demonstration tomorrow, but I really hope, as an ASF member and Incubator PMC member, that we're careful not to be too prescriptive, and lean toward a more holistic approach to rating health and success capability of the podlings under our oversight. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discussion] Harmony podling to ask for vote for graduation
Niclas Hedhman wrote: On Tuesday 17 October 2006 12:44, Geir Magnusson Jr wrote: Thanks, and we look forward to your comments. To avoid cross-post confusion, I will forward this message to the harmony-dev list rather than CC. Amazing feat, indeed. I was very pessimistic to the start of Harmony, and am gladly proven wrong. Now, has all IP concerns been sorted out, especially to the been exposed to Sun's SCSL'd reference codebase been sorted out, both for existing committers and some process to how this is applied to new committers?? Yes. There never were any existing committers. We started with zero and people were voted in. (Individuals listed on the proposal had a lower bar - the just had to show participation and submit some patches/fixes). Every contributor we accept new independent material from has to complete our Authorized Contributor Questionnaire (which you can find on the website) which we keep a tiff or pdf of in SVN. I think we currently have 120 on file. Also, we ask for ACQs from all individuals that contributed to any bulk contribution - one in which software was written elsewhere and donated to us. These IP processes are built on top of the standard Apache process. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discussion] Harmony podling to ask for vote for graduation
Niclas Hedhman wrote: On Wednesday 18 October 2006 10:33, Geir Magnusson Jr wrote: Will you be satisfied with a vote on posting a snapshot? I think some Incubator PMC member wants to see a 'full release' artifact for review. The podling should select a release manager producing the artifact, which the PPMC first ensure is correct and vote upon, before asking the IPMC to take a closer look. Right now, we really don't have anything to release. Will y'all be satisfied if we go through the process for a new snapshot, pretending it's a release for Incubator purpose? If the release artifact(s) that is/are voted Ok by the PPMC also satisfies the IPMC members, then I think noone has any further objections for graduation. Given that the physical artifact is going to be the same as the snapshots we have now, can you please comment on that now so we can fix any problems before the process demonstration, so that we're don't wind up playing fetch me a rock? Note that the best practice of LICENSE and NOTICE in META-INF has been noted and addressed. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[discussion] Harmony podling to ask for vote for graduation
All, The PPMC of the Apache Harmony incubator podling has voted to ask for graduation from the Apache Incubator. We have enjoyed our time here with you, but feel that we don't want to overstay our welcome. We want to do our part to help make sure the ASF has more projects than the Incubator :) I believe the active mentors (myself, Stefano, Leo and Dims) will assert that the community is healthy and very active. While we do have the required level of legal diversity in our committers (diversity factor = 5), we are very motivated to continue to diversify, a feeling shared by all on the PPMC, and we see this as a very healthy thing. We have been very lucky to receive significant donations of code from several sources to help bootstrap the project, but it's clear that the community is building on and improving the code very actively, almost frenetically. As an example, our dev list - which is only development discussion - had over 1900 messages in Sept 2006. Right now, we have 1500 messages for October, and we are only halfway through the month. Our commit list, which also adds JIRA traffic, had 2851 messages in Sept 2006. Clearly the community is working together and doing development in the project. There are many examples of collaboration and sharing of ownership - a mutual feeling of stewardship over the whole project, even though most contributors tend to be specialized in one area, due to the complexity of the project. In terms of technical progress, we have a working, modern virtual machine with JIT (dynamic compilation of bytecode at runtime), a working GC and a next-gen GC in progress, and all the other required elements such as thread manager, execution manager, basic bytecode verifier, etc. On the classlibrary side, we have about 94% of the Java SE 5 library complete, an amazing feat. Together they form a JRE that we have been providing snapshots of via the website, and this JRE is capable of running significantly complex software like Tomcat, Ant, Eclipse, etc (not without bugs, of course...). We also have the basic JDK tools underway, such as javac, javah, javap, rmic, keytool, etc. While still far from done, we feel that we've come a long way in the 11 months that we have had actual code in the project. We won't have a release of this software until we are finished with Java SE 5. We may have milestone release late this quarter or in Q1 of next year, but we wish to avoid hyping the capability of what we have, and get our software stabilized and useful for general use. Users are very important to us, but we realize that there's a minimum amount of functionality and stability required before it's interesting to the casual user, and we're just reaching that point. We'd like to help make this as efficient a process as possible - please let us know if there are any issues that will prevent a successful vote by the PMC on our graduation. If there are no un-addressed issues in the next 3 days, I'd like to call a vote late on Thursday, October 19th, so we can possibly be finished in time for the next Board meeting, October 25th. Thanks, and we look forward to your comments. To avoid cross-post confusion, I will forward this message to the harmony-dev list rather than CC. geir Champion and Mentor, Apache Harmony podling - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ratify Tuscany PPMC vote to release project pom and buildtools artifacts
+1 Jeremy Boynes wrote: The Tuscany PPMC has voted to release a parent pom and buildtools jar that are dependencies for a forthcoming M2 release. These would be made available through the m2-incubating-repository to allow end users to build source distributions of that release. In accordance with Incubator release procedures we are asking the Incubator PMC to approve this release. Vote thread (with links to artifacts and aRAT results): http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL PROTECTED] Vote result: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL PROTECTED] -- Jeremy - 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: Wonka, Mika, and Apache
There certainly is interest in Apache Harmony, as this is very much aligned to what we've already been doing for the past year and a few months. geir On Sep 27, 2006, at 5:09 AM, Chris Gray wrote: Hello guys, To introduce myself: I'm one of the original developers of the Wonka embedded VM, and my company sells both support for Wonka and our own derivative which we call Mika. Recently we made Mika available under the same BSD-style licence as Wonka. My question is whether Apache would be interested in adopting Wonka/ Mika as a project, either within Harmony or as an embedded counterpart thereto. Currently ownership of the code is divided between Punch Telematix, who acquired the assets of my former employer Acunia, and my own company. Punch have no interest in the VM beyond the fact that it is an essential component of a product (the CarCube) which they inherited from Acunia. I believe they would have no objection to granting rights to the AF, beyond the sheer effort of doing so. They can probably be persuaded, but first I'd like to know if there is sufficient interest within the AF. Best regards, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html 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: [JiniProposal] Choosing a new name...
While we all appreciate you inviting the community to help, I also encourage the proposers to consider choosing a name among yourselves. There's nothing wrong with that, and as it's the project you are proposing, it's natural that you can choose the name. geir Jim Hurley wrote: Hi all- I apologize for the gap in communication on our Proposal. Following my summary post: http://mail-archives.apache.org/mod_mbox/incubator-general/200608.mbox/[EMAIL PROTECTED] and list discussion, I believe choosing a new name for the project and then updating our Proposal are the last bits before we can ask for an incubator vote. We've been fairly consumed by our Jini Community Meeting event last week in Brussels (see the Jini.org front page for links to info from the event), so again, I'm sorry for not getting this closed sooner so we can move on and (hopefully) get going. As we're all too familiar with :-o -- picking a name (that everyone likes) is hard. In order to get as many creative ideas as possible, and have a defined process (so that it doesn't drag out) for making a decision... we'd like to: * Gather Name Ideas -- through Tuesday, Sept 26 Ask both the Apache incubator and Jini Community for name ideas. In order to not consume the lists with name mail, if you could send me, [EMAIL PROTECTED] your name ideas, and optionally your reasoning/meaning behind the name. I'd really appreciate it. For example: name: Eden -- reminds me of Barbara Eden from I Dream of Genie! ;-) * Choose the New Name (voting) -- Thursday, Sept 28 through Monday, Oct 2 We'll take the list of ideas, make sure they pass TM, etc and select a top ten choices that we'll put up for an open vote. Whatever name is supported the most by the vote is the one we'll choose for the project. If these dates feel too tight we can be a little pliable, but we are hoping to update our Proposal and have the voting (start) before the upcoming ApacheCon if possible. There's obviously an endless amount of ways to go about picking a name... this might not be the best, but we wanted to engage the Apache incubator and our existing Community in contributing. We're betting that with everyone's creative juices flowing - we're going to collectively come up with a cool name that represents the project well and that most people like. I hope you'll give us your support. thanks -Jim - 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] approve the 4.0.2 release of ActiveMQ
I gave it a cursory look, and things seem to be in order. +1 Hiram Chirino wrote: In accordance with the incubator release procedure (see below) the Apache ActiveMQ community has voted on and approved the 4.0.2 release binary. We would now like to request the permission of the Incubator PMC to perform the release. Release notes: http://incubator.apache.org/activemq/activemq-402-release.html Vote thread: http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/200608.mbox/[EMAIL PROTECTED] Vote result: The VOTE has passed with 7 ppmc +1's and no -1s. +1 Hiram Chirino +1 James Strachan +1 Rob Davies +1 Guillaume Nodet +1 Alan D. Cabrera +1 Aaron Mulder +1 Brian McCallister We also had 1 non ppmc +1: +1 Kevan Miller Release tarball: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3/maven1/incubator-activemq/distributions/ Releases section of the Incubation Policy: http://incubator.apache.org/incubation/Incubation_Policy.html#Releases Here's my non binding +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
Jason van Zyl wrote: On 15 Aug 06, at 12:27 PM 15 Aug 06, Geir Magnusson Jr wrote: Jan Blok wrote: Hi, What could be the problem of any real-time communication medium usage between some community members as long as every one agrees code and design decisions are made on the mailing list? Because the reality is that decisions are made on IRC, implicitly. It's hard to engage in an argument that already happened, especially when the discussion was very conversational rather than formal : A: what do you think? B: Well, like you said before... A : about the contstructor B : no, the other thing A : related to using =? B : right that it.. it would be better if that was done as Jim suggested versus the more formal statements people make in email I'm beginning to agree that ensuring that re-serializing the Properties preserves the original delimiter (= in Jim's example) that was used in the original file. That's a sweeping generalization which in many cases is not true. Of course - it was clearly contrived. And most people don't make single coherent statements in email as well. But I find it far easier to track a thread in email. Email can be just as unclear and people going Sorry, I don't understand what you just said happens often. In IRC where you can iterate to the point of understanding and pastebin examples to get your point across works very well. I don't think the argument can be made that one form of communication has a better rate of conveyance. I would say IRC does, you would say email does. I think the argument here is one of persons/groups being excluded or not which is matter of project members' attitudes about inclusion. It would be interesting to see if such things could be measured with language analysis, to find density or continuity of content. I know that I personally have a rough time reading IRC logs, even just backscrolling though what my client captures is always far different than being there in real time. My biggest problem with IRC is that fact that not everyone can be there. I understand how people find it more efficient - I actually prefer face to face or phone... :) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
Jason van Zyl wrote: On 16 Aug 06, at 9:40 AM 16 Aug 06, Dion Gillard wrote: You mean like this: http://docs.codehaus.org/display/MAVEN/IRC+Log+Design+Discussion+26+May+2005 That particular discussion had everyone who even vaguely knew what the issue at hand was, even so you only know we talked about it because we logged it. Also, the use of our IRC has evolved over time just as people evolve their communication strategies. Geir's example below is exactly what he and I used to do *all* the time except we never posted anything to the mailing lists. We designed pretty much every last detail of Velocity over IRC and usually it was a private IRC conversation. So everyone changes to adjust to what best suits the situation. It would be interesting to go look back at the vel dev list and test that assertion. I remember a lot of private chatting throughout the day, but as that was 6 years ago, I don't remember much. I have trouble remembering last week sometimes... gier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
Jan Blok wrote: Hi, What could be the problem of any real-time communication medium usage between some community members as long as every one agrees code and design decisions are made on the mailing list? Because the reality is that decisions are made on IRC, implicitly. It's hard to engage in an argument that already happened, especially when the discussion was very conversational rather than formal : A: what do you think? B: Well, like you said before... A : about the contstructor B : no, the other thing A : related to using =? B : right that it.. it would be better if that was done as Jim suggested versus the more formal statements people make in email I'm beginning to agree that ensuring that re-serializing the Properties preserves the original delimiter (= in Jim's example) that was used in the original file. geir Regards Jan Blok Jim Jagielski wrote: I think one way of looking at this is simply remembering that the ASF values community over code. Yes, IRC and other real-time communication methods means quicker code development, etc, but it places, IMO, an undue barrier to the development of the community. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Bob Scheifler wrote: Filip at Apache wrote: jini is a trademark directory isn't The question wasn't about Jini vs others. Geir said he wouldn't support Apache EMail or Apache Web, and I'd like to understand how those two are different from Apache Directory, Apache Web Services, etc. I have no clue why we let Directory happen ;) as it did come out of the Incubator, but as for WS, that is a far older umbrella project. I'm beginning to believe that there was a moment in time in the History of Open Source where such umbrellas had positive community properties that provided a nurturing environment for new people and projects to embed. For example, Jakarta had a strong, diverse, cross-sub-project community for a long time that had a single identity unto itself, and it was incredibly prolific. It may be now that we've all collectively matured in how we do open source, so that model may no longer be as needed (if it was needed) or productive as it once was. It certainly has major downsides, such as misplaced identity and affiliation w/ the umbrella vs the ASF. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Jukka Zitting wrote: I think the question boils down to the issue of what will happen to the Jini standard now that the JDP has been closed down. It's correct to insist in that the standard shouldn't be developed within the implementation project if the goal is to allow independent implementations. Thus, there are two options: 1) It is decided (by what community?) that there is no need for independent implementations, in which case bringing in the project with both the implementation and the specifications under the name of Apache Jini would make sense. 2) Independent implementations remains a goal for the Jini standard, and a suitably independent body (be it an Apache project, a real standardization organization, or whatever) is chartered for the maintenance and development of the standard. In this case we bring in the JTSK (+ related tools) implementation as an Apache Something project that focuses on the implementation of the externally defined standard. I'm personally in favor of option 2, but at this point I think it's premature to decide what to do with the Jini standard. Thanks for summarizing well what I have been advocating. I think that we should consider the Jini standard separately - we have a community and a codebase, and should proceed with that now. Because it still is a standard we can work on that in parallel if all parties are willing. I believe therefore that we have now returned to the original question... what should the name of the new podling be called? :) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Jukka Zitting wrote: Hi, On 8/14/06, Bob Scheifler [EMAIL PROTECTED] wrote: I'm extremely reluctant to start out with two podlings. I'm not sure what governance you have in mind beyond the spec process, but I don't believe we have sufficient commitments from people to keep an equivalent of the existing Jini community standards process going forward. I think our best shot at success is a single podling, which maintains both specs and code under a single development process. +1 If it becomes more evident that a cleaner spec/impl divide is needed, then that can be handled during incubation when everyone has a better understanding of the issues. For now I think it makes more sense to bring the existing community in as it exists instead of artificially splitting it based on external requirements. We have a tradition, for good reason, for not giving our projects technology domain ownership for implementations. I'd never support Apache EMail or Apache Web. That's why if we are going to have Apache Jini, it shouldn't be implementation focused. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
Eelco Hillenius wrote: The community learns about each other in a shared, non-exclusionary method. Private Email/IM/IRC does NOT foster that. Public IRC, free for anyone to join, at a channel that is 'officially' published/ promoted however, does. No it doesn't.It's exclusionary in that email allows timezone independent participation, and IMO, reading an IRC chat after the fact is far different than being there. It's like reading a musical score - far different than being there. Like I stated earlier, I actually believe that since we started supporting the logged IRC channel - which usually has about half of the active committers and about 15 - 30 users online at any given time - that our list traffic got more focussed and thus more valuable for following/ accessing the archives. I'm not arguing email should not be the preferred method of communicating, just that IRC is a valuable additional communication channel which imho is very suitable to open development. The problem is that decisions do get made there if your not careful... geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Sanjiva Weerawarana wrote: On Mon, 2006-08-14 at 12:41 -0400, Geir Magnusson Jr wrote: We have a tradition, for good reason, for not giving our projects technology domain ownership for implementations. I'd never support Apache EMail or Apache Web. That's why if we are going to have Apache Jini, it shouldn't be implementation focused. Absolutely +1 from me! If we do create Apache Jini then it must be that we did it at the cost of Sun Jini going away. I'm an Apache bigot, so I think of it at the benefit of :D geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Bob Scheifler wrote: Geir Magnusson Jr wrote: We have a tradition, for good reason, for not giving our projects technology domain ownership for implementations. I'd never support Apache EMail or Apache Web. Is it written somewhere that ASF project names must mean ownership of rather than merely category of? I could go add that to the website if that would help. We're not a legalistic community where exploiting loopholes or lack of written law is encouraged... Let me try to illustrate it this way - would you be interested in bringing what you have to the ASF if there already was a project called Apache Jini? geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Noel J. Bergman wrote: Bob, What is your concern? Can you please try to be simple and specific about it? For example, what if we created [EMAIL PROTECTED] and [EMAIL PROTECTED] Forget the question of how many podlings --- I am simply talking about a list related to specification work, and a list related to implementation. Is that a starter? And if we have them both under a single podling to start, and we see how it goes, does that work for you? That doesn't work for me. I do believe that it is likely that you will eventually want two projects. Why? Because of the governance structure used at the ASF. All members of the Project Management Committee get equal votes, and veto ability on technical matters. Consensus based development and maintanence of specs in an open forum is perfectly viable. But development of specifications differs from development of code. The former requires a long term view, a mindset towards stability, and probably MORE ability to create a stable consensus than the latter. But if we start with the mailing lists separate and the source control split, which seems natural from what everyone is saying, I expect that the governmance issue will sort itself out in due course. Like a subproject? Thoughts? I'm not a fan. geir --- Noel - 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: Jini : Separate Governance and Implementation Projects
Bob Scheifler wrote: Geir Magnusson Jr wrote: I'm extremely reluctant to start out with two podlings. Why? I think we are talking about two very different community dynamics. For the reason I stated: I don't believe we have sufficient commitments from people willing and able to run a broad-based standards process. Wouldn't it be the same people in the code podling working in two podlings? If it works out that they have different governance, then we're golden. If they work out to be the same governance, then no harm done - just bring them together. The community dynamics around standards and an implementation may well be very different, but I'm not suggesting that we try to maintain standards going forward, just that we try to maintain a separation between interface and implementation. Ok - that's fine. Then we just don't start the 'standards' podling? That still won't change my opinion about the problem with calling it Apache Jini How would it work? Would you give every committer a vote on the specs as they were created? What is the hurdle needed to get committer status? Participation in both? We understand how to do code communities here at the ASF, and no experience in how to do spec creation/governance. Isn't a key purpose of incubation to work out the process? Well, no - it's to build healthy apache communities and oversee IP inflows. When the Incubator is figuring out new process - which is what happened with Geronimo, the first project that was all community and no code - things can be painful for that community. So by separating this, we can be sure we can do well building the code community, and figure out the spec community along the way, if there was interest. But by your starting sentence, you don't seem to believe that's viable anyway. Is it OK if we don't have all of the answers up front? Absolutely. Within the Sun team that created most of the specs and code that are being proposed as the starting point for the project, to my mind the development process for the two has pretty much been the same. And that's a warning sign for me, right off the line, because I have trouble seeing how the development process inside a company is going to be similar to the somewhat chaotic dev process of an Apache project. The questions about committer votes and status for specs vs code seem the same as those for component A vs component B in a multi-component project. We tend not to segregate the committers. At the risk over oversimplification, if I view a spec as Java interface plus javadoc, and an implementation as Java class plus javadoc, they are both code plus doc, amenable to the same overall process. You didn't just risk oversimplification, you committed an oversimplification felony :) I'd argue that they are completely different in that the creation of a spec requires different skills than implementing that spec. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini?
I'm going to reply to this as I found no good point in the thread. I think that instead of spinning on this lock, we should move forward with some other name to get things booted, and then resolve the Jini name issue in parallel. Clearly there's sufficient interest to see this become an Apache community - I don't think that having a working name will be a big problem as the Jini community will be fully aware of the project and it's goals. So Jim et al, if you like this, propose a working name, and lets get going... geir Sanjiva Weerawarana wrote: So whatever happened to the Jini proposal?? I just remembered that there was a lot of discussion but don't recall the conclusion. Sanjiva. - 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: Jini?
Noel J. Bergman wrote: Geir Magnusson Jr wrote: I think that instead of spinning on this lock, we should move forward with some other name to get things booted, and then resolve the Jini name issue in parallel. I don't know that the name is an issue at all, if Sun is willing to transfer the trademark to the ASF, as was done with SpamAssassin. The impression that I have from Craig and others is that this is do-able. According to Simon, this is something that a Sun contact can work on, and according to Jim Hurley, We would prefer to contribute it, but I'd like some discussion on this list on whether that's a viable option. The answer, Jim, is yes. We did the same with the SpamAssassin trademark. Because there is a difference. JINI is a technology domain. SpamAssassin is a project. Between that and Craig's observations regarding the JDO precedent, it begs the question of why we should not go forward with the JINI name, which is what Sun, itself, is offering, and which is the name with which people associate. If we eventually find that we must change the name, which it seems we would all like to avoid, we can do so later. I'd rather go forward with a neutral project name, and then work out the implications of managing a trademark that we'd have to allow others to use. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Specifications as (part of) ASF projects (was RE: Too many licenses? Was: [vote] Accept Glasgow)
What broken mail client are you using? inline... Noel J. Bergman wrote: Carl Trieloff wrote: - Is Apache in the business of writing and publishing specifications? - As long as Apache is not in the business of also creating specifications, there will be by definition some separation between code and spec processes, and I would like to work with the ASF to try improve this. Wait ... why can't a specification be a releasable, just like a codebase? The only issue, as I see it, would be enforcement of compliance. And Roy even put forward a proposed license amendment for such things. Which license amendment? The license amendment that I'm thinking of was specific to JCP TCKs and how derivative works of a TCK can't be used for compatibility - it had nothing to do w/ enforcement of compliance with a spec. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Specifications as (part of) ASF projects
Noel J. Bergman wrote: Geir Magnusson Jr wrote: Noel J. Bergman wrote: Wait ... why can't a specification be a releasable, just like a codebase? The only issue, as I see it, would be enforcement of compliance. And Roy even put forward a proposed license amendment for such things. Which license amendment? The license amendment that I'm thinking of was specific to JCP TCKs and how derivative works of a TCK can't be used for compatibility - it had nothing to do w/ enforcement of compliance with a spec. grrr mail client changed? The JSR licemse, not the TCK license. I don't remember a JSR license. I remember an addendum for an RI, and an addendum for a TCK. Not that it can't be modified, but what else would you call the clauses forbidding the use of the trademark names, references to the specification, and restricted name space unless the code passed the TCK? Dunno, but different than enforced compliance. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini?
Noel J. Bergman wrote: Geir Magnusson Jr wrote: Noel J. Bergman wrote: I don't know that the name is an issue at all, if Sun is willing to transfer the trademark to the ASF, as was done with SpamAssassin. The impression that I have from Craig and others is that this is do-able. According to Simon, this is something that a Sun contact can work on, and according to Jim Hurley, We would prefer to contribute it, but I'd like some discussion on this list on whether that's a viable option. The answer, Jim, is yes. We did the same with the SpamAssassin trademark. Because there is a difference. JINI is a technology domain. SpamAssassin is a project. If Sun is going to do the trademark assignment, there is no difference. We would have the trademark for the technology domain. And if you take into consideration the concurrent talk about specifications coming under ASF practices, that would dovetail nicely. Sorry, I think it's a big difference. We aren't ready to handle either yet, so I think that the proposed Jini project would be subject to lots of uncertainty, which isn't fair (been there, done that...) I guess we could call the project Apache Jini, but that sounds like an umbrella in the making, and I don't think we'd allow a Apache AJAX, Apcahe Web2.0, Apache Java, Apache SQL, Apache Blog, Apache OS, etc project... Between that and Craig's observations regarding the JDO precedent, it begs the question of why we should not go forward with the JINI name, which is what Sun, itself, is offering, and which is the name with which people associate. If we eventually find that we must change the name, which it seems we would all like to avoid, we can do so later. I'd rather go forward with a neutral project name, and then work out the implications of managing a trademark that we'd have to allow others to use. Given Apache JDO, which is also a technology domain, how do you justify that view? Please note: asking for justification is a debating question, not an attack. :-) You have to work far harder than that to attack me :) It's an implementation of a spec. A single spec that is part of an external spec-governing ecosystem, the JCP. Jini isn't a spec, it's it's own spec ecosystem. It's not part of the JCP, for example. So Apache Jini is like saying Apache JCP (I'm stretching to make a point...). geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini?
Geir Magnusson Jr wrote: It's an implementation of a spec. A single spec that is part of an external spec-governing ecosystem, the JCP. Jini isn't a spec, it's it's own spec ecosystem. It's not part of the JCP, for example. So Apache Jini is like saying Apache JCP (I'm stretching to make a point...). That said, I'd be all for Apache JINI as an experiment to do a spec governance project for JINI, and Apache $FOO as the thing that takes the code being suggested in the proposal. I just wouldn't cross the beams at this point. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jini : Separate Governance and Implementation Projects
As the champion for JINI, I suppose it behooves me to try and get this untangled. I'm not a Jini expert, but my understanding is that it is it's own spec ecosystem. Therefore, I'm against having one project doing software implementation that is called Jini, just as I'd be against projects like Apache JCP, Apache W3C, Apache OASIS, Apache ECMA etc. However, we do have a chance here to host the governance and spec process for JINI. Therefore, I'd like to propose that we create two podlings, one for JINI governance, and one for building the implementation and community around the working code that has been proposed. Comments? geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Craig L Russell wrote: On Aug 13, 2006, at 7:05 PM, Geir Magnusson Jr wrote: As the champion for JINI, I suppose it behooves me to try and get this untangled. I'm not a Jini expert, but my understanding is that it is it's own spec ecosystem. Therefore, I'm against having one project doing software implementation that is called Jini, just as I'd be against projects like Apache JCP, Apache W3C, Apache OASIS, Apache ECMA etc. As I understand it, Jini is not equivalent to JCP or any of the other orgs you name here. It's an org with a tighter focus. That said, it appears that it is the intent of the Jini community to have multiple implementations of the spec. [1] Yes - it's not a perfect analogy. However, we do have a chance here to host the governance and spec process for JINI. And I'd say that this purpose is very much in line with what we did with JDO. The project has both the spec and tck but not an implementation. IIRC, Sun is the spec lead. Apache isn't. Therefore, I'd like to propose that we create two podlings, one for JINI governance, and one for building the implementation and community around the working code that has been proposed. And if the spec podling focused on the spec and compliance test aspects (the org.jini stuff), and the impl podling focused on the implementation aspects (the com.sun.jini stuff), I think it would be a lot cleaner. Exactly. It would appear then that the Apache Jini podling would be the former, and the to be named podling the latter. Fortunately, the incubator should be warmed up for a naming discussion. chortle I'd suggest we let the proposers give the name a shot first... geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Blaze
James Strachan wrote: I guess its a murky area legally - making similar APIs using documentation as a guide. e.g. its quite striking how many extremely similar APIs are in .Net and Mono to the JDK. FWIW there's a current practice to get around Sun's bizarre licensing on various Java/J2EE APIs - folks type in their own version of the source code using the javadoc as a guide. e.g. try the geronimo-spec-*.jar as an Apache licensed version of the crappily-licensed-Sun J2EE jars. I guess thats legal right? So maybe just using documentation to create similar APIs on other platforms is OK? That's not why people do it - they do it because until recently, Sun's binaries for for the API classes/interfaces were available only under unacceptable restrictive terms. geir On 7/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think there may be some legal issues with creating an API that resembles JMS too closely. From the JMS licence terms: Subject to the terms and conditions of this license, Sun hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense) under Sun's intellectual property rights to review the Specification internally solely for the purpose of designing and developing your Java applets and applications intended to run on the Java platform. Other than this limited license, you acquire no right, title or interest in or to the Specification or any other Sun intellectual property. The Specification contains the proprietary information of Sun and may only be used in accordance with the license terms set forth herein. The key bit here is intended to run on the Java platform. That said there is definitely merit in having our .NET API and C++ API being relatively similar. XMS for C# does resemble JMS very closely although with delegates and with the naming convention for interfaces. I am not sure whether IBM would be interested in donating XMS. RG |-+ | | James Strachan | | | [EMAIL PROTECTED]| | | mail.com| | || | | 19/07/2006 20:50 | | | Please respond to| | | general | |-+ --| | | | To: general@incubator.apache.org | | cc: | | Subject: Re: [Proposal] Blaze | --| On 7/19/06, Paul Fremantle [EMAIL PROTECTED] wrote: Currently ActiveMQ has several C/C++ clients (with another client library waiting to get through the donator's lawyers), so it might make sense at some point to try unify the C++ clients together too so users have a single C++ API for their messaging client and then a number of implentations/transports/protocols to use at deployment time. i.e. making a JMS for C++ API. (We've got a good start called CMS in ActiveMQ...) I agree that a C++ (and also C) rendering of a JMS like API is going to be a very useful thing. James - do you have any idea how CMS matches or differs from IBM's XMS ( http://www-128.ibm.com/developerworks/websphere/library/techarticles/0509_phillips/0509_phillips.html )? XMS is also a rendering of JMS into C/C#/C++. Thanks for the link! I've had a quick look and it looks remarkably close to the current CMS client. Hardly surprising I guess since they are both kinda clones of the JMS API but in C++ and using JMS 1.1 and mostly ignoring the crappy bits of JMS 1.0.2b :) I couldn't see the C# client so not sure if we differ a bit there - we ended up changing the C# client a little from JMS to make use of C# coding conventions and features (like delegates and events etc) - and we followed that sucky C# practice of naming interfaces IConnection etc :). Not sure if the XMS in C# does the same. (We imaginatively called the C# client NMS for .Net Messaging System). I wonder if IBM and the XMS folks would be interested in donating the *API* code for XMS to Apache and working with other folks at Apache so we can merge some of the C/C++/C# clients together into a single reuable client API with pluggable providers (and maybe even some resuable optional implementation
Re: [VOTE] Accept Heraldry into the Incubator
+1 (And I'll note now that I'm interested in participating, although can't commit the time to be a mentor right now.) Ted Leung wrote: It seems like the discussion on Heraldry has died down, so I'd like to call for a VOTE on accepting Heraldry into the incubator. In keeping with Apache practice, I'd like to allow 72 hours or so for the vote to close, so please vote by 11:59PST on Thursday July 13th. The current proposal is here: http://wiki.apache.org/incubator/HeraldryIdentityProposal, and I've included the full text below. My vote is +1 Ted -- = Proposal = This is a proposal to create a project within the Apache Software Foundation to develop technologies around the emerging user-centric identity space. The project would utilize Yadis [1] for URL/XRI-based service discovery and OpenID [2] for web based single-sign-on and the basis of exchanging profile data. Yadis is currently being standardized within OASIS as part of the XRI effort, within a TC committed to creating royalty-free work, and OpenID has emerged as a de-facto specification. The two initial components of the project, downloadable perspective, would be an Identity Provider application and libraries in various languages that implement Yadis and OpenID. The initial goal would be to both provide an out-of-the-box application as well as the required libraries for other developers to integrate Yadis and OpenID into their existing applications. To provide some background, the Higgins Project is being actively developed within Eclipse and is a framework that will enable users and enterprises to integrate identity, profile, and relationship information across multiple systems. Using context providers, existing and new systems such as directories, collaboration spaces, and communications technologies (e.g. Microsoft/IBM WS-*, LDAP, email, IM, etc.) can be plugged into the Higgins framework. Applications written to the Higgins API can virtually integrate the identity, profile, and relationship information across these heterogeneous systems. They current have integration with Microsoft's CardSpace and we'll be working with them over the next few months to add support for OpenID. It hasn't yet been determined, nor does it need to be right now, if the code to tie OpenID into Higgins will live within Apache or Eclipse. = Rationale = While identity systems such as X.509 have existed for many years, and more recently SAML and the Liberty Alliance framework, only within the past two years has there been a true emergence of user-centric technologies. Pursuant to Kim Camerons laws of identity, technologies such as LID, Yadis, OpenID, and Sxip were defined to put control of a persons digital identity back into their own hands. Both Yadis and OpenID have reached a point where they have millions of users and a strong community backing. On May 28th 2006, Brion Vibber of WikiMedia announced in a Google Tech Talk that WikiPedia would support both of them within the following month. This sort of broad adoption and traction has not been seen with other technologies of this kind in this space. By bringing these technologies to one place, these communities will have a place to fully converge and continue the development of interoperable implementations. Additionally, by working with the Higgins Project, ASF will be able to provide a foundation where a person can use one or more digital identities consistently across blogs, eCommerce sites, and portals as well as even high-risk transactions via their desktop computer. Currently Apache does not offer any project such as the one being proposed. Integration with projects such as Lenya would definitely be encouraged. = Initial Goals = * Expansion of Yadis and OpenID libraries into additional languages beyond the existing Python, Ruby, Perl, and PHP libraries * OpenID authentication specification revision to fix known security considerations, investigate compatibility with the DIX IETF proposal, describe Yadis integration, and allow either an URL or XRI be used as the End Users Identifier * Continue the development of a data transfer protocol on top of OpenID to allow the exchange of profile data as well as other secure messages * Investigate existing mechanisms for profile exchange, namely Sxip 2.0 and SAML, and investigate how they would be layered atop OpenID * Integration of the OpenID Authentication protocol with the Higgins framework to provide desktop integration * Extension of OpenID to support non-browser based authentication use cases. ie authentication to a Subversion server, creation of mod_authnz_openid, using your OpenID Identity without modifying the svn client-side tool = Known Risks = == Commercial Interest == * Many companies are currently working to build businesses supported on top of these technologies. As part of the code contributions,
Re: [EMAIL PROTECTED]
David N. Welton wrote: robert burrell donkin wrote: ... an idea and community ... i was wondering whether we might widen the general incubator list to include ideas for new projects provided that they are prefixed by [idea] in the subject so that anyone who's not interested can ignore. It would be difficult to bring an idea accompanied by a community. The community bit usually happens when there is working code and people pick it up and start using it. Not always. Geronimo started without code, and so did Harmony. Granted, we started with clear specs and had some ideas about code reuse, but still... As another counter-example, Jakarta Commons was an idea several of us had, which was more important than the seed code, because we were rallying around the idea, not the specific seeds. So I do believe that we should [continue to] be open to motivated people with just an idea... And as to Robert's post, I don't see why people just can't throw them out here. Having too much [EMAIL PROTECTED] traffic because of new ideas people are discussing would be an excellent problem to have. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extensible Ajax Platform (XAP) Project Update
This thread may be dead/resolved, in which case just ignore me. Cliff Schmidt wrote: On 6/23/06, Noel J. Bergman [EMAIL PROTECTED] wrote: The use of e-mail as the primary means for communication is part of ASF policy and philosophy, and we can certainly learn lessons from projects that have gone against it. IRC tends to breed a more closed, albeit arguably more integrated, community. That said, if IRC can be used as a learning tool to rapidly bring new people up to speed, and if the information gathered from those sessions is preserved for others to follow up via web-site and e-mail, how do people perceive that? I've never done that on a project, but I think it could be a reasonable thing for a project to try. I believe the Synapse folks have been doing regular IRC meetings from early on. I'd be interested in their perspective on the pros and cons, particularly as an incubating project. Someone did point out that dev traffic is falling off while commit traffic is same or increasing. As a XAP mentor, I know that the committers already understand that no decisions will be made over IRC, that logs of each IRC will be immediately made available to the entire community, and that they need to be sensitive to any concerns from people wishing but unable to participate. But, are there other thoughts from the Synapse folks or anyone else who has used regular IRC meetings? I think that people can have that understanding, but I think that it doesn't matter - it's been my experience that while people are able to quote the letter of the law as well as the explain the reason behind it, people unintentionally make informal decisions on IRC and execute on them, all with the best of intentions. I know i've seen it with Geronimo, and it can be very disruptive, even though it may be accidental. I think lots of decisions made on dev lists are the same - informal - without the trappings of a vote or such, because many decisions are made by lazy consensus - people discuss things or search for help, and then continue down whatever modified path the group explicitly or implicitly agreed to. In the case of XAP, I'm guessing that many of the committers are employees or contractors/consultants of Nexaweb. Were I a mentor, I'd want to be sure that pre-existing development process is being sufficiently broken up to make it an Apache community development project, and would worry that regular IRC meetings might be confused with periodic development meetings... geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Jini Project
It's my impression that the trademark would be donated to the ASF to avoid this problem. I'm not sure though. geir Leo Simons wrote: On Thu, Jun 22, 2006 at 03:43:13PM -0400, Bob Scheifler wrote: Leo Simons wrote: I guess this means keeping jini.org around for a long time to come, and I think this means you need a name for [EMAIL PROTECTED] which is not jini :) Could you expand on why you think that? Thanks. IANAL and not an expert but I can try. More concretely, jini is a name/brand/trademark which seens to be governed by eg http://www.sunsource.net/TUPPCP.html http://www.sun.com/suntrademarks/ And is owned by sun for which there are rather strict guidelines: http://www.sun.com/policies/trademarks/ Similarly, terms like apache, jakarta, tomcat are also marks (even if not registered) which are somehow owned by the ASF (and we have a PRC committee to protect them). When SpamAssassin entered incubation the trademark (which was registered) ownership was transferred to the ASF, so the name was kept for the new project. If the jini name is not owned by the ASF (not just legally, also morally), we shouldn't name our software directly after it, for a variety of reasons, like * its less confusing for users * it avoids potential legal worries * it avoids a whole lot of discussion, hurt feelings, etc. * if a project ever outgrows its original boundaries a bit (happens quite often, for example lucene had a C port while it was still at jakarta) its not a problem This is why there is no java.apache.org but instead there is jakarta.apache.org, there is no j2se.apache.org but there is harmony, there is no j2ee.apache.org but there is geronimo, etc. There was, in fact, at some point, a java.apache.org, and IIUC the ASF got a lot of flak about that from sun legal (and rightly so). While its quite possible to change names halfway through incubation, in general IMHO its just easier to bite the bullet up front because various resources (jira projects, svn repositories, mailing lists, etc) are coupled to the name. To answer another question, yes, I believe this also means that there should be no jini in the name. There's a variety of creative ways most open source projects deal with that, like putting lots of extra letters in and around a word, naming by association (so you end up with Apache Aladdin since that's about genies too), or naming through acronyms (so you end up with Apache JiKit for JIni Kit). I hope the above is clear. I'm really no expert. If there's need for further details, I would suggest talking to a trademark/branding lawyer or two. But usually its just a lot easier to pick a new name, so that's what we tend to do :) LSD - 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: [PROPOSAL] CeltiXfire Project
Hani is a good guy. He really understands technology, he's honest, he's open and he has a utterly wicked and warped sense of humor. I count him as a friend of mine, and I certainly have no problem with him becoming a committer for CeltixFire. BileBlog is satire with almost always a grain of truth. He just pushes the point far beyond sanity, and that's what makes it such a fun read. I see no downside, and the upside is that he started to understand what we're really about. Sincerely Geir Asshat Magnusson Sanjiva Weerawarana wrote: On Wed, 2006-06-21 at 09:46 -0400, Dan Diephouse wrote: Please, Hani has been a great contributor to the XFire project: http://fisheye.codehaus.org/changelog/~author=hani/xfire/ Not only has he contributed code, he has written documentation and helped users out on the mailing list/irc. While you may not like what he says on his blog, anyone that has worked with him on a project will vouch for his extensive expertise and ability to work in a team. Its not just whether I don't like what he says on his blog (I personally find it amusing .. and don't care to go beyond that), but its about whether he really believes what he says and thinks the ASF is nothing but a pile of poo (to paraphrase his style of writing). Why in the world doesn't he want to be part of that? If you want a project to succeed in the ASF you have to be willing to give up control, be willing to live with diversity (yes even if it has poor spelling), and overall be tolerant of other people's interests and needs. Hani doesn't appear to be able to do any of that to me. I also encourage people to watch Hani's TSS interview. Quite enlightening of what he thinks of lots of things. http://www.theserverside.com/tt/talks/videos/HaniSuleiman/interview.tss?bandwidth=real - Anyway, he's one guy. I won't pursue this thread further; this proposal has much more interesting stuff to talk about independent of one Mr. Suleiman. Sanjiva. - 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: [Proposal] Jini Project
Leo Simons wrote: On Mon, Jun 19, 2006 at 10:15:38AM -0400, Jim Hurley wrote: Let the records show that Geir is listed as initial committer too yet probably doesn't work at sun, unless he switched companies again :) Hey, it's been 6 months already, but no, I'm still at Intel. :) * Mentor - Geir Magnusson Jr. Lately popular opinion seems to be that it'd be good if there were at least three mentors. Any others? The snippet you quoted is bait :) We figured that we'd have people volunteering once this was proposed and people saw that there was only me. So please, volunteers for mentor wanted and very welcome! At least 3 more! geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Heraldry Identity Project
With the additional request that when discussion is over and it comes for a vote, a copy of what is being voted in be submitted in the email calling for the vote. gier Paul Querna wrote: General Comments: Is it possible to put this proposal onto the wiki ( http://wiki.apache.org/incubator/ ) for a stable url when there are updates/changes? Recordon, David wrote: snip Initial Committers -- David Recordon ([EMAIL PROTECTED]) Andy Dale ([EMAIL PROTECTED]) Brad Fitzpatrick ([EMAIL PROTECTED]) Brian Ellin ([EMAIL PROTECTED]) Dan Lyke ([EMAIL PROTECTED]) Dan Quelhorst ([EMAIL PROTECTED]) Drummond Reed ([EMAIL PROTECTED]) Johannes Ernst ([EMAIL PROTECTED]) Jonathan Daugherty ([EMAIL PROTECTED]) Josh Hoyt ([EMAIL PROTECTED]) Les Chasen ([EMAIL PROTECTED]) Matt Pelletier ([EMAIL PROTECTED]) Michael Graves ([EMAIL PROTECTED]) Paul Trevithick ([EMAIL PROTECTED]) Steve Churchill ([EMAIL PROTECTED]) Trotter Cashion ([EMAIL PROTECTED]) Wil Tan ([EMAIL PROTECTED]) My biggest concern right now is that there seems to be a 1 to 1 mapping of so many of the initial committers to the individual code bases that want to be donated. It worries me about fragmentation of the project, especially since there are at least 4 or 5 different programing languages already involved. -Paul - 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] Incubator PMC to approve ActiveMQ 4.0 Release (new binary)
+1 from me as well. Sorry. geir James Strachan wrote: Passed with +1s from jstrachan, jim, jvanzyl, brianm and no -1s. Many thanks to all those who responded to the plethora of emails to get the release distro into good shape :) On 6/5/06, James Strachan [EMAIL PROTECTED] wrote: We ended up recutting the binary of the 4.0 release of ActiveMQ to address a few issues brought up in the Incubator PMC vote; I'd just like to call another vote to explicitly approve the new binary distro to avoid confusion (as most Incubator PMC folks voted on the previous binary). Can I ask the Incubator PMC to please approve the new binary for the ActiveMQ 4.0 release. Release notes: http://incubator.apache.org/activemq/activemq-40-release.html Vote threads: http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/200605.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/200605.mbox/[EMAIL PROTECTED] Vote result: The latest vote was 7 +1s and no -1s. +1 Hiram Chirino +1 Guillaume Nodet +1 Bruce Snyder +1 Adrian Co +1 Jonas Lim +1 James Strachan +1 Fritz Oconer Release tarball: http://people.apache.org/~chirino/incubator-activemq-4.0/maven1/incubator-activemq/distributions/ Here's my +1 -- James --- http://radio.weblogs.com/0112098/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please change Open JPA to OpenJPA
I don't understand the problem. The project is OpenJPA. The wiki is
OpenJPA. The project proposal, which everyone agreed to, had
open-jpa-dev in it, so it was created that way. Do you all think that
it's a killer problem to have that hypen in the list name when
everything else is OpenJPA?
geir
Craig L Russell wrote:
+1 from me. I'd also like to see the wiki and jira set up if we've
agreed on the name.
Craig
On May 8, 2006, at 10:48 AM, Davanum Srinivas wrote:
+1 from me.
On 5/8/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
Did we decide to do this? I am willing to help make the change if I
can.
-dain
On May 5, 2006, at 5:46 AM, Bill Stoddard wrote:
Torsten Curdt wrote:
It's ok, we can deal :) I've chatted with Patrick about it the past
as obviously I like OpenFOO as in Open{SSL,SSH,LDAP,EJB,JMS,ORB}
etc. His perspective was whatever the community wants is good with
him. I think that's a pretty reasonable stance so in that same
spirit, if Apache Open JPA is the cool new way to do acronyms,
that's
fine with me.
Ihatewhitespacesinnames+1forOpenJPAcheers--Torsten;-)
+1
Bill
-
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]
--
Davanum Srinivas : http://wso2.com/blogs/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please change Open JPA to OpenJPA
Oh - it's in SVN too... since there's nothing there except the README I
put there to test, I'll move that now.
geir
Dain Sundstrom wrote:
Just to be clear, the only the only items with hyphenated names
remaining are the svn location and the mailing lists. Both of these
will have to be changed when the project graduates anyway, so they can
be fixed later. Right?
IMO I think that it is better to make the change before the project gets
going, but if everyone wants to wait, I can too.
-dain
On May 8, 2006, at 1:51 PM, Craig L Russell wrote:
The names with hypens will be changed once the project graduates from
the incubator, so I don't see it as an issue.
Craig
On May 8, 2006, at 1:33 PM, Geir Magnusson Jr wrote:
I don't understand the problem. The project is OpenJPA. The wiki
is OpenJPA. The project proposal, which everyone agreed to, had
open-jpa-dev in it, so it was created that way. Do you all think
that it's a killer problem to have that hypen in the list name when
everything else is OpenJPA?
geir
Craig L Russell wrote:
+1 from me. I'd also like to see the wiki and jira set up if we've
agreed on the name.
Craig
On May 8, 2006, at 10:48 AM, Davanum Srinivas wrote:
+1 from me.
On 5/8/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
Did we decide to do this? I am willing to help make the change if I
can.
-dain
On May 5, 2006, at 5:46 AM, Bill Stoddard wrote:
Torsten Curdt wrote:
It's ok, we can deal :) I've chatted with Patrick about it
the past
as obviously I like OpenFOO as in Open{SSL,SSH,LDAP,EJB,JMS,ORB}
etc. His perspective was whatever the community wants is good
with
him. I think that's a pretty reasonable stance so in that same
spirit, if Apache Open JPA is the cool new way to do acronyms,
that's
fine with me.
Ihatewhitespacesinnames+1forOpenJPAcheers--Torsten;-)
+1
Bill
-
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]
--Davanum Srinivas : http://wso2.com/blogs/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
-
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: Please change Open JPA to OpenJPA
done
Everyone will have to re-check out at
https://svn.apache.org/repos/asf/incubator/openjpa
geir
Geir Magnusson Jr wrote:
Oh - it's in SVN too... since there's nothing there except the README I
put there to test, I'll move that now.
geir
Dain Sundstrom wrote:
Just to be clear, the only the only items with hyphenated names
remaining are the svn location and the mailing lists. Both of these
will have to be changed when the project graduates anyway, so they can
be fixed later. Right?
IMO I think that it is better to make the change before the project
gets going, but if everyone wants to wait, I can too.
-dain
On May 8, 2006, at 1:51 PM, Craig L Russell wrote:
The names with hypens will be changed once the project graduates from
the incubator, so I don't see it as an issue.
Craig
On May 8, 2006, at 1:33 PM, Geir Magnusson Jr wrote:
I don't understand the problem. The project is OpenJPA. The wiki
is OpenJPA. The project proposal, which everyone agreed to, had
open-jpa-dev in it, so it was created that way. Do you all think
that it's a killer problem to have that hypen in the list name when
everything else is OpenJPA?
geir
Craig L Russell wrote:
+1 from me. I'd also like to see the wiki and jira set up if we've
agreed on the name.
Craig
On May 8, 2006, at 10:48 AM, Davanum Srinivas wrote:
+1 from me.
On 5/8/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
Did we decide to do this? I am willing to help make the change if I
can.
-dain
On May 5, 2006, at 5:46 AM, Bill Stoddard wrote:
Torsten Curdt wrote:
It's ok, we can deal :) I've chatted with Patrick about it
the past
as obviously I like OpenFOO as in Open{SSL,SSH,LDAP,EJB,JMS,ORB}
etc. His perspective was whatever the community wants is
good with
him. I think that's a pretty reasonable stance so in that same
spirit, if Apache Open JPA is the cool new way to do acronyms,
that's
fine with me.
Ihatewhitespacesinnames+1forOpenJPAcheers--Torsten;-)
+1
Bill
-
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]
--Davanum Srinivas : http://wso2.com/blogs/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status Report for Harmony
Leo Simons wrote: (please drop harmony-dev from the CC list on replies. Thanks!) Hi Noel, Sorry for the lack of report for harmony so far (BTW, we should probably get Marvin to send out automated reminders to relevant (P)PMCs too, it should save you some nagging effort). The wiki is currently down, so I can't see what's up there right now or whether someone else already wrote something so I'm resorting to sending an e-mail; hope that's ok. Leo, we've had a report in for Harmony for every time it was due. Not sure what you're saying here. If you mean for this month, the board meeting is next week, right? I put the note below in the wiki... cheers, Leo - Harmony status report - Harmony is going well, so well that it is not easy to sum up all the things happening. There is, however, currently nothing requiring board or incubator PMC attention. Highlights for the last quarter: * no releases. * We have welcomed one new PPMC member: * Tim Ellison * we have welcomed three new committers: * Mikhail Loenko * George Harley * Stepan Mishura and expect to add quite a few more in the next quarter. * we have received and processed several more bulk contributions from different parties, including for beans, regex, math, jndi, logging, prefs, sql, math(again), crypto, and rmi (twice), hundreds upon hundreds of unit tests, an eclipse plugin for doing harmony development, and more. Our framework for accepting these contributions (based on jira, svn, and faxes and documented on the harmony website) seems to be working well. * there was concern over a potential copyright infringement within our JCHEVM component. This concern has been addressed by receiving a code donation for the potentially infringing files, without having to resort to lawyers and to the mutual satisfaction of all parties and under the watchful eye of the Incubator PMC. * we have begun collaborating with the SableVM community, which has relicensed its VM under the ALv2 (the related previous potential licensing/copyright issues have been resolved without having to resort to lawyers and to the mutual satisfaction of all parties and under the watchful eye of the Incubator PMC). * we have seen a lot of discussion on how to do testing, how to use jira, etc etc, as more and more developers gear up to contribute to the project. These kinds of discussions are going well and the collaborative consensus-based process is emerging. * we have identified the (future) need for some serious build and testing server infrastructure but have not approached the infrastructure team about this yet. IBM is currently hosting a Maven Continuum server to run the harmony tests, and sending the results to our mailing lists. - On Sun, Apr 16, 2006 at 06:47:52PM -0400, Noel J. Bergman wrote: See: http://wiki.apache.org/incubator/April2006 *STILL* waiting to hear from ADF Faces, Agila, AltRMI, Felix, Harmony, Kabuki, and WebWork 2. - 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: Can't commit
Try now. BTW, is there really only one committer (you) in this podling? There is only one person listed in the svn group 'lucene-dot-net' geir George Aroush wrote: Hi folks, I am trying to update the file lucene.net.xml (which is here: https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/projects /lucene.net.xml) but can't. I am getting the error message: 403 Forbidden (https://svn.apache.org) Am I doing something wrong or do I not have the right permissions set to do so? Regards, -- George - 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: Can't commit
George Aroush wrote: Hi Geir, It works now. Thanks! Yes, right now I am the only committer (and the project lead.) I'm trying to finish off this last infestructer and once I do, I will be adding other committers. My next question now is, to push his change to the website, I am suppose to run build.sh (or build.bat. Do you know from where do I run it? If my question is not clear, let me ask this. How do I get what I just committed to appear here: http://incubator.apache.org/projects/lucene.net.html ? run build.sh on your own machine, locally. Check the results with your web browser on what was created on the local file system. svn commit (and verify only the files you believe should be changed were in fact changed) ssh to minotaur.apache.org cd /www/incubator.apache.org/ svn update That should do it, assuming I got it right (I just typed from memory...) geir Regards, -- George -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 11, 2006 11:02 AM To: general@incubator.apache.org Subject: Re: Can't commit Try now. BTW, is there really only one committer (you) in this podling? There is only one person listed in the svn group 'lucene-dot-net' geir George Aroush wrote: Hi folks, I am trying to update the file lucene.net.xml (which is here: https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/pr ojects /lucene.net.xml) but can't. I am getting the error message: 403 Forbidden (https://svn.apache.org) Am I doing something wrong or do I not have the right permissions set to do so? Regards, -- George - 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] - 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: Can't commit
you should be able to do that as well... George Aroush wrote: Thanks Geir! I did per your instruction and I now have it updated. One more question. How do I get the following page fixed as well: http://incubator.apache.org/lucene.net/ ? Regards, -- George -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 11, 2006 1:47 PM To: general@incubator.apache.org Subject: Re: Can't commit George Aroush wrote: Hi Geir, It works now. Thanks! Yes, right now I am the only committer (and the project lead.) I'm trying to finish off this last infestructer and once I do, I will be adding other committers. My next question now is, to push his change to the website, I am suppose to run build.sh (or build.bat. Do you know from where do I run it? If my question is not clear, let me ask this. How do I get what I just committed to appear here: http://incubator.apache.org/projects/lucene.net.html ? run build.sh on your own machine, locally. Check the results with your web browser on what was created on the local file system. svn commit (and verify only the files you believe should be changed were in fact changed) ssh to minotaur.apache.org cd /www/incubator.apache.org/ svn update That should do it, assuming I got it right (I just typed from memory...) geir Regards, -- George -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 11, 2006 11:02 AM To: general@incubator.apache.org Subject: Re: Can't commit Try now. BTW, is there really only one committer (you) in this podling? There is only one person listed in the svn group 'lucene-dot-net' geir George Aroush wrote: Hi folks, I am trying to update the file lucene.net.xml (which is here: https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/p r ojects /lucene.net.xml) but can't. I am getting the error message: 403 Forbidden (https://svn.apache.org) Am I doing something wrong or do I not have the right permissions set to do so? Regards, -- George - 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] - 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] - 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] Incubator PMC to approve the 4.0-RC1 release of ActiveMQ
How does one distinguish this, the 2nd candidate, from the 1st candidate of the 4.0-RC1 release? Doesn't the RC in RC1 mean Release Candidate ? Also, when you start it up, it says INFO BrokerService - For help or more information please see: http://www.logicblaze.com Finally, when I simply unpack and run bin/activemq I get the following stacktrace on startup. That wouldn't be a blocker for release, but I thought you might want to know ERROR BrokerService - Failed to start ActiveMQ JMS Message Broker. Reason: java.io.EOFException java.io.EOFException at java.io.DataInputStream.readFully(DataInputStream.java:268) at java.io.DataInputStream.readUTF(DataInputStream.java:639) at java.io.DataInputStream.readUTF(DataInputStream.java:610) at org.apache.activemq.openwire.v1.BaseDataStreamMarshaller.looseUnmarshalString(BaseDataStreamMarshaller.java: 35) at org.apache.activemq.openwire.v1.JournalTraceMarshaller.looseUnmarshal(JournalTraceMarshaller.java:112) at org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:348) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:210) at org.apache.activemq.store.journal.JournalPersistenceAdapter.recover(JournalPersistenceAdapter.java:452) at org.apache.activemq.store.journal.JournalPersistenceAdapter.start(JournalPersistenceAdapter.java:209) at org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:902) at org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:863) at org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:443) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:351) at org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:43) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutow reCapableBeanFactory.java:1058) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapa leBeanFactory.java:363) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListabl BeanFactory.java:275) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:318) at org.apache.xbean.spring.context.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:15 ) at org.apache.xbean.spring.context.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:48 at org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:40) at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:56) at org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:81) at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:46) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:49) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:81) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:49) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:45) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.activemq.console.Main.runTaskClass(Main.java:135) at org.apache.activemq.console.Main.main(Main.java:67) ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.BeanCreation xception: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService' defined in class path resource [ ctivemq.xml]: Initialization of bean failed; nested exception is java.io.EOFException: null ERROR: java.lang.Exception: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org apache.activemq.xbean.XBeanBrokerService' defined in class path resource [activemq.xml]: Initialization of bean failed; nested exception is java.io.EOFException: null James Strachan wrote: In accordance with the incubator release procedure (see below) the ActiveMQ community has voted on and approved a proposal to release the 2nd candidate of the 4.0-RC1 release. We
Re: [VOTE] Incubator PMC to approve the 4.0-RC1 release of ActiveMQ
James Strachan wrote: On 3/30/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: C:\Documents and Settings\gmagnussjava -version java version 1.4.2_10 Its nothing to do with running from a directory with spaces in it is it? I'm not - that was just showing my cmd line. I'm running activeMQ from a dir w/o spaces. geir -- James --- http://radio.weblogs.com/0112098/ - 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] Incubator PMC to approve the 4.0-RC1 release of ActiveMQ
Hiram Chirino wrote: Hi Geir, It looks like ActiveMQ RC1 is failing to load the data files from a previous version of ActiveMQ. This is expected since we will not support backward compatibility until the final released 4.0. The question is where is it picking up old data files from? You make want to delete the contents of you activemq-data directory. Ah - I have activemq 4.0 - M4 there. So 4.0 RC1 is incompatible w/ 4.0 M4? I deleted activemq-data and it works now. geir On 3/30/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: How does one distinguish this, the 2nd candidate, from the 1st candidate of the 4.0-RC1 release? Doesn't the RC in RC1 mean Release Candidate ? Also, when you start it up, it says INFO BrokerService - For help or more information please see: http://www.logicblaze.com Finally, when I simply unpack and run bin/activemq I get the following stacktrace on startup. That wouldn't be a blocker for release, but I thought you might want to know ERROR BrokerService - Failed to start ActiveMQ JMS Message Broker. Reason: java.io.EOFException java.io.EOFException at java.io.DataInputStream.readFully(DataInputStream.java:268) at java.io.DataInputStream.readUTF(DataInputStream.java:639) at java.io.DataInputStream.readUTF(DataInputStream.java:610) at org.apache.activemq.openwire.v1.BaseDataStreamMarshaller.looseUnmarshalString(BaseDataStreamMarshaller.java: 35) at org.apache.activemq.openwire.v1.JournalTraceMarshaller.looseUnmarshal(JournalTraceMarshaller.java:112) at org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:348) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:210) at org.apache.activemq.store.journal.JournalPersistenceAdapter.recover(JournalPersistenceAdapter.java:452) at org.apache.activemq.store.journal.JournalPersistenceAdapter.start(JournalPersistenceAdapter.java:209) at org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:902) at org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:863) at org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:443) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:351) at org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:43) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutow reCapableBeanFactory.java:1058) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapa leBeanFactory.java:363) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListabl BeanFactory.java:275) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:318) at org.apache.xbean.spring.context.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:15 ) at org.apache.xbean.spring.context.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:48 at org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:40) at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:56) at org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:81) at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:46) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:49) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:81) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:49) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:45) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.activemq.console.Main.runTaskClass(Main.java:135) at org.apache.activemq.console.Main.main(Main.java:67) ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.BeanCreation xception: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService' defined in class path resource [ ctivemq.xml]: Initialization of bean failed; nested
Re: [POLICY] incubator directory for IP drops
What we do in Harmony (where we're very concerned about such things) is reference the JIRA entry - since we require any such contribution to come through JIRA - and bring each into SVN once accepted so it's always available in original form for inspection in the future. geir robert burrell donkin wrote: the consensus on the previous thread was that it would be a good idea to have a single directory where the tarballed code referred to in the grants could be drop during IP clearance. this gives a canonical version of the donation in a central location for later reference (if that's ever needed). this would only be done after the software grant has been acknowledge by jim but before the final IP clearance. no one jumped in with a suggestion so unless anyone can come up with a better location, i'm going to specify http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/drops in the updated IP clearence documentation (which should arrive sometime today). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubation Process and PPMCs
Garrett Rooney wrote: On 3/20/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Geir Magnusson Jr wrote: Rodent of Unusual Size wrote: Here are the SVN names for everyone who has committed to each of the trees: (Question : are those people who committed here at the ASF, or does it include people who committed into the codebase before it was brought here?) Beats me. Those are the sames that svn log says have been on commit messages. Until very recently (i.e. the xbean import) we didn't do anything about the usernames on the imported data, so there are probably some imports that have either the wrong usernames or potentially usernames that don't actually exist at the ASF. My question was slightly different, related to commits before the import date vs the commits after the import date for the same id. geir -garrett - 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: Incubation Process and PPMCs
Oh! I thought that the sysadmin loads preserved history... Garrett Rooney wrote: On 3/20/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Garrett Rooney wrote: On 3/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: My question was slightly different, related to commits before the import date vs the commits after the import date for the same id. Yeah, there's no easy way to determine that programatically at this point. Why not? Each commit has a timestamp associated with it. Examine/count only those in the right date range. Well, it's harder than that because the commits are not completely ordered, you'd have to know the date ranges and what subset of the tree they apply to. But what I actually meant was that you'd have to manually track down the dates at which each import occurred, because that can't easily be deduced from the revision history, since imports happen via svnadmin load, which just looks like a series of commits. -garrett - 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] Accept OpenJPA as an Incubator Podling
+1 from me (of course) Geir Magnusson Jr wrote: What follows is the official proposal for OpenJPA. The unofficial version can be found here http://wiki.apache.org/incubator/OpenJPAProposal Please vote on acceptance of this proposal. The vote will run 1 week until Sunday, March 26, 2006 or until all Incubator PMC members have voted. [ ] +1 Accept the OpenJPA proposal [ ] 0 Don't care [ ] -1 Reject for the following reason : === OpenJPA Project Proposal = OpenJPA will be an ASL-licensed implementation of the Java Persistence API (JPA) which is defined as part of JSR-220. Rationale = We think that Open JPA is something that will benefit from wide collaboration, being able to build a community of developers and committers that outlive the founders, and that will be embraced by other Apache efforts, such as the Geronimo project as part of an EJB 3.0 container. Given the existing momentum forming behind JPA even at this early stage, we are confident that an industrial-grade ASL implementation of JSR220 will attract a diverse community. Criteria Meritocracy === The Open JPA committers recognize the desirability of building software as a meritocracy and look forward to growing a healthy community of developers to enhance the JPA APIs. Community = The proposed committer community is includes members of the BEA JPA team and several individuals from the Apache community. Core Developers === Fourteen of the initial committers are BEA employees. One of those is a committer on the Apache JDO project. We anticipate that five of these fourteen will be involved in the core code development, and the other nine will be involved in documentation and ongoing QA for the project. Three of the initial committers are committers on the Geronimo project. Two are IBM employees involved in the WebSphere product team. One is from Intel. Alignment = Open JPA will be a candidate for use in Geronimo as the default JPA implementation. Other projects that have general-purpose JPA needs may be users of the Open JPA project. Open JPA has some level of alignment with the Apache DB project. In particular, the Open JPA codebase already includes support for Derby databases. JPA is for use in any Java application, not just J2EE. Therefore, any application that needs to do data persistence in the object/relational style (including any application that currently uses Hibernate) will benefit from Open JPA. License === The existing codebase is owned by BEA and is subject to a proprietary license. The applicable code will be relicensed under the Apache Software License 2.0. Avoiding the Warning Signs == Orphaned products - Open JPA is a derivative of the basis of the BEA WebLogic Server (WLS) EJB3 JPA implementation, and so is an important piece of the BEA code base. As this is a very eagerly anticipated specification for the Java community, we expect that this project will continue to grow and develop within its own community, and be embraced by other open source projects (such as Geronimo) as well. Inexperience with open source - The authors of the existing code (who will be part of the initial committer list) have experience with open source development already, in both professional and personal contexts. Examples: serp ([WWW] http://serp.sourceforge.net) (used in Kodo currently), sqlline and jline ([WWW] http://sqlline.sourceforge.net and [WWW] http://jline.sourceforge.net) (used by the Kodo development team, and used by the Apache JDO team), Growl ([WWW] http://growl.info). Four of the initial committers have extensive experience within the Geronimo project, among other open-source projects. Homogeneous developers -- The members of the initial committer list have been working in a distributed, multi-national, asynchronous environment for the last five years, while working at SolarMetric. We had a team of up to 7 people working from 6 different locations over the course of the last five years. Reliance on Salaried Developers --- Most of the developers are paid by their employer to contribute to this project, but given the anticipation from the Java community for the a JPA implementation and the committers' sense of ownership for the code, the project would continue without issue if no salaried developers contributed to the project. No ties to other Apache products Open JPA will likely be used by Geronimo, requires some Apache products (regexp, commons collections, commons lang, commons pool), and supports Apache commons logging. A fascination with the Apache brand --- We think that Open JPA is something that will benefit from wide collaboration, being able to build a community of developers
Re: [VOTE] Accept OpenJPA as an Incubator Podling
What we'll probably do is run it like we're running Harmony. The list of committers on the proposal are the people we expect to show up, but we won't be creating accounts by default - we'll need to have each person say yes, I'm ready and will be contributing immediately before making the account for them. geir Yoav Shapira wrote: +1, closely keeping in mind our earlier discussion regarding earned merit among everyone, commiters, testers, doc writers, etc. Yoav On 3/19/06, Roy T. Fielding [EMAIL PROTECTED] wrote: +1 Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - 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: [POLICY] Lazy account creation [WAS Re: [VOTE] Accept OpenJPA as an Incubator Podling]
robert burrell donkin wrote: On 3/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: What we'll probably do is run it like we're running Harmony. The list of committers on the proposal are the people we expect to show up, but we won't be creating accounts by default - we'll need to have each person say yes, I'm ready and will be contributing immediately before making the account for them. this seems a useful tradition: is it too early to codified this into policy? I think so. One problem is that it places special status on some people that others don't have, once you get rolling. So n months into the project, if one of the listed people pops up and gets working, fast-tracking commit might make others that have been working in the project (and don't have commit) unhappy. Maybe the solution is a well-codified policy with some time limit, so that it doesn't seem arbitrary and capricious. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Open JPA
some Apache products (regexp, commons collections, commons lang, commons pool), and supports Apache commons logging. :A fascination with the Apache brand: We think that Open JPA is something that will benefit from wide collaboration, being able to build a community of developers and committers that outlive the founders, and that will be embraced by other Apache efforts, such as the Geronimo project. Scope of Subprojects No subprojects proposed. Initial Source == BEA Systems, Inc. will contribute the initial core source code for implementing JPA. ASF Resources to be Created === Mailing lists: open-jpa-dev@ open-jpa-commits@ open-jpa-ppmc@ (with moderated subscriptions) open-jpa-user@ SVN Repository: https://svn.apache.org/repos/asf/incubator/open-jpa JIRA: Open-JPA (OPEN-JPA) Initial Committers == Abe White (awhite at bea dot com) Marc Prud'hommeaux (mprudhom at bea dot com) Patrick Linskey (plinskey at bea dot com) Pinaki Poddar (pinaki dot poddar at bea dot com) Steve Kim (stkim at bea dot com) Seetharam Param (sparam at bea dot com) Reena Mathew (rmathew at bea dot com) Jacob Thomas (jthomas at bea dot com) Ajay Prabhu (aprabhu at bea dot com) Sathish Santhanam (sathish at bea dot com) Maruthi Nuthikattu (maruthi at bea dot com) Anurag Bahl (abahl at bea dot com) Mihir Kulkarni (mihirk at bea dot com) Srinivasa Segu (srinivasa dot segu at bea dot com) Greg Campbell (gcamp at yjsinc dot com) Eric Lindauer (e_lindauer at yahoo dot com) Gianny Damour (gianny dot damour at optusnet dot com dot au) Matt Hogstrom (matt at hogstrom dot org) David Jencks (djencks at apache dot org) Kevin Sutter (kwsutter at gmail dot com) David Wisneski (wisneskid at gmail dot com) Geir Magnusson Jr (geirm at apache dot org) Sponsor == We kindly request the Incubator PMC to accept sponsorship for this proposal. Champion === Geir Magnusson, Jr. (geirm at apache dot org) Mentors === Eddie O'Neil (ekoneil at apache dot org) Brian McAllister (brianm at apache dot org) Geir Magnusson, Jr. (geirm at apache dot org) ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Jackrabbit to TLP status (pending board approval)
+1 Roy T. Fielding wrote: The Apache Jackrabbit committers have voted to request graduation from the Incubator as a TLP. http://mail-archives.apache.org/mod_mbox/incubator-jackrabbit-dev/200603.mbox/[EMAIL PROTECTED] The following votes have been recorded: Committers +1 Roy T. Fielding +1 Stefan Guggisberg +1 Serge Huber +1 Stefano Mazzocchi (requested emeritus status) +1 Felix Meschberger +1 Brian Moseley +1 David Nuescheler Dominique Pfister +1 Peeter Piegaze +1 Edgar Poce Gianugo Rabellino (requested emeritus status) Tim Reilly (requested emeritus status) +1 Marcel Reutegger Paul Russell +1 Andrew Savory (requested emeritus status) +1 Angela Schreiber +1 Tobias Strasser Sylvain Wallez +1 Jukka Zitting Non-binding +1 Chandresh Turakhia +1 Helio +1 Michael Singer Under the Incubator process, Jackrabbit must have a destination prior to exiting incubation, which means the ASF Board must decide whether or not create a TLP for Apache Jackrabbit prior to the Incubator vote being official. However, I suspect that the board would want some indication that we are ready to graduate first. So, I am asking for a vote of the Incubator on graduation of Jackrabbit that is conditional on the board's approval of a TLP for that purpose. This way we don't have to vote again after the board meeting on Wednesday. Please send in your +1/0/-1 to approve/abstain/disapprove. Status: http://incubator.apache.org/projects/jackrabbit.html Site: http://incubator.apache.org/jackrabbit/ List: http://mail-archives.apache.org/mod_mbox/incubator-jackrabbit-dev/ Cheers, Roy - 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] Graduate Jackrabbit to TLP status (pending board approval)
William A. Rowe, Jr. wrote: Roy T. Fielding wrote: On Mar 13, 2006, at 9:02 AM, Noel J. Bergman wrote: Can you confirm the community diversity? That is one thing I could not tell straight off, although I do note the comment in July 2005 about crossing the threshold, and observe that there have been at least 4 committers added since then. So I'm assuming that it is fine, and therefore +1. Good point. Here is the current list of committers and their last known affiliation I'm counting 8 employees of Day who are not-Roy (I trust you particularly to know how to wear two different hats) and 6 non-employees constituting the initial PMC. As such, I'm afraid I must cast -1 at this time soley on the issue of diversity, to graduate this to a TLP. That vote would change as diversity continues to increase (which I trust it will.) Why? We have asked for 3 legally-independent committers. Jackrabbit has that by my count. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thoughts on Umbrellas, Federations, and Communication
Henri Yandell wrote: On 3/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Well, back in Jakarta's heyday, the general list was the meeting place for all the subprojects. It was a lot of fun. I'm not sure we could do that on an apache-wide scale though. Part of the fun was because we knew each other, and that there was a topic domain that was narrow, but broad enough to span Jakarta. We also have blogging now - it was just being born (or so) in the heyday. So if I come up with something I want to talk about, I can just blog it. And do you find the same richness of discussion and camaraderie in blogging that I felt (and I believe others did too) in the fun and froth of [EMAIL PROTECTED] geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Open JPA
Niclas Hedhman wrote: On Saturday 11 March 2006 03:21, Rodent of Unusual Size wrote: Which is a really long-winded way of saying: At graduation, maybe it's worthwhile to see whether the podling committers actually earned any Apache merit. Agree. That would also allow for a lot lower bar at the start of podlings without flooding ASF with inactive committers. However, it may be hard to quantify an exclusion, and we may see people making commits just for the sake of passing which may not be merit. This is why I think it's a PPMC judgement. If at the time of graduation we think that the PPMC can become the PMC of a top level project (or join an existing PMC), then it's something they can take care of. If we agree there is an issue here, we should just ensure that it's an aspect the PPMC has to consider on their way out. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thoughts on Umbrellas, Federations, and Communication
Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Geir Magnusson Jr wrote: Well, back in Jakarta's heyday, the general list was the meeting place for all the subprojects. It was a lot of fun. I'm not sure we could do that on an apache-wide scale though. Part of the fun was because we knew each other, and that there was a topic domain that was narrow, but broad enough to span Jakarta. What's wrong with [EMAIL PROTECTED] That's open to all committers and one of it's intended goals was to provide exactly what you describe.. Dunno. I always think of it as related to community issues, rather than limited-interest technology-related discussion... geir - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBRBHORJrNPMCpn3XdAQLHaAP9FD6HsdvzvyjSzzI6eCwzHqKOKS4Q4Ysa YK10ywdxvmH876c9Xg/G+DRNkPk5a0W3FiKoatiZXx8LkyXuAJUn3K+vps03S3wS AOBUlw2PB9T098Sa1iEgdQ46g74DM4A45WN2TnuxHr+2+Iob/5hVIyr2CcjOFY+O o/KXaLnOnYI= =6+cn -END PGP SIGNATURE- - 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]
