As a keen R user I tried both branches, but I couldn’t make work Charles' 
version (maybe my mistake). I found some issue on Amos' version (mainly about 
charting), reported on his github page (he has suggested to test more 
extensively and report after merge - fair enough).

In conclusion I do not have sound enough elements to judge on which one is 
better. As I’m in favour of competition as a general principle, taking into 
account that they seem to be close to the finishing line I would suggest to 
merge each one and let users decide: I concur with Eran.

It would be useful (just to avoid similar occurrences in the future) to 
understand why we arrived here though.  How is it possible that a fundamental 
pr as R interpreter takes so long to be integrated?  I would humbly suggest for 
the future to give better treatment to the big hitting functionalities.  
Clearly the more a ‘big’ functionality is delayed, the more will be deemed 
attractive to develop alternative versions (some time better versions, some 
time equally useful).

Another consideration is the over present issue of graphics.  From an R 
standpoint, due to the extreme richness of its graphic offering, so far I found 
that no notebook is entirely satisfactory: for example the growing family of 
htmlwidgets are badly (or not) displayed in many cases. It would certainly 
benefit the community to invest time and activities on perfecting these issues, 
but so be it.


Enzo
e...@smartinsightsfromdata.com



> On 29 Feb 2016, at 12:36, Eran Witkon <eranwit...@gmail.com> wrote:
> 
> 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