Re: [IVY] maillists moderator needed
On 11/1/06, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Hello Xavier, this is certainly something that you are allowed to do. So I will let infrastructure know that we have the 3 people needed. Will you do this with your gmail mail address ? Yes my gmail address is allright for that. Thanks. Xavier Regards, Antoine Xavier Hanin wrote: On 11/1/06, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Hi, infrastructure actually needs 3 moderators for the emails. Stefan Bodewig and myself are volunteers. We need a third. I don't know if this is something I'm allowed to do, but if I can I volunteer. Xavier Regards, Antoine Original-Nachricht Datum: Tue, 31 Oct 2006 20:06:02 +0100 Von: Stefan Bodewig [EMAIL PROTECTED] An: general@incubator.apache.org Betreff: Re: [IVY] setup of infrastructure Please go ahead yourself, you can volunteer me as moderator for all lists but another moderator - preferably in a different time zone than Central Europe - would be good. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IVY] setup of infrastructure
On 11/1/06, Brett Porter [EMAIL PROTECTED] wrote: On 31/10/06, Xavier Hanin [EMAIL PROTECTED] wrote: Does Ivy want to import history, or just the latest code? An history import would be nice, but isn't there a problem with legal issues, since old code was not under Apache License? And maybe the easier is just to import latest code (well, I should release a new version next week - maybe the last pre apache version, so it may be a good time to import just after the release). What do other think? If it were me, I'd rather import the history than having to maintain it myself. There are no legal issues (BSD is compatible with the Apache License). Thanks for your advice Brett. I'll go with history import if it's not too complex to import into apache infrastructure. Can someone tell me what you expect from our svn repository to do the import? Xavier Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IVY] setup of infrastructure
Xavier Hanin wrote: On 11/1/06, Brett Porter [EMAIL PROTECTED] wrote: On 31/10/06, Xavier Hanin [EMAIL PROTECTED] wrote: Does Ivy want to import history, or just the latest code? An history import would be nice, but isn't there a problem with legal issues, since old code was not under Apache License? And maybe the easier is just to import latest code (well, I should release a new version next week - maybe the last pre apache version, so it may be a good time to import just after the release). What do other think? If it were me, I'd rather import the history than having to maintain it myself. There are no legal issues (BSD is compatible with the Apache License). Thanks for your advice Brett. I'll go with history import if it's not too complex to import into apache infrastructure. Can someone tell me what you expect from our svn repository to do the import? If you can block all commit access to the repository, then a simple zip should do the job, If I understand correctly. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IVY] setup of infrastructure
On 11/1/06, Upayavira [EMAIL PROTECTED] wrote: Xavier Hanin wrote: On 11/1/06, Brett Porter [EMAIL PROTECTED] wrote: On 31/10/06, Xavier Hanin [EMAIL PROTECTED] wrote: Does Ivy want to import history, or just the latest code? An history import would be nice, but isn't there a problem with legal issues, since old code was not under Apache License? And maybe the easier is just to import latest code (well, I should release a new version next week - maybe the last pre apache version, so it may be a good time to import just after the release). What do other think? If it were me, I'd rather import the history than having to maintain it myself. There are no legal issues (BSD is compatible with the Apache License). Thanks for your advice Brett. I'll go with history import if it's not too complex to import into apache infrastructure. Can someone tell me what you expect from our svn repository to do the import? If you can block all commit access to the repository, then a simple zip should do the job, If I understand correctly. I can block access to the repository. So the only thing is to zip the directory on my svn server containing the db directory, is that it? This means that the hook directory will be part of the zip, I currently have a hook for sending mail on commit, but I think there's already something like this on apache usual svn install, no? So maybe the db directory is enough? We use a filesystem based svn repository, is that ok? It's a lot of question I'm sorry, but I'm not familiar with ASF infrastructure. - Xavier Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Apache Roller (incubating) 3.0
+1 from me as well (w/ PMC hat on) On Oct 31, 2006, at 7:44 PM, Henri Yandell wrote: +1 with PMC hat on (having just +1'd with Roller tester hat on over on roller-dev and had nothing but doc quibbles). Hen On 10/31/06, Davanum Srinivas [EMAIL PROTECTED] wrote: +1 from me. -- dims On 10/31/06, Dave [EMAIL PROTECTED] wrote: Please vote to release Apache Roller (incubating) 3.0 - We've gone through five release candidates, latest is here: http://people.apache.org/~snoopdave/apache-roller-3.0-rc5- incubating/ - We've fixed everything that came up with the RCs: http://rollerweblogger.org/wiki/Wiki.jsp?page=Roller30Testing - The code has been in production at a number of sites now for over a month e.g. http://blogs.sun.com - The what's new page and all docs have been updated http://rollerweblogger.org/wiki/Wiki.jsp?page=Roller_3.0_WhatsNew - And we have three votes from committers (not including me): +1 Matt Raible +1 Allen Gilliland +1 Elias Torres Vote threads are here: http://www.mail-archive.com/roller-dev%40incubator.apache.org/ msg03740.html http://www.mail-archive.com/roller-dev%40incubator.apache.org/ msg03879.html Thanks, - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - 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] Release Apache Roller (incubating) 3.0
I took a look at this and it looked fine to me. +1 Paul (wearing my trilby) On 11/1/06, Jim Jagielski [EMAIL PROTECTED] wrote: +1 from me as well (w/ PMC hat on) On Oct 31, 2006, at 7:44 PM, Henri Yandell wrote: +1 with PMC hat on (having just +1'd with Roller tester hat on over on roller-dev and had nothing but doc quibbles). Hen On 10/31/06, Davanum Srinivas [EMAIL PROTECTED] wrote: +1 from me. -- dims On 10/31/06, Dave [EMAIL PROTECTED] wrote: Please vote to release Apache Roller (incubating) 3.0 - We've gone through five release candidates, latest is here: http://people.apache.org/~snoopdave/apache-roller-3.0-rc5- incubating/ - We've fixed everything that came up with the RCs: http://rollerweblogger.org/wiki/Wiki.jsp?page=Roller30Testing - The code has been in production at a number of sites now for over a month e.g. http://blogs.sun.com - The what's new page and all docs have been updated http://rollerweblogger.org/wiki/Wiki.jsp?page=Roller_3.0_WhatsNew - And we have three votes from committers (not including me): +1 Matt Raible +1 Allen Gilliland +1 Elias Torres Vote threads are here: http://www.mail-archive.com/roller-dev%40incubator.apache.org/ msg03740.html http://www.mail-archive.com/roller-dev%40incubator.apache.org/ msg03879.html Thanks, - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - 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] -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IVY] setup of infrastructure
Xavier Hanin wrote: On 11/1/06, Upayavira [EMAIL PROTECTED] wrote: Xavier Hanin wrote: On 11/1/06, Brett Porter [EMAIL PROTECTED] wrote: On 31/10/06, Xavier Hanin [EMAIL PROTECTED] wrote: Does Ivy want to import history, or just the latest code? An history import would be nice, but isn't there a problem with legal issues, since old code was not under Apache License? And maybe the easier is just to import latest code (well, I should release a new version next week - maybe the last pre apache version, so it may be a good time to import just after the release). What do other think? If it were me, I'd rather import the history than having to maintain it myself. There are no legal issues (BSD is compatible with the Apache License). Thanks for your advice Brett. I'll go with history import if it's not too complex to import into apache infrastructure. Can someone tell me what you expect from our svn repository to do the import? If you can block all commit access to the repository, then a simple zip should do the job, If I understand correctly. I can block access to the repository. So the only thing is to zip the directory on my svn server containing the db directory, is that it? This means that the hook directory will be part of the zip, I currently have a hook for sending mail on commit, but I think there's already something like this on apache usual svn install, no? So maybe the db directory is enough? We use a filesystem based svn repository, is that ok? It's a lot of question I'm sorry, but I'm not familiar with ASF infrastructure. No, the hooks directory won't be needed. However, I'm not as knowledgeable as you might think, and would suggest you just zip up the lot, including hooks directory, just to be safe, unless someone else more knowledgeable tells you otherwise. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
clarification on SF license and sandboxes
Can anyone tell me if it's OK to put code into a sandbox that has been attached to a JIRA without granting ASF license? Thanks
Re: clarification on SF license and sandboxes
If I am not mistaken, if it is a patch it is already handles by the apache license itself. If it isn't a patch, I think it's best to ask for the granting specifically.. Mvgr, Martin kelvin goodson wrote: Can anyone tell me if it's OK to put code into a sandbox that has been attached to a JIRA without granting ASF license? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Request to release TuscanyC++ M2
A non-binding +1 from me. Any more IPMCers have time to check out and vote on this so we get the magic 3? ...ant On 10/24/06, Andrew Borley [EMAIL PROTECTED] wrote: We have held a vote on tuscany-dev@ws.apache.org to publish a new milestone release of the Tuscany C++ implementation. The vote email thread is available here: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg09946.html In summary we have 5 +1 votes: 4 from committers and 1 non-binding, and no 0s or -1s. We would like to request approval from the Incubator PMC to release this version. people.apache.org still appears to be unavailable after the weekend changes, but when it's back the candidate distribution is available here: http://people.apache.org/~ajborley/cpp-1.0-incubator-M2-RC3a/ And RAT results for each distro are available here: http://people.apache.org/~ajborley/cpp-1.0-incubator-M2-RC3a/rat Many thanks Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] - Ratify Tuscany PPMC vote to release SDO for Java M2 artifacts
Bill, thanks for your comments. I have made fixes in the trunk for the license file suggestions you raise where I am certain of the required changes ( http://svn.apache.org/viewvc?view=revrevision=470007) and I have raised a JIRA ( http://issues.apache.org/jira/browse/TUSCANY-894) to make certain of my new understanding that the CPL is no longer required in our LICENSE file. There is documentation in the binary distribution in the javadoc folder, which is pointed to from the readme.html file. There is documentation in the samples distribution in the site/apidocs folder (not my choice of layout, its what maven defines as the standard location and I haven't been able to work out how to configure that) There are instructions in the source distribution on how to build the javadoc that is found in the binary and samples distributions. Best Regards, Kelvin. On 27/10/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Kelvin, The release includes the license and notice files but I don't see any file pointing out the licenses of the individual jar files included in the release. The notice file is some what ambiguous on what is included under which license. It refers to the EPL and CPL (both are fine AFAIKT from [1]). But it seems like the notices of which jar is licensed under which license should be more explicit [2]. Since none of the license stuff is board approved yet its not binding (AFAIK) so take that for what its worth. One other thing is the lack of docs, I could not find any. TTFN, -bd- [1] http://people.apache.org/~cliffs/3party.html [2] http://people.apache.org/~cliffs/3party.html#labeling On Oct 25, 2006, at 11:09 AM, kelvin goodson wrote: The Tuscany PPMC has voted to release the SDO for Java API implementation as part of the M2 release. In accordance with Incubator release procedures we are asking the Incubator PMC to approve this release. Vote thread:* *http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09797.html Result thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10046.html Regards, Kelvin Goodson. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clarification on SF license and sandboxes
It's best practice to require that contributions be accompanied by the checkbox to grant the license. I haven't seen any official Apache policy guideline on this subject. Is the contributor willing to re-attach the file to the JIRA, this time with the checkbox ticked? That's the best way to handle it. Craig On Nov 1, 2006, at 6:47 AM, kelvin goodson wrote: Can anyone tell me if it's OK to put code into a sandbox that has been attached to a JIRA without granting ASF license? Thanks 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! smime.p7s Description: S/MIME cryptographic signature
[jira] Assigned: (INCUBATOR-49) create a status page for UIMA
[ http://issues.apache.org/jira/browse/INCUBATOR-49?page=all ] Rodent of Unusual Size reassigned INCUBATOR-49: --- Assignee: Rodent of Unusual Size create a status page for UIMA - Key: INCUBATOR-49 URL: http://issues.apache.org/jira/browse/INCUBATOR-49 Project: Incubator Issue Type: Task Components: site Reporter: Ian Holsman Assigned To: Rodent of Unusual Size please create a status page for UIMA (and other stuff required to start the podling on the site). (I don't think I have the access to do this myself) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clarification on SF license and sandboxes
thanks, i'll pursue that On 01/11/06, Craig L Russell [EMAIL PROTECTED] wrote: It's best practice to require that contributions be accompanied by the checkbox to grant the license. I haven't seen any official Apache policy guideline on this subject. Is the contributor willing to re-attach the file to the JIRA, this time with the checkbox ticked? That's the best way to handle it. Craig On Nov 1, 2006, at 6:47 AM, kelvin goodson wrote: Can anyone tell me if it's OK to put code into a sandbox that has been attached to a JIRA without granting ASF license? Thanks 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!
Re: [IVY] setup of infrastructure
Usually, a dumpfile is used rather than a zipped up repository, I think. I would suggest locating an svn admin who can work with you to do a test now - so you'd dump the repository without locking it out, load it up into the test repository, check it works, so that you know what to do and minimise downtime of your commit access when you are ready to do the real thing. I'm not an svn admin either, though - so best to get in touch with them and see how they usually do it :) Cheers, Brett On 02/11/06, Upayavira [EMAIL PROTECTED] wrote: Xavier Hanin wrote: On 11/1/06, Upayavira [EMAIL PROTECTED] wrote: Xavier Hanin wrote: On 11/1/06, Brett Porter [EMAIL PROTECTED] wrote: On 31/10/06, Xavier Hanin [EMAIL PROTECTED] wrote: Does Ivy want to import history, or just the latest code? An history import would be nice, but isn't there a problem with legal issues, since old code was not under Apache License? And maybe the easier is just to import latest code (well, I should release a new version next week - maybe the last pre apache version, so it may be a good time to import just after the release). What do other think? If it were me, I'd rather import the history than having to maintain it myself. There are no legal issues (BSD is compatible with the Apache License). Thanks for your advice Brett. I'll go with history import if it's not too complex to import into apache infrastructure. Can someone tell me what you expect from our svn repository to do the import? If you can block all commit access to the repository, then a simple zip should do the job, If I understand correctly. I can block access to the repository. So the only thing is to zip the directory on my svn server containing the db directory, is that it? This means that the hook directory will be part of the zip, I currently have a hook for sending mail on commit, but I think there's already something like this on apache usual svn install, no? So maybe the db directory is enough? We use a filesystem based svn repository, is that ok? It's a lot of question I'm sorry, but I'm not familiar with ASF infrastructure. No, the hooks directory won't be needed. However, I'm not as knowledgeable as you might think, and would suggest you just zip up the lot, including hooks directory, just to be safe, unless someone else more knowledgeable tells you otherwise. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org Better Builds with Maven book - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IVY] setup of infrastructure
On 11/1/06, Brett Porter [EMAIL PROTECTED] wrote: Usually, a dumpfile is used rather than a zipped up repository, I think. I would suggest locating an svn admin who can work with you to do a test now - so you'd dump the repository without locking it out, load it up into the test repository, check it works, so that you know what to do and minimise downtime of your commit access when you are ready to do the real thing. I'm not an svn admin either, though - so best to get in touch with them and see how they usually do it :) A zipped up repository (assuming it's in fsfs format, not bdb) is just as easy for us to work with as a dumpfile, just means there's one more step for the infra person doing the job (usually me). The other thing we need is a list of the committers who have committed to the repos in question and the mapping from their old username to their ASF username so we can convert the old svn:author revprops to match the new ASF usernames, for consistency. Once both of those are available, and all the paperwork (CLAs, software grants, etc) are sent in and acknowledged by the ASF secretary just file an INFRA Jira ticket to schedule things and we'll get it moving. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] - Ratify Tuscany PPMC vote to release SDO for Java M2 artifacts
Robert, thanks for your comments. I believe the tag issue is now resolved, by earlier notes on this thread. (http://mail-archives.apache.org/mod_mbox/incubator-general/200610.mbox/[EMAIL PROTECTED] ) The CCLA issue has also been resolved by jeremy boynes (http://www.mail-archive.com/tuscany-commits@ws.apache.org/msg00018.html ) The MANIFEST requirement is an unknown quantity to me, but I will investigate. For the most part the instances of files that you reference which do not have license headers are that way intentionally since either they are generated or because they are present for verification of test execution, and must be equivalent to the data generated in the execution of the tests. This is true of all of the files in the test/resources hierarchy that don't have headers. There are some files that were in error in the samples hierarchy which I have fixed up in the trunk as you asked.I missed these when I ran rat against the source because we had a different source code structure at that time. The files in the model directory are generated and until now I had never looked inside them. If anything I I had assumed that thery were of a format that wouldn't take a comment. I see now that the .ecore file and the .genmodel files are generated XML. so i have added license headers to these two, but I can not modify the .mdl file without risking breaking it. I will investigate whether this file format has a comment syntax i can use to apply a header to the file. I looked at rearranging my source and binary distros in the way you suggested. The binary distro is the way it is (i.e. it unpacks into the working directory) because of maven assembly plugin defaults. I have tried to figure out how to reconfigure maven to put a base directory into the archive, but it wasn't obvious from the assembly plugin documentation and my attempts to play with the configuration failed. The issue I have over having a common base directory for the spec, impl and sample source distributions is that as I understand it the root directory of the distributions each need to contain a BUILDING.txt file. Having a common name for the root directory would cause one extraction to overwrite the contents of the first. I could move BUILDING.txt down to a 2nd level of directory, but that might not make it so obvious what to do with the archives. Any pointers as to how best to do this for the future would be most welcome, thanks. So the one remaining thing is the MANIFEST file issue. In the interest of expediting this release, would you be happy if I opened a JIRA for that issue and committed to resolve it before a further release? Best Regards, Kelvin. On 28/10/06, robert burrell donkin [EMAIL PROTECTED] wrote: On 10/25/06, kelvin goodson [EMAIL PROTECTED] wrote: The Tuscany PPMC has voted to release the SDO for Java API implementation as part of the M2 release. In accordance with Incubator release procedures we are asking the Incubator PMC to approve this release. reviewing http://people.apache.org/~kelvingoodson/sdo_java/RC5a/ http://people.apache.org/%7Ekelvingoodson/sdo_java/RC5a/ (since the email doesn't include the explicit reference) major --- no major issues there are a few minor questions that need clearing up in 'important' below. i'd be happy to see these issues resolved in the source without recutting the release provided that the provinance of these files is ok. (running RAT will give exact filenames.) important --- i can't find a tag in subversion. please take a tag next time (or explain your tag naming system if i've missed it). the files in http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/resources/ appear to be missing license headers. please conform that this is either an oversight or that they are generated. the status file is worrying: there are two CCLAs pending. please confirm that this is either an oversight or that these CCLAs are not pertinent to this material. MANIFESTs are missing Implementation-Vendor-Id (yes, i know it's a PITA and the various jarspecifications are a mess). best to add it if you can do so without too much pain. files in http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/model/ are missing license headers. please confirm that this was an oversight or provide a reason why they don't need them. a few files in http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/src/test/resources/ are missing license headers. please confirm that this was an oversight or provide a reason why they don't need them. stylistic the download directories are a bit of a hotch-potch. the binary unpacks to the current directory, sample unpacks to samples, sdo impl unpacks to sdo, sdo api to sdo-api. it's best to have a naming plan and stick to it. releases which unpack to the current directory irritate me (and many other users). i prefer the unpack to directories named after the release (this makes it easier to
Re: clarification on SF license and sandboxes
On 11/1/06, Craig L Russell [EMAIL PROTECTED] wrote: It's best practice to require that contributions be accompanied by the checkbox to grant the license. I haven't seen any official Apache policy guideline on this subject. Given that Bugzilla doesn't have such a thing - it would seem that it can't be that critical. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clarification on SF license and sandboxes
Given that there is a checkbox in JIRA, and the fact that this is confusing at least, could we get the checkbox removed, or the policy documented? Craig On Nov 1, 2006, at 4:11 PM, Henri Yandell wrote: On 11/1/06, Craig L Russell [EMAIL PROTECTED] wrote: It's best practice to require that contributions be accompanied by the checkbox to grant the license. I haven't seen any official Apache policy guideline on this subject. Given that Bugzilla doesn't have such a thing - it would seem that it can't be that critical. Hen - 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! smime.p7s Description: S/MIME cryptographic signature
Re: clarification on SF license and sandboxes
On 11/1/06, Craig L Russell [EMAIL PROTECTED] wrote: Given that there is a checkbox in JIRA, and the fact that this is confusing at least, could we get the checkbox removed, or the policy documented? The point of the checkbox is that if it's checked, you don't need to ask further. That Bugzilla doesn't have it means that we have to ask, which generally takes longer. Documenting the policy would be fine, but removing the checkbox would be a step backwards, IMO, especially since we specifically asked for it to be added. -- Martin Cooper Craig On Nov 1, 2006, at 4:11 PM, Henri Yandell wrote: On 11/1/06, Craig L Russell [EMAIL PROTECTED] wrote: It's best practice to require that contributions be accompanied by the checkbox to grant the license. I haven't seen any official Apache policy guideline on this subject. Given that Bugzilla doesn't have such a thing - it would seem that it can't be that critical. Hen - 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!
Re: [VOTE] Publish Yoko M1 release
+1 (non-binding) 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: clarification on SF license and sandboxes
Hi Martin, Thanks for your comments. They seem to contradict what Henri is saying. Can we continue this discussion until we reach some conclusion? Thanks, Craig On Nov 1, 2006, at 6:57 PM, Martin Cooper wrote: On 11/1/06, Craig L Russell [EMAIL PROTECTED] wrote: Given that there is a checkbox in JIRA, and the fact that this is confusing at least, could we get the checkbox removed, or the policy documented? The point of the checkbox is that if it's checked, you don't need to ask further. That Bugzilla doesn't have it means that we have to ask, which generally takes longer. Documenting the policy would be fine, but removing the checkbox would be a step backwards, IMO, especially since we specifically asked for it to be added. -- Martin Cooper Craig On Nov 1, 2006, at 4:11 PM, Henri Yandell wrote: On 11/1/06, Craig L Russell [EMAIL PROTECTED] wrote: It's best practice to require that contributions be accompanied by the checkbox to grant the license. I haven't seen any official Apache policy guideline on this subject. Given that Bugzilla doesn't have such a thing - it would seem that it can't be that critical. Hen - 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! 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! smime.p7s Description: S/MIME cryptographic signature
[STATUS] (incubator) Thu Nov 2 00:01:57 2006
APACHE INCUBATOR PROJECT STATUS: -*-indented-text-*- Last modified at [$Date: 2006-02-05 04:40:19 -0500 (Sun, 05 Feb 2006) $] Web site: http://Incubator.Apache.Org/ Wiki page: http://wiki.apache.org/incubator/ [note: the Web site is the 'official' documentation; the wiki pages are for collaborative development, including stuff destined for the Web site.] Pending Issues == o We need to be very very clear about what it takes to be accepted into the incubator. It should be a very low bar to leap, possibly not much more than 'no problematic code' and the existence of a healthy community (we don't want to become a dumping ground). o We need to be very very clear about what it takes for a podling to graduate from the incubator. The basic requirements obviously include: has a home, either as part of another ASF project or as a new top-level project of its own; needs to be a credit to the ASF and function well in the ASF framework; ... See also: https://issues.apache.org/jira/browse/INCUBATOR Resolved Issues === o The policy documentation does not need ratification of changes if there seems consensus. Accordingly, the draft status of these documents can be removed and we will use the lazy commit first, discuss later mode common across the ASF for documentation (http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=517190) o Coming up with a set of bylaws for the project (http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=517190) o All projects under incubation must maintain a status Web page that contains information the PMC needs about the project. (http://incubator.apache.org/guides/website.html) o Projects under incubation should display appropriate disclaimers so that it is clear that they are, indeed, under incubation (http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=504543) o Clearly and authoritatively document how to edit, generate, and update the Web site (three separate functions) (http://incubator.apache.org/guides/website.html). The Incubation Process == TODO: this does not belong in the STATUS file and probably was integrated into other documentation a while ago. That should be double-checked and then this section should be removed. This tries to list all the actions items that must be complete for a project before it can graduate from the incubator. It is probably incomplete. Identify the project to be incubated: -- Make sure that the requested project name does not already exist and check www.nameprotect.com to be sure that the name is not already trademarked for an existing software product. -- If request from an existing Apache project to adopt an external package, then ask the Apache project for the cvs module and mail address names. -- If request from outside Apache to enter an existing Apache project, then post a message to that project for them to decide on acceptance. -- If request from anywhere to become a stand-alone PMC, then assess the fit with the ASF, and create the lists and modules under the incubator address/module names if accepted. Interim responsibility: -- Who has been identified as the mentor for the incubation? -- Are they tracking progress on the project status Web page? Copyright: -- Have the papers that transfer rights to the ASF been received? It is only necessary to transfer rights for the package, the core code, and any new code produced by the project. -- Have the files been updated to reflect the new ASF copyright? Verify distribution rights: -- For all code included with the distribution that is not under the Apache license, do we have the right to combine with Apache-licensed code and redistribute? -- Is all source code distributed by the project covered by one or more of the following approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the same terms? Establish a list of active committers: -- Are all active committers listed in the project status file? -- Do they have accounts on cvs.apache.org? -- Have they submitted a contributors agreement? Infrastructure: -- CVS modules created and committers added to avail file? -- Mailing lists set up and archived? -- Problem tracking system (Bugzilla)? -- Has the project migrated to our infrastructure? Collaborative Development: -- Have all of the active long-term volunteers been identified and acknowledged as committers on the project? -- Are there three or more independent committers? [The legal definition of independent is long and boring, but basically it means that there is no binding relationship between the individuals, such as a
[VOTE] OFBiz Test Snapshot Release: 4.0.0 TS5
The OFBiz podling (PPMC and community) has reached a consensus internally approving the 4.0.0 TS5 test snapshot release. We are now requesting a vote for review and approval from the general Incubator group and the Incubator PMC. The current incubation docs recommend doing this sort of test snapshot release, and it appears from recent conversations that this will most likely soon be required for all podlings nearing graduation. Based on our experience this has been a valuable exercise and through these 5 tries we have made significant improvements to the legal and other aspects of OFBiz and eventual releases. You'll recognize most of this from the similar message I sent on September 22nd for our TS3. Thanks to feedback from various people (especially Robert Burrell Duncan and the RAT tool) we have corrected many license header issues and fleshed out the NOTICE file, which are now both hopefully up to par. The intent of this release is not to be something that will be maintained over time or used be end-users of the project, and there is no branch for it in SVN. Our goal with this test snapshot release was to create an initial release process and make sure that all of the artifacts are in place as needed. This includes: - all license headers and copyright notices in place (ASL2 headers) - no remaining old copyright notices or headers - NOTICE, LICENSE, KEYS, et cetera files in place - test proper zip and tgz files, plus the md5 and asc files for each - put README file and other such things in place to make it (hopefully) easy for an end user to run OOTB Based on what has been established as part of this test snapshot experience we plan to do a real release (version 4.0.0) after graduation with a branch and such that will be maintained over time and that is meant to be used by end-users, but those (again) are not the intents of this test snapshot release. The files for the release are available in my people.apache.org account, see the links below for detailed locations. -David http://people.apache.org/~jonesde/apache-ofbiz-incubating-4.0.0.TS5.zip http://people.apache.org/~jonesde/apache-ofbiz- incubating-4.0.0.TS5.zip.md5 http://people.apache.org/~jonesde/apache-ofbiz- incubating-4.0.0.TS5.zip.asc http://people.apache.org/~jonesde/apache-ofbiz-incubating-4.0.0.TS5.tgz http://people.apache.org/~jonesde/apache-ofbiz- incubating-4.0.0.TS5.tgz.md5 http://people.apache.org/~jonesde/apache-ofbiz- incubating-4.0.0.TS5.tgz.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to get a source OFBiz release WAS: [VOTE] OFBiz Test Snapshot Release: 4.0.0 TS5
Hi all, based on past comments in this list I'd like to add that this is a pre-built release (e.g. the objects and Derby demo database are already set up and packaged in the distribution); we did this because it can take up to 20 minutes (with slower hardware) to build the whole project from scratch and this could waste too much of your (and that of the persons that just want to give a look at it) time. However, if you want to play with a clean source distribution (for example, if you want to run the RAT tool etc...), just run the clean-all ant script: all the objects and the db will be removed. Jacopo David E Jones wrote: The OFBiz podling (PPMC and community) has reached a consensus internally approving the 4.0.0 TS5 test snapshot release. We are now requesting a vote for review and approval from the general Incubator group and the Incubator PMC. The current incubation docs recommend doing this sort of test snapshot release, and it appears from recent conversations that this will most likely soon be required for all podlings nearing graduation. Based on our experience this has been a valuable exercise and through these 5 tries we have made significant improvements to the legal and other aspects of OFBiz and eventual releases. You'll recognize most of this from the similar message I sent on September 22nd for our TS3. Thanks to feedback from various people (especially Robert Burrell Duncan and the RAT tool) we have corrected many license header issues and fleshed out the NOTICE file, which are now both hopefully up to par. The intent of this release is not to be something that will be maintained over time or used be end-users of the project, and there is no branch for it in SVN. Our goal with this test snapshot release was to create an initial release process and make sure that all of the artifacts are in place as needed. This includes: - all license headers and copyright notices in place (ASL2 headers) - no remaining old copyright notices or headers - NOTICE, LICENSE, KEYS, et cetera files in place - test proper zip and tgz files, plus the md5 and asc files for each - put README file and other such things in place to make it (hopefully) easy for an end user to run OOTB Based on what has been established as part of this test snapshot experience we plan to do a real release (version 4.0.0) after graduation with a branch and such that will be maintained over time and that is meant to be used by end-users, but those (again) are not the intents of this test snapshot release. The files for the release are available in my people.apache.org account, see the links below for detailed locations. -David http://people.apache.org/~jonesde/apache-ofbiz-incubating-4.0.0.TS5.zip http://people.apache.org/~jonesde/apache-ofbiz-incubating-4.0.0.TS5.zip.md5 http://people.apache.org/~jonesde/apache-ofbiz-incubating-4.0.0.TS5.zip.asc http://people.apache.org/~jonesde/apache-ofbiz-incubating-4.0.0.TS5.tgz http://people.apache.org/~jonesde/apache-ofbiz-incubating-4.0.0.TS5.tgz.md5 http://people.apache.org/~jonesde/apache-ofbiz-incubating-4.0.0.TS5.tgz.asc - 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]
incubator-info.txt?
Let me know if this should be on [EMAIL PROTECTED] I'd like to add a bit to David Reid's marvin script so it notifies Incubating subprojects that their reports are due. To do this I'd like to emulate the committers/board/committee-info.txt file with an incubator-info.txt file. At first I thought I'd just do a cut-down version of the file, but I think the whole file is worth cloning. 1) List of projects and chairs. In Incubator's case we'd replace chairs with notification emails. Currently I have the private@ addresses there. 2) Reporting Schedule. I'd replicate this entirely using the wiki page for the data. 3) List of PPMCs. I don't think we have anywhere where the list of PPMC members is defined. I'm not sure whether it should live within the incubator svn tree, or in the same direcory as committee-info.txt (for ease of use). Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IVY] setup of infrastructure
On 11/1/06, Garrett Rooney [EMAIL PROTECTED] wrote: On 11/1/06, Brett Porter [EMAIL PROTECTED] wrote: Usually, a dumpfile is used rather than a zipped up repository, I think. I would suggest locating an svn admin who can work with you to do a test now - so you'd dump the repository without locking it out, load it up into the test repository, check it works, so that you know what to do and minimise downtime of your commit access when you are ready to do the real thing. I'm not an svn admin either, though - so best to get in touch with them and see how they usually do it :) A zipped up repository (assuming it's in fsfs format, not bdb) is just as easy for us to work with as a dumpfile, just means there's one more step for the infra person doing the job (usually me). In our case using a dump file may be easier, because our svn repository wasn't properly setup: a unique repository for several projects, and no branches / tags / trunk / releases directories. So I will have to use svn admin tools on a dump file to get a clean repository with standard directories. So if a dumpfile is as easy to use for you as a zipped repository, I think I will send a dumpfile. The other thing we need is a list of the committers who have committed to the repos in question and the mapping from their old username to their ASF username so we can convert the old svn:author revprops to match the new ASF usernames, for consistency. OK, I'll send this list too when we'll be ready. Once both of those are available, and all the paperwork (CLAs, software grants, etc) are sent in and acknowledged by the ASF secretary just file an INFRA Jira ticket to schedule things and we'll get it moving. How can I know that the paperwork is ok? I've already sent my ICLA and the software grant, but I don't know if they were properly received and processed. Thanks for your time, - Xavier -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
