On Fri, Sep 6, 2013 at 4:16 PM, Aaron McCurry <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>
