Re: [VOTE] Release Apache Qpid Incubating M3 (RC4)
2008/9/4 Daniel Kulp [EMAIL PROTECTED]: Definitely a big step in the right direction, however.. The ruby, c++, and python packages don't have the disclaimer in them. The Java licenses file mentions the EPL, but I didn't see any eclipse licensed jars and stuff. I could have missed it though. Not a big deal though. Dan Thanks for catching that Dan I've put the missing files in now. The Java Management Console is and Eclipse bundle though we don't release it as a standalone component to run it or compile it you will need a variety of EPL jars. At some point we may have individual releases of the broker, client and management console but for M3 just now they are a single Java release. Regards, Martin On Tuesday 02 September 2008 5:25:08 pm Aidan Skinner wrote: There were some problems with the NOTICE and LICENSE files in RC3 (is there a good guide to this anywhere? having all the individual licenses in LICENSE seems odd to me...) so I've rolled RC4[1] and would like to restart the vote to release Apache Qpid M3. I started the vote on qpid-dev at 2008-08-22: http://markmail.org/message/2a6pmx3sdgvh5bu5 And closed it on 2008-08-27 http://markmail.org/message/xb3qppr5krtdp43w There were: 8 +1s (1 of which was binding) 0 0's 0 -1's Which were cast by: Alan Conway Arnaud Simon Martin Ritchie Gordon Sim Carl Trieloff Yoav Shapira (binding) Rajith Attapattu Lahiru Gunathilake Artifacts can be found at http://people.apache.org/~aidan/qpid/M3-RC4/ Release notes are located here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312117sty leName=HtmlprojectId=12310520Create=Create Please vote to: [+1] Release Apache Qpid M3 [0] que? [-1] No, there's still an issue with it which needs to be corrected - Aidan [1] I ran release.sh and uploaded the output, ritchiem did the actual leg work for this one -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martin Ritchie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] accept Tashi into the Incubator
The voting appears to have ended, with 14+ votes and zero negative votes, and three volunteers to be mentors (thank you!): 1. Matthieu Riou ([EMAIL PROTECTED]) 2. Craig L Russell ([EMAIL PROTECTED]) 3. Paul Freemantle ([EMAIL PROTECTED]) What is the next step for admission into the incubator? Dave O On Thu, Aug 14, 2008 at 10:11 PM, Matthieu Riou [EMAIL PROTECTED] wrote: So shouldn't this vote get tallied now? Seems that we're well passed the 72 hours. Matthieu On Thu, Aug 14, 2008 at 12:44 PM, Matt Hogstrom [EMAIL PROTECTED] wrote: +1 On Aug 4, 2008, at 1:48 PM, Doug Cutting wrote: Please vote on accepting Tashi into the Incubator. Tashi's proposal is at: http://wiki.apache.org/incubator/TashiProposal Thanks! Doug - 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] -- -- David O'Hallaron -- Director, Intel Research Pittsburgh -- Assoc Prof of CS and ECE, Carnegie Mellon University -- http://www.cs.cmu.edu/~droh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (INCUBATOR-82) Allow extra release distribution channels like the central Maven repository
Allow extra release distribution channels like the central Maven repository --- Key: INCUBATOR-82 URL: https://issues.apache.org/jira/browse/INCUBATOR-82 Project: Incubator Issue Type: Improvement Components: policy Reporter: Jukka Zitting There has been a lot of discussion about whether to allow podlings to publish their releases in the central Maven repository. The current (undocumented) policy is that podlings may not use the central Maven repository as a distribution channel. I am planning to call the Incubator PMC to vote on changing this policy. Instead of the specific case of the Maven repository, I would like to make the policy change cover any _additional_ distribution channels that the podlings may want to use. Otherwise we'll be having the same discussion again with other channels like Ruby Gems, Python Package Index, Perl CPAN, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (INCUBATOR-82) Allow extra release distribution channels like the central Maven repository
[ https://issues.apache.org/jira/browse/INCUBATOR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated INCUBATOR-82: --- Attachment: INCUBATOR-82.patch Proposed patch, version 1. Is there something obvious that I'm missing? Any other feedback or comments on the details? I'd like to nail down the exact wording of the proposed policy change before I call the vote on [EMAIL PROTECTED] Allow extra release distribution channels like the central Maven repository --- Key: INCUBATOR-82 URL: https://issues.apache.org/jira/browse/INCUBATOR-82 Project: Incubator Issue Type: Improvement Components: policy Reporter: Jukka Zitting Attachments: INCUBATOR-82.patch There has been a lot of discussion about whether to allow podlings to publish their releases in the central Maven repository. The current (undocumented) policy is that podlings may not use the central Maven repository as a distribution channel. I am planning to call the Incubator PMC to vote on changing this policy. Instead of the specific case of the Maven repository, I would like to make the policy change cover any _additional_ distribution channels that the podlings may want to use. Otherwise we'll be having the same discussion again with other channels like Ruby Gems, Python Package Index, Perl CPAN, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Poloka
Hi Guillaume, This is interesting! Thank you for the tip on ServiceMix. I will take a look in the ServiceMix code. Do you think it would make sense to send the Poloka proposal to the ServiceMix mailing list? Cheers Serge -Original Message- From: Guillaume Nodet [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 5:05 PM To: general@incubator.apache.org Subject: Re: [PROPOSAL] Poloka Btw, Apache ServiceMix also has a JBI service engine implementating WS-BrokeredNotification on top of a JMS broker (which btw saves a lot of work ...). It would be interesting to see if we can come up with something that could be shared by the three projects (Savan, Poloka and ServiceMix) ... On Wed, Aug 20, 2008 at 5:55 PM, Mankovskii, Serge [EMAIL PROTECTED] wrote: I am re-sending this proposal because the first time it ended up in the Etch proposal thread. Sorry Etch guys! This is a proposal to enter Poloka in to the incubator. See http://wiki.apache.org/incubator/PolokaProposal We do not have a champion at the moment. We are looking forward to the community input. Cheers Serge Mankovski -- = POLOKA Project Proposal = == Abstract == Poloka will be a standalone reference implementation of the WS-BaseNotification, WS-Topics and the WS-BrokeredNotification standards. It is aiming to go beyond the WS-BrokeredNotification specification and deliver a reliable and scalable network of WS-BrokeredNotification brokers. All existing implementations of WS-BrokeredNotification focus on implementation of a message broker. Poloka will implement additional features that would allow for a federation of brokers. It will extend WS-BrokeredNotification specification with the notion of a federated broker network and allow for a reliable, a scalable and a highly available implementation of the WS-BrokeredNotification standard. == Proposal == Poloka will provide a reference implementation of WS-BaseNotification, WS-Topics and WS-BrokeredNotification standards. The project will provide a clear separation of functionality required by the existing standards from additional functionality provided as an enhancement and elaboration on the standards Poloka will: 1. not be tightly coupled with WS-RF and WSDM standards 1. implement the WS-BrokeredNotification specification absent in the Apache Muse project 1. will implement a network of brokers that will provide scalability, reliability and fault tolerance 1. feed implementation and design experiences into the OASIS standards process and might lead to new revisions of the WS-Notification stack of standards == Background == Poloka is a second generation of the research project going on for the last five years at the University of Toronto's Middleware Systems Research Group under the [http://research.msrg.utoronto.ca/Padres/WebHome PADRES] project. During these years the group developed a stable code base that will form a base for the first release of Poloka. The PADRES project has developed a number of new technologies that allow for a scalable and reliable federation of publish/subscribe brokers. The PADRES federation mechanisms allow for redundant message routing, load balancing, complex event processing and other useful features that become available to the federated network of the WS-BrokeredNotification brokers. The project was started before WS-BrokeredNotification standard was created. The initial release of Poloka will contain existing PADRES code that does not use any WS-* compliant interfaces. However that will change with the future releases. PADRES brokers will be enriched with the WS--Notification interfaces on the notification producer and notification consumer side. The Broker-to-Broker communication side of communication is not covered by any existing standards to date and it would remain non-WS based. The team engaged in the development of Poloka involves two former participants of the OASIS committee that produced WS-BaseNotification, WS-Topics and WS-BrokeredNotification standards. Their engagement would serve dual purposes: to serve as source if first-hand authoritative knowledge of the standards and as a conduit for the standards use experience that might result in future evolution of the WS-BaseNotification, WS-Topics and WS-BrokeredNotification standards. A note about the project name; we are inspired by the impact WikiWiki made on the world of web applications. We followed the naming exampled set by author of the Wiki and simply translated word Broker using a Hawaiian dictionary. Poloka simply means Broker == Rationale == Current adoption of the WS-Notification set of standard is impeded by absence of a standalone reference implementation. For example WS-Notification implementation in Apache Muse is incomplete and tightly coupled with programming model of WS-RF
Re: [PROPOSAL] Poloka
Yeah, one of our user wants to contribute new features to the WS notification broker, so she may be interested. FYI, the WS-Notification service engine code is located here: https://svn.apache.org/repos/asf/servicemix/components/engines/servicemix-wsn2005/trunk/ We're using CXF wsdl2java tool to generate the classes and interfaces from the WSDL, then provide implementation of those on top of a JMS broker. On Thu, Sep 4, 2008 at 5:56 PM, Mankovskii, Serge [EMAIL PROTECTED] wrote: Hi Guillaume, This is interesting! Thank you for the tip on ServiceMix. I will take a look in the ServiceMix code. Do you think it would make sense to send the Poloka proposal to the ServiceMix mailing list? Cheers Serge -Original Message- From: Guillaume Nodet [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 5:05 PM To: general@incubator.apache.org Subject: Re: [PROPOSAL] Poloka Btw, Apache ServiceMix also has a JBI service engine implementating WS-BrokeredNotification on top of a JMS broker (which btw saves a lot of work ...). It would be interesting to see if we can come up with something that could be shared by the three projects (Savan, Poloka and ServiceMix) ... On Wed, Aug 20, 2008 at 5:55 PM, Mankovskii, Serge [EMAIL PROTECTED] wrote: I am re-sending this proposal because the first time it ended up in the Etch proposal thread. Sorry Etch guys! This is a proposal to enter Poloka in to the incubator. See http://wiki.apache.org/incubator/PolokaProposal We do not have a champion at the moment. We are looking forward to the community input. Cheers Serge Mankovski -- = POLOKA Project Proposal = == Abstract == Poloka will be a standalone reference implementation of the WS-BaseNotification, WS-Topics and the WS-BrokeredNotification standards. It is aiming to go beyond the WS-BrokeredNotification specification and deliver a reliable and scalable network of WS-BrokeredNotification brokers. All existing implementations of WS-BrokeredNotification focus on implementation of a message broker. Poloka will implement additional features that would allow for a federation of brokers. It will extend WS-BrokeredNotification specification with the notion of a federated broker network and allow for a reliable, a scalable and a highly available implementation of the WS-BrokeredNotification standard. == Proposal == Poloka will provide a reference implementation of WS-BaseNotification, WS-Topics and WS-BrokeredNotification standards. The project will provide a clear separation of functionality required by the existing standards from additional functionality provided as an enhancement and elaboration on the standards Poloka will: 1. not be tightly coupled with WS-RF and WSDM standards 1. implement the WS-BrokeredNotification specification absent in the Apache Muse project 1. will implement a network of brokers that will provide scalability, reliability and fault tolerance 1. feed implementation and design experiences into the OASIS standards process and might lead to new revisions of the WS-Notification stack of standards == Background == Poloka is a second generation of the research project going on for the last five years at the University of Toronto's Middleware Systems Research Group under the [http://research.msrg.utoronto.ca/Padres/WebHome PADRES] project. During these years the group developed a stable code base that will form a base for the first release of Poloka. The PADRES project has developed a number of new technologies that allow for a scalable and reliable federation of publish/subscribe brokers. The PADRES federation mechanisms allow for redundant message routing, load balancing, complex event processing and other useful features that become available to the federated network of the WS-BrokeredNotification brokers. The project was started before WS-BrokeredNotification standard was created. The initial release of Poloka will contain existing PADRES code that does not use any WS-* compliant interfaces. However that will change with the future releases. PADRES brokers will be enriched with the WS--Notification interfaces on the notification producer and notification consumer side. The Broker-to-Broker communication side of communication is not covered by any existing standards to date and it would remain non-WS based. The team engaged in the development of Poloka involves two former participants of the OASIS committee that produced WS-BaseNotification, WS-Topics and WS-BrokeredNotification standards. Their engagement would serve dual purposes: to serve as source if first-hand authoritative knowledge of the standards and as a conduit for the standards use experience that might result in future evolution of the WS-BaseNotification, WS-Topics and WS-BrokeredNotification standards. A note about the project
[jira] Commented: (INCUBATOR-82) Allow extra release distribution channels like the central Maven repository
[ https://issues.apache.org/jira/browse/INCUBATOR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628371#action_12628371 ] Bertrand Delacretaz commented on INCUBATOR-82: -- Looks good to me. Allow extra release distribution channels like the central Maven repository --- Key: INCUBATOR-82 URL: https://issues.apache.org/jira/browse/INCUBATOR-82 Project: Incubator Issue Type: Improvement Components: policy Reporter: Jukka Zitting Attachments: INCUBATOR-82.patch There has been a lot of discussion about whether to allow podlings to publish their releases in the central Maven repository. The current (undocumented) policy is that podlings may not use the central Maven repository as a distribution channel. I am planning to call the Incubator PMC to vote on changing this policy. Instead of the specific case of the Maven repository, I would like to make the policy change cover any _additional_ distribution channels that the podlings may want to use. Otherwise we'll be having the same discussion again with other channels like Ruby Gems, Python Package Index, Perl CPAN, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Web20Kit: A Web 2.0 technology evaluation kit
Here are some suggestions for alternate names : Olio Ratatouille MixMatch (3 above indicating we're trying to mix and match components) Ketero (Ethiopian I believe for 'appointment') or Catero Shanti Craig L Russell wrote: Hi Martin, On Aug 26, 2008, at 7:51 PM, Martin Cooper wrote: Yeah, an association with WebKit was my first assumption as well. Agreed. New name.initiate().run(). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] accept Tashi into the Incubator
On Thu, Sep 4, 2008 at 8:02 AM, David O'Hallaron [EMAIL PROTECTED] wrote: The voting appears to have ended, with 14+ votes and zero negative votes, and three volunteers to be mentors (thank you!): 1. Matthieu Riou ([EMAIL PROTECTED]) 2. Craig L Russell ([EMAIL PROTECTED]) 3. Paul Freemantle ([EMAIL PROTECTED]) What is the next step for admission into the incubator? Ah! I'm glad someone finally reacts :) I was hoping for Doug to close the vote but anyway it passed, so let's move on. I'll get your infra (mailing lists and repository) set up and will contact initial committers (the two Michaels) for CLAs. I believe a grant for the initial codebase will also be needed. Cheers, Matthieu Dave O On Thu, Aug 14, 2008 at 10:11 PM, Matthieu Riou [EMAIL PROTECTED] wrote: So shouldn't this vote get tallied now? Seems that we're well passed the 72 hours. Matthieu On Thu, Aug 14, 2008 at 12:44 PM, Matt Hogstrom [EMAIL PROTECTED] wrote: +1 On Aug 4, 2008, at 1:48 PM, Doug Cutting wrote: Please vote on accepting Tashi into the Incubator. Tashi's proposal is at: http://wiki.apache.org/incubator/TashiProposal Thanks! Doug - 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] -- -- David O'Hallaron -- Director, Intel Research Pittsburgh -- Assoc Prof of CS and ECE, Carnegie Mellon University -- http://www.cs.cmu.edu/~droh http://www.cs.cmu.edu/%7Edroh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Apache Qpid Incubating M3 (RC5)
There were some problems with DISCLAIMER so I've rolled RC5 and would like to restart the vote to release Apache Qpid M3. I started the vote on qpid-dev at 2008-08-22: http://markmail.org/message/2a6pmx3sdgvh5bu5 And closed it on 2008-08-27 http://markmail.org/message/xb3qppr5krtdp43w There were: 8 +1s (1 of which was binding) 0 0's 0 -1's Which were cast by: Alan Conway Arnaud Simon Martin Ritchie Gordon Sim Carl Trieloff Yoav Shapira (binding) Rajith Attapattu Lahiru Gunathilake Artifacts can be found at http://people.apache.org/~aidan/qpid/M3-RC5/ Release notes are located here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312117styleName=HtmlprojectId=12310520Create=Create Please vote to: [+1] Release Apache Qpid M3 [0] meh [-1] Non, il y a un problème, your french is rubbish and when did babelfish.altavista.com move to yahoo! anyway? - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://cwiki.apache.org/qpid Nine-tenths of wisdom consists in being wise in time. - Theodore Roosevelt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Apache Qpid Incubating M3 (RC5)
+1 from looks ok. Rajith On Thu, Sep 4, 2008 at 7:46 PM, Aidan Skinner [EMAIL PROTECTED] wrote: There were some problems with DISCLAIMER so I've rolled RC5 and would like to restart the vote to release Apache Qpid M3. I started the vote on qpid-dev at 2008-08-22: http://markmail.org/message/2a6pmx3sdgvh5bu5 And closed it on 2008-08-27 http://markmail.org/message/xb3qppr5krtdp43w There were: 8 +1s (1 of which was binding) 0 0's 0 -1's Which were cast by: Alan Conway Arnaud Simon Martin Ritchie Gordon Sim Carl Trieloff Yoav Shapira (binding) Rajith Attapattu Lahiru Gunathilake Artifacts can be found at http://people.apache.org/~aidan/qpid/M3-RC5/http://people.apache.org/%7Eaidan/qpid/M3-RC5/ Release notes are located here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312117styleName=HtmlprojectId=12310520Create=Create Please vote to: [+1] Release Apache Qpid M3 [0] meh [-1] Non, il y a un problème, your french is rubbish and when did babelfish.altavista.com move to yahoo! anyway? - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://cwiki.apache.org/qpid Nine-tenths of wisdom consists in being wise in time. - Theodore Roosevelt -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
