Mailing-List: contact dev-help@apex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apex.apache.org
MIME-Version: 1.0
In-Reply-To: <CAJpToqemZ7S_Ki=mQ1A5gCPiWaE5BqOhKuxmy5Vyex=N6KAdSw@mail.gmail.com>
References: <CAA7LveFjaN7Fd0OjRoGyOUgfqCEJbkxPVDdm+DDr28xe4duOcw@mail.gmail.com>
 <CAMaZnT5bJ6isrSrZrb2Y8jAWz_0Oi2isXtiTzwaeQq32SbpgVg@mail.gmail.com>
 <CAMqituNCrMO4U6kgyuiucsr=5Z57xd4wt19N+KsjYxRwnf_fdg@mail.gmail.com>
 <CAA7LveGK=9XM2+Ux_+ixzcNZ0_HM6oE=uVc-xMdWQV_=qKPLRQ@mail.gmail.com>
 <CAKJfLDPDg9Py3DaMSGGDHo+F9CgfDo5J-W2OhshKPn41wByvWw@mail.gmail.com>
 <CAMqituN9MtW2o+sUSm3nbhk0D17SgVp32aaUDPOar=94+AWbdg@mail.gmail.com> <CAJpToqemZ7S_Ki=mQ1A5gCPiWaE5BqOhKuxmy5Vyex=N6KAdSw@mail.gmail.com>
From: Gaurav Gupta <gaurav.gopi123@gmail.com>
Date: Fri, 27 May 2016 13:13:27 -0700
Message-ID: <CAJpToqcVcefS+BqjM2mG1A8g8FWh=mzstkXqX87AmTHRJoqdeg@mail.gmail.com>
Subject: Re: A proposal for Malhar
To: dev@apex.apache.org
Content-Type: multipart/alternative; boundary=001a114b13ee8ad4f30533d88c8a
archived-at: Fri, 27 May 2016 20:14:13 -0000

--001a114b13ee8ad4f30533d88c8a
Content-Type: text/plain; charset=UTF-8

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

--001a114b13ee8ad4f30533d88c8a--