I am in favor of contrib too as long as it did not imply "license incompatible" issue in other Apache projects. I found the following
https://mail-archives.apache.org/mod_mbox/pig-user/201205.mbox/%3CCAB-acjMTZUy=8skp+aqdm4rj1ordbxynvjnmsfymjsdfdvp...@mail.gmail.com%3E https://cwiki.apache.org/confluence/display/PIG/PiggyBank https://issues.apache.org/jira/browse/HIVE-639 Looks like contrib is viable if we all decide to adopt that name. Thks Amol On Fri, May 27, 2016 at 9:23 AM, Pramod Immaneni <[email protected]> wrote: > I like the idea of using contrib for this end. > > On Fri, May 27, 2016 at 7:57 AM, Thomas Weise <[email protected]> > wrote: > > > That's a good proposal. Sounds like an "incubator" space inside Malhar. > > > > Originally that was the intention behind the contrib module. But now it > > contains many connectors that should be promoted to their own modules. > So a > > possible route would be to use contrib for early/evolving code and then > > promote as it matures. > > > > In any case the expectations need to be documented: > > > > http://apex.apache.org/contributing.html > > > > Currently these guidelines skip everything till submitting PR, we need to > > update them to give newcomers a better picture. > > > > Thomas > > > > > > 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 > > > > > >
