apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amol Kekre <a...@datatorrent.com>
Subject Re: A proposal for Malhar
Date Fri, 27 May 2016 21:25:27 GMT
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+AqDM4Rj1oRDBxYnVJnmsFYmJSdFDVP6Lg@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 <pramod@datatorrent.com>
wrote:

> I like the idea of using contrib for this end.
>
> On Fri, May 27, 2016 at 7:57 AM, Thomas Weise <thomas@datatorrent.com>
> 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 <
> pramod@datatorrent.com>
> > 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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message