hawq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruilong Huo <h...@apache.org>
Subject [RESULT][VOTE]: Apache HAWQ 2.2.0.0-incubating Release (RC2) IPMC
Date Tue, 25 Apr 2017 15:20:09 GMT
Hi All,

The VOTE for releasing Apache HAWQ 2.2.0.0-incubating from IPMC is now
closed. With a total of -1 vote, the VOTE fails. Overall vote breakdown is
as follows:

+1 (binding)      0
----------------------------
NULL

+0 (binding)      0
----------------------------
NULL

-1 (binding)      1
----------------------------
Roman Shaposhnik

Thanks everyone, especially Roman, for taking the time to review and vote. The
major issue is the lack of LICENSE, NOTICE, and DISCLAIMER files in the
binary and redundant dependent libraries. We will address these issues and
prepare the artifacts for RC3. Details below:

on the binary portion of this releases. Here's why:
    1. The deal breaker issue is a total lack of clear IP attribution in
     binary artifacts. There's no proper LICENSE, NOTICE and
     DISCLAIMER file in neither the x86 binary package of HAWQ
     nor in the JAVA packages of companion components. This
     need to be fixed as per:
         http://www.apache.org/dev/licensing-howto.html#binary
         http://incubator.apache.org/guides/release-java.html#notes
     Note that you HAVE to account to all the dependencies you're
     bundling in a binary release which means your LICENSE and
     NOTICE files will likely get bigger. For Java side of HAWQ
     Apache Geode offers a good place to look for how to deal with
     those files in a binary distribution.

     2. This is one is less of a deal deal breaker for the first release,
but
     will be so for subsequent ones: you really shouldn't be shipping
     apache-tomcat package. For one, you already have a dependency
     on bigtop-tomcat in hawq-ranger-plugin which means shipping
     apache-tomcat is wasteful, could conflicting with distribution RPM
     names and frankly looks a bit sloppy coming from the same project.

     3. This is even less of a dealbreaker than #2, but it may help you
     simplify solving for #1: I don't think you need to ship all those
     extra dependencies in hawq-ranger-plugin -- a much better option
     is getting them from a classpath just like other Java packages of
     HAWQ do.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message