Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Mon, Aug 20, 2012 at 5:30 PM, Dave Fisher dave2w...@comcast.net wrote: In my mind as an IPMC member and Apache Member, this is a source release VOTE with convenience binary artifacts. Thank you, Dave. I consider your statement to override the assertion on ooo-dev that binaries are part of the official release, and that suffices to address my concern about this specific VOTE: no ASF policy is being challenged. I withdraw my -1. Edge case and RAT check discussion at the bottom, if that balances your vote in either direction. I've read through a number of recent threads in the ooo-dev archives. It bothers me a bit that AFAICT the RAT report was not run prior to cutting the RC. As a freelance IPMC vote, I have few tools at my disposal to assess a release and I have to rely on the diligence of the PPMC with regards to IP integrity. In and of itself, RAT is just a helper, but whether it gets run is a heuristic. :) I wonder why Run RAT did not end up on a pre-release checklist anywhere. Please advise about whether you think the PPMC needs to respin the VOTE and/or the Artifacts in any way. * Sums and sigs look good for all 3 source archives. * All archives contain identical source files. * I could not find a version control tag for 3.4.1-rc2, but I was able to obtain the AOO34 branch at the specified revision 1372282; it was close, though seemingly not exact. The discrepancies are shown below. I don't believe this should block, but it would be nice to know why the differences exist. * I did not attempt to build and test, as I believe others have this covered. The one thing I want to follow up on is the outcome of the posthumous RAT audit: http://markmail.org/message/yrb4ujtj5s4poi5b ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar No idea. But it is test code, not needed for building. ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar Not needed for building. It is part of a test setup for testing Certification Revocation Lists. So for the last two we should verify license. If the license allows redistribution, then I think we're fine. If not, then we need to build a new src ZIP without them. If I hear that those files pass muster, I expect to vote +1. Marvin Humphrey marvin@smokey:~/Desktop/aoo341 $ gpg --verify aoo-3.4.1-incubating-src.tar.gz.asc gpg: Signature made Fri Aug 17 09:30:40 2012 PDT using RSA key ID 51B5FDE8 gpg: Good signature from Juergen Schnmidt j...@apache.org gpg: aka Juergen Schmidt jogischm...@googlemail.com gpg: aka Juergen Schmidt jogischm...@gmail.com gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: D09F B15F 1A24 768D DF1F A29C CFEE F316 51B5 FDE8 marvin@smokey:~/Desktop/aoo341 $ gpg --verify aoo-3.4.1-incubating-src.tar.bz2.asc gpg: Signature made Fri Aug 17 09:31:06 2012 PDT using RSA key ID 51B5FDE8 gpg: Good signature from Juergen Schnmidt j...@apache.org gpg: aka Juergen Schmidt jogischm...@googlemail.com gpg: aka Juergen Schmidt jogischm...@gmail.com gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: D09F B15F 1A24 768D DF1F A29C CFEE F316 51B5 FDE8 marvin@smokey:~/Desktop/aoo341 $ gpg --verify aoo-3.4.1-incubating-src.zip.asc gpg: Signature made Fri Aug 17 09:30:07 2012 PDT using RSA key ID 51B5FDE8 gpg: Good signature from Juergen Schnmidt j...@apache.org gpg: aka Juergen Schmidt jogischm...@googlemail.com gpg: aka Juergen Schmidt jogischm...@gmail.com gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: D09F B15F 1A24 768D DF1F A29C CFEE F316 51B5 FDE8 marvin@smokey:~/Desktop/aoo341 $ shasum -c aoo-3.4.1-incubating-src.tar.gz.sha256 aoo-3.4.1-incubating-src.tar.gz: OK marvin@smokey:~/Desktop/aoo341 $ shasum -c aoo-3.4.1-incubating-src.zip.sha256 aoo-3.4.1-incubating-src.zip: OK marvin@smokey:~/Desktop/aoo341 $ shasum -c aoo-3.4.1-incubating-src.tar.bz2.sha256 aoo-3.4.1-incubating-src.tar.bz2: OK marvin@smokey:~/Desktop/aoo341 $ openssl md5 aoo-3.4.1-incubating-src.tar.gz MD5(aoo-3.4.1-incubating-src.tar.gz)= 356b8441d3bb08ffbbd76798188e8853 marvin@smokey:~/Desktop/aoo341 $ cat aoo-3.4.1-incubating-src.tar.gz.md5 356b8441d3bb08ffbbd76798188e8853 aoo-3.4.1-incubating-src.tar.gz marvin@smokey:~/Desktop/aoo341 $ openssl md5 aoo-3.4.1-incubating-src.tar.bz2 MD5(aoo-3.4.1-incubating-src.tar.bz2)= 8768256bba577f4dd97ade0032e5f5d0 marvin@smokey:~/Desktop/aoo341 $ cat aoo-3.4.1-incubating-src.tar.bz2.md5 8768256bba577f4dd97ade0032e5f5d0 aoo-3.4.1-incubating-src.tar.bz2 marvin@smokey:~/Desktop/aoo341 $ openssl md5
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
Rob: I believe it is rather foolish to argue that Roy is incorrect. For starters, he wrote the Bylaws, and is well-versed in the intent of this Foundation. Second, the Foundation policies take precedence over third-party concepts, so whether you/OSI may define a binary as open source is wholly immaterial. And lastly, you cannot defer to most would disagree as the only authority is the Foundation, rather than most. -g On Aug 20, 2012 5:11 PM, Rob Weir robw...@apache.org wrote: On Mon, Aug 20, 2012 at 3:45 PM, Marvin Humphrey mar...@rectangular.com wrote: On Sat, Aug 18, 2012 at 5:24 AM, Andre Fischer awf@gmail.com wrote: [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating) [ ] 0 Don't care [ ] -1 Do not release this package because... -1 I object to the claim that the AOO binaries are officially part of this release: http://s.apache.org/ha We are officially voting on binaries as well and these are being inspected and these will be part of the official release. The policy I am basing my vote on is section 6.3 of the the ASF bylaws as interpreted by Roy Fielding: http://apache.org/foundation/bylaws.html#6.3 Each Project Management Committee shall be responsible for the active management of one or more projects identified by resolution of the Board of Directors which may include, without limitation, the creation or maintenance of open-source software for distribution to the public at no charge. http://s.apache.org/rk5 This issue is not open for discussion. It is is a mandate from the certificate of this foundation -- our agreement with the State of Delaware that I signed as incorporator. It is fundamental to our status as an IRS 501(c)3 charity. It is the key charter delegated by the board as part of every TLP resolution: charged with the creation and maintenance of open-source software ... for distribution at no charge to the public. Class files are not open source. Jar files filled with class files are not Actually, the bylaws do not define open source or software. So pick your definition. The industry standard was the OSI definition, or so I thought, which makes it clear that open source also includes binaries that are accompanied by source code, or where well-publicized means of obtaining the source code are given. See: http://opensource.org/osd.html I'd point out that the ALv2 applies to source as well as binaries. open source. The fact that they are derived from open source is applicable only to what we allow projects to be dependent upon, not what we vote on as a release package. Release votes are on verified open source artifacts. Binary packages are separate from source packages. One cannot vote to approve a release containing a mix of source and binary code because the binary is not open source and cannot be verified to be safe for release (even if it was derived from open source). Again, most would disagree with the assertion that binaries are not open source. Regards, -Rob I thought that was frigging obvious. Why do I need to write documentation to explain something that is fundamental to the open source definition? I intend to withdraw my -1 on clarification from those IPMC members casting +1 binding votes that this release VOTE is limited to the source release. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Aug 20, 2012 5:06 PM, Dave Fisher dave2w...@comcast.net wrote: On Aug 20, 2012, at 12:45 PM, Marvin Humphrey wrote: ... -1 I object to the claim that the AOO binaries are officially part of this release: ... I am not surprised at your response, but it is hard and unproductive to argue with Rob. This sounds like a problem that the PPMC needs to solve. (at a minimum, the term should be discuss; rarely should a healthy community argue, let alone concerns about unproductive discussions) -g
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On 8/21/12 8:14 AM, Marvin Humphrey wrote: On Mon, Aug 20, 2012 at 5:30 PM, Dave Fisher dave2w...@comcast.net wrote: In my mind as an IPMC member and Apache Member, this is a source release VOTE with convenience binary artifacts. Thank you, Dave. I consider your statement to override the assertion on ooo-dev that binaries are part of the official release, and that suffices to address my concern about this specific VOTE: no ASF policy is being challenged. I withdraw my -1. Edge case and RAT check discussion at the bottom, if that balances your vote in either direction. I've read through a number of recent threads in the ooo-dev archives. It bothers me a bit that AFAICT the RAT report was not run prior to cutting the RC. As a freelance IPMC vote, I have few tools at my disposal to assess a release and I have to rely on the diligence of the PPMC with regards to IP integrity. In and of itself, RAT is just a helper, but whether it gets run is a heuristic. :) I wonder why Run RAT did not end up on a pre-release checklist anywhere. Please advise about whether you think the PPMC needs to respin the VOTE and/or the Artifacts in any way. * Sums and sigs look good for all 3 source archives. * All archives contain identical source files. * I could not find a version control tag for 3.4.1-rc2, but I was able to obtain the AOO34 branch at the specified revision 1372282; it was close, though seemingly not exact. The discrepancies are shown below. I don't believe this should block, but it would be nice to know why the I can explain this because I prepared the source release. The binaries (MacOS) and the first build of the src release were made on clean source tree based on revision r1372282. After this I analyzed a potential further bugfix on the same tree. I made some debug output in 3 cxx files. But after deeper analysis we decided that we don't want include this fix in 3.4.1. The risk to break something else was to high and we postponed the fix to the next release. After this we recognize some problems with the RAT output. I deleted some svn generated *.rej files and built the src package again to clean up the RAT output. It seems that I have overseen the debug messages in the changed cxx files. I can easy repackage the src release on the same tree where I revert the local changes to revision 1372282. If we all agree I can easy exchange the src release packages with the new ones. differences exist. * I did not attempt to build and test, as I believe others have this covered. The one thing I want to follow up on is the outcome of the posthumous RAT audit: http://markmail.org/message/yrb4ujtj5s4poi5b ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar No idea. But it is test code, not needed for building. ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar Not needed for building. It is part of a test setup for testing Certification Revocation Lists. So for the last two we should verify license. If the license allows redistribution, then I think we're fine. If not, then we need to build a new src ZIP without them. If I hear that those files pass muster, I expect to vote +1. Both jars are checked in and this can be seen as mistake. The reason is that they are built by Netbeans projects and whoever checked in the code has checked in the dist folder as well. And a further mistake is that both project don't move the output in the output directory of the module. That is the default behaviour in all modules, generated output during the build process goes into the module output directory. For example: module_name/unxmacxi.pro/... The ant script that package the src release takes care of the output directories and exclude them. In this case the by mistake checked in jars are packed as well. This have to be fixed definitely and we have already started to fix it on trunk. See issues [1] and [2]. The question is if it is release critical or not at this point? I think it isn't because the jars are the output of 2 existing NetBeans projects that are part of the src release as well. And I would like to prevent if possible a new revision number because that means new binaries as well. I propose the following for this release: 1. revert the debug output in the 3 *.cxx files and repackage the src release based on r1372282 Cleanup for future releases on trunk. 2. Remove the 2 jars (the dist folder) from svn, adapt the projects to deliver the output in the module output directory 3. Check other binaries again and make the RAT exclude list more fine grained to document better for what reason the binaries have to be kept... Juergen [1] https://issues.apache.org/ooo/show_bug.cgi?id=120634 [2] https://issues.apache.org/ooo/show_bug.cgi?id=120635 Marvin Humphrey marvin@smokey:~/Desktop/aoo341 $ gpg --verify aoo-3.4.1-incubating-src.tar.gz.asc gpg:
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Tue, Aug 21, 2012 at 4:11 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 8/21/12 8:14 AM, Marvin Humphrey wrote: On Mon, Aug 20, 2012 at 5:30 PM, Dave Fisher dave2w...@comcast.net wrote: In my mind as an IPMC member and Apache Member, this is a source release VOTE with convenience binary artifacts. Thank you, Dave. I consider your statement to override the assertion on ooo-dev that binaries are part of the official release, and that suffices to address my concern about this specific VOTE: no ASF policy is being challenged. I withdraw my -1. Edge case and RAT check discussion at the bottom, if that balances your vote in either direction. I've read through a number of recent threads in the ooo-dev archives. It bothers me a bit that AFAICT the RAT report was not run prior to cutting the RC. As a freelance IPMC vote, I have few tools at my disposal to assess a release and I have to rely on the diligence of the PPMC with regards to IP integrity. In and of itself, RAT is just a helper, but whether it gets run is a heuristic. :) I wonder why Run RAT did not end up on a pre-release checklist anywhere. Please advise about whether you think the PPMC needs to respin the VOTE and/or the Artifacts in any way. * Sums and sigs look good for all 3 source archives. * All archives contain identical source files. * I could not find a version control tag for 3.4.1-rc2, but I was able to obtain the AOO34 branch at the specified revision 1372282; it was close, though seemingly not exact. The discrepancies are shown below. I don't believe this should block, but it would be nice to know why the I can explain this because I prepared the source release. The binaries (MacOS) and the first build of the src release were made on clean source tree based on revision r1372282. After this I analyzed a potential further bugfix on the same tree. I made some debug output in 3 cxx files. But after deeper analysis we decided that we don't want include this fix in 3.4.1. The risk to break something else was to high and we postponed the fix to the next release. After this we recognize some problems with the RAT output. I deleted some svn generated *.rej files and built the src package again to clean up the RAT output. It seems that I have overseen the debug messages in the changed cxx files. I can easy repackage the src release on the same tree where I revert the local changes to revision 1372282. If we all agree I can easy exchange the src release packages with the new ones. differences exist. * I did not attempt to build and test, as I believe others have this covered. The one thing I want to follow up on is the outcome of the posthumous RAT audit: http://markmail.org/message/yrb4ujtj5s4poi5b ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar No idea. But it is test code, not needed for building. ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar Not needed for building. It is part of a test setup for testing Certification Revocation Lists. So for the last two we should verify license. If the license allows redistribution, then I think we're fine. If not, then we need to build a new src ZIP without them. If I hear that those files pass muster, I expect to vote +1. Both jars are checked in and this can be seen as mistake. The reason is that they are built by Netbeans projects and whoever checked in the code has checked in the dist folder as well. And a further mistake is that both project don't move the output in the output directory of the module. That is the default behaviour in all modules, generated output during the build process goes into the module output directory. Or said otherwise, these two JAR's are built from ALv2-licensed source code, part of the source artifact distribution: ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar So we have license to distribute and no special notice is required. Apparently this redundancy was inherited from the initial code that came in via the Oracle SGA. We'll fix in the trunk. Regards, -Rob For example: module_name/unxmacxi.pro/... The ant script that package the src release takes care of the output directories and exclude them. In this case the by mistake checked in jars are packed as well. This have to be fixed definitely and we have already started to fix it on trunk. See issues [1] and [2]. The question is if it is release critical or not at this point? I think it isn't because the jars are the output of 2 existing NetBeans projects that are part of the src release as well. And I would like to prevent if possible a new revision number because that means new binaries as well. I propose the following for this release: 1. revert the debug output in the 3 *.cxx files and repackage the src
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On 18 August 2012 13:24, Andre Fischer awf@gmail.com wrote: Hi all, this is a call for vote on releasing the following candidate as Apache OpenOffice 3.4.1 (incubating). This will be the second incubator release for Apache OpenOffice after the 3.4 release with already more than 11 million downloads. This release candidate provides the following important key changes compared to the OpenOffice 3.4 release: (1) Five more translations: Finnish, British English, Khmer, Slovak, and Slovenian. (2) As of 2012/08/16, there were 69 verified issues that have been resolved. (Complete list at http://s.apache.org/Huv) (3) Update of the NOTICE file: it now properly mentions CoinMP as numerical equation solver. (3) Most external source archives are now downloaded from their project servers. For all of them exists a fallback at http://ooo-extras.apache-extras.org.codespot.com/files/. The Apache SVN repository is only used as secondary fallback and is not used in practice. It will be removed in the next release. For a detailed feature overview please see the release notes at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes. The release candidate artifacts (source release, as well as binary releases for 20 languages) and further information how to verify and review Apache OpenOffice 3.4.1 (incubating) can be found on the following wiki page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO3.4.1 Please vote on releasing this package as Apache OpenOffice 3.4.1 (incubating). I think the NOTICE file included in the source release is wrong. NOTICE files are for *required* notices only, and should be as short as possible, and should only relate to software that is actually included in the particular artifact in which they appear. There are several repeated instances of === This product includes software developed by The Apache Software Foundation (http://www.apache.org/). === There should only be one instance at the head of the file. The Tomcat (Tomcat? is that really included?) section mentions NSIS - is that really included? There are lots of other entries which look superfluous. It's vital that the NOTICE file only include *required* notices. If the binary builds include additional software, then their NL files need to include any required references. I think the NOTICE problems are serious enough to warrant a respin. The vote starts now and will be open until: Tuesday, August 21st: 2012-08-21 15pm UTC+2. The PPMC vote took already place on the public ooo-dev mailing list. There where 11 +1 votes including one IPMC member binding +1, 10 +1 votes fro PPMC members (this includes the one IPMC member), one +1 vote from a community member. No abstinations, no -1 votes. Vote thread: http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201208.mbox/%3C502B8FCD.4050100%40googlemail.com%3E The vote will be open for 3 days. [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating) [ ] 0 Don't care [ ] -1 Do not release this package because... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On 8/21/12 12:52 PM, sebb wrote: On 18 August 2012 13:24, Andre Fischer awf@gmail.com wrote: Hi all, this is a call for vote on releasing the following candidate as Apache OpenOffice 3.4.1 (incubating). This will be the second incubator release for Apache OpenOffice after the 3.4 release with already more than 11 million downloads. This release candidate provides the following important key changes compared to the OpenOffice 3.4 release: (1) Five more translations: Finnish, British English, Khmer, Slovak, and Slovenian. (2) As of 2012/08/16, there were 69 verified issues that have been resolved. (Complete list at http://s.apache.org/Huv) (3) Update of the NOTICE file: it now properly mentions CoinMP as numerical equation solver. (3) Most external source archives are now downloaded from their project servers. For all of them exists a fallback at http://ooo-extras.apache-extras.org.codespot.com/files/. The Apache SVN repository is only used as secondary fallback and is not used in practice. It will be removed in the next release. For a detailed feature overview please see the release notes at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes. The release candidate artifacts (source release, as well as binary releases for 20 languages) and further information how to verify and review Apache OpenOffice 3.4.1 (incubating) can be found on the following wiki page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO3.4.1 Please vote on releasing this package as Apache OpenOffice 3.4.1 (incubating). I think the NOTICE file included in the source release is wrong. NOTICE files are for *required* notices only, and should be as short as possible, and should only relate to software that is actually included in the particular artifact in which they appear. There are several repeated instances of === This product includes software developed by The Apache Software Foundation (http://www.apache.org/). === There should only be one instance at the head of the file. The Tomcat (Tomcat? is that really included?) section mentions NSIS - is that really included? There are lots of other entries which look superfluous. It's vital that the NOTICE file only include *required* notices. I can't argue about the exact content and the format how a NOTICE have to look like. No changes in the NOTICE file for the src release compared to AOO 3.4 We had many discussion on the NOTICE file for 3.4 and followed the advices of we got from these discussion The discussion took place on ooo-dev legal-discuss And you can find comments here on the list. If the binary builds include additional software, then their NL files need to include any required references. The binaries includes an aggregated NOTICE file where other included external software (category-b) is integrated. Here we added the COINMP stuff for the 3.4.1 release that was raised as feedback to 3.4. I think the NOTICE problems are serious enough to warrant a respin. mmh, I am unsure, the next time somebody else with a different view and opinion comes up and we have to change it again? Again we changed it according the advices we got for the AOO 3.4 release. Juergen The vote starts now and will be open until: Tuesday, August 21st: 2012-08-21 15pm UTC+2. The PPMC vote took already place on the public ooo-dev mailing list. There where 11 +1 votes including one IPMC member binding +1, 10 +1 votes fro PPMC members (this includes the one IPMC member), one +1 vote from a community member. No abstinations, no -1 votes. Vote thread: http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201208.mbox/%3C502B8FCD.4050100%40googlemail.com%3E The vote will be open for 3 days. [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating) [ ] 0 Don't care [ ] -1 Do not release this package because... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On 21.08.2012 12:52, sebb wrote: I think the NOTICE problems are serious enough to warrant a respin. This is an unreasonable request. The IPMC voted on the 3.4.0 release. The notice file has not changed between 3.4.0 and 3.4.1. How then do you justify this new requirement? It is not fair to the podling if the IPMC invents new requirements and reverses its own decisions for no apparent reason. This NOTICE issue certainly shouldn't be ground for vetoing a release. By the way, the same holds for binaries being included in the releases. The 3.4.0 release, with binaries, was approved. If the podling did not change its release procedures and policies and artefacts in the meantime, it's not reasonable to hold up what amounts to a security release solely based on the IPMC having screwed up the previous release vote. It is fair to require changes for the next release. It's not fair to use different criteria for two successive, essentially identical releases. (N.B.: I use the term essentially identical in the sense that, whilst some of the sources have changed, the overall structure of the release artefacts has not.) -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On 21/08/12 13:59, Branko Čibej wrote: On 21.08.2012 12:52, sebb wrote: I think the NOTICE problems are serious enough to warrant a respin. This is an unreasonable request. The IPMC voted on the 3.4.0 release. The notice file has not changed between 3.4.0 and 3.4.1. How then do you justify this new requirement? Let me offer some advice from somebody who has been where you are now. Please keep in mind that the ASF is a large, volunteer organization. The backs and forths you are seeing here are normal and probably can't be avoided in flat organization like this. This can be strange and/or frustrating to people who are either paid to do their Apache work, or who come from smaller organizations where it was easier to come to a decision. Try to keep a positive attitude, go with the flow, and become a part of the wider Apache community (not just your project). Help improve things where you see they are lacking. This community aspect is very important at Apache. As to the issue at hand, this is not a new requirement. The issue just wasn't spotted last time. Yes, that's annoying, but it can't be helped. The NOTICE and the LICENSE files are the most important files in your distribution, and you should make every effort to get them right. Sebb raises valid concerns that need to be addressed. Just trying to help here, so no flak my way please :-) BTW, I think AOO is doing an amazing job. I was not optimistic when the project came to Apache, and I'm amazed you are where you are now. Keep up the good work. --Thilo It is not fair to the podling if the IPMC invents new requirements and reverses its own decisions for no apparent reason. This NOTICE issue certainly shouldn't be ground for vetoing a release. By the way, the same holds for binaries being included in the releases. The 3.4.0 release, with binaries, was approved. If the podling did not change its release procedures and policies and artefacts in the meantime, it's not reasonable to hold up what amounts to a security release solely based on the IPMC having screwed up the previous release vote. It is fair to require changes for the next release. It's not fair to use different criteria for two successive, essentially identical releases. (N.B.: I use the term essentially identical in the sense that, whilst some of the sources have changed, the overall structure of the release artefacts has not.) -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote: On 21/08/12 13:59, Branko Čibej wrote: On 21.08.2012 12:52, sebb wrote: I think the NOTICE problems are serious enough to warrant a respin. This is an unreasonable request. The IPMC voted on the 3.4.0 release. The notice file has not changed between 3.4.0 and 3.4.1. How then do you justify this new requirement? Let me offer some advice from somebody who has been where you are now. Please keep in mind that the ASF is a large, volunteer organization. The backs and forths you are seeing here are normal and probably can't be avoided in flat organization like this. This can be strange and/or frustrating to people who are either paid to do their Apache work, or who come from smaller organizations where it was easier to come to a decision. Try to keep a positive attitude, go with the flow, and become a part of the wider Apache community (not just your project). Help improve things where you see they are lacking. This community aspect is very important at Apache. As to the issue at hand, this is not a new requirement. The issue just wasn't spotted last time. Yes, that's annoying, but it can't be helped. The NOTICE and the LICENSE files are the most important files in your distribution, and you should make every effort to get them right. Sebb raises valid concerns that need to be addressed. A suggested exercise at ApacheCon. Get a group of 20 Members, break them into groups of 5. Give each group an identical list of 3rd party dependencies and ask them to create a NOTICE file that expresses them. Give them 30 minutes. Compare the results. I'd bet any amount that all four NOTICE files will differ in substantive ways, and that there would be disagreement, both within the groups, and across the groups, on which was correct. -Rob Just trying to help here, so no flak my way please :-) BTW, I think AOO is doing an amazing job. I was not optimistic when the project came to Apache, and I'm amazed you are where you are now. Keep up the good work. --Thilo It is not fair to the podling if the IPMC invents new requirements and reverses its own decisions for no apparent reason. This NOTICE issue certainly shouldn't be ground for vetoing a release. By the way, the same holds for binaries being included in the releases. The 3.4.0 release, with binaries, was approved. If the podling did not change its release procedures and policies and artefacts in the meantime, it's not reasonable to hold up what amounts to a security release solely based on the IPMC having screwed up the previous release vote. It is fair to require changes for the next release. It's not fair to use different criteria for two successive, essentially identical releases. (N.B.: I use the term essentially identical in the sense that, whilst some of the sources have changed, the overall structure of the release artefacts has not.) -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Tue, Aug 21, 2012 at 9:24 AM, Rob Weir robw...@apache.org wrote: On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote: On 21/08/12 13:59, Branko Čibej wrote: On 21.08.2012 12:52, sebb wrote: I think the NOTICE problems are serious enough to warrant a respin. This is an unreasonable request. The IPMC voted on the 3.4.0 release. The notice file has not changed between 3.4.0 and 3.4.1. How then do you justify this new requirement? Let me offer some advice from somebody who has been where you are now. Please keep in mind that the ASF is a large, volunteer organization. The backs and forths you are seeing here are normal and probably can't be avoided in flat organization like this. This can be strange and/or frustrating to people who are either paid to do their Apache work, or who come from smaller organizations where it was easier to come to a decision. Try to keep a positive attitude, go with the flow, and become a part of the wider Apache community (not just your project). Help improve things where you see they are lacking. This community aspect is very important at Apache. As to the issue at hand, this is not a new requirement. The issue just wasn't spotted last time. Yes, that's annoying, but it can't be helped. The NOTICE and the LICENSE files are the most important files in your distribution, and you should make every effort to get them right. Sebb raises valid concerns that need to be addressed. this point has, in fact, been the subject of a long-standing debate in the IPMC. While I have the greatest respect for sebb, there are other members of this PMC for whom I also have great respect who have taken the opposite view -- that - within reason - flaws in these files can be noted and repaired for the next release. The situation at hand is complicated by the running graduation thread for AOO, since it seems to me to be reasonable to expect that these files have achieved a consensus state before graduation. However, that's just a thought on my part. A suggested exercise at ApacheCon. Get a group of 20 Members, break them into groups of 5. Give each group an identical list of 3rd party dependencies and ask them to create a NOTICE file that expresses them. Give them 30 minutes. Compare the results. I'd bet any amount that all four NOTICE files will differ in substantive ways, and that there would be disagreement, both within the groups, and across the groups, on which was correct. -Rob Just trying to help here, so no flak my way please :-) BTW, I think AOO is doing an amazing job. I was not optimistic when the project came to Apache, and I'm amazed you are where you are now. Keep up the good work. --Thilo It is not fair to the podling if the IPMC invents new requirements and reverses its own decisions for no apparent reason. This NOTICE issue certainly shouldn't be ground for vetoing a release. By the way, the same holds for binaries being included in the releases. The 3.4.0 release, with binaries, was approved. If the podling did not change its release procedures and policies and artefacts in the meantime, it's not reasonable to hold up what amounts to a security release solely based on the IPMC having screwed up the previous release vote. It is fair to require changes for the next release. It's not fair to use different criteria for two successive, essentially identical releases. (N.B.: I use the term essentially identical in the sense that, whilst some of the sources have changed, the overall structure of the release artefacts has not.) -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Tue, Aug 21, 2012 at 9:38 AM, Benson Margulies bimargul...@gmail.com wrote: On Tue, Aug 21, 2012 at 9:24 AM, Rob Weir robw...@apache.org wrote: On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote: On 21/08/12 13:59, Branko Čibej wrote: On 21.08.2012 12:52, sebb wrote: I think the NOTICE problems are serious enough to warrant a respin. This is an unreasonable request. The IPMC voted on the 3.4.0 release. The notice file has not changed between 3.4.0 and 3.4.1. How then do you justify this new requirement? Let me offer some advice from somebody who has been where you are now. Please keep in mind that the ASF is a large, volunteer organization. The backs and forths you are seeing here are normal and probably can't be avoided in flat organization like this. This can be strange and/or frustrating to people who are either paid to do their Apache work, or who come from smaller organizations where it was easier to come to a decision. Try to keep a positive attitude, go with the flow, and become a part of the wider Apache community (not just your project). Help improve things where you see they are lacking. This community aspect is very important at Apache. As to the issue at hand, this is not a new requirement. The issue just wasn't spotted last time. Yes, that's annoying, but it can't be helped. The NOTICE and the LICENSE files are the most important files in your distribution, and you should make every effort to get them right. Sebb raises valid concerns that need to be addressed. this point has, in fact, been the subject of a long-standing debate in the IPMC. While I have the greatest respect for sebb, there are other members of this PMC for whom I also have great respect who have taken the opposite view -- that - within reason - flaws in these files can be noted and repaired for the next release. The situation at hand is complicated by the running graduation thread for AOO, since it seems to me to be reasonable to expect that these files have achieved a consensus state before graduation. However, that's just a thought on my part. We're just running the community readiness graduation vote on ooo-dev right now. We're also discussing the composition of the PMC, drafting the charter on our wiki, looking toward nominating a Chair, etc. But no formal IPMC vote on graduation is underway. That will happen in due course. One option might be to agree that the NOTICE issues are not fatal to the purpose of a NOTICE file, and approve the release. But then have further discussion on it leading to changes in our trunk, and that could be a condition of graduation. -Rob A suggested exercise at ApacheCon. Get a group of 20 Members, break them into groups of 5. Give each group an identical list of 3rd party dependencies and ask them to create a NOTICE file that expresses them. Give them 30 minutes. Compare the results. I'd bet any amount that all four NOTICE files will differ in substantive ways, and that there would be disagreement, both within the groups, and across the groups, on which was correct. -Rob Just trying to help here, so no flak my way please :-) BTW, I think AOO is doing an amazing job. I was not optimistic when the project came to Apache, and I'm amazed you are where you are now. Keep up the good work. --Thilo It is not fair to the podling if the IPMC invents new requirements and reverses its own decisions for no apparent reason. This NOTICE issue certainly shouldn't be ground for vetoing a release. By the way, the same holds for binaries being included in the releases. The 3.4.0 release, with binaries, was approved. If the podling did not change its release procedures and policies and artefacts in the meantime, it's not reasonable to hold up what amounts to a security release solely based on the IPMC having screwed up the previous release vote. It is fair to require changes for the next release. It's not fair to use different criteria for two successive, essentially identical releases. (N.B.: I use the term essentially identical in the sense that, whilst some of the sources have changed, the overall structure of the release artefacts has not.) -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail:
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On 21/08/12 15:24, Rob Weir wrote: [...] A suggested exercise at ApacheCon. Get a group of 20 Members, break them into groups of 5. Give each group an identical list of 3rd party dependencies and ask them to create a NOTICE file that expresses them. Give them 30 minutes. Compare the results. I'd bet any amount that all four NOTICE files will differ in substantive ways, and that there would be disagreement, both within the groups, and across the groups, on which was correct. -Rob Sure. You can do the same exercise with 20 IBM lawyers with similar results. And still you need to get the approval of IBM legal. --Thilo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On 21 August 2012 14:38, Benson Margulies bimargul...@gmail.com wrote: On Tue, Aug 21, 2012 at 9:24 AM, Rob Weir robw...@apache.org wrote: On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote: On 21/08/12 13:59, Branko Čibej wrote: On 21.08.2012 12:52, sebb wrote: I think the NOTICE problems are serious enough to warrant a respin. This is an unreasonable request. The IPMC voted on the 3.4.0 release. The notice file has not changed between 3.4.0 and 3.4.1. How then do you justify this new requirement? Let me offer some advice from somebody who has been where you are now. Please keep in mind that the ASF is a large, volunteer organization. The backs and forths you are seeing here are normal and probably can't be avoided in flat organization like this. This can be strange and/or frustrating to people who are either paid to do their Apache work, or who come from smaller organizations where it was easier to come to a decision. Try to keep a positive attitude, go with the flow, and become a part of the wider Apache community (not just your project). Help improve things where you see they are lacking. This community aspect is very important at Apache. As to the issue at hand, this is not a new requirement. The issue just wasn't spotted last time. Yes, that's annoying, but it can't be helped. The NOTICE and the LICENSE files are the most important files in your distribution, and you should make every effort to get them right. Sebb raises valid concerns that need to be addressed. this point has, in fact, been the subject of a long-standing debate in the IPMC. While I have the greatest respect for sebb, there are other members of this PMC for whom I also have great respect who have taken the opposite view -- that - within reason - flaws in these files can be noted and repaired for the next release. There are two issues here: 1) whether the NOTICE file is correct 2) if not, whether the problems are such as to require a respin. I hope we are agreed that the NOTICE file is not correct. The reason I think that problems in NOTICE files are to be taken seriously is that the N (L) files are vital for our licensing. The situation at hand is complicated by the running graduation thread for AOO, since it seems to me to be reasonable to expect that these files have achieved a consensus state before graduation. However, that's just a thought on my part. A suggested exercise at ApacheCon. Get a group of 20 Members, break them into groups of 5. Give each group an identical list of 3rd party dependencies and ask them to create a NOTICE file that expresses them. Give them 30 minutes. Compare the results. I'd bet any amount that all four NOTICE files will differ in substantive ways, and that there would be disagreement, both within the groups, and across the groups, on which was correct. -Rob Just trying to help here, so no flak my way please :-) BTW, I think AOO is doing an amazing job. I was not optimistic when the project came to Apache, and I'm amazed you are where you are now. Keep up the good work. --Thilo It is not fair to the podling if the IPMC invents new requirements and reverses its own decisions for no apparent reason. This NOTICE issue certainly shouldn't be ground for vetoing a release. By the way, the same holds for binaries being included in the releases. The 3.4.0 release, with binaries, was approved. If the podling did not change its release procedures and policies and artefacts in the meantime, it's not reasonable to hold up what amounts to a security release solely based on the IPMC having screwed up the previous release vote. It is fair to require changes for the next release. It's not fair to use different criteria for two successive, essentially identical releases. (N.B.: I use the term essentially identical in the sense that, whilst some of the sources have changed, the overall structure of the release artefacts has not.) -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Tue, Aug 21, 2012 at 4:59 AM, Branko Čibej br...@apache.org wrote: It is fair to require changes for the next release. It's not fair to use different criteria for two successive, essentially identical releases. When the option to be fair exists, fair is great! With regards to my own vote, I'm going to try to apply Jukka's criteria on rights: http://markmail.org/message/jtj27kdlhvgocexg Personally I'm fine with things like missing license headers or partially incomplete license metadata (which sounds like is the case here), as long as those are just omissions that don't fundamentally affect our rights (or those of downstream users) to distribute the releases and as long as there's a commitment to fix such issues in time for the next release. Extraneous information in the NOTICE file imposes a burden on some downstream distributors and consumers. Thee is almost certainly room for improvement in the AOO NOTICE file, and we have made some progress towards a consensus on exactly what ought to be in NOTICE since the first incubating release of AOO -- though there is also considerable room for improvement in the ASF documentation with regards to NOTICE. :) However, is there anything about the NOTICE file in this AOO release candidate which affects _rights_, either our own or those of downstream users? I've looked through the file, and if that's the case, I don't see it. If sebb thinks a respin is merited, that's his call, and his review is a welcome contribution. However, considering how much effort it takes to spin up an AOO release, the good faith and substantial effort invested by the podling in assembling the NOTICE file in the first place, and the good record of the AOO podling in incorporating suggestions, my opinion is that a promise to incorporate any NOTICE revisions into trunk suffices and that a new RC is not required. In contrast, I am more concerned about extra files that were apparently inadvertently committed and were not caught by either the primary mechanism of PPMC members watching the commits list or by the last line of defense of running a RAT report prior to rolling the release. If files which are incompatible with our licensing end up in a distribution, that has the potential to affect _rights_. And what with AOO's history, there is a big target painted on the project and there is a conspicuous need to maintain absolute control over what ends up in releases. It looks like the late audit has revealed that those files are OK, but it feels like we might have dodged a bullet. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Tue, Aug 21, 2012 at 1:11 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 8/21/12 8:14 AM, Marvin Humphrey wrote: * I could not find a version control tag for 3.4.1-rc2, but I was able to obtain the AOO34 branch at the specified revision 1372282; it was close, though seemingly not exact. The discrepancies are shown below. I don't believe this should block, but it would be nice to know why the I can explain this because I prepared the source release. The binaries (MacOS) and the first build of the src release were made on clean source tree based on revision r1372282. After this I analyzed a potential further bugfix on the same tree. I made some debug output in 3 cxx files. But after deeper analysis we decided that we don't want include this fix in 3.4.1. The risk to break something else was to high and we postponed the fix to the next release. After this we recognize some problems with the RAT output. I deleted some svn generated *.rej files and built the src package again to clean up the RAT output. It seems that I have overseen the debug messages in the changed cxx files. I can easy repackage the src release on the same tree where I revert the local changes to revision 1372282. If we all agree I can easy exchange the src release packages with the new ones. Thank you for the thorough explanation. If I have understood you correctly, all files flagged by either RAT or by the check against the svn export of revision 1372282 have been accounted for and we have sufficient rights to distribute them. That being the case, in my view it is not necessary to roll a new RC. +1 to release. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Tue, Aug 21, 2012 at 11:01 AM, Marvin Humphrey mar...@rectangular.com wrote: On Tue, Aug 21, 2012 at 4:59 AM, Branko Čibej br...@apache.org wrote: It is fair to require changes for the next release. It's not fair to use different criteria for two successive, essentially identical releases. When the option to be fair exists, fair is great! With regards to my own vote, I'm going to try to apply Jukka's criteria on rights: http://markmail.org/message/jtj27kdlhvgocexg Personally I'm fine with things like missing license headers or partially incomplete license metadata (which sounds like is the case here), as long as those are just omissions that don't fundamentally affect our rights (or those of downstream users) to distribute the releases and as long as there's a commitment to fix such issues in time for the next release. Extraneous information in the NOTICE file imposes a burden on some downstream distributors and consumers. Thee is almost certainly room for improvement in the AOO NOTICE file, and we have made some progress towards a consensus on exactly what ought to be in NOTICE since the first incubating release of AOO -- though there is also considerable room for improvement in the ASF documentation with regards to NOTICE. :) However, is there anything about the NOTICE file in this AOO release candidate which affects _rights_, either our own or those of downstream users? I've looked through the file, and if that's the case, I don't see it. If sebb thinks a respin is merited, that's his call, and his review is a welcome contribution. However, considering how much effort it takes to spin up an AOO release, the good faith and substantial effort invested by the podling in assembling the NOTICE file in the first place, and the good record of the AOO podling in incorporating suggestions, my opinion is that a promise to incorporate any NOTICE revisions into trunk suffices and that a new RC is not required. In contrast, I am more concerned about extra files that were apparently inadvertently committed and were not caught by either the primary mechanism of PPMC members watching the commits list or by the last line of defense of running a RAT report prior to rolling the release. If files which are I did check on these JAR files, to see how they got into Subversion in the first place. They were checked in as part of the legacy project and brought over when we did the original svndump import of the project last June. So it would not have been found looking at commit logs. But you are right that this should have been found during the IP review and preparation of the AOO 3.4.0 release. I think the main error was in believing that since this was a minor maintenance release, with only a handful of carefully reviewed patches, and that since AOO 3.4.0 was thoroughly reviewed and approved, that we could concentrate our effort on reviewing the delta between the two releases. Of course, if we do this we'll never find pre-existing errors, and it is clear now that they can exist as well. What's the old saying? Every new class of users finds a new class of bugs. Regards, -Rob incompatible with our licensing end up in a distribution, that has the potential to affect _rights_. And what with AOO's history, there is a big target painted on the project and there is a conspicuous need to maintain absolute control over what ends up in releases. It looks like the late audit has revealed that those files are OK, but it feels like we might have dodged a bullet. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On 8/21/12 5:10 PM, Marvin Humphrey wrote: On Tue, Aug 21, 2012 at 1:11 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 8/21/12 8:14 AM, Marvin Humphrey wrote: * I could not find a version control tag for 3.4.1-rc2, but I was able to obtain the AOO34 branch at the specified revision 1372282; it was close, though seemingly not exact. The discrepancies are shown below. I don't believe this should block, but it would be nice to know why the I can explain this because I prepared the source release. The binaries (MacOS) and the first build of the src release were made on clean source tree based on revision r1372282. After this I analyzed a potential further bugfix on the same tree. I made some debug output in 3 cxx files. But after deeper analysis we decided that we don't want include this fix in 3.4.1. The risk to break something else was to high and we postponed the fix to the next release. After this we recognize some problems with the RAT output. I deleted some svn generated *.rej files and built the src package again to clean up the RAT output. It seems that I have overseen the debug messages in the changed cxx files. I can easy repackage the src release on the same tree where I revert the local changes to revision 1372282. If we all agree I can easy exchange the src release packages with the new ones. Thank you for the thorough explanation. If I have understood you correctly, all files flagged by either RAT or by the check against the svn export of revision 1372282 have been accounted for and we have sufficient rights to distribute them. That being the case, in my view it is not necessary to roll a new RC. exactly that is my understanding when I checked the sources. We always try to address concerns immediately. But we are also humans and no machines and can make errors or can oversee things. But as mentioned before we are happy to incorporate any kind of valuable feedback. The more detaield the feedback is and potential concerns are the better it is. And of course it is much easier to change things accordingly. We are still learning. +1 to release. Thanks Juergen Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote: On 21/08/12 13:59, Branko Čibej wrote: On 21.08.2012 12:52, sebb wrote: I think the NOTICE problems are serious enough to warrant a respin. This is an unreasonable request. The IPMC voted on the 3.4.0 release. The notice file has not changed between 3.4.0 and 3.4.1. How then do you justify this new requirement? Let me offer some advice from somebody who has been where you are now. To be clear: Branko is an IPMC mentor, and not part of the AOO community. And I do happen to agree with Benson (else-thread) that any NOTICE problems here do not require a respin. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Aug 21, 2012, at 8:01 AM, Marvin Humphrey wrote: On Tue, Aug 21, 2012 at 4:59 AM, Branko Čibej br...@apache.org wrote: It is fair to require changes for the next release. It's not fair to use different criteria for two successive, essentially identical releases. When the option to be fair exists, fair is great! With regards to my own vote, I'm going to try to apply Jukka's criteria on rights: http://markmail.org/message/jtj27kdlhvgocexg Personally I'm fine with things like missing license headers or partially incomplete license metadata (which sounds like is the case here), as long as those are just omissions that don't fundamentally affect our rights (or those of downstream users) to distribute the releases and as long as there's a commitment to fix such issues in time for the next release. Extraneous information in the NOTICE file imposes a burden on some downstream distributors and consumers. Thee is almost certainly room for improvement in the AOO NOTICE file, and we have made some progress towards a consensus on exactly what ought to be in NOTICE since the first incubating release of AOO -- though there is also considerable room for improvement in the ASF documentation with regards to NOTICE. :) However, is there anything about the NOTICE file in this AOO release candidate which affects _rights_, either our own or those of downstream users? I've looked through the file, and if that's the case, I don't see it. If sebb thinks a respin is merited, that's his call, and his review is a welcome contribution. However, considering how much effort it takes to spin up an AOO release, the good faith and substantial effort invested by the podling in assembling the NOTICE file in the first place, and the good record of the AOO podling in incorporating suggestions, my opinion is that a promise to incorporate any NOTICE revisions into trunk suffices and that a new RC is not required. Thanks. In contrast, I am more concerned about extra files that were apparently inadvertently committed and were not caught by either the primary mechanism of PPMC members watching the commits list Checking three of these jars - there were all part of the initial svn commit - r1162288 - Initial import of the old OOo hg repository tip revision. or by the last line of defense of running a RAT report prior to rolling the release. If files which are incompatible with our licensing end up in a distribution, that has the potential to affect _rights_. And what with AOO's history, there is a big target painted on the project and there is a conspicuous need to maintain absolute control over what ends up in releases. Thanks for your answer to Jürgen and your +1 to release. It looks like the late audit has revealed that those files are OK, but it feels like we might have dodged a bullet. Yes, but the shotgun was loaded with salt, so it just stings a little ;-) Regards, Dave Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Tue, Aug 21, 2012 at 11:26 AM, Greg Stein gst...@gmail.com wrote: On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote: On 21/08/12 13:59, Branko Čibej wrote: On 21.08.2012 12:52, sebb wrote: I think the NOTICE problems are serious enough to warrant a respin. This is an unreasonable request. The IPMC voted on the 3.4.0 release. The notice file has not changed between 3.4.0 and 3.4.1. How then do you justify this new requirement? Let me offer some advice from somebody who has been where you are now. To be clear: Branko is an IPMC mentor, and not part of the AOO community. Oops. I meant IPMC *member*. (and an ASF Member for a couple years) And I do happen to agree with Benson (else-thread) that any NOTICE problems here do not require a respin. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
The vote period for releasing Apache OpenOffice 3.4.1 (incubating) RC2 has concluded. The ballot passed. VOTE TALLY +1: IPMC members: +1 Marvin Humphrey +1 Dave Fisher +1 Jim Jagielski For reference see also the vote thread on ooo-dev http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201208.mbox/%3C5031F593.9010801%40gmail.com%3E Thank you for your support Juergen - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT][VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
sorry for posting it again but I forgot the RESULT tag in the subject On 8/21/12 5:29 PM, Jürgen Schmidt wrote: The vote period for releasing Apache OpenOffice 3.4.1 (incubating) RC2 has concluded. The ballot passed. VOTE TALLY +1: IPMC members: +1 Marvin Humphrey +1 Dave Fisher +1 Jim Jagielski For reference see also the vote thread on ooo-dev http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201208.mbox/%3C5031F593.9010801%40gmail.com%3E Thank you for your support Juergen - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On 21.08.2012 17:29, Greg Stein wrote: On Tue, Aug 21, 2012 at 11:26 AM, Greg Stein gst...@gmail.com wrote: On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote: On 21/08/12 13:59, Branko Čibej wrote: On 21.08.2012 12:52, sebb wrote: I think the NOTICE problems are serious enough to warrant a respin. This is an unreasonable request. The IPMC voted on the 3.4.0 release. The notice file has not changed between 3.4.0 and 3.4.1. How then do you justify this new requirement? Let me offer some advice from somebody who has been where you are now. To be clear: Branko is an IPMC mentor, and not part of the AOO community. Oops. I meant IPMC *member*. (and an ASF Member for a couple years) And I do happen to agree with Benson (else-thread) that any NOTICE problems here do not require a respin. (nod) I should've emphasized that I'm spamming ex-cathedra as an uninterested observer. :) -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Aug 21, 2012, at 4:59 AM, Branko Čibej wrote: On 21.08.2012 12:52, sebb wrote: I think the NOTICE problems are serious enough to warrant a respin. This is an unreasonable request. The IPMC voted on the 3.4.0 release. The notice file has not changed between 3.4.0 and 3.4.1. How then do you justify this new requirement? It is his opinion, not a requirement. It is not fair to the podling if the IPMC invents new requirements and reverses its own decisions for no apparent reason. This NOTICE issue certainly shouldn't be ground for vetoing a release. Nobody can veto a release. Even the board would require a majority vote, though root has the power to stop distribution. By the way, the same holds for binaries being included in the releases. The 3.4.0 release, with binaries, was approved. If the podling did not change its release procedures and policies and artefacts in the meantime, it's not reasonable to hold up what amounts to a security release solely based on the IPMC having screwed up the previous release vote. Of course it is reasonable to expect a podling to read and respect the release process. That's the point of doing the release with IPMC review. It is fair to require changes for the next release. It's not fair to use different criteria for two successive, essentially identical releases. (N.B.: I use the term essentially identical in the sense that, whilst some of the sources have changed, the overall structure of the release artefacts has not.) Fairness has nothing to do with it. These issues are all documented http://www.apache.org/dev/release.html http://www.apache.org/legal/src-headers.html#notice http://incubator.apache.org/guides/releasemanagement.html#best-practices-svn This is not a difficult task, but it does require practice to get right. Every RM on every project goes through this pain. Adherence is necessary to enable peer review. Peer review is necessary to enable volunteers to act on behalf of the ASF. Acting on behalf of the ASF is necessary for legal protection of the project contributors. We are teaching the project how to do an open source release without being held individually liable for the millions of things that might get one sued for making an open source release. Being half-assed about it would not be doing them a favor. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Sat, Aug 18, 2012 at 5:24 AM, Andre Fischer awf@gmail.com wrote: [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating) [ ] 0 Don't care [ ] -1 Do not release this package because... -1 I object to the claim that the AOO binaries are officially part of this release: http://s.apache.org/ha We are officially voting on binaries as well and these are being inspected and these will be part of the official release. The policy I am basing my vote on is section 6.3 of the the ASF bylaws as interpreted by Roy Fielding: http://apache.org/foundation/bylaws.html#6.3 Each Project Management Committee shall be responsible for the active management of one or more projects identified by resolution of the Board of Directors which may include, without limitation, the creation or maintenance of open-source software for distribution to the public at no charge. http://s.apache.org/rk5 This issue is not open for discussion. It is is a mandate from the certificate of this foundation -- our agreement with the State of Delaware that I signed as incorporator. It is fundamental to our status as an IRS 501(c)3 charity. It is the key charter delegated by the board as part of every TLP resolution: charged with the creation and maintenance of open-source software ... for distribution at no charge to the public. Class files are not open source. Jar files filled with class files are not open source. The fact that they are derived from open source is applicable only to what we allow projects to be dependent upon, not what we vote on as a release package. Release votes are on verified open source artifacts. Binary packages are separate from source packages. One cannot vote to approve a release containing a mix of source and binary code because the binary is not open source and cannot be verified to be safe for release (even if it was derived from open source). I thought that was frigging obvious. Why do I need to write documentation to explain something that is fundamental to the open source definition? I intend to withdraw my -1 on clarification from those IPMC members casting +1 binding votes that this release VOTE is limited to the source release. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Aug 20, 2012, at 12:45 PM, Marvin Humphrey wrote: On Sat, Aug 18, 2012 at 5:24 AM, Andre Fischer awf@gmail.com wrote: [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating) [ ] 0 Don't care [ ] -1 Do not release this package because... -1 I object to the claim that the AOO binaries are officially part of this release: http://s.apache.org/ha We are officially voting on binaries as well and these are being inspected and these will be part of the official release. I am not surprised at your response, but it is hard and unproductive to argue with Rob. The policy I am basing my vote on is section 6.3 of the the ASF bylaws as interpreted by Roy Fielding: http://apache.org/foundation/bylaws.html#6.3 Each Project Management Committee shall be responsible for the active management of one or more projects identified by resolution of the Board of Directors which may include, without limitation, the creation or maintenance of open-source software for distribution to the public at no charge. http://s.apache.org/rk5 This issue is not open for discussion. It is is a mandate from the certificate of this foundation -- our agreement with the State of Delaware that I signed as incorporator. It is fundamental to our status as an IRS 501(c)3 charity. It is the key charter delegated by the board as part of every TLP resolution: charged with the creation and maintenance of open-source software ... for distribution at no charge to the public. Class files are not open source. Jar files filled with class files are not open source. The fact that they are derived from open source is applicable only to what we allow projects to be dependent upon, not what we vote on as a release package. Release votes are on verified open source artifacts. Binary packages are separate from source packages. One cannot vote to approve a release containing a mix of source and binary code because the binary is not open source and cannot be verified to be safe for release (even if it was derived from open source). I thought that was frigging obvious. Why do I need to write documentation to explain something that is fundamental to the open source definition? I intend to withdraw my -1 on clarification from those IPMC members casting +1 binding votes that this release VOTE is limited to the source release. My IPMC VOTE was done entirely by inspecting / unpacking the source release and building a MacOSX distro entirely from source. The package started fine. Comparisons to SVN and a RAT scan via the buildbot was accomplished. rat-excludes file has not been changed since before the prior 3.4.0 release, but please look at it to see if there is anything in there that is troublesome - there are some binary files but they are in example and test directories. Perhaps there are edge cases, but it is typical to have examples and unit tests that include binaries in other projects. There are some wildcard excludes that may be better as specific. I recommend that you do any RAT scan on Linux as there is trouble of some kind on MacOSX and Windows. Let us know if you think that this is beyond cups and saucers level. I did not consider the binary packages for multiple platforms and languages at all in my VOTE. Regards, Dave Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Mon, Aug 20, 2012 at 3:45 PM, Marvin Humphrey mar...@rectangular.com wrote: On Sat, Aug 18, 2012 at 5:24 AM, Andre Fischer awf@gmail.com wrote: [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating) [ ] 0 Don't care [ ] -1 Do not release this package because... -1 I object to the claim that the AOO binaries are officially part of this release: http://s.apache.org/ha We are officially voting on binaries as well and these are being inspected and these will be part of the official release. The policy I am basing my vote on is section 6.3 of the the ASF bylaws as interpreted by Roy Fielding: http://apache.org/foundation/bylaws.html#6.3 Each Project Management Committee shall be responsible for the active management of one or more projects identified by resolution of the Board of Directors which may include, without limitation, the creation or maintenance of open-source software for distribution to the public at no charge. http://s.apache.org/rk5 This issue is not open for discussion. It is is a mandate from the certificate of this foundation -- our agreement with the State of Delaware that I signed as incorporator. It is fundamental to our status as an IRS 501(c)3 charity. It is the key charter delegated by the board as part of every TLP resolution: charged with the creation and maintenance of open-source software ... for distribution at no charge to the public. Class files are not open source. Jar files filled with class files are not Actually, the bylaws do not define open source or software. So pick your definition. The industry standard was the OSI definition, or so I thought, which makes it clear that open source also includes binaries that are accompanied by source code, or where well-publicized means of obtaining the source code are given. See: http://opensource.org/osd.html I'd point out that the ALv2 applies to source as well as binaries. open source. The fact that they are derived from open source is applicable only to what we allow projects to be dependent upon, not what we vote on as a release package. Release votes are on verified open source artifacts. Binary packages are separate from source packages. One cannot vote to approve a release containing a mix of source and binary code because the binary is not open source and cannot be verified to be safe for release (even if it was derived from open source). Again, most would disagree with the assertion that binaries are not open source. Regards, -Rob I thought that was frigging obvious. Why do I need to write documentation to explain something that is fundamental to the open source definition? I intend to withdraw my -1 on clarification from those IPMC members casting +1 binding votes that this release VOTE is limited to the source release. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
Top-Post - you question is answered below. In my mind as an IPMC member and Apache Member, this is a source release VOTE with convenience binary artifacts. Edge case and RAT check discussion at the bottom, if that balances your vote in either direction. Please advise about whether you think the PPMC needs to respin the VOTE and/or the Artifacts in any way. Thanks Regards, Dave On Aug 20, 2012, at 2:06 PM, Dave Fisher wrote: On Aug 20, 2012, at 12:45 PM, Marvin Humphrey wrote: On Sat, Aug 18, 2012 at 5:24 AM, Andre Fischer awf@gmail.com wrote: [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating) [ ] 0 Don't care [ ] -1 Do not release this package because... -1 I object to the claim that the AOO binaries are officially part of this release: http://s.apache.org/ha We are officially voting on binaries as well and these are being inspected and these will be part of the official release. I am not surprised at your response, but it is hard and unproductive to argue with Rob. The policy I am basing my vote on is section 6.3 of the the ASF bylaws as interpreted by Roy Fielding: http://apache.org/foundation/bylaws.html#6.3 Each Project Management Committee shall be responsible for the active management of one or more projects identified by resolution of the Board of Directors which may include, without limitation, the creation or maintenance of open-source software for distribution to the public at no charge. http://s.apache.org/rk5 This issue is not open for discussion. It is is a mandate from the certificate of this foundation -- our agreement with the State of Delaware that I signed as incorporator. It is fundamental to our status as an IRS 501(c)3 charity. It is the key charter delegated by the board as part of every TLP resolution: charged with the creation and maintenance of open-source software ... for distribution at no charge to the public. Class files are not open source. Jar files filled with class files are not open source. The fact that they are derived from open source is applicable only to what we allow projects to be dependent upon, not what we vote on as a release package. Release votes are on verified open source artifacts. Binary packages are separate from source packages. One cannot vote to approve a release containing a mix of source and binary code because the binary is not open source and cannot be verified to be safe for release (even if it was derived from open source). I thought that was frigging obvious. Why do I need to write documentation to explain something that is fundamental to the open source definition? I intend to withdraw my -1 on clarification from those IPMC members casting +1 binding votes that this release VOTE is limited to the source release. My IPMC VOTE was done entirely by inspecting / unpacking the source release and building a MacOSX distro entirely from source. The package started fine. Comparisons to SVN and a RAT scan via the buildbot was accomplished. rat-excludes file has not been changed since before the prior 3.4.0 release, but please look at it to see if there is anything in there that is troublesome - there are some binary files but they are in example and test directories. Perhaps there are edge cases, but it is typical to have examples and unit tests that include binaries in other projects. There are some wildcard excludes that may be better as specific. I recommend that you do any RAT scan on Linux as there is trouble of some kind on MacOSX and Windows. Let us know if you think that this is beyond cups and saucers level. I did not consider the binary packages for multiple platforms and languages at all in my VOTE. Regards, Dave Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
Hi all, this is a call for vote on releasing the following candidate as Apache OpenOffice 3.4.1 (incubating). This will be the second incubator release for Apache OpenOffice after the 3.4 release with already more than 11 million downloads. This release candidate provides the following important key changes compared to the OpenOffice 3.4 release: (1) Five more translations: Finnish, British English, Khmer, Slovak, and Slovenian. (2) As of 2012/08/16, there were 69 verified issues that have been resolved. (Complete list at http://s.apache.org/Huv) (3) Update of the NOTICE file: it now properly mentions CoinMP as numerical equation solver. (3) Most external source archives are now downloaded from their project servers. For all of them exists a fallback at http://ooo-extras.apache-extras.org.codespot.com/files/. The Apache SVN repository is only used as secondary fallback and is not used in practice. It will be removed in the next release. For a detailed feature overview please see the release notes at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes. The release candidate artifacts (source release, as well as binary releases for 20 languages) and further information how to verify and review Apache OpenOffice 3.4.1 (incubating) can be found on the following wiki page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO3.4.1 Please vote on releasing this package as Apache OpenOffice 3.4.1 (incubating). The vote starts now and will be open until: Tuesday, August 21st: 2012-08-21 15pm UTC+2. The PPMC vote took already place on the public ooo-dev mailing list. There where 11 +1 votes including one IPMC member binding +1, 10 +1 votes fro PPMC members (this includes the one IPMC member), one +1 vote from a community member. No abstinations, no -1 votes. Vote thread: http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201208.mbox/%3C502B8FCD.4050100%40googlemail.com%3E The vote will be open for 3 days. [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating) [ ] 0 Don't care [ ] -1 Do not release this package because... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Aug 18, 2012, at 8:24 AM, Andre Fischer awf@gmail.com wrote: The vote will be open for 3 days. [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating) [ ] 0 Don't care [ ] -1 Do not release this package because... +1 (binding) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On 8/18/12 08:24 , Andre Fischer wrote: Hi all, this is a call for vote on releasing the following candidate as Apache OpenOffice 3.4.1 (incubating). This will be the second incubator release for Apache OpenOffice after the 3.4 release with already more than 11 million downloads. This release candidate provides the following important key changes compared to the OpenOffice 3.4 release: (1) Five more translations: Finnish, British English, Khmer, Slovak, and Slovenian. (2) As of 2012/08/16, there were 69 verified issues that have been resolved. (Complete list at http://s.apache.org/Huv) Do I actually need a bugzilla account to view the issue list? The above link directs me to a login screen... - richard (3) Update of the NOTICE file: it now properly mentions CoinMP as numerical equation solver. (3) Most external source archives are now downloaded from their project servers. For all of them exists a fallback at http://ooo-extras.apache-extras.org.codespot.com/files/. The Apache SVN repository is only used as secondary fallback and is not used in practice. It will be removed in the next release. For a detailed feature overview please see the release notes at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes. The release candidate artifacts (source release, as well as binary releases for 20 languages) and further information how to verify and review Apache OpenOffice 3.4.1 (incubating) can be found on the following wiki page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO3.4.1 Please vote on releasing this package as Apache OpenOffice 3.4.1 (incubating). The vote starts now and will be open until: Tuesday, August 21st: 2012-08-21 15pm UTC+2. The PPMC vote took already place on the public ooo-dev mailing list. There where 11 +1 votes including one IPMC member binding +1, 10 +1 votes fro PPMC members (this includes the one IPMC member), one +1 vote from a community member. No abstinations, no -1 votes. Vote thread: http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201208.mbox/%3C502B8FCD.4050100%40googlemail.com%3E The vote will be open for 3 days. [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating) [ ] 0 Don't care [ ] -1 Do not release this package because... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On 18.08.2012 17:53, Richard S. Hall wrote: On 8/18/12 08:24 , Andre Fischer wrote: Hi all, this is a call for vote on releasing the following candidate as Apache OpenOffice 3.4.1 (incubating). This will be the second incubator release for Apache OpenOffice after the 3.4 release with already more than 11 million downloads. This release candidate provides the following important key changes compared to the OpenOffice 3.4 release: (1) Five more translations: Finnish, British English, Khmer, Slovak, and Slovenian. (2) As of 2012/08/16, there were 69 verified issues that have been resolved. (Complete list at http://s.apache.org/Huv) Do I actually need a bugzilla account to view the issue list? The above link directs me to a login screen... It is a shared query. Please try this (slightly longer) link: https://issues.apache.org/ooo/buglist.cgi?f1=OPo3=equalslist_id=24324f0=OPv3=3.4.1_release_blocker%3Fquery_based_on=Resolved341ReleaseBlockero2=equalsf4=bug_severityquery_format=advancedj1=ORf3=flagtypes.namef2=flagtypes.namebug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDf5=CPf6=CPv2=3.4.1_release_blocker%2Bknown_name=Resolved341ReleaseBlocker -Andre - richard (3) Update of the NOTICE file: it now properly mentions CoinMP as numerical equation solver. (3) Most external source archives are now downloaded from their project servers. For all of them exists a fallback at http://ooo-extras.apache-extras.org.codespot.com/files/. The Apache SVN repository is only used as secondary fallback and is not used in practice. It will be removed in the next release. For a detailed feature overview please see the release notes at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes. The release candidate artifacts (source release, as well as binary releases for 20 languages) and further information how to verify and review Apache OpenOffice 3.4.1 (incubating) can be found on the following wiki page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO3.4.1 Please vote on releasing this package as Apache OpenOffice 3.4.1 (incubating). The vote starts now and will be open until: Tuesday, August 21st: 2012-08-21 15pm UTC+2. The PPMC vote took already place on the public ooo-dev mailing list. There where 11 +1 votes including one IPMC member binding +1, 10 +1 votes fro PPMC members (this includes the one IPMC member), one +1 vote from a community member. No abstinations, no -1 votes. Vote thread: http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201208.mbox/%3C502B8FCD.4050100%40googlemail.com%3E The vote will be open for 3 days. [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating) [ ] 0 Don't care [ ] -1 Do not release this package because... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org