My comment inline On Fri, May 27, 2016 at 9:00 AM, David Yan <[email protected]> wrote:
> This is an important change because not only will it help contributors who > want to contribute to Apex Malhar, it also helps users on deciding which > operators they can use. > Thanks > > 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. Thanks > David > > On Fri, May 27, 2016 at 7:13 AM, Amol Kekre <[email protected]> wrote: > > > This is a very good idea and will greatly help contributors. The > > requirements to submit code to this Malhar folder should be very > minimal. A > > few that come to my mind > > > > - Should compile > > - License of the external lib (if any) should be Apache compliant license > > // Need to see if this is part of ASF guidelines > > > > Everything else including naming, idempotency, performance, ... should be > > waived. > > > > Thks > > Amol > > > > > > On Thu, May 26, 2016 at 11:25 PM, Pramod Immaneni < > [email protected]> > > wrote: > > > > > As you all know the continued success and growth of an open source > > project > > > is dependent on new members joining the project and contributing. This > > will > > > depend on how accessible the project is for new folks to make > meaningful > > > contributions. For a project like ours where the code base has been in > > > development for years, it can be quite daunting for new members to just > > > pick up and make contributions. We need to find ways to make it easier > > for > > > people to do so. Malhar, namely the operator library, is an area where > > > people can contribute without requiring deep knowledge or expertise. > > > > > > We have seen operators take time to mature as evidenced by the road > taken > > > by some of our commonly used operators to reach production quality. > This > > is > > > due to the fact that apart from the core functionality the operator is > > > trying to implement there are many other aspects to address such as > > > performance, idempotency, processing semantics and scalability. It > would > > be > > > difficult even for folks familiar with all these aspects to get > > everything > > > right the first time around and produce comprehensive operators let > alone > > > first time contributors. At the same time operators cannot reach this > > > maturity level unless they get used in different scenarios and get a > good > > > look at by different people. In maturity I am also including API > > stability. > > > > > > I would like to propose creation of a space inside Malhar, a > sub-folder, > > > where contributions can first go in if they are not fully ready and > when > > > they mature can be moved out of the sub-folder into an existing module > > or a > > > new module of its own, the package paths can remain the same. The > > > evaluation bar for contributions into this space would be more > permissive > > > than it is today, it would require the functionality the operator was > > > developed for be working but will not necessitate that all fault > tolerant > > > and scalability aspects be addressed. It will also allow new operators > > that > > > are variations of existing operators till such time as we can determine > > if > > > the new functionality can be subsumed by the original operator or it > > makes > > > sense for the new operator to exist as a separate entity. It will be > > up-to > > > committers and contributors to work together and make the decisions as > to > > > whether the individual contributions go into this space or are ready to > > > just go into the regular modules. > > > > > > What does everyone think. > > > > > > Thanks, > > > Pramod > > > > > >
