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=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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
