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=12312322&version=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 no change is required. Can you confirm? > > 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? Kind of, we don't test on windows. > >> 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. OK, I didn't know that was a rule. > > 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 N&L files 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? > . > > RELEASE_NOTES.html does not have an AL header (nor is it valid HTML). > > Various s4-benchmarks/config/ files don't have AL headers. That was intentional, so we might just remove them. > > The logback.xml files don't have AL headers. OK > >>> >>>> >>>> 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? > > Probably not a requirement for a release, but the KEYS file is tricky > to read as it stands. > I cannot easily tell if your signing key is in there, for example. > > If you follow the sample commands in the header it will create the > header followed by the key. > > It should look something like > > http://www.apache.org/dist/abdera/KEYS > or > http://www.apache.org/dist/zookeeper/KEYS > > Or indeed > http://www.apache.org/dist/incubator/ambari/KEYS > or > http://www.apache.org/dist/incubator/wink/KEYS I updated the KEYS file following your recommendation. > >> >>> >>>> >>>> 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? > > If I were RM I would re-roll the release to fix that. > >> >> >> 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 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
