I think we should ask ourselves what is the guiding principle here, for
example, if in the future I want to create yet another JDBC interpreter or
Flink interpreter, should I only extend the one that already exist or can I
create my own and let the user community decide? realistically I don't
think we can control where people invest their time and contribution and as
long as it has no licencing issues and align with other project guidance it
should be up to the users to decide.

Eran W

On Mon, Feb 29, 2016 at 2:13 PM DuyHai Doan <doanduy...@gmail.com> wrote:

> Hello Alexander
>
> My opinion is no one, unless being an expert with R, is able to judge the
> quality of both contributions apart from the authors themselves. So let's
> make them work together to merge 2 PR into a good one.  Those PR,
> especially the #208 has been there for a while and it's high time they get
> merged so the community can move on.
>
> Unless there are R experts in the Zeppelin community and so they should
> speak to give their own opinions.
>
> My 2 cents
>
> Duy Hai DOAN
>
> On Mon, Feb 29, 2016 at 1:04 PM, Alexander Bezzubov <b...@apache.org>
> wrote:
>
> > Hi fellow Zeppelin community members,
> >
> > as you know, we have 2 contributions for ZEPPELIN-156
> > <https://issues.apache.org/jira/browse/ZEPPELIN-156> AKA R
> > <https://github.com/apache/incubator-zeppelin/pull/208> interpreter
> > <https://github.com/apache/incubator-zeppelin/pull/702>.
> > Both have merit, so wearing my PPMC hat, I'd like to suggest us to make a
> > decision, how we move forward with it avoiding user confusion.
> >
> > Here is what we can do:
> >  - a. pick only one of those and merge it
> >  - b. ask authors of both of them to collaborate together and come up
> with
> > one
> >  - c. merge each, as soon as it's ready and let users\maintainers decide
> > which one is best at the end
> >
> > This is not an official VOTE (which is possible to arrange, but is rather
> > bad way to build a consensus).
> >
> > It is a discussion, aimed to see if we all, as community, can build a
> > consensus together cooperatively -  meaning, *everyone compromises
> > something *and* there are no really strong opinions against the final
> > plan*.
> >
> > I specifically DO NOT ask which one is better, have more features, etc,
> > etc, etc.
> > What I ask for are opinions on a community way of reconciling this
> > situation and moving project forward together.
> >
> > What do you think?
> >
> > --
> > Kind regards,
> > Alexander.
> >
>

Reply via email to