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