I too prefer plan A - merging two different R interpreters sounds like a maintenance and documentation headache for end users.
Do you or the community feel there are “specific” additional steps from a “technical” or “development” perspective that need to happen in order merge 208? If we know what’s holding back the merge technically (all history aside) we can work as a community to solve it. Olympic spirit! Looking forward to helping this through. ---- Jeff Steinmetz Principal Architect Akili Interactive On 3/2/16, 8:14 PM, "Amos Elberg" <amos.elb...@gmail.com> wrote: >Alex -- the gist of my email is that we already have a consensus, and have had >a consensus since November. The consensus was to merge 208. That's "Plan A." > >With all respect, I don't see that anyone other than you believes we don't >have a consensus on Plan A already, or has any issue with Plan A. > >In fact, I'm going to call now for "lazy consensus" on Plan A: End the debate >and move rapidly to merge 208, completing whatever work is necessary to do >that (if any). > >For the record, yes, I do object to Plan C. Numerous users have complained >that with two different PRs, they don't know which interpreter to use. That's >a strong reason to not merge two. In fact it will confuse people more, because >one interpreter's R environment won't be shared with the other interpreter, >and you can't move variables between them. Moreover, no-one has presented any >benefit to merging the second one. > >In addition, while 208 seems to be ready to merge (waiting only on the work >you're doing on CI), the second PR is nowhere close. So, that's another >reason: 208 should not have to wait for the other to be ready. > >But in any event, I disagree that there is any issue here. > >If you intend to continue this thread, then please address the issues raised >in my e-mail earlier. Please also explain any strong objection to Plan A. > >Thanks, > >-Amos > >On Thursday, March 03, 2016 12:09:33 PM Alexander Bezzubov wrote: >> Guys, please let's keep the discussion focused on the subject. >> >> Amos, I do not understand, are you saying that you do object on the >> community proceeding with plan C? If not - there is no need to answer\post >> in this thread right now. >> >> Again, we are not debating fate\merit\features of any particular >> contribution here. >> >> Please post in this thread only if you strongly disagree with the suggested >> plan. >> I'm calling for a lazy consensus and as soon as there are no objections - >> will be ready to proceed with the plan above. >> >> Sooner we reach a consensus on the topic - sooner we can make further >> progress. >> >> -- >> Alex >> >> On Thu, Mar 3, 2016 at 11:45 AM, Amos Elberg <amos.elb...@gmail.com> wrote: >> > Alex - What are we still debating at this point? >> > >> > I'm starting to feel like Charlie Brown with the football here. >> > >> > The PR was submitted in August and originally reviewed at the beginning of >> > September. >> > In, I think, early December, it was then extensively reviewed and >> > discussed. I made a few requested changes, and at that time there was a >> > decision to merge 208 pending Moon working on the CI problem. >> > In January the PR was reviewed again, by you and others, and I thought >> > you'd decided to merge pending some changes from me, and you were going to >> > work on CI. >> > In February, when people continued to email the list to ask what was up, >> > we >> > said again that the community was moving to merge 208. >> > The thread started a few days ago. Nobody argued for changing the plan. >> > The discussion lapsed until, today, I responded to a technical point. >> > >> > I'm not sure why this is coming up again. If Eric (or others) feel >> > strongly about the issues Eric raised with 208, which is things like >> > whether to link rscala or fork it (or whatever), why can't they just >> > submit >> > PRs with those change after 208 is merged? The architectures of the two >> > PRs have been converging as Eric's been incorporating functionality. >> > No-one claims that Eric's interpreter provides any additional >> > functionality, or that its more stable, or anything like that. So why are >> > we still talking about this? >> > >> > If the issue is that Eric put in substantial work, that was a choice he >> > made after he knew the status of 208. He also had the benefit of seeing >> > how I solved various technical problems, like using rscala, sharing the >> > Spark Context, etc. In fact, when I first started on this project, I saw >> > that Eric had done some preliminary work, and wrote him to see if we could >> > collaborate. He wasn't interested. In November, when I heard that >> > Datalayer had produced an interpreter (I didn't realize Datalayer is Eric) >> > I wrote them offering to work together. No reply. And in December also. >> > No reply. Eric didn't even submit the PR until after there was already a >> > consensus to merge 208. His PR only started to approach feature parity in >> > the last few weeks, after we decided *again* to try to merge 208. >> > >> > Someone commented earlier in this thread that we need to get this resolved >> > so the community can move on. I agree. I want to move on also. >> > >> > Is there any substantial reason at this point why we're revisiting the >> > issue instead of simply trying to merge 208? Is there any reason not to >> > view the discussion in this email chain as resolved in favor of merging >> > 208 >> > and moving forward? Is there anything you're waiting on me for that you >> > need so 208 can get merged? What, at this point, is left to be done so >> > 208 >> > can be merged? >> > >> > On Wed, Mar 2, 2016 at 7:53 PM, Alexander Bezzubov <b...@apache.org> wrote: >> > > 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. >
