apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gaurav Gupta <gaurav.gopi...@gmail.com>
Subject Re: A proposal for Malhar
Date Fri, 27 May 2016 20:37:44 GMT
David,

Why do you want to have operators is new incubator  space that will never
be used?
My question what is this new incubator space going to provide that can't be
achieved by annotations?

Thanks
Gaurav

On Fri, May 27, 2016 at 1:20 PM, David Yan <david@datatorrent.com> wrote:

> 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