apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Yan <da...@datatorrent.com>
Subject Re: A proposal for Malhar
Date Fri, 27 May 2016 20:20:33 GMT
Yes, we can certainly do that for operators that have the potential to be
up to par.

But we know that there are also many operators that are not likely to be
used in a real use case and will probably not change.  Examples include
most operators in lib/math and lib/algo.

It's not helpful to have them stay in the repository.

David

On Fri, May 27, 2016 at 1:13 PM, Gaurav Gupta <gaurav.gopi123@gmail.com>
wrote:

> To add to my previous mail,
> Contributor can add
> org.apache.hadoop.classification.InterfaceStability.Evolving
> / org.apache.hadoop.classification.InterfaceStability.Unstable annotations
> to operator and list of JIRAs in documentation that are being tracked to
> move the given operator to stable state...
>
>
> On Fri, May 27, 2016 at 1:05 PM, Gaurav Gupta <gaurav.gopi123@gmail.com>
> wrote:
>
> > Can same goal not be achieved by
> > using org.apache.hadoop.classification.InterfaceStability.Evolving /
> > org.apache.hadoop.classification.InterfaceStability.Unstable annotation?
> >
> > On Fri, May 27, 2016 at 12:35 PM, David Yan <david@datatorrent.com>
> wrote:
> >
> >> >
> >> > >
> >> > > >
> >> > > > Malhar in its current state, has way too many operators that
fall
> in
> >> > the
> >> > > > "non-production quality" category. We should make it obvious
to
> >> users
> >> > > that
> >> > > > which operators are up to par, and which operators are not, and
> >> maybe
> >> > > even
> >> > > > remove those that are likely not ever used in a real use case.
> >> > > >
> >> > >
> >> > > I am ambivalent about revisiting older operators and doing this
> >> exercise
> >> > as
> >> > > this can cause unnecessary tensions. My original intent is for
> >> > > contributions going forward.
> >> > >
> >> > >
> >> > IMO it is important to address this as well. Operators outside the
> play
> >> > area should be of well known quality.
> >> >
> >> >
> >> I think this is important, and I don't anticipate much tension if we
> >> establish clear criteria.
> >> It's not helpful if we let the old subpar operators stay and put up the
> >> bars for new operators.
> >>
> >> David
> >>
> >
> >
>

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