Thank you guys for actually answering the question! My personal opinion on making a progress here, and in further cases like that, lies with a plan C.
Please correct me if I'm wrong, but what I can see in this thread is a consensus around going further with plan C: merging contribution as soon as it is ready, without the need to block another contributions (as they have technical merit, of course) and let actual users decide. At this point, I'd really love to hear only from people that disagree with above and have strong opinions about that or think that the concerns they have raised before were not addressed properly. Thanks again, I really appreciate everyone's time, spent on this issue. -- Alex On Tue, Mar 1, 2016 at 1:02 PM, Jeff Steinmetz <jeffrey.steinm...@gmail.com> wrote: > I too was able to use R via PR 208 with success. > > I have it running as expected within the Virtual Machine outlined in this > updated PR > https://github.com/apache/incubator-zeppelin/pull/751/ > > > With the `repl` package (also installed via the VM script), plotting such > as native R histograms worked within the notebook display system as well. > So - this looks good to me. > > Not to oversimplify things, it “seems” this PR (or this PR and a future PR > for packaging) just needs: > - the packaging worked out (get the R scripts included in the > distribution) > - a few license additions to the rscala files (if they are not generated > but part of the base requirements) > - a profile addition such as -P r to only build with R binaries if > desired. > > Unless I am missing something, it could be merged with one final focused > effort. > Somebody could tweak the documentation a bit to match the tone of the > other interpreter docs post merge. > > Regards, > Jeff Steinmetz > Principal Architect > Akili Interactive > > > > On 2/29/16, 6:45 AM, "Sourav Mazumder" <sourav.mazumde...@gmail.com> > wrote: > > >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. > >> >>> > >> >> > >> > >> > >
