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 >> > >> >> > >>