flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Saputra <henry.sapu...@gmail.com>
Subject Re: Question on providing CDH packages
Date Fri, 15 Aug 2014 21:45:40 GMT
Ah sorry Alan, did not see your reply to Owen.

Mea culpa from me.

- Henry

On Fri, Aug 15, 2014 at 2:15 PM, Alan Gates <gates@hortonworks.com> wrote:

> Sorry, apparently this was unclear, as others asked the same question.
> Flink hasn't had any Apache releases yet.  I was referring to the proposed
> release that Robert sent out,
> http://people.apache.org/~rmetzger/flink-0.6-incubating-rc7/
> Alan.
>   Sean Owen <srowen@gmail.com>
>  August 15, 2014 at 11:26 AM
> PS, sorry for being dense, but I don't see vendor packages at
> http://flink.incubator.apache.org/downloads.html ?
> Is it this page?
> http://flink.incubator.apache.org/docs/0.6-SNAPSHOT/building.html
> That's more benign, just helping people rebuild for certain distros if
> desired. Can the example be generified to refer to a fictional "ACME
> Distribution"? But a note here and there about gotchas building for
> certain versions and combos seems reasonable.
> I also find this bit in the build script, although vendor-specific, is
> a small nice convenience for users:
> https://github.com/apache/incubator-flink/blob/master/pom.xml#L195
>   Owen O'Malley <omalley@apache.org>
>  August 15, 2014 at 11:01 AM
> As a mentor, I agree that vendor specific packages aren't appropriate for
> the Apache site. (Disclosure: I work at Hortonworks.) Working with the
> vendors to make packages available is great, but they shouldn't be hosted
> at Apache.
> .. Owen
>   Sean Owen <srowen@gmail.com>
>  August 15, 2014 at 10:32 AM
> I hope not surprisingly, I agree. (Backstory: I am at Cloudera.) I
> have for example lobbied Spark to remove CDH-specific releases and
> build profiles. Not just for this reason, but because it is often
> unnecessary to have vendor-specific builds, and also just increases
> maintenance overhead for the project.
> Matei et al say they want to make it as easy as possible to consume
> Spark, and so provide vendor-build-specific artifacts and such here
> and there. To be fair, Spark tries to support a large range of Hadoop
> and YARN versions, and getting the right combination of profiles and
> versions right to recreate a vendor release was kind of hard until
> about Hadoop 2.2 (stable YARN really).
> I haven't heard of any formal policy. I would ask whether there are
> similar reasons to produce pre-packaged releases like so?
>   Alan Gates <gates@hortonworks.com>
>  August 15, 2014 at 10:24 AM
>  Let me begin by noting that I obviously have a conflict of interest since
> my company is a direct competitor to Cloudera.  But as a mentor and Apache
> member I believe I need to bring this up.
> What is the Apache policy towards having a vendor specific package on a
> download site?  It is strange to me to come to Flink's website and see
> packages for Flink with CDH (or HDP or MapR or whatever).  We should avoid
> providing vendor specific packages.  It gives the appearance of preferring
> one vendor over another, which Apache does not want to do.
> I have no problem at all with Cloudera hosting a CDH specific package of
> Flink, nor with Flink project members working with Cloudera to create such
> a package.  But I do not think they should be hosted at Apache.
> Alan.
> --
> Sent with Postbox <http://www.getpostbox.com>
> NOTICE: This message is intended for the use of the individual or entity
> to which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.

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