Hey guys,
I think the JIRA associated to this discussion needs some attention:
https://issues.apache.org/jira/browse/FLINK-1452
On Mon, Jan 26, 2015 at 2:24 PM, Max Michels wrote:
> +1 for having an optional flink-contrib maven dependency and an
> extension repository in the long run.
>
> On M
+1 for having an optional flink-contrib maven dependency and an
extension repository in the long run.
On Mon, Jan 26, 2015 at 12:00 PM, Robert Metzger wrote:
> I've added a JIRA issue to create the module:
> https://issues.apache.org/jira/browse/FLINK-1452
>
>
> On Mon, Jan 26, 2015 at 11:39 AM,
I've added a JIRA issue to create the module:
https://issues.apache.org/jira/browse/FLINK-1452
On Mon, Jan 26, 2015 at 11:39 AM, Till Rohrmann
wrote:
> +1 for Robert's proposal.
>
> On Mon, Jan 26, 2015 at 5:43 AM, Henry Saputra
> wrote:
>
> > +1 for the idea.
> >
> > We need to make sure PMC
+1 for Robert's proposal.
On Mon, Jan 26, 2015 at 5:43 AM, Henry Saputra
wrote:
> +1 for the idea.
>
> We need to make sure PMC of Flink maintains knowledge of standard
> Flink distribution, hence the "flink-contrib" should not be part of
> the release.
>
> - Henry
>
> On Sun, Jan 25, 2015 at 10
+1 for the idea.
We need to make sure PMC of Flink maintains knowledge of standard
Flink distribution, hence the "flink-contrib" should not be part of
the release.
- Henry
On Sun, Jan 25, 2015 at 10:33 AM, Robert Metzger wrote:
> I'm also in favor of option 1) with a "flink-contrib" maven modul
+1 to what robert said
On Sun, Jan 25, 2015 at 8:54 PM, Kostas Tzoumas wrote:
> +1 for a package repository in the long run as per Ted's suggestion, and
> moving forward with what Robert proposes
>
> On Sun, Jan 25, 2015 at 10:33 AM, Robert Metzger
> wrote:
>
>> I'm also in favor of option 1) wi
+1 for a package repository in the long run as per Ted's suggestion, and
moving forward with what Robert proposes
On Sun, Jan 25, 2015 at 10:33 AM, Robert Metzger
wrote:
> I'm also in favor of option 1) with a "flink-contrib" maven module.
>
> I agree with Ted that we should certainly think abou
I'm also in favor of option 1) with a "flink-contrib" maven module.
I agree with Ted that we should certainly think about establishing a highly
visible, easy to contribute and easy to use infrastructure for all kinds of
contributions around the project.
But I suspect that we need some time to come
As the community of flink add-ons grows, a CPAN or maven-like mechanism
might be a nice option. That would let people download and install
extensions very fluidly.
The argument for making Apache contributions is definitely valid, but the
argument for the agility of fostering independent projects
I am also more in favor of option 1).
2015-01-24 20:27 GMT+01:00 Kostas Tzoumas :
> Thanks Fabian for starting the discussion.
>
> I would be biased towards option (1) that Stephan highlighted for the
> following reasons:
>
> - A separate github project is one more infrastructure to manage, and i
Thanks Fabian for starting the discussion.
I would be biased towards option (1) that Stephan highlighted for the
following reasons:
- A separate github project is one more infrastructure to manage, and it
lives outside the ASF. I would like to bring as much code as possible to
the Apache Software
Yes, a "flink-contrib" project would be great.
We have two options:
1) Make it part of the flink apache project.
- PRO this makes it easy to get stuff for users
- CONTRA this means stronger requirements on the code, blocker for code
that uses dependencies under certain licenses, etc.
2) Make
I think top level maven module called "flink-contrib" is reasonable. There are
other projects having contrib package such as Akka, Django.
Regards, Chiwan Park (Sent with iPhone)
2015. 1. 24. 오후 7:15 Fabian Hueske 작성:
> Hi all,
>
> we got a few contribution requests lately to add cool but "no
Hi all,
we got a few contribution requests lately to add cool but "non-core"
features to our API.
In previous discussions, concerns were raised to not bloat the APIs with
too many "shortcut", "syntactic sugar", or special-case features.
Instead we could setup a place to add Input/OutputFormats, c
14 matches
Mail list logo
