incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] S4 0.6.0 Incubating Release Candidate 3
Date Wed, 27 Mar 2013 21:59:19 GMT
On 27 March 2013 20:57, Matthieu Morel <mmorel@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 <mmorel@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.

>>
>> 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 N&L 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 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

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

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message