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