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:41:12 GMT
I think you misunderstood what I said.
For operators that will never be used and have no potential to improve, my
opinion is to remove them completely.
I am not against using the annotations in place of the incubator space.

David

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

> 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