Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating
Hi Niall, Niall Pemberton wrote: Firstly, I'm +1 on this release. I have a few minor comments/suggestions which you may want to consider for the next release (or not!) 1) Theres a parent pom for apache which if you make the parent of the uimaj pom means you don't have to duplicate the license and organization details in your poms: http://repo1.maven.org/maven2/org/apache/apache/ sounds good, we'll look into it. 2) The source distro unzips to directory uimaj-2.2.2-incubating and the binary distro to apache-uima - which is inconsistent. I don't recall if there was a reason for this, but I agree, seems odd. We'll follow up on uima-dev. 3) IMO its better if the jars include the version number - which they do for the maven repo, but not the ones in the binary distro I personally agree with you, but we had a long discussion about this and the no version numbers in jar names faction carried the day. I believe the main reason is that it makes upgrading to a new version easier, or switching between versions for testing purposes. --Thilo Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Revising the IP Clearance Form (was: cut the crap)
On 4/23/08, Noel J. Bergman [EMAIL PROTECTED] wrote: Robert Burrell Donkin wrote: i've committed a stripped down template and moved the prose into a guide. this guide is just copy ATM With all due and sincere respect to Roy, the current IP Clearance form was done in conjunction with the Board. Over the past several years it has been modified slightly by the current President, Chair, and at least one other Director, so it is not some unknown quantity haphazardly slapped together. Given that we now have a Legal Committee, any substantive revision of that form should be run through them. This is not a comment on content, but on process. Let's do due diligence to the document. If the IP template should be RTC then it should be moved into the policy area. But IMO the incubator is not the right place for normative legal policy: the legal committee should maintain policy. I agree with Roy. The educational aspect obscures the function. The current template is in need of revision since it satisfies neither goal. But I don't have the energy to push through any policy changes ATM. Just revert the changes and open another JIRA... Robert --- 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: [VOTE] Approve the release of Tuscany Java SCA 1.2-incubating
+1 Paul On Tue, Apr 22, 2008 at 3:04 PM, Matthieu Riou [EMAIL PROTECTED] wrote: On Thu, Apr 17, 2008 at 8:07 AM, Luciano Resende [EMAIL PROTECTED] wrote: The Apache Tuscany project request IPMC permission to release the Java SCA 1.2-incubating. The vote thread is here ... http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30405.html The artifacts are available for review at: http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/ This includes the signed binary and source distributions, the RAT report, and the Maven staging repository. The eclipse updatesite for the Tuscany Eclipse plugins is available at: http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/updatesite/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/updatesite/ The release tag is available at : http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC4/ +1 Matthieu -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating
Thilo Goetz wrote: snip 3) IMO its better if the jars include the version number - which they do for the maven repo, but not the ones in the binary distro I personally agree with you, but we had a long discussion about this and the no version numbers in jar names faction carried the day. I believe the main reason is that it makes upgrading to a new version easier, or switching between versions for testing purposes. We actually have a Jira issue that may address this, for the next release: http://issues.apache.org/jira/browse/UIMA-857 - Marshall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating
On Wed, Apr 23, 2008 at 7:24 AM, Marshall Schor [EMAIL PROTECTED] wrote: Thilo Goetz wrote: 3) IMO its better if the jars include the version number - which they do for the maven repo, but not the ones in the binary distro I personally agree with you, but we had a long discussion about this and the no version numbers in jar names faction carried the day. I believe the main reason is that it makes upgrading to a new version easier, or switching between versions for testing purposes. We actually have a Jira issue that may address this, for the next release: http://issues.apache.org/jira/browse/UIMA-857 Among the UIMA committers, I'm the main proponent of the no version numbers in jar names. Jar file names that change in each version have always driven me crazy because they force users to update their classpaths when they upgrade their UIMA version. A lot of tools just don't handle this well - Eclipse is one example, AFAIK it doesn't give you any way to use wildcards in classpath so as to pick up any version. I don't see UIMA-857 as a solution, because UIMA is an embeddable component and people want to take our jar files and add them to their classpaths using typical Java means. I personally wouldn't be happy relying on some special UIMA mechanism for finding its jar files. -Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Approve the release of Tuscany Java SCA 1.2-incubating
This vote has passed with 3 +1 and no 0s or -1s. +1 votes received from : Ant Elder, Matthieu Riou Paul Fremantle. On Tue, Apr 22, 2008 at 11:58 PM, Paul Fremantle [EMAIL PROTECTED] wrote: +1 Paul On Tue, Apr 22, 2008 at 3:04 PM, Matthieu Riou [EMAIL PROTECTED] wrote: On Thu, Apr 17, 2008 at 8:07 AM, Luciano Resende [EMAIL PROTECTED] wrote: The Apache Tuscany project request IPMC permission to release the Java SCA 1.2-incubating. The vote thread is here ... http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30405.html The artifacts are available for review at: http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/ This includes the signed binary and source distributions, the RAT report, and the Maven staging repository. The eclipse updatesite for the Tuscany Eclipse plugins is available at: http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/updatesite/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/updatesite/ The release tag is available at : http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC4/ +1 Matthieu -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (INCUBATOR-74) IP Clearance Template is rubbish
IP Clearance Template is rubbish Key: INCUBATOR-74 URL: https://issues.apache.org/jira/browse/INCUBATOR-74 Project: Incubator Issue Type: Bug Reporter: Robert Burrell Donkin http://mail-archives.apache.org/mod_mbox/incubator-general/200804.mbox/[EMAIL PROTECTED] -- 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-74) IP Clearance Template is rubbish
[ https://issues.apache.org/jira/browse/INCUBATOR-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Burrell Donkin updated INCUBATOR-74: --- Attachment: ip.diff I'd approach this by splitting into guide and stripped down template IP Clearance Template is rubbish Key: INCUBATOR-74 URL: https://issues.apache.org/jira/browse/INCUBATOR-74 Project: Incubator Issue Type: Bug Reporter: Robert Burrell Donkin Attachments: ip.diff http://mail-archives.apache.org/mod_mbox/incubator-general/200804.mbox/[EMAIL PROTECTED] -- 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: cut the crap
On Tue, Apr 22, 2008 at 11:14 PM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: On Mon, Apr 21, 2008 at 7:55 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Roy T. Fielding wrote: I've wasted too much time today on the stupid IP Clearance template that insists on asking a bunch of irrelevant questions about decisions that the Incubator is not responsible for making. The required IP clearance questions should be: Date: Identify the Contribution: Identify the Contributor(s): What are the filenames for the applicable software grant(s): Corporate CLA(s): Individual CLA(s): Location of initial import: Destination PMC: That's it. One more; Determine www.a.o/licenses/exports implications for notifications. That's my last crypto audit step, putting that request to all incubator podlings and ensuring this mess is under control moving forwards. Without adding this as an IP import step, it won't happen. i've committed a stripped down template and moved the prose into a guide. this guide is just copy ATM but i'll try to find some time to tidy it up sometime tomorrow. feedback on the template appreciated or just jump in with a patch ;-) after process objections, i've reverted the source and withdraw this patch. if anyone wants to pick it up, i've opened a JIRA. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Size of websites in incubator.apache.org
I was adding cxf to the site-publish/.htaccess file and was going to go ahead and add the others that have graduated, but I want to double check something first. Several of the graduated projects have created their own .htaccess in their project directory wrather that use the top level .htaccess. Example: servicemix/.htaccess The question is: is it better to leave it like that or move them to the top level .htaccess and completely remove the project directory? I don't really care which, but consistency is probably good and which ever way we go, it should be documented in the post graduation checklist stuff. Dan On Tuesday 22 April 2008, Tony Stevenson wrote: Good day, As part of rolling out the new backup server for the infra team, I have discovered that several podling sites are extremely large. Namely: 119M/x1/www/incubator.apache.org/activemq 324M/x1/www/incubator.apache.org/cxf 102M/x1/www/incubator.apache.org/directory 166M/x1/www/incubator.apache.org/lucene.net 587M/x1/www/incubator.apache.org/openjpa 299M/x1/www/incubator.apache.org/servicemix 166M/x1/www/incubator.apache.org/uima I am singling out all sites that over 100MB in size here. Can someone please check the contents of these directories? I appreciate that some of them have graduated from the incubator and as such, these datasets are either redundant or should be archived. I would appreciate a definitive directive as to what should be done with these directories. I will also be updating the documentation on how to handle graduation/removal from the incubator. I'll send an update once this has been done too. Cheers, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cut the crap
Robert Burrell Donkin wrote: On Tue, Apr 22, 2008 at 11:14 PM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: On Mon, Apr 21, 2008 at 7:55 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Roy T. Fielding wrote: I've wasted too much time today on the stupid IP Clearance template that insists on asking a bunch of irrelevant questions about decisions that the Incubator is not responsible for making. The required IP clearance questions should be: Date: Identify the Contribution: Identify the Contributor(s): What are the filenames for the applicable software grant(s): Corporate CLA(s): Individual CLA(s): Location of initial import: Destination PMC: That's it. One more; Determine www.a.o/licenses/exports implications for notifications. That's my last crypto audit step, putting that request to all incubator podlings and ensuring this mess is under control moving forwards. Without adding this as an IP import step, it won't happen. i've committed a stripped down template and moved the prose into a guide. this guide is just copy ATM but i'll try to find some time to tidy it up sometime tomorrow. feedback on the template appreciated or just jump in with a patch ;-) after process objections, i've reverted the source and withdraw this patch. if anyone wants to pick it up, i've opened a JIRA. Thanks Robert, I actually think it was a mistake not to just leave things be. But given that Sam's volunteered his committee to take this on and asked that you back it out, I'm sure he'll find the volunteer to see it through. Be sure to nag [if|when] that doesn't happen. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [jira] Commented: (INFRA-1585) Zone for Shindig
Shindig wants to run an instance of review board, a nightly build, and a running reference server. Is this something shindig should do (using a Zone), or should we try something else first? Thanks, -Dan -- Forwarded message -- From: Joe Schaefer (JIRA) [EMAIL PROTECTED] Date: Wed, Apr 23, 2008 at 3:09 PM Subject: [jira] Commented: (INFRA-1585) Zone for Shindig To: [EMAIL PROTECTED] [ https://issues.apache.org/jira/browse/INFRA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591742#action_12591742] Joe Schaefer commented on INFRA-1585: - I would appreciate it if you ran your request by [EMAIL PROTECTED] before we go any further. Infrastructure has not granted zones to incubating projects before, as the request for a zone typically comes from a PMC. If all you can get is lazy consensus on [EMAIL PROTECTED], I suppose that's good enough for us. Zone for Shindig Key: INFRA-1585 URL: https://issues.apache.org/jira/browse/INFRA-1585 Project: Infrastructure Issue Type: Wish Security Level: public(Regular issues) Components: Zones Reporter: Dan Bentley Assignee: Norman Maurer Shindig wants a Zone to run an instance of Review Board, a sample container, and a nightly build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (INCUBATOR-74) IP Clearance Template is rubbish
[ https://issues.apache.org/jira/browse/INCUBATOR-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591773#action_12591773 ] Roy T. Fielding commented on INCUBATOR-74: -- I like the approach, but the template only needs a single table: http://incubator.apache.org/ip-clearance/httpd-mod_domain-clearance.html We could add links from the table headings to their definition in the guide. IP Clearance Template is rubbish Key: INCUBATOR-74 URL: https://issues.apache.org/jira/browse/INCUBATOR-74 Project: Incubator Issue Type: Bug Reporter: Robert Burrell Donkin Attachments: ip.diff http://mail-archives.apache.org/mod_mbox/incubator-general/200804.mbox/[EMAIL PROTECTED] -- 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: cut the crap
On Wed, Apr 23, 2008 at 9:13 PM, Roy T. Fielding [EMAIL PROTECTED] wrote: snip Robert's separation of guide and template was a good start, though my version of the template is much smaller. IMHO the only way that documentation gets written here is by first draft then collective improvement This is not a legal document. This is, at most, a secretarial function that is being done so that we have a place to look for dotted i's and crossed t's. +1 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cut the crap
On Wed, Apr 23, 2008 at 8:04 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Robert Burrell Donkin wrote: On Tue, Apr 22, 2008 at 11:14 PM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: On Mon, Apr 21, 2008 at 7:55 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Roy T. Fielding wrote: I've wasted too much time today on the stupid IP Clearance template that insists on asking a bunch of irrelevant questions about decisions that the Incubator is not responsible for making. The required IP clearance questions should be: Date: Identify the Contribution: Identify the Contributor(s): What are the filenames for the applicable software grant(s): Corporate CLA(s): Individual CLA(s): Location of initial import: Destination PMC: That's it. One more; Determine www.a.o/licenses/exports implications for notifications. That's my last crypto audit step, putting that request to all incubator podlings and ensuring this mess is under control moving forwards. Without adding this as an IP import step, it won't happen. i've committed a stripped down template and moved the prose into a guide. this guide is just copy ATM but i'll try to find some time to tidy it up sometime tomorrow. feedback on the template appreciated or just jump in with a patch ;-) after process objections, i've reverted the source and withdraw this patch. if anyone wants to pick it up, i've opened a JIRA. Thanks Robert, I actually think it was a mistake not to just leave things be. roy's right: the form's filled with rubbish that isn't checked or enforced by the incubator. it doesn't work as an educational document either. But given that Sam's volunteered his committee to take this on he has? and asked that you back it out, i've checked my mail and i can find nothing in my inbox I'm sure he'll find the volunteer to see it through. same people, different hats - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cut the crap
Roy T. Fielding wrote: One more; Determine www.a.o/licenses/exports implications for notifications. No. That is not part of IP clearance, sorry, and I will not repeat all of the process associated with being a chair within something as trivial as a secretarial function (connecting the dots between the legal paperwork and import). We have better places to document the role of a chair. Ahhh of course, we are reading the process from two different perspectives. Code-import, you are right. Each PMC chair was just given the exercise to review the /licenses/exports documentation and determine if their code was implicated in that policy. I have no issues with leaving it out of the IP clearance doc. For a code import into a podling, you would be wrong; Noel (singular) isn't in a position to know what's happening in 2 dozen podlings, so this needs to be spelled out in the process status/flow of the incubating projects. So happy to leave IP clearance alone. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Size of websites in incubator.apache.org
On Wed, Apr 23, 2008 at 11:26 AM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: AIUI using the top level .htaccess is better for performance so that's what i recommend (but hopefully someone will jump in and correct me if +1. (Not having .htaccess at all is actually best; but that requires us tweaking the master httpd conf files whenever a PMC wants a redirect - doable but feh.) -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cut the crap
On Wed, Apr 23, 2008 at 10:14 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Roy T. Fielding wrote: One more; Determine www.a.o/licenses/exports implications for notifications. No. That is not part of IP clearance, sorry, and I will not repeat all of the process associated with being a chair within something as trivial as a secretarial function (connecting the dots between the legal paperwork and import). We have better places to document the role of a chair. Ahhh of course, we are reading the process from two different perspectives. Code-import, you are right. Each PMC chair was just given the exercise to review the /licenses/exports documentation and determine if their code was implicated in that policy. I have no issues with leaving it out of the IP clearance doc. i see nothing wrong with including it within a guide to IP clearance for projects. deleting the inappropriate sentence is not much a burden for someone filling in a template so i'm agnostic on inclusion in the template... For a code import into a podling, you would be wrong; Noel (singular) isn't in a position to know what's happening in 2 dozen podlings, so this needs to be spelled out in the process status/flow of the incubating projects. we're working on a guide to bootstrapping podlings including IP import help for podlings. i had it in mind to include it in there. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (INFRA-1585) Zone for Shindig
Hey folks, As additional background, at ApacheCon EU, Noel Bergman proposed the idea of Shindig getting a Zone (for running a sample instance, as well as for nightly builds). Noel was actually quite surprised that we didn't already have one. I think review board is a natural extension of what we'd use that Zone for, to improve the quality of code reviews. -Dan On Wed, Apr 23, 2008 at 12:31 PM, Dan Bentley [EMAIL PROTECTED] wrote: Shindig wants to run an instance of review board, a nightly build, and a running reference server. Is this something shindig should do (using a Zone), or should we try something else first? Thanks, -Dan -- Forwarded message -- From: Joe Schaefer (JIRA) [EMAIL PROTECTED] Date: Wed, Apr 23, 2008 at 3:09 PM Subject: [jira] Commented: (INFRA-1585) Zone for Shindig To: [EMAIL PROTECTED] [ https://issues.apache.org/jira/browse/INFRA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591742#action_12591742 ] Joe Schaefer commented on INFRA-1585: - I would appreciate it if you ran your request by [EMAIL PROTECTED] before we go any further. Infrastructure has not granted zones to incubating projects before, as the request for a zone typically comes from a PMC. If all you can get is lazy consensus on [EMAIL PROTECTED], I suppose that's good enough for us. Zone for Shindig Key: INFRA-1585 URL: https://issues.apache.org/jira/browse/INFRA-1585 Project: Infrastructure Issue Type: Wish Security Level: public(Regular issues) Components: Zones Reporter: Dan Bentley Assignee: Norman Maurer Shindig wants a Zone to run an instance of Review Board, a sample container, and a nightly build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
