I'll go ahead and remove it today.

On Thu, Oct 20, 2016 at 8:21 PM, Stephan Ewen <se...@apache.org> wrote:
> +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 <c...@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 <m...@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 <rmetz...@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 <u...@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
>> > >>
>> >
>>

Reply via email to