David, I thought you wanted to add unused operators to incubator space :). I totally agree with you that Malhar should be cleaned by removing unused operators.
Gaurav On Fri, May 27, 2016 at 1:41 PM, David Yan <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> > 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 < > [email protected]> > > > 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 < > > [email protected]> > > > > 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 <[email protected] > > > > > > 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 > > > > >> > > > > > > > > > > > > > > > > > > > >
