hawq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noa Horn <nh...@pivotal.io>
Subject Re: Propose an Apache HAWQ Release
Date Thu, 24 Dec 2015 00:56:05 GMT
Regarding 2 (gradle), thank you for the reference. I will open a JIRA for
Do we have to credit bigtop or can we just take the file as is?

On Wed, Dec 23, 2015 at 4:39 PM, Roman Shaposhnik <roman@shaposhnik.org>

> On Fri, Dec 18, 2015 at 11:04 AM, Ting(Goden) Yao <tyao@pivotal.io> wrote:
> > I just tagged "2.0.0-beta-incubating-RC2" based on latest commit:
> >
> https://github.com/apache/incubator-hawq/commit/b6cb39c37e83fb5ee542b9f953c3a5e28e4617eb
> This looks *much* better than RC1. Great progress, team!
> Still a few things are left that need to be addressed:
>    0. Content of  tools/bin/pythonSrc doesn't look good to me.
>    There's GPL stuff in there that absolutely MUST be purged
>    from our repo. There are a few things under MIT and BSD
>    licenses in there as well, but since you will have to come up
>    with a solution for GPL archives you may as well get rid of
>    all of them.
>    1. netperf-2.4.3.tar.gz needs to be removed. It is under a specific
>    license from HP and we can't carry it in the tarball release of HAWQ
>    2. I still think that we need to get rid of Gradle jar. In order to
> solve
>    boostraping problem you can either use the approach Bigtop is taking:
>           https://github.com/apache/bigtop/blob/master/gradlew#L18
>    (just replace your gradelw with Bigtop's). Or you can mandate Gradle.
>    3. I really appreciate RAT integration, but looking at the exclude list
>    I don't think the following belongs there:
>              <exclude>**/*.mk</exclude>
>              <exclude>**/*.mak</exclude>
>              <exclude>**/*.yaml</exclude>
>              <exclude>**/*.m4</exclude>
>              <exclude>config/*</exclude>
>              <exclude>**/*.rc</exclude>
>              <exclude>**/*.f</exclude>
>              <exclude>**/Makefile*</exclude>
>    Instead of wholesale exclusion like that I'd like to see exclusion
> based on
>    subtrees of the source tree. IOW, if a file that matches one of the
> above
>    masks comes from PG just mark it so and mark a folder. Excluding a whole
>    class of files based on extension makes RAT less useful in the future.
>    4. In general, I'd like to see the exclude list for RAT be more
> structured
>    and concise. It is currently 446 entries long and pretty much impossible
>    to review properly.
> Thanks,
> Roman.

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