Very similar is my experience too. Could run PR 208 with least effort. And so far I am very successful to use it to create demonstrations covering end to end machine learning use cases in Zeppelin (showcasing how data can be shared across scala, SparkR, R easily where data preparation/model creation done in SparkR/Scala where as visualization in R) using PR 208 in different meetups and other forums.
Regards, Sourav On Mon, Feb 29, 2016 at 5:04 AM, enzo <e...@smartinsightsfromdata.com> wrote: > 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. > >>> > >> > >
