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] Graduate Oozie podling from Apache Incubator
On Mon, Aug 20, 2012 at 10:04 PM, Alejandro Abdelnur t...@cloudera.com wrote: Please cast your votes: [X] +1 Graduate Oozie podling from Apache Incubator -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache DeltaSpike 0.3-incubating
+1 On Mon, Aug 20, 2012 at 3:47 PM, Mark Struberg strub...@yahoo.de wrote: Hi Folks! The deltaspike-0.3-incubating vote has internally passed with lots of +1. We have 2 IPMC +1 so far and like to ask for a tough review from fellow IPMCs. [+1] all fine, ship it [+0] I don't care but smells fine [-1] stop it, this stuff contains a blocker ${insertreason} The VOTE is open for 72h. txs and LieGrue, strub - Forwarded Message - From: Mark Struberg strub...@yahoo.de To: deltaspike-...@incubator.apache.org deltaspike-...@incubator.apache.org Cc: Sent: Monday, August 20, 2012 3:43 PM Subject: Re: [VOTE] [RESULT] Apache DeltaSpike 0.3-incubating T ime to tally the vote. +1: Mark Struberg (IPMC), Shane Bryzak, Gerhard Petracek (IPMC), Mehdi Heidarzadeh (nonbinding), Lincoln Baxter, Romain Manni-Buccau, Thomas Herzog (nonbinding), Cody Lerum, Arne Limburg, Charles Moulliard, Jason Porter, Ken Finnigan, Christian Kaltepoth, Antoine Sabot-Durand no -1 and no 0. I'll forward the vote mail for a rewiew to general@incubator. LieGrue, strub - Original Message - From: Mark Struberg strub...@yahoo.de To: deltaspike deltaspike-...@incubator.apache.org Cc: Sent: Wednesday, August 15, 2012 11:56 AM Subject: [VOTE] Apache DeltaSpike 0.3-incubating Hi! I like to call a VOTE on the Apache DeltaSpike 0.3-incubating release. The Maven staging repository: https://repository.apache.org/content/repositories/orgapachedeltaspike-010/ The source release package: https://repository.apache.org/content/repositories/orgapachedeltaspike-010/org/apache/deltaspike/deltaspike-project/0.3-incubating/ I've pushed the GIT release branch to my github account: https://github.com/struberg/incubator-deltaspike/tree/deltaspike-0.3-incubating (The branch will be pushed and merged to master after the VOTE passed.) The TAG can be found here: https://github.com/struberg/incubator-deltaspike/tree/deltaspike-project-0.3-incubating Please note: This VOTE is majority approval with a minimum of three +1votes of PPMC members. The VOTE is open for 72 hours. [+1] all fine, ship it [+0] I don't care but smells fine [-1] stop it, this stuff contains a blocker ${insertreason} LieGrue, strub - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache OpenOffice Community Graduation Vote
On Tue, Aug 21, 2012 at 5:30 AM, Benson Margulies bimargul...@gmail.com wrote: Officially, no Apache project has ever, ever, released a binary. Apache projects have published convenience binaries to accompany their releases, which have been, by definition, source Agreed - for the Flex podling the mentors have asked for a distinct binaries folder, see http://apache.org/dist/incubator/flex/4.8.0-incubating/ I think that's a good step, and it would be even better to add a README in there which points to an URL that explains the source/binary release thing. The best way to clarify that is to probably to create an issue at https://issues.apache.org/jira/browse/LEGAL and discuss on the legal-discuss list, where people from multiple projects that are affected by this can join. It's an ASF-wide issue, not an Incubator issue. -Bertrand (not volunteering - busy enough) - 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 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] Graduate Oozie podling from Apache Incubator
[X] +1 Graduate Oozie podling from Apache Incubator (binding) Regards, Arvind Prabhakar On Mon, Aug 20, 2012 at 10:25 AM, Alejandro Abdelnur t...@cloudera.comwrote: This is the second call for vote to graduate Oozie podling from Apache Incubator, comments and suggestions received during the first call have been addressed. Oozie entered the Incubator in July of 2011. Since then it has added two new committers and made two significant releases following the ASF policies and guidelines. The community of Oozie is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. Oozie community has voted to proceed with graduation [1] and the result can be found at [2]. Please cast your votes: [ ] +1 Graduate Oozie podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Oozie podling [ ] -1 Reject graduation of Oozie podling from Apache Incubator This vote will be open for at least 72 hours. Please find the proposed board resolution below. [1] http://s.apache.org/WDb [2] http://s.apache.org/AB2 Regards, Alejandro Abdelnur - X. Establish the Apache Oozie Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a system for managing and scheduling workflows that run different types of Hadoop jobs (such as MapReduce, Pig, Hive and Sqoop) as well as system specific jobs (such as Java programs and shell scripts) for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Oozie Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Oozie Project be and hereby is responsible for the creation and maintenance of software related to a system for managing and scheduling workflows that run different types of Hadoop jobs (such as MapReduce, Pig, Hive and Sqoop) as well as system specific jobs (such as Java programs and shell scripts); and be it further RESOLVED, that the office of Vice President, Apache Oozie be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Oozie Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Oozie Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Oozie Project: * Alan Gatesga...@apache.org * Alejandro Abdelnurt...@apache.org * Andreas Neumann a...@apache.org * Angelo Huang ange...@apache.org * Chao Wang broo...@apache.org * Chris Douglas cdoug...@apache.org * Devaraj Das d...@apache.org * Harsh Chouraria ha...@apache.org * Mayank Bansal may...@apache.org * Mohammad Islamkam...@apache.org * Virag Kothari vi...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Alejandro Abdelnur be appointed to the office of Vice President, Apache Oozie, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Oozie PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Oozie Project; and be it further RESOLVED, that the Apache Oozie Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Oozie podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Oozie podling encumbered upon the Apache Incubator Project are hereafter discharged.
Re: [VOTE] Apache OpenOffice Community Graduation Vote
On 8/21/12 12:03 AM, drew wrote: On Mon, 2012-08-20 at 13:32 -0700, Marvin Humphrey wrote: On Sun, Aug 19, 2012 at 8:53 AM, Rob Weir robw...@apache.org wrote: Per the IPMC's Guide to Successful Graduation [1] this is the optional, but recommended, community vote for us to express our willingness/readiness to govern ourselves. If this vote passes then we continue by drafting a charter, submitting it for IPMC endorsement, and then to the ASF Board for final approval. Details can be found in the Guide to Successful Graduation. Everyone in the community is encouraged to vote. Votes from PPMC members and Mentors are binding. This vote will run 72-hours. [ ] +1 Apache OpenOffice community is ready to graduate from the Apache Incubator. [ ] +0 Don't care. [ ] -1 Apache OpenOffice community is not ready to graduate from the Apache Incubator because... In my opinion, the issue of binary releases ought to be resolved before graduation. If the podling believes that ASF-endorsed binaries are a hard requirement, then it seems to me that the ASF is not yet ready for AOO and will not be until suitable infrastructure and legal institutions to support binary releases (sterile build machines, artifact signing, etc) have been created and a policy has been endorsed by the Board. One possibility discussed in the past was to have downstream commercial vendors release binaries a la Subversion's example, which would obviate the need for all the effort and risk associated with providing support for ASF-endorsed binaries. For whatever reason, the AOO podling seems not to have gone this direction, though. Marvin Humphrey Hi Marvin, Well, for myself, I don't have a problem with the AOO project not having official binary releases - in such a circumstance I would strongly prefer no binary release at all. As one of the active developers I would have a serious problem if we as project couldn't provide binary releases for our users. And I thought the ASF is a serious enough institution that can ensure to deliver binaries of these very popular end user oriented software and can of course protect the very valuable brand OpenOffice that the ASF now owns as well. The satisfaction of developers (at least my personal) is the fact that I work on a piece of software used by millions of users worldwide and these users require a binary version. And one of a trusted source and that is allowed to name it OpenOffice. I thought also that the ASF could leverage the brand in a way to generate more donations for the ASF and benefit even more from the overall success of the project. I know people who didn't know Apache before but now because of OpenOffice. Maybe worth to think about it! But I get ones more the impression that I am probably wrong. If the day should come that I will leave this project it will have nothing to do with the project itself. Juergen On the other hand if there is a binary release from the AOO project then I believe it should be treated as a fully endorsed action. One guys opinion. Thanks Drew Jensen AOO PPMC member - 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 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] Apache OpenOffice Community Graduation Vote
On Tue, Aug 21, 2012 at 11:54 AM, Jürgen Schmidt jogischm...@gmail.com wrote: ...As one of the active developers I would have a serious problem if we as project couldn't provide binary releases for our users. And I thought the ASF is a serious enough institution that can ensure to deliver binaries of these very popular end user oriented software and can of course protect the very valuable brand OpenOffice that the ASF now owns as well... As has been repeatedly mentioned in this thread and elsewhere, at the moment ASF releases consist of source code, not binaries. OTOH I don't think anybody said the ASF will never allow projects to distribute binaries - but people who want to do that need to get together (*) and come up with a proposal that's compatible with the ASF's goals and constraints, so that a clear policy can be set. A related discussion is ongoing on infra-dev [1] about signing artifacts, where we also have suggested that people get together and express their requirements in a constructive way instead of complaining. -Bertrand (*) Earlier in this thread, I have suggested using legal-discuss + LEGAL jira issues to manage this cross-project discussion. The pmcs@ alias + this list can be used to invite all projects and podlings to join such a discussion. [1] http://s.apache.org/signing_reqs - 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] Apache OpenOffice Community Graduation Vote
I would like to offer a very loud +1 to Bertrand's email. Here we are on a community graduation vote thread. This sub-discussion would seem to lead to one of three outcomes: 1) No place new. AOO proceeds out of the incubator operating under the current regime, and those AOO community members who are already engaged in discussions with infra and others about the preconditions for formal binary releases continue -- taking Bertrand's suggestion. 2) The community votes to stay in the incubator until a binary release plan exists. I can't see why this has any attraction for the community. 3) The community, or a subset thereof, takes their marbles and sets up shop in some other environment where binary releases are well-established. Before people start throwing things at me, I want to emphasize that (3) is offered only for completeness. If (1) is the order of the day, and an IPMC vote comes around soon, I'll be voting in favor of graduation. - 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:
[jira] [Commented] (PODLINGNAMESEARCH-12) Establish whether Apache Amber is a suitable name
[ https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438756#comment-13438756 ] Antonio Sanso commented on PODLINGNAMESEARCH-12: US Trademark Search http://www.trademarkia.com/trademarks-search.aspx?tn=amber Results include mainly chemical stuff, nothing seems to be software/computer related Establish whether Apache Amber is a suitable name --- Key: PODLINGNAMESEARCH-12 URL: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-12 Project: Podling Suitable Names Search Issue Type: Suitable Name Search Reporter: Antonio Sanso We have to do some investigations to ensure that Apache Amber is a suitable name for a TLP. Here are some resources related to this issue: http://incubator.apache.org/guides/names.html http://www.apache.org/foundation/marks/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - 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 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
[VOTE] [RESULT] Release Bigtop version 0.4.0
Thanks for voting. The vote passes as follows: +1 (binding): Tom White, Patrick Hunt Alan Gates +1 (non binding): Roman Shaposhnik, Konstantin Boudnik, Johnny Zhang, Anatoli Fomenko, Stephen Chu, Bruno Mahé No 0 or -1 votes were cast. I pushed the Maven repos, bits and the site out. The sync up should happen within the usual 24 hours. Thanks, Roman. On Fri, Aug 17, 2012 at 2:29 PM, Roman Shaposhnik r...@apache.org wrote: This is the fourth release for Apache Bigtop (incubating), version 0.4.0. This has been voted through on the bigtop-dev@incubator.a.o mailing list, and now requires a vote on general@incubator.a.o Votes already cast (on bigtop-dev): +1 (binding): Tom White, Patrick Hunt +1 (non binding): Roman Shaposhnik, Konstantin Boudnik, Johnny Zhang, Anatoli Fomenko, Stephen Chu, Bruno Mahé, It fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12318889styleName=HtmlprojectId=12311420 *** Please download, test and vote by Tue 08/21 noon PST Note that we are voting upon the source (tag) Source and binary files: http://people.apache.org/~rvs/bigtop-0.4.0-incubating-RC2 Maven staging repo: https://repository.apache.org/content/repositories/orgapachebigtop-132/ The tag to be voted upon: http://svn.apache.org/repos/asf/incubator/bigtop/tags/release-0.4.0-incubating-RC2 Bigtop's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/bigtop/dist/KEYS - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org