Re: [VOTE] Apache Drill 0.6.0-incubating release
This vote thread looks like a hanging chad. The current vote count is: +1 Ted +1 Lars +1 Justin +1 or -1: Grant -0 Jan I would love to have a clarification vote from Grant. I read his concern and the subsequent messages to mean +1 but I'm a bit biased as I'd like to see this release go out. Whatever the case, I suggest we give 24 hours for additional feedback and then finish the vote. If Grant does not clarify his stance, I propose that we ignore his ambiguous vote. Steven, how does that sound? thanks, Jacques On Tue, Oct 14, 2014 at 8:46 AM, Ted Dunning ted.dunn...@gmail.com wrote: On Tue, Oct 14, 2014 at 7:24 AM, sebb seb...@gmail.com wrote: If it contains sources, it's not a binary release. Not strictly true. Binary artifacts often contain source code examples. Also, for Drill specifically, the code generation strategy that Drill uses requires that snippets of source for different operators and system packaged UDF's will be in the binary release. The user has no clue about this source, much of which is machine generated from templates. From the user's point of view, however, it is a binary distro because they can download it and run Drill with no further build steps.
Re: [VOTE] Apache Drill 0.6.0-incubating release
This sounds good to me. On Sun, Oct 19, 2014 at 6:22 PM, Jacques Nadeau jacq...@apache.org wrote: This vote thread looks like a hanging chad. The current vote count is: +1 Ted +1 Lars +1 Justin +1 or -1: Grant -0 Jan I would love to have a clarification vote from Grant. I read his concern and the subsequent messages to mean +1 but I'm a bit biased as I'd like to see this release go out. Whatever the case, I suggest we give 24 hours for additional feedback and then finish the vote. If Grant does not clarify his stance, I propose that we ignore his ambiguous vote. Steven, how does that sound? thanks, Jacques On Tue, Oct 14, 2014 at 8:46 AM, Ted Dunning ted.dunn...@gmail.com wrote: On Tue, Oct 14, 2014 at 7:24 AM, sebb seb...@gmail.com wrote: If it contains sources, it's not a binary release. Not strictly true. Binary artifacts often contain source code examples. Also, for Drill specifically, the code generation strategy that Drill uses requires that snippets of source for different operators and system packaged UDF's will be in the binary release. The user has no clue about this source, much of which is machine generated from templates. From the user's point of view, however, it is a binary distro because they can download it and run Drill with no further build steps. -- Steven Phillips Software Engineer mapr.com
Re: [VOTE] Apache Drill 0.6.0-incubating release
On 13 October 2014 17:15, Branko Čibej br...@e-reka.si wrote: On 13.10.2014 16:14, Julian Hyde wrote: For many projects, especially library projects, the convenient binaries that matter most these days are the jars (source, binary, and javadoc) that are deployed to the maven repo. Calcite releases in fact do not currently include a binary tar ball, only a source tar ball and maven jars. Are these jars subjected to due diligence during the release vote? It seems to me that each of those jars is a de facto binary release. If it contains sources, it's not a binary release. Not strictly true. Binary artifacts often contain source code examples. Binary JARs are definitely a binary release. I haven't a clue what Javadocs are, but since they're derived from the sources, I'd prefer to put them in the binary category for simplicity. But that's beside the point. Convenience binaries are anything that was created from the properly voted-on and released source that did not go through the same formal release proces as the source release. If the PMC did not vote on the binary JARs, they are not an Apache Release and therefore none of our guarantees (or liabilities) can apply to them. However, if binary tarballs are distributed from the ASF mirroring system, then the principle of least suprise means that the contents must agree with the NOTICE and LICENSE files, and that the tarball does not contain code that is incompatible with the ALv2. Therefore I think such tarballs MUST be checked for such policy. Clearly the binary hashes and sigs MUST also be checked. -- Brane - 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
Re: [VOTE] Apache Drill 0.6.0-incubating release
On 13 October 2014 15:30, Bertrand Delacretaz bdelacre...@apache.org wrote: On Mon, Oct 13, 2014 at 4:14 PM, Julian Hyde julianh...@gmail.com wrote: For many projects, especially library projects, the convenient binaries that matter most these days are the jars (source, binary, and javadoc) that are deployed to the maven repo... ...Are these jars subjected to due diligence during the release vote?... In projects where I'm active there's reasonable due diligence as the build processes are automated in a way that allows you to trust the build if that's done by someone that you trust. Automated processes can produce incorrect output, even if applied correctly by experienced RMs. The packaging can pick up extraneous files (or omit them). [I have seen this happen on at least two projects.] So it is still important that the tarball contents are checked. That being said, we don't make any guarantees about those jars, so in the end users can either choose to trust the build and distribution process, or build the required jars themselves from a trusted source. I think we do guarantee that the jars we provide are ALv2 licensed (at least implicitly, if not explicitly). In the case of Maven, the ASF doesn't control the distribution process, so it's not a safe channel without signatures or trusted digests, and I don't think Maven allows for those at the moment. So even the best due diligence wouldn't really help for these binaries. -Bertrand - 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
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Tue, Oct 14, 2014 at 7:24 AM, sebb seb...@gmail.com wrote: If it contains sources, it's not a binary release. Not strictly true. Binary artifacts often contain source code examples. Also, for Drill specifically, the code generation strategy that Drill uses requires that snippets of source for different operators and system packaged UDF's will be in the binary release. The user has no clue about this source, much of which is machine generated from templates. From the user's point of view, however, it is a binary distro because they can download it and run Drill with no further build steps.
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Sat, Oct 11, 2014 at 11:52 PM, Justin Mclean jus...@classsoftware.com wrote: ...However votes on releases are more about the source release and binaries releases are just a convenience so I don't see that as a blocker... To clarify, the ASF only releases source code - votes on releases are not more about source, they are *only* about source. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
On 13 October 2014 10:06, Bertrand Delacretaz bdelacre...@apache.org wrote: On Sat, Oct 11, 2014 at 11:52 PM, Justin Mclean jus...@classsoftware.com wrote: ...However votes on releases are more about the source release and binaries releases are just a convenience so I don't see that as a blocker... To clarify, the ASF only releases source code - votes on releases are not more about source, they are *only* about source. I'm not sure I agree with that. If the ASF mirrors are used to distribute convenience binaries, AIUI these must still meet the following basic criteria: - sigs and hashes must be present - NOTICE LICENSE files must agree with the contents of the enclosing tarball - tarballs must not contain 3rd party artifacts with prohibited licenses Such things still need checking, surely? -Bertrand - 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
Re: [VOTE] Apache Drill 0.6.0-incubating release
Hi, On Mon, Oct 13, 2014 at 1:18 PM, sebb seb...@gmail.com wrote: ... If the ASF mirrors are used to distribute convenience binaries, AIUI these must still meet the following basic criteria... I tend to agree and wanted to make sure this is clearly documented, so I reread the following: https://issues.apache.org/jira/browse/LEGAL-155 http://www.apache.org/dev/licensing-howto.html I think the key point that the /dev page makes is that Any redistribution must obey the licensing requirements of the contents so you are right that our binary redistributions need to be checked as well, but as far as incubating projects are concerned it is IMO vital to get things right for the source releases first, and make sure podlings understand the difference between source code releases and convenience binaries. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Mon, Oct 13, 2014 at 7:51 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Any redistribution must obey the licensing requirements of the contents so you are right that our binary redistributions need to be checked as well, but as far as incubating projects are concerned it is IMO vital to get things right for the source releases first, and make sure podlings understand the difference between source code releases and convenience binaries. Based on recent discussion, a review of this distinction would be valuable for many at Apache.
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Mon, Oct 13, 2014 at 3:54 PM, Ted Dunning ted.dunn...@gmail.com wrote: On Mon, Oct 13, 2014 at 7:51 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: make sure podlings understand the difference between source code releases and convenience binaries. Based on recent discussion, a review of this distinction would be valuable for many at Apache. Aren't these pages sufficient for that? http://apache.org/dev/release.html (search for bina) http://www.apache.org/dev/licensing-howto.html#binary Otherwise I'd suggest adding an about convenience binaries section at http://apache.org/dev/release.html with a small set of relevant questions and answers. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
For many projects, especially library projects, the convenient binaries that matter most these days are the jars (source, binary, and javadoc) that are deployed to the maven repo. Calcite releases in fact do not currently include a binary tar ball, only a source tar ball and maven jars. Are these jars subjected to due diligence during the release vote? It seems to me that each of those jars is a de facto binary release. (Not that I think there is too little due diligence! We've been on the receiving end of a fair amount recently.) Julian On Oct 13, 2014, at 10:02 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Mon, Oct 13, 2014 at 3:54 PM, Ted Dunning ted.dunn...@gmail.com wrote: On Mon, Oct 13, 2014 at 7:51 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: make sure podlings understand the difference between source code releases and convenience binaries. Based on recent discussion, a review of this distinction would be valuable for many at Apache. Aren't these pages sufficient for that? http://apache.org/dev/release.html (search for bina) http://www.apache.org/dev/licensing-howto.html#binary Otherwise I'd suggest adding an about convenience binaries section at http://apache.org/dev/release.html with a small set of relevant questions and answers. -Bertrand - 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
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Mon, Oct 13, 2014 at 4:14 PM, Julian Hyde julianh...@gmail.com wrote: For many projects, especially library projects, the convenient binaries that matter most these days are the jars (source, binary, and javadoc) that are deployed to the maven repo... ...Are these jars subjected to due diligence during the release vote?... In projects where I'm active there's reasonable due diligence as the build processes are automated in a way that allows you to trust the build if that's done by someone that you trust. That being said, we don't make any guarantees about those jars, so in the end users can either choose to trust the build and distribution process, or build the required jars themselves from a trusted source. In the case of Maven, the ASF doesn't control the distribution process, so it's not a safe channel without signatures or trusted digests, and I don't think Maven allows for those at the moment. So even the best due diligence wouldn't really help for these binaries. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
Thanks Justin, as you can tell from the log I pasted, I tried that solution (unpacking the release, and using the KEYS file inside, but I was unable to verify it). Can you see below? Any ideas? ++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: Justin Mclean jus...@classsoftware.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Sunday, October 12, 2014 at 10:23 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: [VOTE] Apache Drill 0.6.0-incubating release Hi, I can¹t seem to find the KEYS to verify the release. The KEYS file is inside the release (probably not the best place for it). Also: https://pgp.mit.edu/pks/lookup?search=Steven+Phillipsop=index Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Mon, Oct 13, 2014 at 6:54 AM, Ted Dunning ted.dunn...@gmail.com wrote: On Mon, Oct 13, 2014 at 7:51 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Any redistribution must obey the licensing requirements of the contents so you are right that our binary redistributions need to be checked as well, but as far as incubating projects are concerned it is IMO vital to get things right for the source releases first, and make sure podlings understand the difference between source code releases and convenience binaries. Based on recent discussion, a review of this distinction would be valuable for many at Apache. I very much second this. I think bringing some clarity at least into the areas of: #1 rules for complete source release tarballs #2 rules for complete binary convenience tarballs #3 rules for lose sources that appear in ASF Maven #4 rules for lose binaries that appear in ASF Maven To Bertrand's point ASF is clearly in business of producing #1. #2 at least has a nice property of being self-contained. #3 and #4 are the trickiest for me to get my head around. Thanks, Roman. P.S. Btw, am I missing any other way that we push anything that can be thought of as a release to ASF infrastrcture? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Mon, Oct 13, 2014 at 11:48 AM, Roman Shaposhnik r...@apache.org wrote: Based on recent discussion, a review of this distinction would be valuable for many at Apache. I very much second this. I think bringing some clarity at least into the areas of: #1 rules for complete source release tarballs #2 rules for complete binary convenience tarballs #3 rules for lose sources that appear in ASF Maven #4 rules for lose binaries that appear in ASF Maven Should projects like Cordova cause #5 rules for binaries sent out via mechanism like NLM. ?
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Mon, Oct 13, 2014 at 7:14 AM, Julian Hyde julianh...@gmail.com wrote: It seems to me that each of those jars is a de facto binary release. Definitely not. An official release by the Apache Software Foundation consists of source code which has been audited by a PMC. Of course it is not possible to audit an entire codebase at each release point, but we achieve that effective result through PMC monitoring of a commits list: if the last release was fully reviewed, each delta since then has also been reviewed, and we can demonstrate that the difference between the two releases is the sum of those deltas, then the current release has been reviewed. Binaries combine that carefully audited source code with an opaque build machine, and the result is not auditable. Releasing source is an act of the foundation. A binary package is an act of the individual who prepared it. The Foundation was not set up to take on the liabilitiy associated with binary releases: http://s.apache.org/roy-binary-deps-3 How is that different from any of our other projects? End users don't compile Java. Hell, most developers don't compile Java. We distribute plenty of binaries. We just don't call them SOURCE. The source is what we review. The source is what we bless. If anyone wants to go further than that, they are free to do so as long as they don't call the result an Apache release. It is a binary package, a user convenience, a download hosted by openoffice.org. I don't care. People have to understand this. There will always be a role for downstream commercial or non-commercial redistributions of Apache products. Why? Because the ASF is incapable of taking on the enormous liability associated with released binaries that are not produced in a controlled environment with a controlled set of tools. Changing policy to make binary releases official acts by the foundation would require us to account for those liability issues -- a daunting undertaking. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Mon, Oct 13, 2014 at 1:49 PM, Marvin Humphrey mar...@rectangular.com wrote: The Foundation was not set up to take on the liabilitiy associated with binary releases: http://s.apache.org/roy-binary-deps-3 How is that different from any of our other projects? End users don't compile Java. Hell, most developers don't compile Java. We distribute plenty of binaries. We just don't call them SOURCE. The source is what we review. The source is what we bless. If anyone wants to go further than that, they are free to do so as long as they don't call the result an Apache release. It is a binary package, a user convenience, a download hosted by openoffice.org. I don't care. People have to understand this. There will always be a role for downstream commercial or non-commercial redistributions of Apache products. Why? Because the ASF is incapable of taking on the enormous liability associated with released binaries that are not produced in a controlled environment with a controlled set of tools. Changing policy to make binary releases official acts by the foundation would require us to account for those liability issues -- a daunting undertaking. Fine. But I will still perform as much diligence on those artifacts that I am involved in as possible. I think it is important that this be done to make my consumers have as good a life as possible. The final difference is that due diligence /must/ be applied to source artifacts and /should/ be applied to binary artifacts. The nature of the diligence does not, however, change.
Re: [VOTE] Apache Drill 0.6.0-incubating release
On 13.10.2014 16:14, Julian Hyde wrote: For many projects, especially library projects, the convenient binaries that matter most these days are the jars (source, binary, and javadoc) that are deployed to the maven repo. Calcite releases in fact do not currently include a binary tar ball, only a source tar ball and maven jars. Are these jars subjected to due diligence during the release vote? It seems to me that each of those jars is a de facto binary release. If it contains sources, it's not a binary release. Binary JARs are definitely a binary release. I haven't a clue what Javadocs are, but since they're derived from the sources, I'd prefer to put them in the binary category for simplicity. But that's beside the point. Convenience binaries are anything that was created from the properly voted-on and released source that did not go through the same formal release proces as the source release. If the PMC did not vote on the binary JARs, they are not an Apache Release and therefore none of our guarantees (or liabilities) can apply to them. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
-incubating-src/ .. [chipotle:~/tmp/apache-drill-0.6.0-rc] mattmann% ls apache-drill-0.6.0-incubating-src DEPENDENCIESINSTALL.md LICENSE README.md contrib/ exec/ header protocol/ src/ DISCLAIMER KEYSNOTICE common/ distribution/ git.properties pom.xml sample-data/tools/ [chipotle:~/tmp/apache-drill-0.6.0-rc] mattmann% gpg --import apache-drill-0.6.0-incubating-src/KEYS gpg: key AB10D143: Jacques Nadeau jacq...@apache.org not changed gpg: Total number processed: 1 gpg: unchanged: 1 [chipotle:~/tmp/apache-drill-0.6.0-rc] mattmann% $HOME/bin/verify_gpg_sigs Verifying Signature for file apache-drill-0.6.0-incubating-src.tar.gz.asc gpg: Signature made Thu Oct 2 02:34:43 2014 PDT using RSA key ID F51AD445 gpg: Can't check signature: public key not found Verifying Signature for file drill.asc gpg: no valid OpenPGP data found. gpg: verify signatures failed: unexpected data [chipotle:~/tmp/apache-drill-0.6.0-rc] mattmann% Am I not using the right KEYS file? Cheers, Chris ++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: lars hofhansl la...@apache.org Reply-To: general@incubator.apache.org general@incubator.apache.org, lars hofhansl la...@apache.org Date: Wednesday, October 8, 2014 at 9:45 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: [VOTE] Apache Drill 0.6.0-incubating release +1 (binding) - Downloaded bin and -src tarballs. - Not knowing much about the internals of Drill (yet), I poked around in the tarballs, looks all good. - Ran some of the examples. - All looks good. Packaging is clean. Few comments: - I would probably prefer the documentation to be part of either the bin or src tarball, seems that should be part of the distribution. - The documentation on https://cwiki.apache.org/confluence/display/DRILL/Apache+Drill+in+10+Minut es#ApacheDrillin10Minutes-StartDrill is a bit outdated (refers to release 0.4.0 at points) As for the Java8/Unittest failure discussion. IMHO a release does not need to be free of bugs (that's not actually possible anyway), it just means it is useful snaphot of the software. In any case this is an important discussion to have. (As the HBase 0.94 release manager I introduced a strict monthly release cadence and we found that far more useful then getting all the last fixes in - those just have to wait a month. Only for critical correctness issues did I delay a release for a few days. Obviously that is just my opinion.) Thanks. -- Lars From: Ted Dunning ted.dunn...@gmail.com To: general@incubator.apache.org general@incubator.apache.org Sent: Wednesday, October 8, 2014 12:52 PM Subject: Re: [VOTE] Apache Drill 0.6.0-incubating release +1 (binding) I have downloaded the code, compiled and run the tests. I also checked all checksums, and verified the signatures. I also verified that the signing key was signed by people I trust (and indeed, by me as well) and correctly propagated to the gpg key servers. I also reviewed in both the source and binary that the various notices, licenses and dependency lists appear to be correct. The license files also appear to be correct and include the correct attributions. I have previously checked that the list of dependencies and attributions was both correct and complete and since these are generated automatically, I did not specifically check them again. Moreover, the dependencies have not changed so this gives even higher confidence in this assessment. It should be noted that Drill as a project has been able to produce several high quality releases in a row with different release managers. Moreover, Drill has invested in documentation to help train release managers to help grow the community. On Tue, Oct 7, 2014 at 8:41 AM, jan i j...@apache.org wrote: Hi. I have had a look at your release and it looks good, I could not find any formal errors. But I took a closer look at the release vote thread, because a failing unit test is a serious bad quality signal for me. Whenever I test new software, I download it, build it, then run all test cases to secure I got it build correctly, where I assume I have made something wrong if a test case fails. Apache is known for quality software and I think we all want to keep that image. I am sure the project does not take quality lightly, but the attitude
Re: [VOTE] Apache Drill 0.6.0-incubating release
Hi, I can¹t seem to find the KEYS to verify the release. The KEYS file is inside the release (probably not the best place for it). Also: https://pgp.mit.edu/pks/lookup?search=Steven+Phillipsop=index Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
Actually, the licensing howto says things like this: In LICENSE, add a pointer http://s.apache.org/Hqj to the dependency's license within the source tree and a short note summarizing its licensing: This product bundles SuperWidget 1.2.3, which is available under a 3-clause BSD license. For details, see deps/superwidget/. Under normal circumstances, there is no need to modify NOTICE. Over and over again, it is emphasized that NOTICE does not need to be modified and that the reference should be in the LICENSE file. This seems to contradict your assertion that these references need to be in the NOTICE file. Are you sure we are reading the same document? On Fri, Oct 10, 2014 at 1:30 PM, Sean Owen sro...@gmail.com wrote: No I just went straight for the binary distribution: http://people.apache.org/~smp/apache-drill-0.6.0.rc0/apache-drill-0.6.0-incubating.tar.gz This contains the third-party jar files in jars/. I assume http://www.apache.org/dev/licensing-howto.html is still the law of the land so to speak and indicates that lots of these things need to be in NOTICE. On Oct 10, 2014 9:24 PM, Ted Dunning ted.dunn...@gmail.com wrote: Sean, Are you talking about the src distribution after doing the build? Before doing the build or after [mvn clean], there are no jars in the distribution. Videlicet: - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
I am reading http://www.apache.org/dev/licensing-howto.html . Yes LICENSE also needs to contain more things as well. Yes, there are several situations where NOTICE does not need to change, but this is the key sentence: Aside from Apache-licensed dependencies which supply NOTICE files of their own, it is uncommon for a dependency to require additions to NOTICE. Lots of the dependencies I see here are Apache-licensed dependencies with NOTICE files. The Apache License 2 clause 4 means any (relevant) parts of the NOTICE files must be included in a distribution, and the NOTICE file is the place for that*. Here's a correct (AFAIK) example from Spark: https://github.com/apache/spark/blob/master/NOTICE https://github.com/apache/spark/blob/master/LICENSE Some of the same dependencies are included in both. I don't see why this doesn't apply to Drill too? Unless the guidance above is out of date. * I am not clear whether distribution a .jar, which has its NOTICE file embedded, counts. This would not be the case in an 'uber' jar the the project distributes, and there are some third-party uber jars here like hive-exec, but I don't see a Drill uber jar. Maybe that counts; maybe it's safer just to populate NOTICE appropriately. Or, avoid shipping copies of all these jars directly? On Sat, Oct 11, 2014 at 7:17 AM, Ted Dunning ted.dunn...@gmail.com wrote: Actually, the licensing howto says things like this: In LICENSE, add a pointer http://s.apache.org/Hqj to the dependency's license within the source tree and a short note summarizing its licensing: This product bundles SuperWidget 1.2.3, which is available under a 3-clause BSD license. For details, see deps/superwidget/. Under normal circumstances, there is no need to modify NOTICE. Over and over again, it is emphasized that NOTICE does not need to be modified and that the reference should be in the LICENSE file. This seems to contradict your assertion that these references need to be in the NOTICE file. Are you sure we are reading the same document? On Fri, Oct 10, 2014 at 1:30 PM, Sean Owen sro...@gmail.com wrote: No I just went straight for the binary distribution: http://people.apache.org/~smp/apache-drill-0.6.0.rc0/apache-drill-0.6.0-incubating.tar.gz This contains the third-party jar files in jars/. I assume http://www.apache.org/dev/licensing-howto.html is still the law of the land so to speak and indicates that lots of these things need to be in NOTICE. On Oct 10, 2014 9:24 PM, Ted Dunning ted.dunn...@gmail.com wrote: Sean, Are you talking about the src distribution after doing the build? Before doing the build or after [mvn clean], there are no jars in the distribution. Videlicet: - 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
Re: [VOTE] Apache Drill 0.6.0-incubating release
Drill has had previous releases stopped *precisely* because NOTICE had too much stuff in it. The items you mention are among these items. I think the release is satisfactory as is. On Sat, Oct 11, 2014 at 2:32 AM, Sean Owen sro...@gmail.com wrote: I am reading http://www.apache.org/dev/licensing-howto.html . Yes LICENSE also needs to contain more things as well. Yes, there are several situations where NOTICE does not need to change, but this is the key sentence: Aside from Apache-licensed dependencies which supply NOTICE files of their own, it is uncommon for a dependency to require additions to NOTICE. Lots of the dependencies I see here are Apache-licensed dependencies with NOTICE files. The Apache License 2 clause 4 means any (relevant) parts of the NOTICE files must be included in a distribution, and the NOTICE file is the place for that*. Here's a correct (AFAIK) example from Spark: https://github.com/apache/spark/blob/master/NOTICE https://github.com/apache/spark/blob/master/LICENSE Some of the same dependencies are included in both. I don't see why this doesn't apply to Drill too? Unless the guidance above is out of date. * I am not clear whether distribution a .jar, which has its NOTICE file embedded, counts. This would not be the case in an 'uber' jar the the project distributes, and there are some third-party uber jars here like hive-exec, but I don't see a Drill uber jar. Maybe that counts; maybe it's safer just to populate NOTICE appropriately. Or, avoid shipping copies of all these jars directly? On Sat, Oct 11, 2014 at 7:17 AM, Ted Dunning ted.dunn...@gmail.com wrote: Actually, the licensing howto says things like this: In LICENSE, add a pointer http://s.apache.org/Hqj to the dependency's license within the source tree and a short note summarizing its licensing: This product bundles SuperWidget 1.2.3, which is available under a 3-clause BSD license. For details, see deps/superwidget/. Under normal circumstances, there is no need to modify NOTICE. Over and over again, it is emphasized that NOTICE does not need to be modified and that the reference should be in the LICENSE file. This seems to contradict your assertion that these references need to be in the NOTICE file. Are you sure we are reading the same document? On Fri, Oct 10, 2014 at 1:30 PM, Sean Owen sro...@gmail.com wrote: No I just went straight for the binary distribution: http://people.apache.org/~smp/apache-drill-0.6.0.rc0/apache-drill-0.6.0-incubating.tar.gz This contains the third-party jar files in jars/. I assume http://www.apache.org/dev/licensing-howto.html is still the law of the land so to speak and indicates that lots of these things need to be in NOTICE. On Oct 10, 2014 9:24 PM, Ted Dunning ted.dunn...@gmail.com wrote: Sean, Are you talking about the src distribution after doing the build? Before doing the build or after [mvn clean], there are no jars in the distribution. Videlicet: - 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
Re: [VOTE] Apache Drill 0.6.0-incubating release
That may be so, and I find this issue irritating to deal with, but I don't see that it has bearing on what is ultimately correct. I think that the guidance you refer to was wrong, according to the text of the licenses, and the link I pointed to. But even those are a bit ambiguous, so I raise the question here. This is unclear and annoying != This can be ignored, but maybe there are other clear reasons that NOTICE does not need modification after all. LICENSE looks good. It looks like it is noting the license of lots of the bundled third-party libraries, which seems correct. Some person or process even helpfully grouped the 'category B' dependencies. For NOTICE, here's a specific example. Drill distributes Apache Commons Math 3.1, which is AL2 licensed. Its NOTICE includes stanzas like: ... The BracketFinder (package org.apache.commons.math3.optimization.univariate) and PowellOptimizer (package org.apache.commons.math3.optimization.general) classes are based on the Python code in module optimize.py (version 0.5) developed by Travis E. Oliphant for the SciPy library (http://www.scipy.org/) Copyright © 2003-2009 SciPy Developers. ... I had the same question -- since the .jar files contains its own NOTICE.txt, is that enough? That doesn't seem to be what the AL2 says: ... You distribute must include a readable copy of the attribution notices contained within such NOTICE file ... in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works ... ... although that's getting pretty technical. But this is the part where technical matters. Note that not all .jar files do copy their NOTICE in META-INF for you. The spirit of the license is that a downstream consumer finds this info where she expects to find it. The top-level NOTICE seems like that place, but, could argue anyone would expect to crack open each .jar to figure it out? The stanza has to appear somewhere, no matter what. It binds downstream consumers no matter what. To me it seemed safer to make sure this info was copied into NOTICE but YMMV. It seems clear that the release must only distribute IP in accordance with their licenses. Worth a double-check at least, to feel confident there is a defensible argument that it is? On Sat, Oct 11, 2014 at 3:05 PM, Ted Dunning ted.dunn...@gmail.com wrote: Drill has had previous releases stopped *precisely* because NOTICE had too much stuff in it. The items you mention are among these items. I think the release is satisfactory as is. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
Hi, +1 binding. I checked: - vote assumed OK (see below) - artefact name contains incubating - DISCLAIMER exits - LICENSE and NOTICE are correct for source package - signatures and hash good - All source files have apache headers - No unexpected binary files in artefact While Drill may depend on other other software what matters is what is actually bundled in the package and for the source release everything looks correct to me. For the binary it's likely as per discussion (and the large number of jars) that LICENSE/NOTICE may be missing a few things. However votes on releases are more about the source release and binaries releases are just a convenience so I don't see that as a blocker assuming it's been looked into and will be fixed in a later release. Re the vote thread only PPMC votes are binding on releases so I think the vote count may be incorrect, but I'm assuming there's at least 3 +1 PPMC votes in there given the large number of +1s. A [VOTE][RESULT] summary would be helpful. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
Not sure, and maybe a bit pedantic, but is the NOTICE file a little thin (practically non-existent) given the number of 3rd party libs present? I'm not an expert on what is required there, but when I compare it to projects I'm familiar with like Solr and Mahout, they are vastly different. I _believe_ the NOTICE file is where you are supposed to put NOTICES from licenses that require it. (someone else here can probably help) Beyond that, and I'm not sure if it is a blocker or not, things look good to the extent I tested (packaging, keys, basic run through) So, -1 if the NOTICE thing is a thing that needs to be dealt with now. +1 if it is not. In either case, that would be binding. -Grant On Oct 5, 2014, at 2:14 PM, Steven Phillips s...@apache.org wrote: I would like to present the Apache Drill 0.6.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 30 JIRAs closed in the last month. The vote thread can be found here:http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E The vote passed with: +9 binding +3 non-binding You can find the artifacts for the release at this location:http://people.apache.org/~smp/apache-drill-0.6.0.rc0/ I look forward to your feedback. Thanks, Steven
Re: [VOTE] Apache Drill 0.6.0-incubating release
I had a look, since I was just dealing with NOTICE for another project. The key is whether copies of the third-party libraries are distributed. In the case of Drill, yes there are loads of 3rd party jars distributed in jars/; they are not just Maven deps referenced in pom.xml. I am sure this will entail some entries in NOTICE just from looking at the deps, which aren't there. See for example http://www.apache.org/dev/licensing-howto.html Functionally it's trivial; from a license / legal perspective, it's one of the only things that matter, and ultimately it's vital to dot all those i's and cross those t's. It's tedious to construct the right NOTICE file since it will entail figuring out what third party deps are built in to things like hive-exec too. I have a few tips for whatever brave soul wants to take on that task. Some Maven plugins can do most of the legwork. On Fri, Oct 10, 2014 at 2:24 PM, Grant Ingersoll gsing...@apache.org wrote: Not sure, and maybe a bit pedantic, but is the NOTICE file a little thin (practically non-existent) given the number of 3rd party libs present? I'm not an expert on what is required there, but when I compare it to projects I'm familiar with like Solr and Mahout, they are vastly different. I _believe_ the NOTICE file is where you are supposed to put NOTICES from licenses that require it. (someone else here can probably help) Beyond that, and I'm not sure if it is a blocker or not, things look good to the extent I tested (packaging, keys, basic run through) So, -1 if the NOTICE thing is a thing that needs to be dealt with now. +1 if it is not. In either case, that would be binding. -Grant On Oct 5, 2014, at 2:14 PM, Steven Phillips s...@apache.org wrote: I would like to present the Apache Drill 0.6.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 30 JIRAs closed in the last month. The vote thread can be found here:http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E The vote passed with: +9 binding +3 non-binding You can find the artifacts for the release at this location:http://people.apache.org/~smp/apache-drill-0.6.0.rc0/ I look forward to your feedback. Thanks, Steven - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Fri, Oct 10, 2014 at 6:24 AM, Grant Ingersoll gsing...@apache.org wrote: Not sure, and maybe a bit pedantic, but is the NOTICE file a little thin (practically non-existent) given the number of 3rd party libs present? I'm not an expert on what is required there, but when I compare it to projects I'm familiar with like Solr and Mahout, they are vastly different. I _believe_ the NOTICE file is where you are supposed to put NOTICES from licenses that require it. (someone else here can probably help) In the interval since Solr graduated from the Incubator, what constitutes a required notice has been clarified. See LEGAL-59 and LEGAL-62, especially the comments at http://s.apache.org/XAf and http://s.apache.org/jP. The original rationale for separating NOTICE out in the transition from the Apache License 1.1 to the Apache License 2.0 was to move the following clause: * 3. The end-user documentation included with the redistribution, *if any, must include the following acknowledgment: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgment may appear in the software itself, *if and wherever such third-party acknowledgments normally appear. The presence of that requirement in a license conflicts with the GPL. But as Roy notes, the GPL requires the preservation of notices even when it subsumes all other licenses -- so the kludge of moving it to NOTICE works around the GPL incompatibility. Were the Incubator to review Solr's licensing documentation today, I'm certain that the project would be encouraged to pare things down -- to lower the cost to downstream consumers, and in keeping with the modest original intent of NOTICE. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
Is it correct, then, to say that if Drill does not bundle any GPL licensed libraries, we do not need any additional info in the NOTICE? On Fri, Oct 10, 2014 at 10:45 AM, Marvin Humphrey mar...@rectangular.com wrote: On Fri, Oct 10, 2014 at 6:24 AM, Grant Ingersoll gsing...@apache.org wrote: Not sure, and maybe a bit pedantic, but is the NOTICE file a little thin (practically non-existent) given the number of 3rd party libs present? I'm not an expert on what is required there, but when I compare it to projects I'm familiar with like Solr and Mahout, they are vastly different. I _believe_ the NOTICE file is where you are supposed to put NOTICES from licenses that require it. (someone else here can probably help) In the interval since Solr graduated from the Incubator, what constitutes a required notice has been clarified. See LEGAL-59 and LEGAL-62, especially the comments at http://s.apache.org/XAf and http://s.apache.org/jP. The original rationale for separating NOTICE out in the transition from the Apache License 1.1 to the Apache License 2.0 was to move the following clause: * 3. The end-user documentation included with the redistribution, *if any, must include the following acknowledgment: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgment may appear in the software itself, *if and wherever such third-party acknowledgments normally appear. The presence of that requirement in a license conflicts with the GPL. But as Roy notes, the GPL requires the preservation of notices even when it subsumes all other licenses -- so the kludge of moving it to NOTICE works around the GPL incompatibility. Were the Incubator to review Solr's licensing documentation today, I'm certain that the project would be encouraged to pare things down -- to lower the cost to downstream consumers, and in keeping with the modest original intent of NOTICE. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Steven Phillips Software Engineer mapr.com
Re: [VOTE] Apache Drill 0.6.0-incubating release
The standard practice has been drifting in incubator-land. When I brought this up previously, I was told a few things, 1) the notices required by BSD like licenses apparently should appear in the LICENSE file. 2) notices in the source distribution only need to include things that are included in the source distro 3) notices in the binary distribution should include the things included in the binary distro (clearly many more than in the source distro) 4) maven references from a pom do not invoke a requirement for notices in the source distro. So, If you are talking about the source distribution, this isn't a problem. If you are talking about notices that actually are in the LICENSE file instead of the NOTICE file, this isn't a problem. If you are saying that the notices aren't in the LICENSE file in the binary distro, there is a huge problem (partly because I looked there and found them). My guess is that your next comment and mine as well is that it is really hard to keep track of these requirements as they shift over time. On Fri, Oct 10, 2014 at 6:24 AM, Grant Ingersoll gsing...@apache.org wrote: Not sure, and maybe a bit pedantic, but is the NOTICE file a little thin (practically non-existent) given the number of 3rd party libs present? I'm not an expert on what is required there, but when I compare it to projects I'm familiar with like Solr and Mahout, they are vastly different. I _believe_ the NOTICE file is where you are supposed to put NOTICES from licenses that require it. (someone else here can probably help) Beyond that, and I'm not sure if it is a blocker or not, things look good to the extent I tested (packaging, keys, basic run through) So, -1 if the NOTICE thing is a thing that needs to be dealt with now. +1 if it is not. In either case, that would be binding. -Grant On Oct 5, 2014, at 2:14 PM, Steven Phillips s...@apache.org wrote: I would like to present the Apache Drill 0.6.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 30 JIRAs closed in the last month. The vote thread can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E The vote passed with: +9 binding +3 non-binding You can find the artifacts for the release at this location:http://people.apache.org/~smp/apache-drill-0.6.0.rc0/ I look forward to your feedback. Thanks, Steven
Re: [VOTE] Apache Drill 0.6.0-incubating release
Sean, Are you talking about the src distribution after doing the build? Before doing the build or after [mvn clean], there are no jars in the distribution. Videlicet: *ted:apache-drill-0.6.0-incubating-src$ mvn -q cleanted:apache-drill-0.6.0-incubating-src$ find . -name '*.jar'ted:apache-drill-0.6.0-incubating-src$* On Fri, Oct 10, 2014 at 7:30 AM, Sean Owen sro...@gmail.com wrote: I had a look, since I was just dealing with NOTICE for another project. The key is whether copies of the third-party libraries are distributed. In the case of Drill, yes there are loads of 3rd party jars distributed in jars/; they are not just Maven deps referenced in pom.xml. I am sure this will entail some entries in NOTICE just from looking at the deps, which aren't there. See for example http://www.apache.org/dev/licensing-howto.html Functionally it's trivial; from a license / legal perspective, it's one of the only things that matter, and ultimately it's vital to dot all those i's and cross those t's. It's tedious to construct the right NOTICE file since it will entail figuring out what third party deps are built in to things like hive-exec too. I have a few tips for whatever brave soul wants to take on that task. Some Maven plugins can do most of the legwork. On Fri, Oct 10, 2014 at 2:24 PM, Grant Ingersoll gsing...@apache.org wrote: Not sure, and maybe a bit pedantic, but is the NOTICE file a little thin (practically non-existent) given the number of 3rd party libs present? I'm not an expert on what is required there, but when I compare it to projects I'm familiar with like Solr and Mahout, they are vastly different. I _believe_ the NOTICE file is where you are supposed to put NOTICES from licenses that require it. (someone else here can probably help) Beyond that, and I'm not sure if it is a blocker or not, things look good to the extent I tested (packaging, keys, basic run through) So, -1 if the NOTICE thing is a thing that needs to be dealt with now. +1 if it is not. In either case, that would be binding. -Grant On Oct 5, 2014, at 2:14 PM, Steven Phillips s...@apache.org wrote: I would like to present the Apache Drill 0.6.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 30 JIRAs closed in the last month. The vote thread can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E The vote passed with: +9 binding +3 non-binding You can find the artifacts for the release at this location:http://people.apache.org/~smp/apache-drill-0.6.0.rc0/ I look forward to your feedback. Thanks, Steven - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
No I just went straight for the binary distribution: http://people.apache.org/~smp/apache-drill-0.6.0.rc0/apache-drill-0.6.0-incubating.tar.gz This contains the third-party jar files in jars/. I assume http://www.apache.org/dev/licensing-howto.html is still the law of the land so to speak and indicates that lots of these things need to be in NOTICE. On Oct 10, 2014 9:24 PM, Ted Dunning ted.dunn...@gmail.com wrote: Sean, Are you talking about the src distribution after doing the build? Before doing the build or after [mvn clean], there are no jars in the distribution. Videlicet: - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Fri, Oct 10, 2014 at 11:45 AM, Ted Dunning ted.dunn...@gmail.com wrote: The standard practice has been drifting in incubator-land. There's hardly any daylight between what Roy was recommending 8 years ago and what we recommend today. (NOTICE should be minimal, only bundled bits get documented in LICENSE and NOTICE, etc.) It's true that podlings have gotten inconsistent advice in the past, but we're doing better these days. My guess is that your next comment and mine as well is that it is really hard to keep track of these requirements as they shift over time. Yeah, I feel this frustration. It took way too much effort before I felt a sense of mastery over this subject. The addition of the Licensing How-To seems to have helped. Presumably the completion of the release policy clarification initiative will improve matters further. (Gah, I have no time...) Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Drill 0.6.0-incubating release
+1 (binding) I have downloaded the code, compiled and run the tests. I also checked all checksums, and verified the signatures. I also verified that the signing key was signed by people I trust (and indeed, by me as well) and correctly propagated to the gpg key servers. I also reviewed in both the source and binary that the various notices, licenses and dependency lists appear to be correct. The license files also appear to be correct and include the correct attributions. I have previously checked that the list of dependencies and attributions was both correct and complete and since these are generated automatically, I did not specifically check them again. Moreover, the dependencies have not changed so this gives even higher confidence in this assessment. It should be noted that Drill as a project has been able to produce several high quality releases in a row with different release managers. Moreover, Drill has invested in documentation to help train release managers to help grow the community. On Tue, Oct 7, 2014 at 8:41 AM, jan i j...@apache.org wrote: Hi. I have had a look at your release and it looks good, I could not find any formal errors. But I took a closer look at the release vote thread, because a failing unit test is a serious bad quality signal for me. Whenever I test new software, I download it, build it, then run all test cases to secure I got it build correctly, where I assume I have made something wrong if a test case fails. Apache is known for quality software and I think we all want to keep that image. I am sure the project does not take quality lightly, but the attitude can be fixed later especially with unit tests is to me not a good policy. If the software only runs with 1.7 and not higher, then why not make a simple startup version check, then there would be no problem (of course its even better to solve the problem). I just wonder how this error will affect people using the project. It seems (from the vote thread) you already have solved the problem, but dont want to wait for a respin, can you please at least explain why the project is under such a time constraint, that 72 hours is too long to wait to make good quality. I wanted to give the release a -1 but decided to give -0 binding. in the hope the PMC will go for quality and voluntary respin the release. rgds jan i On 7 October 2014 07:09, Steven Phillips sphill...@maprtech.com wrote: In case there is any confusion, the first email sent out in this thread had the wrong vote count. The second one has the correct count: +9 binding +3 non-binding I should also mention there was one -0 (binding). This was due to unit test failures when using java 1.8. Jiras were filed, and the fix will be included in the next release, not this one. On Sun, Oct 5, 2014 at 11:14 AM, Steven Phillips s...@apache.org wrote: I would like to present the Apache Drill 0.6.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 30 JIRAs closed in the last month. The vote thread can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E The vote passed with: +9 binding +3 non-binding You can find the artifacts for the release at this location: http://people.apache.org/~smp/apache-drill-0.6.0.rc0/ I look forward to your feedback. Thanks, Steven -- Steven Phillips Software Engineer mapr.com
Re: [VOTE] Apache Drill 0.6.0-incubating release
+1 (binding) - Downloaded bin and -src tarballs. - Not knowing much about the internals of Drill (yet), I poked around in the tarballs, looks all good. - Ran some of the examples. - All looks good. Packaging is clean. Few comments: - I would probably prefer the documentation to be part of either the bin or src tarball, seems that should be part of the distribution. - The documentation on https://cwiki.apache.org/confluence/display/DRILL/Apache+Drill+in+10+Minutes#ApacheDrillin10Minutes-StartDrill is a bit outdated (refers to release 0.4.0 at points) As for the Java8/Unittest failure discussion. IMHO a release does not need to be free of bugs (that's not actually possible anyway), it just means it is useful snaphot of the software. In any case this is an important discussion to have. (As the HBase 0.94 release manager I introduced a strict monthly release cadence and we found that far more useful then getting all the last fixes in - those just have to wait a month. Only for critical correctness issues did I delay a release for a few days. Obviously that is just my opinion.) Thanks. -- Lars From: Ted Dunning ted.dunn...@gmail.com To: general@incubator.apache.org general@incubator.apache.org Sent: Wednesday, October 8, 2014 12:52 PM Subject: Re: [VOTE] Apache Drill 0.6.0-incubating release +1 (binding) I have downloaded the code, compiled and run the tests. I also checked all checksums, and verified the signatures. I also verified that the signing key was signed by people I trust (and indeed, by me as well) and correctly propagated to the gpg key servers. I also reviewed in both the source and binary that the various notices, licenses and dependency lists appear to be correct. The license files also appear to be correct and include the correct attributions. I have previously checked that the list of dependencies and attributions was both correct and complete and since these are generated automatically, I did not specifically check them again. Moreover, the dependencies have not changed so this gives even higher confidence in this assessment. It should be noted that Drill as a project has been able to produce several high quality releases in a row with different release managers. Moreover, Drill has invested in documentation to help train release managers to help grow the community. On Tue, Oct 7, 2014 at 8:41 AM, jan i j...@apache.org wrote: Hi. I have had a look at your release and it looks good, I could not find any formal errors. But I took a closer look at the release vote thread, because a failing unit test is a serious bad quality signal for me. Whenever I test new software, I download it, build it, then run all test cases to secure I got it build correctly, where I assume I have made something wrong if a test case fails. Apache is known for quality software and I think we all want to keep that image. I am sure the project does not take quality lightly, but the attitude can be fixed later especially with unit tests is to me not a good policy. If the software only runs with 1.7 and not higher, then why not make a simple startup version check, then there would be no problem (of course its even better to solve the problem). I just wonder how this error will affect people using the project. It seems (from the vote thread) you already have solved the problem, but dont want to wait for a respin, can you please at least explain why the project is under such a time constraint, that 72 hours is too long to wait to make good quality. I wanted to give the release a -1 but decided to give -0 binding. in the hope the PMC will go for quality and voluntary respin the release. rgds jan i On 7 October 2014 07:09, Steven Phillips sphill...@maprtech.com wrote: In case there is any confusion, the first email sent out in this thread had the wrong vote count. The second one has the correct count: +9 binding +3 non-binding I should also mention there was one -0 (binding). This was due to unit test failures when using java 1.8. Jiras were filed, and the fix will be included in the next release, not this one. On Sun, Oct 5, 2014 at 11:14 AM, Steven Phillips s...@apache.org wrote: I would like to present the Apache Drill 0.6.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 30 JIRAs closed in the last month. The vote thread can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E The vote passed with: +9 binding +3 non-binding You can find the artifacts for the release at this location: http://people.apache.org/~smp/apache-drill-0.6.0.rc0/ I look forward to your feedback. Thanks, Steven -- Steven
Re: [VOTE] Apache Drill 0.6.0-incubating release
Thanks Lars. Good perspective. Sent from my iPhone On Oct 8, 2014, at 21:45, lars hofhansl la...@apache.org wrote: +1 (binding) - Downloaded bin and -src tarballs. - Not knowing much about the internals of Drill (yet), I poked around in the tarballs, looks all good. - Ran some of the examples. - All looks good. Packaging is clean. Few comments: - I would probably prefer the documentation to be part of either the bin or src tarball, seems that should be part of the distribution. - The documentation on https://cwiki.apache.org/confluence/display/DRILL/Apache+Drill+in+10+Minutes#ApacheDrillin10Minutes-StartDrill is a bit outdated (refers to release 0.4.0 at points) As for the Java8/Unittest failure discussion. IMHO a release does not need to be free of bugs (that's not actually possible anyway), it just means it is useful snaphot of the software. In any case this is an important discussion to have. (As the HBase 0.94 release manager I introduced a strict monthly release cadence and we found that far more useful then getting all the last fixes in - those just have to wait a month. Only for critical correctness issues did I delay a release for a few days. Obviously that is just my opinion.) Thanks. -- Lars From: Ted Dunning ted.dunn...@gmail.com To: general@incubator.apache.org general@incubator.apache.org Sent: Wednesday, October 8, 2014 12:52 PM Subject: Re: [VOTE] Apache Drill 0.6.0-incubating release +1 (binding) I have downloaded the code, compiled and run the tests. I also checked all checksums, and verified the signatures. I also verified that the signing key was signed by people I trust (and indeed, by me as well) and correctly propagated to the gpg key servers. I also reviewed in both the source and binary that the various notices, licenses and dependency lists appear to be correct. The license files also appear to be correct and include the correct attributions. I have previously checked that the list of dependencies and attributions was both correct and complete and since these are generated automatically, I did not specifically check them again. Moreover, the dependencies have not changed so this gives even higher confidence in this assessment. It should be noted that Drill as a project has been able to produce several high quality releases in a row with different release managers. Moreover, Drill has invested in documentation to help train release managers to help grow the community. On Tue, Oct 7, 2014 at 8:41 AM, jan i j...@apache.org wrote: Hi. I have had a look at your release and it looks good, I could not find any formal errors. But I took a closer look at the release vote thread, because a failing unit test is a serious bad quality signal for me. Whenever I test new software, I download it, build it, then run all test cases to secure I got it build correctly, where I assume I have made something wrong if a test case fails. Apache is known for quality software and I think we all want to keep that image. I am sure the project does not take quality lightly, but the attitude can be fixed later especially with unit tests is to me not a good policy. If the software only runs with 1.7 and not higher, then why not make a simple startup version check, then there would be no problem (of course its even better to solve the problem). I just wonder how this error will affect people using the project. It seems (from the vote thread) you already have solved the problem, but dont want to wait for a respin, can you please at least explain why the project is under such a time constraint, that 72 hours is too long to wait to make good quality. I wanted to give the release a -1 but decided to give -0 binding. in the hope the PMC will go for quality and voluntary respin the release. rgds jan i On 7 October 2014 07:09, Steven Phillips sphill...@maprtech.com wrote: In case there is any confusion, the first email sent out in this thread had the wrong vote count. The second one has the correct count: +9 binding +3 non-binding I should also mention there was one -0 (binding). This was due to unit test failures when using java 1.8. Jiras were filed, and the fix will be included in the next release, not this one. On Sun, Oct 5, 2014 at 11:14 AM, Steven Phillips s...@apache.org wrote: I would like to present the Apache Drill 0.6.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 30 JIRAs closed in the last month. The vote thread can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E The vote passed with: +9 binding +3 non-binding You can find the artifacts
Re: [VOTE] Apache Drill 0.6.0-incubating release
Hi. I have had a look at your release and it looks good, I could not find any formal errors. But I took a closer look at the release vote thread, because a failing unit test is a serious bad quality signal for me. Whenever I test new software, I download it, build it, then run all test cases to secure I got it build correctly, where I assume I have made something wrong if a test case fails. Apache is known for quality software and I think we all want to keep that image. I am sure the project does not take quality lightly, but the attitude can be fixed later especially with unit tests is to me not a good policy. If the software only runs with 1.7 and not higher, then why not make a simple startup version check, then there would be no problem (of course its even better to solve the problem). I just wonder how this error will affect people using the project. It seems (from the vote thread) you already have solved the problem, but dont want to wait for a respin, can you please at least explain why the project is under such a time constraint, that 72 hours is too long to wait to make good quality. I wanted to give the release a -1 but decided to give -0 binding. in the hope the PMC will go for quality and voluntary respin the release. rgds jan i On 7 October 2014 07:09, Steven Phillips sphill...@maprtech.com wrote: In case there is any confusion, the first email sent out in this thread had the wrong vote count. The second one has the correct count: +9 binding +3 non-binding I should also mention there was one -0 (binding). This was due to unit test failures when using java 1.8. Jiras were filed, and the fix will be included in the next release, not this one. On Sun, Oct 5, 2014 at 11:14 AM, Steven Phillips s...@apache.org wrote: I would like to present the Apache Drill 0.6.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 30 JIRAs closed in the last month. The vote thread can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E The vote passed with: +9 binding +3 non-binding You can find the artifacts for the release at this location: http://people.apache.org/~smp/apache-drill-0.6.0.rc0/ I look forward to your feedback. Thanks, Steven -- Steven Phillips Software Engineer mapr.com
Re: [VOTE] Apache Drill 0.6.0-incubating release
The unit test was only on Java 1.8. That problem will be resolved in the next release which will be in roughly a month from now. The current primary target of Drill is 1.7. The number of reviewers for the release is an indication of how the community doesn't view Java 1.8 as a critical platform at this time. On Tue, Oct 7, 2014 at 8:41 AM, jan i j...@apache.org wrote: Hi. I have had a look at your release and it looks good, I could not find any formal errors. But I took a closer look at the release vote thread, because a failing unit test is a serious bad quality signal for me. Whenever I test new software, I download it, build it, then run all test cases to secure I got it build correctly, where I assume I have made something wrong if a test case fails. Apache is known for quality software and I think we all want to keep that image. I am sure the project does not take quality lightly, but the attitude can be fixed later especially with unit tests is to me not a good policy. If the software only runs with 1.7 and not higher, then why not make a simple startup version check, then there would be no problem (of course its even better to solve the problem). I just wonder how this error will affect people using the project. It seems (from the vote thread) you already have solved the problem, but dont want to wait for a respin, can you please at least explain why the project is under such a time constraint, that 72 hours is too long to wait to make good quality. I wanted to give the release a -1 but decided to give -0 binding. in the hope the PMC will go for quality and voluntary respin the release. rgds jan i On 7 October 2014 07:09, Steven Phillips sphill...@maprtech.com wrote: In case there is any confusion, the first email sent out in this thread had the wrong vote count. The second one has the correct count: +9 binding +3 non-binding I should also mention there was one -0 (binding). This was due to unit test failures when using java 1.8. Jiras were filed, and the fix will be included in the next release, not this one. On Sun, Oct 5, 2014 at 11:14 AM, Steven Phillips s...@apache.org wrote: I would like to present the Apache Drill 0.6.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 30 JIRAs closed in the last month. The vote thread can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E The vote passed with: +9 binding +3 non-binding You can find the artifacts for the release at this location: http://people.apache.org/~smp/apache-drill-0.6.0.rc0/ I look forward to your feedback. Thanks, Steven -- Steven Phillips Software Engineer mapr.com
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Tue, Oct 7, 2014 at 8:41 AM, jan i j...@apache.org wrote: It seems (from the vote thread) you already have solved the problem, but dont want to wait for a respin, can you please at least explain why the project is under such a time constraint, that 72 hours is too long to wait to make good quality. You have to make a cut somewhere. There are always a number of very small, low priority bugs and platform issues in any release. Drill is now on a monthly release cycle so triaging a minor bug as something that doesn't stop shipping has very little down-side. On the other hand, delaying by 3+ days is more than a 10% delay in the monthly release. Your characterization of this issue being a quality issue is also a bit of an over-statement. The problem was that several dependencies worked differently on Java8 than Java7. The fix involved changing the version of these dependencies. Changing dependency versions is not a small change and requires a full QA cycle since it takes serious thought to decide what impact the version change might have. The best way for that to happen in a reasonable way is to simply put this fix in the next release.
Re: [VOTE] Apache Drill 0.6.0-incubating release
Hi Jan, The issue was discussed on the release voting thread and there seems to be an agreement in the community that it may not be worth holding the release to include Java 8 support since 1.) Among most of the users, as evident on the vote thread, very few are running Java 8 in dev and test environment and even fewer are running it in production. 2.) The changes that seem to fix the test failures involves moving to a very new release of few libraries which are tightly integrated with Drill's core functionality and hence we would like to test these a bit more before merging in to a release. 3.) With our goal to have shorter and more frequent (monthly) releases, we try to be little judicious with picking what issue could have a wider user impact and should be fixed immediately, vs something which affects a very small percentage of use cases. 4.) And lastly, as Julian mentioned on the thread that the set of fixes might not be complete yet, I think we need more time before we can merge these changes in to a release with confidence to support a new platform. I hope this persuades you to reconsider your position on this release candidate. Regards, aditya... On Tue, Oct 7, 2014 at 12:02 PM, Ted Dunning ted.dunn...@gmail.com wrote: On Tue, Oct 7, 2014 at 8:41 AM, jan i j...@apache.org wrote: It seems (from the vote thread) you already have solved the problem, but dont want to wait for a respin, can you please at least explain why the project is under such a time constraint, that 72 hours is too long to wait to make good quality. You have to make a cut somewhere. There are always a number of very small, low priority bugs and platform issues in any release. Drill is now on a monthly release cycle so triaging a minor bug as something that doesn't stop shipping has very little down-side. On the other hand, delaying by 3+ days is more than a 10% delay in the monthly release. Your characterization of this issue being a quality issue is also a bit of an over-statement. The problem was that several dependencies worked differently on Java8 than Java7. The fix involved changing the version of these dependencies. Changing dependency versions is not a small change and requires a full QA cycle since it takes serious thought to decide what impact the version change might have. The best way for that to happen in a reasonable way is to simply put this fix in the next release.
Re: [VOTE] Apache Drill 0.6.0-incubating release
Hi First let me make it clear I am not a java specialist, and secondly big thanks to both of you for explaining more in detail what the problem is. On 7 October 2014 21:24, Aditya a...@apache.org wrote: Hi Jan, The issue was discussed on the release voting thread and there seems to be an agreement in the community that it may not be worth holding the release to include Java 8 support since 1.) Among most of the users, as evident on the vote thread, very few are running Java 8 in dev and test environment and even fewer are running it in production. 2.) The changes that seem to fix the test failures involves moving to a very new release of few libraries which are tightly integrated with Drill's core functionality and hence we would like to test these a bit more before merging in to a release. very fair I would have done the same. 3.) With our goal to have shorter and more frequent (monthly) releases, we try to be little judicious with picking what issue could have a wider user impact and should be fixed immediately, vs something which affects a very small percentage of use cases. I agree with you in principle, but when the project have bothered to write a unit-test case, it means its an important functionality. 4.) And lastly, as Julian mentioned on the thread that the set of fixes might not be complete yet, I think we need more time before we can merge these changes in to a release with confidence to support a new platform. I agree with this, but it still does not explain why the software not simply deny runing with java1.7+. To me it seems a simple if during load could solve the problem, and is in general something a software should do with all dependencies especially when newer versions dont work (most of us expect newer versions to be backward compatible). I hope this persuades you to reconsider your position on this release candidate. I hope you noted, that I just raised a concern and did not block the release. Regards, aditya... On Tue, Oct 7, 2014 at 12:02 PM, Ted Dunning ted.dunn...@gmail.com wrote: On Tue, Oct 7, 2014 at 8:41 AM, jan i j...@apache.org wrote: It seems (from the vote thread) you already have solved the problem, but dont want to wait for a respin, can you please at least explain why the project is under such a time constraint, that 72 hours is too long to wait to make good quality. You have to make a cut somewhere. There are always a number of very small, low priority bugs and platform issues in any release. Drill is now on a monthly release cycle so triaging a minor bug as something that doesn't stop shipping has very little down-side. I actually agree with the above statement. A release will contain a number of open issues, or errors yet to be found. But to me a failing unit test, is not a low priority bug because it shows that the project feel the tested functionality is important and if the unit test fails, the software will fail for some users. On the other hand, delaying by 3+ days is more than a 10% delay in the monthly release. Is there any demand that makes it nessecary to make an exact monthly releaseor can it be 3weeks sometimes and 5weeks other times ? Your characterization of this issue being a quality issue is also a bit of an over-statement. The problem was that several dependencies worked differently on Java8 than Java7. The fix involved changing the version of these dependencies. Changing dependency versions is not a small change and requires a full QA cycle since it takes serious thought to decide what impact the version change might have. The best way for that to happen in a reasonable way is to simply put this fix in the next release. My intentation was to raise a concern, NOT to block the release (I did on purpose give a 0 and not -1). I am sorry if you feel its an over-statement, but honestly for me failing unit tests and not checking a version dependency (in case of older versions) is cause for alarm. Java1.8 is not exactly brand new, so if the project depend on version 1.7, I really expect the software to check the installed version, and not simply blindly trust the users have installed whats required. In general when I read release notes stating a version, I assume that never versions are ok. I do agree that upgrading to a newer version requires more time and far more testing. I think the project is doing a fine job and look forward to give many +1 in the future, so please dont be upset that I point out something which I feel is important, especially since I do it in a politle way without blocking anything. rgds jan i.
Re: [VOTE] Apache Drill 0.6.0-incubating release
Jan, Your concern was a valid one and definitely one worth explanation. Please do not take my response as a rant from an upset soul :), rather an explanation towards why we chose to do what we did. I apologize if I sounded like one. We are, sometime, limited by the tools that we use and one such limitation of maven's unit test framework which Drill uses is that there is no clean way to enforce upper bound on Java version during test execution. And in the spirit of exploration and tinkering, among the core tenets of open source philosophy, I do not think we should block anyone from trying something unknown, a new platform in this case. We do though, test for and indicate for the known incompatibility. However, I do agree that a well defined list of supported platform helps minimize confusion and makes the users' life a tad easier. To that effect, we will keep the list up-to-date. We thank you and look forward to your participation in our discussions in future. Regards, aditya... On Tue, Oct 7, 2014 at 2:46 PM, jan i j...@apache.org wrote: Hi First let me make it clear I am not a java specialist, and secondly big thanks to both of you for explaining more in detail what the problem is. On 7 October 2014 21:24, Aditya a...@apache.org wrote: Hi Jan, The issue was discussed on the release voting thread and there seems to be an agreement in the community that it may not be worth holding the release to include Java 8 support since 1.) Among most of the users, as evident on the vote thread, very few are running Java 8 in dev and test environment and even fewer are running it in production. 2.) The changes that seem to fix the test failures involves moving to a very new release of few libraries which are tightly integrated with Drill's core functionality and hence we would like to test these a bit more before merging in to a release. very fair I would have done the same. 3.) With our goal to have shorter and more frequent (monthly) releases, we try to be little judicious with picking what issue could have a wider user impact and should be fixed immediately, vs something which affects a very small percentage of use cases. I agree with you in principle, but when the project have bothered to write a unit-test case, it means its an important functionality. 4.) And lastly, as Julian mentioned on the thread that the set of fixes might not be complete yet, I think we need more time before we can merge these changes in to a release with confidence to support a new platform. I agree with this, but it still does not explain why the software not simply deny runing with java1.7+. To me it seems a simple if during load could solve the problem, and is in general something a software should do with all dependencies especially when newer versions dont work (most of us expect newer versions to be backward compatible). I hope this persuades you to reconsider your position on this release candidate. I hope you noted, that I just raised a concern and did not block the release. Regards, aditya... On Tue, Oct 7, 2014 at 12:02 PM, Ted Dunning ted.dunn...@gmail.com wrote: On Tue, Oct 7, 2014 at 8:41 AM, jan i j...@apache.org wrote: It seems (from the vote thread) you already have solved the problem, but dont want to wait for a respin, can you please at least explain why the project is under such a time constraint, that 72 hours is too long to wait to make good quality. You have to make a cut somewhere. There are always a number of very small, low priority bugs and platform issues in any release. Drill is now on a monthly release cycle so triaging a minor bug as something that doesn't stop shipping has very little down-side. I actually agree with the above statement. A release will contain a number of open issues, or errors yet to be found. But to me a failing unit test, is not a low priority bug because it shows that the project feel the tested functionality is important and if the unit test fails, the software will fail for some users. On the other hand, delaying by 3+ days is more than a 10% delay in the monthly release. Is there any demand that makes it nessecary to make an exact monthly releaseor can it be 3weeks sometimes and 5weeks other times ? Your characterization of this issue being a quality issue is also a bit of an over-statement. The problem was that several dependencies worked differently on Java8 than Java7. The fix involved changing the version of these dependencies. Changing dependency versions is not a small change and requires a full QA cycle since it takes serious thought to decide what impact the version change might have. The best way for that to happen in a reasonable way is to simply put this fix in the next release. My intentation was to raise a concern, NOT
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Tue, Oct 7, 2014 at 2:46 PM, jan i j...@apache.org wrote: 4.) And lastly, as Julian mentioned on the thread that the set of fixes might not be complete yet, I think we need more time before we can merge these changes in to a release with confidence to support a new platform. I agree with this, but it still does not explain why the software not simply deny runing with java1.7+. To me it seems a simple if during load could solve the problem, and is in general something a software should do with all dependencies especially when newer versions dont work (most of us expect newer versions to be backward compatible). That is a plausible action. That would not have changed the fact of the failure under 1.8, it would merely have changed the error message. Until this issue was encountered, however, it was the assumption that the code would run on java8, but it was not considered important enough to specifically test since, as Aditya mentioned, java8 has essentially no production presence so far. As such, testing for java8 and refusing to start would simply guaranteeing failure as opposed to being open to success.
Re: [VOTE] Apache Drill 0.6.0-incubating release
On Tue, Oct 7, 2014 at 2:46 PM, jan i j...@apache.org wrote: My intentation was to raise a concern, NOT to block the release (I did on purpose give a 0 and not -1). I am sorry if you feel its an over-statement, but honestly for me failing unit tests and not checking a version dependency (in case of older versions) is cause for alarm. The response that you are getting is a measure of how seriously the Drill project takes community building and consensus.
Re: [VOTE] Apache Drill 0.6.0-incubating release
In case there is any confusion, the first email sent out in this thread had the wrong vote count. The second one has the correct count: +9 binding +3 non-binding I should also mention there was one -0 (binding). This was due to unit test failures when using java 1.8. Jiras were filed, and the fix will be included in the next release, not this one. On Sun, Oct 5, 2014 at 11:14 AM, Steven Phillips s...@apache.org wrote: I would like to present the Apache Drill 0.6.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 30 JIRAs closed in the last month. The vote thread can be found here:http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E The vote passed with: +9 binding +3 non-binding You can find the artifacts for the release at this location:http://people.apache.org/~smp/apache-drill-0.6.0.rc0/ I look forward to your feedback. Thanks, Steven -- Steven Phillips Software Engineer mapr.com
[VOTE] Apache Drill 0.6.0-incubating release
I would like to present the Apache Drill 0.6.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 30 JIRAs closed in the last month. The vote thread can be found here:http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E The vote passed with: +5 binding +6 non-binding You can find the artifacts for the release at this location:http://people.apache.org/~smp/apache-drill-0.6.0.rc0/ I look forward to your feedback. Thanks, Steven
[VOTE] Apache Drill 0.6.0-incubating release
I would like to present the Apache Drill 0.6.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 30 JIRAs closed in the last month. The vote thread can be found here:http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E The vote passed with: +9 binding +3 non-binding You can find the artifacts for the release at this location:http://people.apache.org/~smp/apache-drill-0.6.0.rc0/ I look forward to your feedback. Thanks, Steven
