Re: [VOTE] S4 0.6.0 Incubating Release Candidate 3
Hello all, after getting valuable comments about our release candidate 3 for S4 0.6.0, we'd like to cut a new release candidate. However, we are still not sure about how to address the comments we received, and we cannot work on a new release candidate without understanding the proper actions to take. We are also a bit short on active mentors in the S4 podling, that's why I'm asking to the broader community. We have 2 key questions, which I reproduce below: 1/ about the content of LICENSE and NOTICE, is the following correct? - in the LICENSE file of the binary distribution, in addition to references to non-ASL included dependencies (already there), we need to reference all included dependencies that use ASL2, with the following statement: The Apache License, Version 2.0 applies to the following libraries: A, B, C - in the NOTICE file of the binary distribution, we add notices that dependency libraries explicitly ask for. That is already done and no change is required. 2/ about the inclusion of the gradle wrapper jar + script in the source distribution: We currently use gradle for building the project. Gradle provides a basic wrapper script so that the project can be built without installing gradle beforehand. That is why we include the script + wrapper lib. http://www.apache.org/legal/resolved.html#build-tools says that specific [build] tools have been OK'ed for inclusion in Apache distribution when used for that specific purpose [of building]. Should we exclude the gradle wrapper from our distribution? Thanks for bringing us lights here, if possible! Matthieu On Mar 28, 2013, at 18:15 , Matthieu Morel wrote: Thanks for your comments, Inline, I provide some explanations and ask for guidance on some topics. On Mar 27, 2013, at 22:59 , sebb wrote: On 27 March 2013 20:57, Matthieu Morel mmo...@apache.org wrote: Thanks for the feedback, I replied inline. On Mar 27, 2013, at 21:00 , sebb wrote: On 27 March 2013 19:07, Matthieu Morel mmo...@apache.org wrote: Hi everyone, this is a call for a vote to release Apache S4 0.6.0 incubating. A vote was held on developer mailing list and it passed for RC3 with 6+1's with 5 of them binding: +1 IPMC (phunt) +1PPMC (mmorel, kishoreg, leoneu, fpj) +1 committer non PPMC (dferro) Here is the vote thread on s4-dev: http://markmail.org/thread/n5totrx7jkh2nvzu This release fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312322version=12321702 Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary packages in zip format: http://people.apache.org/~mmorel/s4-0.6.0-incubating-release-candidate-3/ The (git) tag to be voted upon: 0.6.0-RC3: https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=tag;h=9b178170d76333579a9c56564dd060ccd173f115 NOTICE says: Apache S4 Copyright 2012 The Apache Software Foundation Have there been no substantive changes this year? I think you are reading from the master branch in the git repository. In our development process (https://issues.apache.org/jira/browse/S4-35) the master branch holds the released code, while the dev branch holds the code accepted for inclusion and that will be part of the next release. So we cut the release candidate from dev branch. The year in the NOTICE file is 2013. I followed the git link above that you provided, then clicked on tree. I don't know otherwise how to review the source tag. The tag 0.6.0-RC3 points to commit 96938d5afe060f8213f66b3269e6c846cfc045e3 If you use the web interface of the apache git site, in order to reach that commit from the provided link, you may either click on the commit id, on the tag, or on the commit link. gradlew and gradlew.bat don't have AL headers; nor does s4. The s4 file does have headers in the release artifacts. These also need to be added to the GIT copies; and the GIT tag must agree with the source files in the archive(s). By checking out from the git tag for the release and building the distribution (gradlew srcDist), we get the same content than the release candidate. In this case and for that file, isn't what we distribute properly licensed and matching the git tag? But we can certainly add the licensing to the s4 file itself. gradle/gradlew scripts to not have the ASL header because this is generated code. According to the RAT tool, generated code does not need to bear the license header. The RAT tool is just a tool, it does not make the rules. This issue was identified and discussed during the voting process on s4-dev mailing lis. For this release, it was considered valid to leave those generated files not annotated by one of our mentors. That may not have been the correct decision. As you commented to Patrick, there is doubt, so indeed better to add the header. I
Re: [VOTE] S4 0.6.0 Incubating Release Candidate 3
On Wed, Apr 3, 2013 at 11:10 AM, Matthieu Morel mmo...@apache.org wrote: Hey there, just back from vacation, hopefully Sebb can weigh in but here's my thinking: We have 2 key questions, which I reproduce below: 1/ about the content of LICENSE and NOTICE, is the following correct? - in the LICENSE file of the binary distribution, in addition to references to non-ASL included dependencies (already there), we need to reference all included dependencies that use ASL2, with the following statement: The Apache License, Version 2.0 applies to the following libraries: A, B, C - in the NOTICE file of the binary distribution, we add notices that dependency libraries explicitly ask for. That is already done and no change is required. Have you reviewed this section of the release guide? http://incubator.apache.org/guides/releasemanagement.html#best-practice-license Also the license howto was recently updated, a good test of the work done there: http://www.apache.org/dev/licensing-howto.html (see also: https://issues.apache.org/jira/browse/LEGAL-155) 2/ about the inclusion of the gradle wrapper jar + script in the source distribution: We currently use gradle for building the project. Gradle provides a basic wrapper script so that the project can be built without installing gradle beforehand. That is why we include the script + wrapper lib. http://www.apache.org/legal/resolved.html#build-tools says that specific [build] tools have been OK'ed for inclusion in Apache distribution when used for that specific purpose [of building]. Should we exclude the gradle wrapper from our distribution? I don't see any prior LEGAL issue mentioning gradle: https://issues.apache.org/jira/issues/?jql=project%20%3D%20LEGAL%20AND%20text%20~%20gradle however a number of other projects seem to depend on it, you should check what they are doing: https://issues.apache.org/jira/issues/?jql=text%20~%20%22gradle%22 Once you go through that process cut another RC and we'll see. Regards, Patrick On Mar 28, 2013, at 18:15 , Matthieu Morel wrote: Thanks for your comments, Inline, I provide some explanations and ask for guidance on some topics. On Mar 27, 2013, at 22:59 , sebb wrote: On 27 March 2013 20:57, Matthieu Morel mmo...@apache.org wrote: Thanks for the feedback, I replied inline. On Mar 27, 2013, at 21:00 , sebb wrote: On 27 March 2013 19:07, Matthieu Morel mmo...@apache.org wrote: Hi everyone, this is a call for a vote to release Apache S4 0.6.0 incubating. A vote was held on developer mailing list and it passed for RC3 with 6+1's with 5 of them binding: +1 IPMC (phunt) +1PPMC (mmorel, kishoreg, leoneu, fpj) +1 committer non PPMC (dferro) Here is the vote thread on s4-dev: http://markmail.org/thread/n5totrx7jkh2nvzu This release fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312322version=12321702 Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary packages in zip format: http://people.apache.org/~mmorel/s4-0.6.0-incubating-release-candidate-3/ The (git) tag to be voted upon: 0.6.0-RC3: https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=tag;h=9b178170d76333579a9c56564dd060ccd173f115 NOTICE says: Apache S4 Copyright 2012 The Apache Software Foundation Have there been no substantive changes this year? I think you are reading from the master branch in the git repository. In our development process (https://issues.apache.org/jira/browse/S4-35) the master branch holds the released code, while the dev branch holds the code accepted for inclusion and that will be part of the next release. So we cut the release candidate from dev branch. The year in the NOTICE file is 2013. I followed the git link above that you provided, then clicked on tree. I don't know otherwise how to review the source tag. The tag 0.6.0-RC3 points to commit 96938d5afe060f8213f66b3269e6c846cfc045e3 If you use the web interface of the apache git site, in order to reach that commit from the provided link, you may either click on the commit id, on the tag, or on the commit link. gradlew and gradlew.bat don't have AL headers; nor does s4. The s4 file does have headers in the release artifacts. These also need to be added to the GIT copies; and the GIT tag must agree with the source files in the archive(s). By checking out from the git tag for the release and building the distribution (gradlew srcDist), we get the same content than the release candidate. In this case and for that file, isn't what we distribute properly licensed and matching the git tag? But we can certainly add the licensing to the s4 file itself. gradle/gradlew scripts to not have the ASL header because this is generated code. According to the RAT tool, generated code does not need to bear the license header. The RAT tool is just a tool, it does
Re: [VOTE] S4 0.6.0 Incubating Release Candidate 3
Hi, Matthieu, It sounds like you folks are trying hard to get this right -- kudos! On Wed, Apr 3, 2013 at 11:10 AM, Matthieu Morel mmo...@apache.org wrote: 1/ about the content of LICENSE and NOTICE, is the following correct? - in the LICENSE file of the binary distribution, in addition to references to non-ASL included dependencies (already there), we need to reference all included dependencies that use ASL2, with the following statement: The Apache License, Version 2.0 applies to the following libraries: A, B, C I haven't reviewed the release candidate, but that description sounds fine. Some might argue that it's not necessary, but it doesn't hurt -- and if one of those libraries ever changes its license, the discrepancy should serve as a red flag for you to review and fix. - in the NOTICE file of the binary distribution, we add notices that dependency libraries explicitly ask for. That is already done and no change is required. That also sounds correct, assuming that your interpretation of notices that the dependency libraries explicitly ask for and what the dependency licenses actually require are in harmony. :) Hopefully the Licensing How-to gives you enough information to guide your choices. For BSD-3, MIT, and ALv2 dependencies, the requirements are reasonably straightforward. http://www.apache.org/dev/licensing-howto.html#permissive-deps The NOTICE requirements for other licenses are not yet documented by Apache Legal Affairs; this is an area where the ASF needs to do some work, so that our PMCs and PPMCs don't have to pore over licenses making judgment calls. 2/ about the inclusion of the gradle wrapper jar + script in the source distribution: We currently use gradle for building the project. Gradle provides a basic wrapper script so that the project can be built without installing gradle beforehand. That is why we include the script + wrapper lib. http://www.apache.org/legal/resolved.html#build-tools says that specific [build] tools have been OK'ed for inclusion in Apache distribution when used for that specific purpose [of building]. Should we exclude the gradle wrapper from our distribution? Since Gradle appears to be under the Apache License 2.0, the section on the build tools doesn't really come into play. That passage refers to certain tools with licenses which would ordinarily raise concerns. The rationale for not including the gradle wrapper jar file in the canonical source distribution is that a jar file is not source code. There was a discussion on this topic in March 2012 on general@; here's ASF Board member Roy Fielding: http://markmail.org/message/a4kbf33vn57dkz2j 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). Feel free to bundle ALv2 tools with the binary redistribution, or in a separate `-deps` package, though. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] S4 0.6.0 Incubating Release Candidate 3
On Wed, Mar 27, 2013 at 2:59 PM, sebb seb...@gmail.com wrote: On 27 March 2013 20:57, Matthieu Morel mmo...@apache.org wrote: On Mar 27, 2013, at 21:00 , sebb wrote: On 27 March 2013 19:07, Matthieu Morel mmo...@apache.org wrote: gradle/gradlew scripts to not have the ASL header because this is generated code. According to the RAT tool, generated code does not need to bear the license header. The RAT tool is just a tool, it does not make the rules. This issue was identified and discussed during the voting process on s4-dev mailing lis. For this release, it was considered valid to leave those generated files not annotated by one of our mentors. That may not have been the correct decision. Hi Sebb, I had originally -1'd the release due to the missing header on these generated files. I was going by my understanding of Apache guidelines, in particular http://incubator.apache.org/guides/releasemanagement.html#notes-license-headers and I generally follow that first paragraph - where ever possible add the header. I changed my vote based on the RAT output and then consulting the second paragraph in that on license headers section linked above, in particular Copyright may not subsist in a document which is generated by an transformation from an original. What's the correct decision here? Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] S4 0.6.0 Incubating Release Candidate 3
On 28 March 2013 07:40, Patrick Hunt ph...@apache.org wrote: On Wed, Mar 27, 2013 at 2:59 PM, sebb seb...@gmail.com wrote: On 27 March 2013 20:57, Matthieu Morel mmo...@apache.org wrote: On Mar 27, 2013, at 21:00 , sebb wrote: On 27 March 2013 19:07, Matthieu Morel mmo...@apache.org wrote: gradle/gradlew scripts to not have the ASL header because this is generated code. According to the RAT tool, generated code does not need to bear the license header. The RAT tool is just a tool, it does not make the rules. This issue was identified and discussed during the voting process on s4-dev mailing lis. For this release, it was considered valid to leave those generated files not annotated by one of our mentors. That may not have been the correct decision. Hi Sebb, I had originally -1'd the release due to the missing header on these generated files. I was going by my understanding of Apache guidelines, in particular http://incubator.apache.org/guides/releasemanagement.html#notes-license-headers and I generally follow that first paragraph - where ever possible add the header. I changed my vote based on the RAT output and then consulting the second paragraph in that on license headers section linked above, in particular Copyright may not subsist in a document which is generated by an transformation from an original. What's the correct decision here? If in doubt, add the AL header. Patrick - 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] S4 0.6.0 Incubating Release Candidate 3
Thanks for your comments, Inline, I provide some explanations and ask for guidance on some topics. On Mar 27, 2013, at 22:59 , sebb wrote: On 27 March 2013 20:57, Matthieu Morel mmo...@apache.org wrote: Thanks for the feedback, I replied inline. On Mar 27, 2013, at 21:00 , sebb wrote: On 27 March 2013 19:07, Matthieu Morel mmo...@apache.org wrote: Hi everyone, this is a call for a vote to release Apache S4 0.6.0 incubating. A vote was held on developer mailing list and it passed for RC3 with 6+1's with 5 of them binding: +1 IPMC (phunt) +1PPMC (mmorel, kishoreg, leoneu, fpj) +1 committer non PPMC (dferro) Here is the vote thread on s4-dev: http://markmail.org/thread/n5totrx7jkh2nvzu This release fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312322version=12321702 Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary packages in zip format: http://people.apache.org/~mmorel/s4-0.6.0-incubating-release-candidate-3/ The (git) tag to be voted upon: 0.6.0-RC3: https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=tag;h=9b178170d76333579a9c56564dd060ccd173f115 NOTICE says: Apache S4 Copyright 2012 The Apache Software Foundation Have there been no substantive changes this year? I think you are reading from the master branch in the git repository. In our development process (https://issues.apache.org/jira/browse/S4-35) the master branch holds the released code, while the dev branch holds the code accepted for inclusion and that will be part of the next release. So we cut the release candidate from dev branch. The year in the NOTICE file is 2013. I followed the git link above that you provided, then clicked on tree. I don't know otherwise how to review the source tag. The tag 0.6.0-RC3 points to commit 96938d5afe060f8213f66b3269e6c846cfc045e3 If you use the web interface of the apache git site, in order to reach that commit from the provided link, you may either click on the commit id, on the tag, or on the commit link. gradlew and gradlew.bat don't have AL headers; nor does s4. The s4 file does have headers in the release artifacts. These also need to be added to the GIT copies; and the GIT tag must agree with the source files in the archive(s). By checking out from the git tag for the release and building the distribution (gradlew srcDist), we get the same content than the release candidate. In this case and for that file, isn't what we distribute properly licensed and matching the git tag? But we can certainly add the licensing to the s4 file itself. gradle/gradlew scripts to not have the ASL header because this is generated code. According to the RAT tool, generated code does not need to bear the license header. The RAT tool is just a tool, it does not make the rules. This issue was identified and discussed during the voting process on s4-dev mailing lis. For this release, it was considered valid to leave those generated files not annotated by one of our mentors. That may not have been the correct decision. As you commented to Patrick, there is doubt, so indeed better to add the header. I did not bother to check the rest of the tree, but I assume there are other files which are missing their AL headers. The file config/binrelease/LICENSE includes various sentences like: This product uses kryo and minlog, which use the following license: I think that is wrong; the LICENSE and NOTICE files should ONLY include references to works that are *included* in the enclosing archive. If the binary product does not include the 3rd party products, then remove the LICENSE reference entirely. If it does *include* a 3rd party product, then change the LICENSE to say so, and check whether the 3rd party license requires attribution. In the binary release, we do include 3rd party products and the NOTICE and LICENSE files are updated accordingly, during the build process. You may check the binary release artifact. In that case, the wording is wrong; it should say includes, not uses. OK. I've now had a look at the binary lib/ directory, and there are a lot of 3rd party (non-ASF) jars there that don't appear to be mentioned in the LICENSE file. Even if they use AL 2.0, they need to be mentioned, but of course the AL 2.0 text does not need to be repeated. OK, so let me recap in order to make sure what we need: - in the LICENSE file of the binary distribution, in addition to references to non-ASL included dependencies (already there), we need to reference all included dependencies that use ASL2, with the following statement: The Apache License, Version 2.0 applies to the following libraries: A, B, C - in the NOTICE file of the binary distribution, we add notices that dependency libraries explicitely ask for. That is already done and
Re: [VOTE] S4 0.6.0 Incubating Release Candidate 3
On 27 March 2013 19:07, Matthieu Morel mmo...@apache.org wrote: Hi everyone, this is a call for a vote to release Apache S4 0.6.0 incubating. A vote was held on developer mailing list and it passed for RC3 with 6+1's with 5 of them binding: +1 IPMC (phunt) +1PPMC (mmorel, kishoreg, leoneu, fpj) +1 committer non PPMC (dferro) Here is the vote thread on s4-dev: http://markmail.org/thread/n5totrx7jkh2nvzu This release fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312322version=12321702 Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary packages in zip format: http://people.apache.org/~mmorel/s4-0.6.0-incubating-release-candidate-3/ The (git) tag to be voted upon: 0.6.0-RC3: https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=tag;h=9b178170d76333579a9c56564dd060ccd173f115 NOTICE says: Apache S4 Copyright 2012 The Apache Software Foundation Have there been no substantive changes this year? gradlew and gradlew.bat don't have AL headers; nor does s4. I did not bother to check the rest of the tree, but I assume there are other files which are missing their AL headers. The file config/binrelease/LICENSE includes various sentences like: This product uses kryo and minlog, which use the following license: I think that is wrong; the LICENSE and NOTICE files should ONLY include references to works that are *included* in the enclosing archive. If the binary product does not include the 3rd party products, then remove the LICENSE reference entirely. If it does *include* a 3rd party product, then change the LICENSE to say so, and check whether the 3rd party license requires attribution. S4 KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/s4/dist/KEYS The key entries don't have any human-readable headings, as required by the comments. For example: (gpg --list-sigs your name gpg --armor --export your name) this file. The --list-sigs command creates a readable header. We include a RAT check task. It requires to get - the .rat-excludes from the repository (https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=blob;f=.rat-excludes;h=fda230011164a53bd3089f9086c884918e0ea292;hb=refs/heads/dev) Why are the following excluded? logback.xml s4-checkstyle.xml s4-eclipse-format.xml XML supports header comments. - the rat jar from the repository It can be run with : ./gradlew rat output Please cast your vote, thanks! Vote will be open for 72 hours [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Matthieu - 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] S4 0.6.0 Incubating Release Candidate 3
Thanks for the feedback, I replied inline. On Mar 27, 2013, at 21:00 , sebb wrote: On 27 March 2013 19:07, Matthieu Morel mmo...@apache.org wrote: Hi everyone, this is a call for a vote to release Apache S4 0.6.0 incubating. A vote was held on developer mailing list and it passed for RC3 with 6+1's with 5 of them binding: +1 IPMC (phunt) +1PPMC (mmorel, kishoreg, leoneu, fpj) +1 committer non PPMC (dferro) Here is the vote thread on s4-dev: http://markmail.org/thread/n5totrx7jkh2nvzu This release fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312322version=12321702 Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary packages in zip format: http://people.apache.org/~mmorel/s4-0.6.0-incubating-release-candidate-3/ The (git) tag to be voted upon: 0.6.0-RC3: https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=tag;h=9b178170d76333579a9c56564dd060ccd173f115 NOTICE says: Apache S4 Copyright 2012 The Apache Software Foundation Have there been no substantive changes this year? I think you are reading from the master branch in the git repository. In our development process (https://issues.apache.org/jira/browse/S4-35) the master branch holds the released code, while the dev branch holds the code accepted for inclusion and that will be part of the next release. So we cut the release candidate from dev branch. The year in the NOTICE file is 2013. gradlew and gradlew.bat don't have AL headers; nor does s4. The s4 file does have headers in the release artifacts. gradle/gradlew scripts to not have the ASL header because this is generated code. According to the RAT tool, generated code does not need to bear the license header. This issue was identified and discussed during the voting process on s4-dev mailing lis. For this release, it was considered valid to leave those generated files not annotated by one of our mentors. I did not bother to check the rest of the tree, but I assume there are other files which are missing their AL headers. The file config/binrelease/LICENSE includes various sentences like: This product uses kryo and minlog, which use the following license: I think that is wrong; the LICENSE and NOTICE files should ONLY include references to works that are *included* in the enclosing archive. If the binary product does not include the 3rd party products, then remove the LICENSE reference entirely. If it does *include* a 3rd party product, then change the LICENSE to say so, and check whether the 3rd party license requires attribution. In the binary release, we do include 3rd party products and the NOTICE and LICENSE files are updated accordingly, during the build process. You may check the binary release artifact. In the source release, we do not include those products and the NOTICE and LICENSE files take that into account. S4 KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/s4/dist/KEYS The key entries don't have any human-readable headings, as required by the comments. For example: (gpg --list-sigs your name gpg --armor --export your name) this file. The --list-sigs command creates a readable header. I followed the instructions for signing apache releases http://www.apache.org/dev/release-signing.html and didn't see requirement for human readable headings in the KEYS file. (and didn't understand the comments were mandating that) If this is a requirement for the release, I suppose I can update the KEYS file in the subversion repository with the proper headers? We include a RAT check task. It requires to get - the .rat-excludes from the repository (https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=blob;f=.rat-excludes;h=fda230011164a53bd3089f9086c884918e0ea292;hb=refs/heads/dev) Why are the following excluded? logback.xml s4-checkstyle.xml s4-eclipse-format.xml XML supports header comments. There is no reason. Those files are for setting up the development environment and configuring the log output. Other xml files in the release do bear the ASL header. Is that blocking the release? I hope these explanations bring clarification. Regards, Matthieu - the rat jar from the repository It can be run with : ./gradlew rat output Please cast your vote, thanks! Vote will be open for 72 hours [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Matthieu - 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
Re: [VOTE] S4 0.6.0 Incubating Release Candidate 3
On 27 March 2013 20:57, Matthieu Morel mmo...@apache.org wrote: Thanks for the feedback, I replied inline. On Mar 27, 2013, at 21:00 , sebb wrote: On 27 March 2013 19:07, Matthieu Morel mmo...@apache.org wrote: Hi everyone, this is a call for a vote to release Apache S4 0.6.0 incubating. A vote was held on developer mailing list and it passed for RC3 with 6+1's with 5 of them binding: +1 IPMC (phunt) +1PPMC (mmorel, kishoreg, leoneu, fpj) +1 committer non PPMC (dferro) Here is the vote thread on s4-dev: http://markmail.org/thread/n5totrx7jkh2nvzu This release fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312322version=12321702 Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary packages in zip format: http://people.apache.org/~mmorel/s4-0.6.0-incubating-release-candidate-3/ The (git) tag to be voted upon: 0.6.0-RC3: https://git-wip-us.apache.org/repos/asf?p=incubator-s4.git;a=tag;h=9b178170d76333579a9c56564dd060ccd173f115 NOTICE says: Apache S4 Copyright 2012 The Apache Software Foundation Have there been no substantive changes this year? I think you are reading from the master branch in the git repository. In our development process (https://issues.apache.org/jira/browse/S4-35) the master branch holds the released code, while the dev branch holds the code accepted for inclusion and that will be part of the next release. So we cut the release candidate from dev branch. The year in the NOTICE file is 2013. I followed the git link above that you provided, then clicked on tree. I don't know otherwise how to review the source tag. gradlew and gradlew.bat don't have AL headers; nor does s4. The s4 file does have headers in the release artifacts. These also need to be added to the GIT copies; and the GIT tag must agree with the source files in the archive(s). gradle/gradlew scripts to not have the ASL header because this is generated code. According to the RAT tool, generated code does not need to bear the license header. The RAT tool is just a tool, it does not make the rules. This issue was identified and discussed during the voting process on s4-dev mailing lis. For this release, it was considered valid to leave those generated files not annotated by one of our mentors. That may not have been the correct decision. I did not bother to check the rest of the tree, but I assume there are other files which are missing their AL headers. The file config/binrelease/LICENSE includes various sentences like: This product uses kryo and minlog, which use the following license: I think that is wrong; the LICENSE and NOTICE files should ONLY include references to works that are *included* in the enclosing archive. If the binary product does not include the 3rd party products, then remove the LICENSE reference entirely. If it does *include* a 3rd party product, then change the LICENSE to say so, and check whether the 3rd party license requires attribution. In the binary release, we do include 3rd party products and the NOTICE and LICENSE files are updated accordingly, during the build process. You may check the binary release artifact. In that case, the wording is wrong; it should say includes, not uses. I've now had a look at the binary lib/ directory, and there are a lot of 3rd party (non-ASF) jars there that don't appear to be mentioned in the LICENSE file. Even if they use AL 2.0, they need to be mentioned, but of course the AL 2.0 text does not need to be repeated. It's helpful to include the version of the jar that is being included, because it can change between versions. The binary archive does not include gradlew.bat - is that intentional? In the source release, we do not include those products and the NOTICE and LICENSE files take that into account. That's good. But not so good are the names; one is LICENSE and the other is NOTICE.txt. The should both have a .txt extension or neither. Also the source archive contains the 3rd party library lib/gradle-wrapper-1.4.jar This is not mentioned in the LICENSE file (nor NOTICE.txt, but that may not be required). It seems strange to have a jar in a source library. Maybe that is a mistake, but if it is supposed to be there it needs to be reflected in the NL files. RELEASE_NOTES.html does not have an AL header (nor is it valid HTML). Various s4-benchmarks/config/ files don't have AL headers. The logback.xml files don't have AL headers. S4 KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/s4/dist/KEYS The key entries don't have any human-readable headings, as required by the comments. For example: (gpg --list-sigs your name gpg --armor --export your name) this file. The --list-sigs command creates a readable header. I followed the instructions for signing apache
