flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Ewen <se...@apache.org>
Subject Re: Removing flink-contrib/flink-operator-stats
Date Thu, 20 Oct 2016 18:21:55 GMT
+1 for removing it

  - It seems quite unstable (is responsible for almost all build failures
right now)
  - It is not integrated with the metric system. Having more metrics is
desirable, but is a separate effort and needs a different approach.

On Wed, Oct 19, 2016 at 4:23 PM, Greg Hogan <code@greghogan.com> wrote:

> Based on a cursory reading of FLINK-1297 I would lean toward dropping the
> code rather than moving to Apache Bahir. This looks to only be appropriate
> for batch and this module was not integrated into the runtime.
>
> If there is a way forward to make use this code in core Flink then that
> would be even better.
>
> On Wed, Oct 19, 2016 at 9:54 AM, Maximilian Michels <mxm@apache.org>
> wrote:
>
> > +1 for removing it in case it is not widely used. Apache Bahir would
> > be a more appropriate place for this module then.
> >
> > -Max
> >
> >
> > On Wed, Oct 19, 2016 at 3:52 PM, Robert Metzger <rmetzger@apache.org>
> > wrote:
> > > If there are no users and no contributors of the module, I'm +1 to
> remove
> > > it.
> > >
> > > If we decide to remove it from flink-contrib, but there are some
> > > contributors interested in it, I can offer to assist the contributors
> to
> > > add the extension to Apache Bahir.
> > >
> > > On Wed, Oct 19, 2016 at 2:00 PM, Ufuk Celebi <uce@apache.org> wrote:
> > >
> > >> Hey devs,
> > >>
> > >> I would like to propose the removal of the
> > >> flink-contrib/flink-operator-stats module.
> > >>
> > >> It is currently causing some build stability issues
> > >> (https://issues.apache.org/jira/browse/FLINK-4833) and there is no
> > >> active maintainer for it as far as I can tell.
> > >>
> > >> Are there any objections to this?
> > >>
> > >> I know it always feel bad to remove contributed code, but given the
> > >> size and scope of the project I think that it is fair to be
> > >> conservative about these issues. I think we always planned the contrib
> > >> module to be a staging area where we monitor the usefulness of
> > >> non-core additions.
> > >>
> > >> Best,
> > >>
> > >> Ufuk
> > >>
> >
>

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