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