You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by Jacques Nadeau <ja...@apache.org> on 2014/08/31 21:19:49 UTC
[VOTE] Release Apache Drill version 0.5.0-incubating
Oops, correcting the subject.
On Sun, Aug 31, 2014 at 12:18 PM, Jacques Nadeau <ja...@apache.org> wrote:
> Hello All,
>
> I'd like to propose our second monthly release, version 0.5.0-incubating.
> This release includes 109 JIRAs closed [1].
>
> You can find the release artifacts hosted at [2]. Please download and try
> them out and cast your vote.
>
> As always, vote will be open for 72 hours, ending Noon Pacific, September
> 3, 2014.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> When making a vote, please make sure you state whether your vote is
> binding or not. This helps keep things simple.
>
> Thanks,
> Jacques
>
> [1] https://issues.apache.org/jira/browse/DRILL/fixforversion/12324880
> [2] http://people.apache.org/~jacques/apache-drill-0.5.0.rc0/
>
Re: [VOTE] Release Apache Drill version 0.5.0-incubating
Posted by Jacques Nadeau <ja...@apache.org>.
Wow, that's just brutal.
It looks like the fmpp maven build plugin has a "latest" dependency on
freemarker. And freemarker had a failed snapshot build today (yes, today).
See here:
https://oss.sonatype.org/content/repositories/snapshots/org/freemarker/freemarker/2.3.21-SNAPSHOT/
The latest snapshot, 20140831.213647-3, is missing the jar files.
I'm spinning a new build which freezes the fmpp behavior so that we don't
try to download the broken snapshot. Talk about one in a million...
New vote starting soon.
On Sun, Aug 31, 2014 at 9:49 PM, Yash Sharma <ya...@gmail.com> wrote:
> -1 (Non-binding)
>
> Unable to build from source. Is anyone else getting the same error?
>
>
>
> > Link contains source & binary distributions.
>
> > SRC Contains README, NOTICE, INSTALL.md, LICENSE Files.
>
> > BINARY tarball contains README, NOTICE, LECENSE Files.
>
> > Verified Checksums
> md5sum apache-drill-0.5.0-incubating-src.tar.gz
> 47e06d9cd174aeb61593a9d89dfc20c8
> 47e06d9cd174aeb61593a9d89dfc20c8
>
> sha1sum apache-drill-0.5.0-incubating-src.tar.gz
> 3bafe89fb19534978227bf28eae491f9496beb31
> 3bafe89fb19534978227bf28eae491f9496beb31
>
>
> md5sum apache-drill-0.5.0-incubating.tar.gz
> ad0a5746200c75fe58da31edb46f80f6
> ad0a5746200c75fe58da31edb46f80f6
>
> sha1sum apache-drill-0.5.0-incubating.tar.gz
> e98a9c881fa201ee4136ac7bc4628779806aae52
> e98a9c881fa201ee4136ac7bc4628779806aae52
>
>
> > Able to launch drill from binary distribution (Embeded mode).
> > Able to query using sqlline and web interface.
>
>
> > Unable to build from source
> $ mvn clean install -DskipTests
>
>
> [ERROR] Failed to execute goal
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate
> (generate-fmpp-sources) on project drill-java-exec: Execution
> generate-fmpp-sources of goal
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate failed:
> Plugin com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0 or one of its
> dependencies could not be resolved: Could not find artifact
> org.freemarker:freemarker:jar:2.3.21-20140831.213647-3 in
> sonatype-nexus-snapshots (
> https://oss.sonatype.org/content/repositories/snapshots)
>
>
> It references to freemarker:jar:2.3.21-20140831.213647-3
>
> whereas the pom has:
>
> <dependency>
> <groupId>org.freemarker</groupId>
> <artifactId>freemarker</artifactId>
> <version>2.3.19</version>
> </dependency>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Sep 1, 2014 at 12:49 AM, Jacques Nadeau <ja...@apache.org>
> wrote:
>
> > Oops, correcting the subject.
> >
> >
> > On Sun, Aug 31, 2014 at 12:18 PM, Jacques Nadeau <ja...@apache.org>
> > wrote:
> >
> > > Hello All,
> > >
> > > I'd like to propose our second monthly release, version
> 0.5.0-incubating.
> > > This release includes 109 JIRAs closed [1].
> > >
> > > You can find the release artifacts hosted at [2]. Please download and
> > try
> > > them out and cast your vote.
> > >
> > > As always, vote will be open for 72 hours, ending Noon Pacific,
> September
> > > 3, 2014.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > > When making a vote, please make sure you state whether your vote is
> > > binding or not. This helps keep things simple.
> > >
> > > Thanks,
> > > Jacques
> > >
> > > [1] https://issues.apache.org/jira/browse/DRILL/fixforversion/12324880
> > > [2] http://people.apache.org/~jacques/apache-drill-0.5.0.rc0/
> > >
> >
>
Re: [VOTE] Release Apache Drill version 0.5.0-incubating
Posted by Yash Sharma <ya...@gmail.com>.
-1 (Non-binding)
Unable to build from source. Is anyone else getting the same error?
> Link contains source & binary distributions.
> SRC Contains README, NOTICE, INSTALL.md, LICENSE Files.
> BINARY tarball contains README, NOTICE, LECENSE Files.
> Verified Checksums
md5sum apache-drill-0.5.0-incubating-src.tar.gz
47e06d9cd174aeb61593a9d89dfc20c8
47e06d9cd174aeb61593a9d89dfc20c8
sha1sum apache-drill-0.5.0-incubating-src.tar.gz
3bafe89fb19534978227bf28eae491f9496beb31
3bafe89fb19534978227bf28eae491f9496beb31
md5sum apache-drill-0.5.0-incubating.tar.gz
ad0a5746200c75fe58da31edb46f80f6
ad0a5746200c75fe58da31edb46f80f6
sha1sum apache-drill-0.5.0-incubating.tar.gz
e98a9c881fa201ee4136ac7bc4628779806aae52
e98a9c881fa201ee4136ac7bc4628779806aae52
> Able to launch drill from binary distribution (Embeded mode).
> Able to query using sqlline and web interface.
> Unable to build from source
$ mvn clean install -DskipTests
[ERROR] Failed to execute goal
com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate
(generate-fmpp-sources) on project drill-java-exec: Execution
generate-fmpp-sources of goal
com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate failed:
Plugin com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0 or one of its
dependencies could not be resolved: Could not find artifact
org.freemarker:freemarker:jar:2.3.21-20140831.213647-3 in
sonatype-nexus-snapshots (
https://oss.sonatype.org/content/repositories/snapshots)
It references to freemarker:jar:2.3.21-20140831.213647-3
whereas the pom has:
<dependency>
<groupId>org.freemarker</groupId>
<artifactId>freemarker</artifactId>
<version>2.3.19</version>
</dependency>
On Mon, Sep 1, 2014 at 12:49 AM, Jacques Nadeau <ja...@apache.org> wrote:
> Oops, correcting the subject.
>
>
> On Sun, Aug 31, 2014 at 12:18 PM, Jacques Nadeau <ja...@apache.org>
> wrote:
>
> > Hello All,
> >
> > I'd like to propose our second monthly release, version 0.5.0-incubating.
> > This release includes 109 JIRAs closed [1].
> >
> > You can find the release artifacts hosted at [2]. Please download and
> try
> > them out and cast your vote.
> >
> > As always, vote will be open for 72 hours, ending Noon Pacific, September
> > 3, 2014.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > When making a vote, please make sure you state whether your vote is
> > binding or not. This helps keep things simple.
> >
> > Thanks,
> > Jacques
> >
> > [1] https://issues.apache.org/jira/browse/DRILL/fixforversion/12324880
> > [2] http://people.apache.org/~jacques/apache-drill-0.5.0.rc0/
> >
>
Re: [VOTE] Release Apache Drill version 0.5.0-incubating
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Yeah, I've seen that. It is hard for podlings given the varying requirements.
I've gone through the same pain with many release candidates, so I do sympathise and I do try to give incubator projects a little leeway.
> While they provide some guidelines, they aren't as clear as I'd like
You can ask the incubator or legal for clarification and/or ask to modify anything that is unclear or inconsistent.
> Maybe we can remind people that even HTTPD and Tomcat projects produce binaries :D )
:-)
Thanks,
Justin
BTW I've tried the other projects do this defence in the past. Just note that the guidelines have changed and eveolved over time and some Apache projects have long histories and may not 100% compatible with current guidelines.
Re: [VOTE] Release Apache Drill version 0.5.0-incubating
Posted by Jacques Nadeau <ja...@apache.org>.
>
>
> > For points 3 & 4, I think you have a very conservative interpretation of
> Apache requirements which goes beyond the guidelines as well as what other
> projects do.
>
> I think you find the incubator (as a whole) has a more conservative view
> than me. While the vote in only officially on the source release,
> incubator people may look at the binary for NOTICE, LICENCE and Category
> B/Category X license issues. (See thread on UserGrid currently on general@).
> It up to you what you do but if you include Category B jars and don't
> prompt there's a risk the vote may not pass. If you want I can point out
> several projects that do it this way.
>
Yeah, I've seen that. It is hard for podlings given the varying
requirements. You never know for a certain release who is going to think
something is important that wasn't previously. But enough whining...
I want to reassure you that a number of people have read the documents
you've told us to follow. While they provide some guidelines, they aren't
as clear as I'd like and they are clearly inconsistent with what many
projects are doing.
I guess we'll put class-b jars into a separate directory. Given how
important binary distributions are to the community at large, and the
standard that others projects are achieving, hopefully we'll be able to
convince the general incubator list that we're achieving the spirit of the
Apache guidelines. (Maybe we can remind people that even HTTPD and Tomcat
projects produce binaries :D )
thanks again for your help,
Jacques
>
> Thanks,
> Justin
Re: [VOTE] Release Apache Drill version 0.5.0-incubating
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> 1. Do an audit of non classifed RAT files and verify that we aren't including other licenses.
May be easier to just add Apache headers to a few things.
> 2. Examine whether we are including unecessary license notices in the files (e.g. JUnit)
Yep.
> For points 3 & 4, I think you have a very conservative interpretation of Apache requirements which goes beyond the guidelines as well as what other projects do.
I think you find the incubator (as a whole) has a more conservative view than me. While the vote in only officially on the source release, incubator people may look at the binary for NOTICE, LICENCE and Category B/Category X license issues. (See thread on UserGrid currently on general@). It up to you what you do but if you include Category B jars and don't prompt there's a risk the vote may not pass. If you want I can point out several projects that do it this way.
Thanks,
Justin
Re: [VOTE] Release Apache Drill version 0.5.0-incubating
Posted by Jacques Nadeau <ja...@apache.org>.
Yeah, we're spinning another one shortly. Just waiting on Jason :)
Please test this one some. Would rather not have to recreate another
release and then find other issues.
On Tue, Sep 2, 2014 at 10:05 PM, Timothy Chen <tn...@gmail.com> wrote:
> I assume we're going to put up another RC? I'll wait to test the next
> one if that's the case.
>
> Tim
>
> On Tue, Sep 2, 2014 at 5:26 PM, Justin Mclean <ju...@classsoftware.com>
> wrote:
> > Hi,
> >
> >> I believe I have found the missing 9 files you spoke of in a directory
> of the project that has gone stale and is no longer is use.
> >
> > Sounds good.
> >
> >> I want to confirm that these are indeed the correct files before we
> move ahead with the next candidate. Is there a means by which you were able
> to generate these numbers of standards, apache licenses and missing license
> file counts over the whole project
> >
> > By running rat:
> > java -jar ~/apache-rat-0.11/apache-rat-0.11.jar
> ./apache-drill-0.5.0-incubating-src.tar.gz > rat.txt
> >
> >> , or did you have to use grep over the individual sub-projects' rat
> reports?
> >
> > I found the MIT licensed files via find after rat told me there were
> some potential issues.
> > find . -name "*.*" -exec grep "MIT License" {} \; -print
> >
> > Thanks,
> > Justin
> >
>
Re: [VOTE] Release Apache Drill version 0.5.0-incubating
Posted by Timothy Chen <tn...@gmail.com>.
I assume we're going to put up another RC? I'll wait to test the next
one if that's the case.
Tim
On Tue, Sep 2, 2014 at 5:26 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> I believe I have found the missing 9 files you spoke of in a directory of the project that has gone stale and is no longer is use.
>
> Sounds good.
>
>> I want to confirm that these are indeed the correct files before we move ahead with the next candidate. Is there a means by which you were able to generate these numbers of standards, apache licenses and missing license file counts over the whole project
>
> By running rat:
> java -jar ~/apache-rat-0.11/apache-rat-0.11.jar ./apache-drill-0.5.0-incubating-src.tar.gz > rat.txt
>
>> , or did you have to use grep over the individual sub-projects' rat reports?
>
> I found the MIT licensed files via find after rat told me there were some potential issues.
> find . -name "*.*" -exec grep "MIT License" {} \; -print
>
> Thanks,
> Justin
>
Re: [VOTE] Release Apache Drill version 0.5.0-incubating
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I believe I have found the missing 9 files you spoke of in a directory of the project that has gone stale and is no longer is use.
Sounds good.
> I want to confirm that these are indeed the correct files before we move ahead with the next candidate. Is there a means by which you were able to generate these numbers of standards, apache licenses and missing license file counts over the whole project
By running rat:
java -jar ~/apache-rat-0.11/apache-rat-0.11.jar ./apache-drill-0.5.0-incubating-src.tar.gz > rat.txt
> , or did you have to use grep over the individual sub-projects' rat reports?
I found the MIT licensed files via find after rat told me there were some potential issues.
find . -name "*.*" -exec grep "MIT License" {} \; -print
Thanks,
Justin
Re: [VOTE] Release Apache Drill version 0.5.0-incubating
Posted by Jason Altekruse <al...@gmail.com>.
Hello Justin,
I am doing an audit of the Drill source and binary releases to clean up the
dependencies and find the remaining missing licenses.
I believe I have found the missing 9 files you spoke of in a directory of
the project that has gone stale and is no longer is use. The 'sandbox'
directory has a number of files that do not match any of the individual
file filters (by extension), but they were being ignored from the RAT check
by a rule to exclude the whole folder. Removing this shows 9 unknown
licenses (several are just data files without an extension and a few are
old python scripts for a web UI not in use, several mention the apache
license but the format does not match what RAT is looking for)
I want to confirm that these are indeed the correct files before we move
ahead with the next candidate. Is there a means by which you were able to
generate these numbers of standards, apache licenses and missing license
file counts over the whole project, or did you have to use grep over the
individual sub-projects' rat reports?
I want to run the same check that you had earlier to ensure that deleting
this directory does make the numbers line up more appropriately.
-Jason Altekruse
On Tue, Sep 2, 2014 at 9:38 AM, Jacques Nadeau <ja...@apache.org> wrote:
> Thanks for the feedback. It is very helpful. It sounds like you think we
> should make four modifications:
>
> 1. Do an audit of non classifed RAT files and verify that we aren't
> including other licenses.
> 2. Examine whether we are including unecessary license notices in the files
> (e.g. JUnit)
> 3. Exclude class B binary artifacts or require active user consent to
> include them
> 4. Maintain separate directories for class B licenses when included.
>
> I think that you have good points in 1 & 2. I will open JIRAs to solve
> these.
>
> For points 3 & 4, I think you have a very conservative interpretation of
> Apache requirements which goes beyond the guidelines as well as what other
> projects do. For class B licenses [1]: "[class B licenses require] an
> explicit action by the user to get the reciprocally-licensed source". This
> seems to be specifically focused on source distribution, not binary
> artifacts. Since we don't bundle the source, we should be okay according
> to these guidelines.
>
> Additionally, I did a quick review of similar projects. For this review, I
> chose to look at the jersey-core artifact, something that falls under the
> CDDL license (class B). If I review the published artifacts for both
> Hadoop (2.5.0) and HBase (94.21), both include the binary artifact for this
> within their distribution, without special user consent and in the same
> directory as other binary artifacts that fall under class A licenses.
>
> Thanks again for your feedback. I think issues 1 & 2 above sink the rc1
> candidate so let's correct and roll another.
>
> Jacques
>
> [1] http://www.apache.org/legal/3party.html
>
>
> On Mon, Sep 1, 2014 at 6:16 PM, Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > Hi,
> >
> > Looks like the source LICENSE are missing the MIT and BSD bundled
> software.
> >
> > Can you list out what software is bundled into the source release that is
> > MIT or BSD licensed?
> >
> > From a quick search I see that these have MIT licenses:
> > ./contrib/native/client/src/clientlib/y2038/time64.c
> > ./contrib/native/client/src/clientlib/y2038/time64.h
> > ./contrib/native/client/src/clientlib/y2038/time64_config.h
> > ./contrib/native/client/src/clientlib/y2038/time64_limits.h
> >
> > It's hard to check the rat report as there over 300 files that don't have
> > headers, while most of these a json and the like it makes it hard to
> review
> > and know what's going on.
> >
> > From rat I get 1897 standards, 1569 Apache licensed and 315 unknown (or
> > missing) licenses. 1897 - 1569 - 315 = 13 files that have other licences.
> > I've only found 4 above, so what are the other 9 files?
> >
> > Just follow the instructions at [1] and your project mentors should be
> > able to help with this.
> >
> > The binary LICENSE and NOTICE look better, but I think they are still
> > including too much, for example the LICENSE states:
> >
> > "This product bundles JUnit (junit:junit:4.11 - http://junit.org)"
> >
> > Does it actually bundle jars or source code from JUnit or does it just
> > contain tests that are run by JUnit? If it bundles the JUnit jar does it
> > really need to?
> >
> > There's also (IMO) an issue with how you've bundleding CDDL, EPL and MPL
> > licensed software in the binary release, see Category B licenses at [2].
> > They need to be clearly marked and you need to prompt the user to accept
> > their license (or not include them in the binary if that's at all
> > possible). I would also put them in another directory separate form the
> > category A licensed binaries if they do need to be bundled.
> >
> > Thanks,
> > Justin
> >
> > 1. http://www.apache.org/dev/licensing-howto.html#permissive-deps
> > 2. http://www.apache.org/legal/3party.html
>
Re: [VOTE] Release Apache Drill version 0.5.0-incubating
Posted by Jacques Nadeau <ja...@apache.org>.
Thanks for the feedback. It is very helpful. It sounds like you think we
should make four modifications:
1. Do an audit of non classifed RAT files and verify that we aren't
including other licenses.
2. Examine whether we are including unecessary license notices in the files
(e.g. JUnit)
3. Exclude class B binary artifacts or require active user consent to
include them
4. Maintain separate directories for class B licenses when included.
I think that you have good points in 1 & 2. I will open JIRAs to solve
these.
For points 3 & 4, I think you have a very conservative interpretation of
Apache requirements which goes beyond the guidelines as well as what other
projects do. For class B licenses [1]: "[class B licenses require] an
explicit action by the user to get the reciprocally-licensed source". This
seems to be specifically focused on source distribution, not binary
artifacts. Since we don't bundle the source, we should be okay according
to these guidelines.
Additionally, I did a quick review of similar projects. For this review, I
chose to look at the jersey-core artifact, something that falls under the
CDDL license (class B). If I review the published artifacts for both
Hadoop (2.5.0) and HBase (94.21), both include the binary artifact for this
within their distribution, without special user consent and in the same
directory as other binary artifacts that fall under class A licenses.
Thanks again for your feedback. I think issues 1 & 2 above sink the rc1
candidate so let's correct and roll another.
Jacques
[1] http://www.apache.org/legal/3party.html
On Mon, Sep 1, 2014 at 6:16 PM, Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> Looks like the source LICENSE are missing the MIT and BSD bundled software.
>
> Can you list out what software is bundled into the source release that is
> MIT or BSD licensed?
>
> From a quick search I see that these have MIT licenses:
> ./contrib/native/client/src/clientlib/y2038/time64.c
> ./contrib/native/client/src/clientlib/y2038/time64.h
> ./contrib/native/client/src/clientlib/y2038/time64_config.h
> ./contrib/native/client/src/clientlib/y2038/time64_limits.h
>
> It's hard to check the rat report as there over 300 files that don't have
> headers, while most of these a json and the like it makes it hard to review
> and know what's going on.
>
> From rat I get 1897 standards, 1569 Apache licensed and 315 unknown (or
> missing) licenses. 1897 - 1569 - 315 = 13 files that have other licences.
> I've only found 4 above, so what are the other 9 files?
>
> Just follow the instructions at [1] and your project mentors should be
> able to help with this.
>
> The binary LICENSE and NOTICE look better, but I think they are still
> including too much, for example the LICENSE states:
>
> "This product bundles JUnit (junit:junit:4.11 - http://junit.org)"
>
> Does it actually bundle jars or source code from JUnit or does it just
> contain tests that are run by JUnit? If it bundles the JUnit jar does it
> really need to?
>
> There's also (IMO) an issue with how you've bundleding CDDL, EPL and MPL
> licensed software in the binary release, see Category B licenses at [2].
> They need to be clearly marked and you need to prompt the user to accept
> their license (or not include them in the binary if that's at all
> possible). I would also put them in another directory separate form the
> category A licensed binaries if they do need to be bundled.
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/licensing-howto.html#permissive-deps
> 2. http://www.apache.org/legal/3party.html
Re: [VOTE] Release Apache Drill version 0.5.0-incubating
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Looks like the source LICENSE are missing the MIT and BSD bundled software.
Can you list out what software is bundled into the source release that is MIT or BSD licensed?
From a quick search I see that these have MIT licenses:
./contrib/native/client/src/clientlib/y2038/time64.c
./contrib/native/client/src/clientlib/y2038/time64.h
./contrib/native/client/src/clientlib/y2038/time64_config.h
./contrib/native/client/src/clientlib/y2038/time64_limits.h
It's hard to check the rat report as there over 300 files that don't have headers, while most of these a json and the like it makes it hard to review and know what's going on.
From rat I get 1897 standards, 1569 Apache licensed and 315 unknown (or missing) licenses. 1897 - 1569 - 315 = 13 files that have other licences. I've only found 4 above, so what are the other 9 files?
Just follow the instructions at [1] and your project mentors should be able to help with this.
The binary LICENSE and NOTICE look better, but I think they are still including too much, for example the LICENSE states:
"This product bundles JUnit (junit:junit:4.11 - http://junit.org)"
Does it actually bundle jars or source code from JUnit or does it just contain tests that are run by JUnit? If it bundles the JUnit jar does it really need to?
There's also (IMO) an issue with how you've bundleding CDDL, EPL and MPL licensed software in the binary release, see Category B licenses at [2]. They need to be clearly marked and you need to prompt the user to accept their license (or not include them in the binary if that's at all possible). I would also put them in another directory separate form the category A licensed binaries if they do need to be bundled.
Thanks,
Justin
1. http://www.apache.org/dev/licensing-howto.html#permissive-deps
2. http://www.apache.org/legal/3party.html