incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: [VOTE] Release Blur version 0.2.0-incubating
Date Mon, 09 Sep 2013 03:59:14 GMT
On Fri, Sep 6, 2013 at 4:16 PM, Aaron McCurry <amccurry@gmail.com> wrote:
> Thanks Patrick for reviewing!  I do have some questions.

NP. Happy to help and psyched to see it's getting close to a release!

> On Fri, Sep 6, 2013 at 6:38 PM, Patrick Hunt <phunt@apache.org> wrote:
>
>> Hi Aaron. Great first pass.
>>
>> I'm -1 at the moment. In general things look good however I noticed
>> the following issues
>>
>> 1) RAT identified a large number of files with licensing issues (see
>> attached)
>>
>> You can run the rat tool (http://creadur.apache.org/rat/) manually via:
>> java -jar ~/apache-rat-0.10/apache-rat-0.10.jar . > ../rat.txt
>> (run it on both your source and binary artifacts)
>>
>> I see that the RAT plugin is included in pom.xml, but for some reason
>> it's not being validated as part of the build? That should be fixed.
>>
>
> Ok, should I add an exclude for each of the 3rd party script (or script
> like) files in the exclude list?  Meaning things like jquery js and css
> files that are under a different license and should be accounted for in the
> LICENSE file.
>

Given you haven't removed anything from those files, and you've
accounted for them in the LICENSE I would say yes, it's ok to list
them as an exclude.

> Also since the docs/site/ in all generated by maven can I exclude those
> from rate as well?  Or do I need to setup a site header to add the license?
>  I assume there is a way to do that.
>

Generated files don't need. RAT output file mentions:

>>>> JavaDocs are generated and so license header is optional
>>>> Generated files do not required license headers

That said, a good rule of thumb is to include the boilerplate if
possible. I've found it's easier to include it than to answer the same
issue time and again. :-)


An aside - why do you need to distribute generated files in the source
artifact? Perhaps consider not committing/including them? (only in the
bin)

>
>>
>> 2) the many image files that are included (source artifact), are they
>> under compatible licenses? Or are they images the project created?
>>
>
> I will look into them.  I see that most of them are assets in the
> blur-console contrib, so I will have to defer to Chris Rohr on what they
> are and how they were created he is the expert there.  There are a couple
> in the docs that are screenshots that I created.
>

As long as you created them (not covered by some other license) you're
fine, I just wasn't sure.

>
>>
>> 3) your README should mention Apache prominently
>>
>> 4) the license/notice for the src repo looks ok. however the binary
>> has an issue. Binary releases are a pain to get right and maintain.
>> For example see section 4d from the apache license, as applied to
>> derivative works (you are including 3rd party code - i.e. jars):
>>
>>       (d) If the Work includes a "NOTICE" text file as part of its
>>           distribution, then any Derivative Works that You distribute must
>>           include a readable copy of the attribution notices contained
>>           within such NOTICE file, excluding those notices that do not
>>           pertain to any part of the Derivative Works, in at least one
>>           of the following places: ....
>>
>
> So just to clarify, for each derivative work that has a NOTICE file I need
> to include that NOTICE file in the blur binary artifact?  Can place the
> NOTICE file beside the jar in the lib directory?
>

Typically you would copy/paste the apropos NOTICE entries into your
NOTICE file. I know, it's a pain.

Have you looked at this? http://www.apache.org/dev/licensing-howto.html

>
>>
>> One way around this is if the jar you are including itself has the
>> NOTICE file - in the case of hadoop-core jar that's not the case and
>> you need to handle.
>>
>
> Does this mean if the jar that Blur depends on contains a NOTICE within it
> then it's handled?  Or am I just confused?

It should mean this, for that dependency, yes.

>
>
>>
>> 5) I would recommend naming the directory of the source artifact
>> distinct from the binary artifact. Perhaps
>> apache-blur-0.2.0-incubating-src and apache-blur-0.2.0-incubating
>> respectively. (optional though, just makes folks lives easier if they
>> d/l and extract both)
>>
>
> Agreed.
>
>
> Thanks again!

NP!

Patrick

PS. I also recommend naming the voting threads to include the RC
version (RC1, RC2, etc...) in the subject line as it helps to separate
the threads/votes and make them distinct, e.g. when you start the vote
on RC2 it will be more clear.


>
> Aaron
>
>>
>>
>> Patrick
>>
>> On Thu, Sep 5, 2013 at 9:45 PM, Aaron McCurry <amccurry@gmail.com> wrote:
>> > This is the first release candidate for Apache Blur, version
>> > 0.2.0-incubating.
>> >
>> > It fixes the following issues:
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12324255&styleName=Html&projectId=12313721
>> >
>> > *** Please download, test and vote by [3 working days after sending].
>> >
>> > Note that we are voting upon the source (tag), binaries are provided for
>> > convenience.
>> >
>> > Source and binary files:
>> > https://dist.apache.org/repos/dist/dev/incubator/blur/0.2.0-incubating/
>> >
>> > The tag to be voted upon:
>> >
>> https://git-wip-us.apache.org/repos/asf?p=incubator-blur.git;a=tag;h=5c177eb8c27bfd6238f31dc781043c9c29d69021
>> >
>> > Blur's KEYS file containing PGP keys we use to sign the release:
>> >
>> https://dist.apache.org/repos/dist/dev/incubator/blur/0.2.0-incubating/KEYS
>>

Mime
View raw message