Thank you everybody for expressing valuable opinions: Enzo, Amos, Jeff, Eran, Damien, Eric, Sourav, Luciano, DuyHai, Moon - I'm very glad to see the misunderstanding being finally resolved.
The solely purpose of this thread was to _document the community consensus_ and please correct me if I'm wrong, one can clearly see it here now: as Enzo suggested, let’s bygones be bygones and let's integrate these PRs asap in the usual way (which I tried to describe above as option C). Without any further delay, I'm happy to be able to spend time working on making R interpreters to meet a very few project's technical requirements that are left (tracked in PRs themselves) in order to get it merged. Thank you guys very much! -- Alex On Wed, Mar 9, 2016 at 9:04 PM, enzo <e...@smartinsightsfromdata.com> wrote: > I would like to re-express how I see the issue of a R interpreter in > Zeppelin. > > First of all I think it would be incredibly useful to have this > functionality: the ability of Zeppelin to select an interpreter at the cell > level, associated with the ability to “map” data from one interpreter to > the other brings Zeppelin to the forefront of the notebook movement. > Further delays could harm the success Zeppelin deserves (and the > competition is lurking). > > I expressed - and confirm - my favour for option c: merge PR 208 and 702 > ASAP (as in , yesterday?), then with extensive real road testing on each, > ideally decide to merge both into one solution in a year or so (maybe a > merged solution where you can select slightly different approaches using > interpreters parameters, or at least configuration parameters). > > Please note that my position is mainly driven by pragmatism: > From what I could test, from a R user point of view I consider the two PR > too similar to decide for one or the other. > On the other hand there are (minor) differences of approach that I would > like to explore more in-depth: I reserve to express my opinion at a later > stage after say writing >1,000 lines of code or more with each of them. > There is no chance with the heated debates we are currently have to come > up with a merged solution now. Besides, it would take too long (e.g. > debating incessantly over every single line of code). It would be great > but it is just not going to happen very soon. > > Abrasiveness aside, I also think that the community should recognise Amos > contribution on the R interpreter: regardless on any final decision on any > line of code (or PR) I think he has been a pioneer in developing this > functionality. Sadly with inexplicable delays etc. I am left with the > impression that he got a rough deal. > > But the community needs to move on: let’s bygones be bygones and let's > integrate these PRs (fast, please?). > > Enzo > e...@smartinsightsfromdata.com > > > > > On 8 Mar 2016, at 20:05, Amos B. Elberg <amos.elb...@gmail.com> wrote: > > > > Those are not the options people were voting on before, and they frankly > don't make sense. What was plan "a" before, was to merge 208 without > further delay. That's what people were voting for. > > > > The three new "options" leave out the one I had proposed, and which > people had voted for: merge 208 without more delay. If Eric or someone else > thinks it should be different, they can make a PR to change it. > > > > The only person who objected to that plan was Moon. > > > > That would be the normal way to do things. The normal way to do things > is to take a PR when it's ready, and if someone wants to make a change or > thinks it should be done differently, that's just another PR. Your options > "a" and "c" are therefore the same thing. What I proposed, and people voted > for, was exactly that, but also adding that 208 should be merged without > further delay. > > > > Option B, Eric rejected. In addition, 208 is only waiting on the ppmc to > fix CI and merge, so there's no reason for it now. > > > > I still don't see that there's been any purpose to this discussion. The > normal way to things, 208 should have been merged months ago. > > > > > >> On Mar 8, 2016, at 11:29 AM, Alexander Bezzubov <b...@apache.org> wrote: > >> > >> As we are waiting for answers on 2 question from prev. email (only from > >> those who _strongly disagres_ with plan C) > >> I have realized that one possible way of explanation for the lack of > >> consensus here may be the poor wording in the initial email that I used. > >> > >> Just want to clarify the discussed options, to make sure we all are on > the > >> same page: > >> > >> - A. Pick _only_ one of those and merge only it, discarding the second > >> option > >> > >> *Action items*: us, having a separate discussion thread (out of scope of > >> this thread), with very carefull comparison of both of them to pick the > one > >> to merge, which will take time and a lot of effort. > >> *Price for community**:* Huge. > >> Non-collaborative nature of this approach requires us, including PPMCs, > to > >> pass strong judgments and oppinions far beyond of basic requirements of > >> just getting code merge. This is counter-productive. As it is a > non-trivial > >> feature in question - it will require sharp expert opinions to build > >> a consensus, and potentially encourage more finger-pointing and blaming > >> instead of help and collaboration. > >> *Main benefit:* avoids user confusion? (not sure how big is that, as > >> there are plenty of other places for user confusion in Zeppelin as well) > >> > >> - B. ask authors of both of them to collaborate together > >> > >> *Action items:* authors collaborate in order to come up with a single > >> contribution that has benefit of not confusing user and have strengths > of > >> both contributions. > >> *Main benefit: *meritocratic, shows healthy collaboration between > >> community members, avoids user confusion > >> *Price **for comunity**: *unknown. Requires time for waiting for > >> collaboration to happen one day. > >> > >> - C. merge (potentially) each of them, but at least one, depending which > >> one is ready first and then let users\maintainers decide which one is > >> actually the best > >> *Action items: *just merge things as they are ready > >> (CI\doc\test\licensing). > >> *Price for community:* small\tolerable. A small price of user confusion > >> at first (very easy to overcome with docs), it also has a tolerable > price > >> of developers potentially maintaining both of them for a while. > >> *Main benefit* - Huge. > >> It is meritocratic, meaning that it shows that any contribution, given > that > >> it has technical merit, got accepted as soon as they meet basic project > >> quality requirements, after authors spend their time and effort on > building > >> something useful for a user. > >> > >> > >> I hope our mentors will correct me here if I'm wrong, but options "B" > and > >> "C" sounds like following the Apache Way to me. > >> "A" sounds like we need to start telling people what to do and judge > them, > >> instead of being open, inclusive "community over code". > >> > >> Sorry for the noise if that does not add anything, but hope that helps > to > >> clarify current situation. > >> > >> That being said, we are now waiting for an answers on 2 question from > prev. > >> email from people who _strongly disagres_ with plan C. > >> > >> -- > >> Alex > >> > >> On Wed, Mar 9, 2016 at 12:37 AM, Sourav Mazumder < > >> sourav.mazumde...@gmail.com> wrote: > >> > >>> Hi Alex, > >>> > >>> In case it helps taking the decision fast my vote would be for option a > >>> (pr 208). > >>> > >>> I thought one has to vote only if he/she is against option a. > >>> > >>> Regards, > >>> Sourav > >>> > >>>> On Mar 8, 2016, at 2:59 AM, Alexander Bezzubov <b...@apache.org> > wrote: > >>>> > >>>> Hi Amos, > >>>> > >>>> I'm sorry that you have to repeat yourself. > >>>> But in order to keep the discussion understandable to everybody, > >>> including > >>>> our mentors who can not follow all the thread in all mailing lists, > and > >>> for > >>>> us to reach a consensus without having a formal vote here, I have to > >>> kindly > >>>> ask you again: > >>>> > >>>> can you please write just 2 sentences, answering each question below: > >>>> 1. Why you think that plan C is not a good long-term meritocratic > >>> solution > >>>> that includes interest of everybody in this discussion (both users and > >>>> developers working on this feature, and not only yours as an original > >>>> author of 208) > >>>> > >>>> 2. If you think option C is not acceptable, what is the compromise > that > >>>> you suggest for the community, given what both, users and developers > have > >>>> spoken out in this thread. > >>>> (Keep saying "let's do A" - is not a compromise, it is your personal > >>>> opinion that you have already expressed in this thread and a tally > above > >>> is > >>>> in place to assure everybody that it has been heard) > >>>> > >>>> Please keep in mind the reason I ask you those questions - we are all > >>>> looking for the compromise here together, and so far it's only you who > >>> have > >>>> strong -1 on something that looks like a suitable solution for > everyone > >>>> else. > >>>> So as PPMC member I want to make sure that we try our best to respect > >>>> everybody's opinion here and that the raised concerns are addressed > >>>> properly, before moving further. > >>>> > >>>> Thanks. > >>>> > >>>> -- > >>>> Alex > >>>> > >>>> > >>>> > >>>>> On Tue, Mar 8, 2016 at 6:21 PM, Amos Elberg <amos.elb...@gmail.com> > >>> wrote: > >>>>> > >>>>> Alex: I believe I have repeatedly explained why C is not > meritocratic, > >>> and > >>>>> not good for anybody. In fact, it would only make worse the problem > >>> that > >>>>> many > >>>>> users have complained about -- confusion created by the presence of > 702. > >>>>> I do > >>>>> not believe I should have to repeat myself *again*. > >>>>> > >>>>>> Please correct me if I'm wrong, but at this poit one can see only > one > >>>>>> strong -1 for going on with plan C. > >>>>> > >>>>> You're wrong. No-one has advocated for C. You actually (apparently) > >>> want > >>>>> B. > >>>>> Moreover, no-one has given any justification for C or, for that > matter, > >>> B. > >>>>> > >>>>> Continuing this discussion, when there has been a consensus in favor > of > >>> A > >>>>> all > >>>>> along, is inconsistent with the management of an Apache project. > >>>>> Moreover, it > >>>>> is dishonest. > >>>>> > >>>>> If we are going to continue this discussion --- please put forward a > >>>>> simple, > >>>>> clear explanation of what in 702 leads you -- or anyone -- to think > that > >>>>> including 702 would add anything to Zeppelin at all, if 208 is > merged. > >>>>> > >>>>>> On Tuesday, March 08, 2016 08:11:47 AM Alexander Bezzubov wrote: > >>>>>> Eric, > >>>>>> thank you for chimming in and I'm sorry for miss-information on 702! > >>>>>> > >>>>>> To be honest, I totally agree on your point on B. That would be the > >>> best > >>>>> of > >>>>>> all worlds, but given the time and input from other participants the > >>>>>> concensus over B seems to be hard to reach. I would love to > contribute > >>> in > >>>>>> B, but if its not possible, C sounds like a way to go to me. > >>>>>> > >>>>>> Please correct me if I'm wrong, but at this poit one can see only > one > >>>>>> strong -1 for going on with plan C. > >>>>>> > >>>>>> I want to ask Amos to give > >>>>>> - the concise gist of why he thinks plan C is not a good > meritocratic > >>>>>> solution for everybody (without mentioning any other people, please) > >>>>>> - and what is the compromiss he suggests, given what the community > have > >>>>>> spoken out > >>>>>> > >>>>>> -- > >>>>>> Alex > >>>>>> > >>>>>>> On Tue, Mar 8, 2016, 16:21 Eric Charles <e...@apache.org> wrote: > >>>>>>> Small precisions on #702: > >>>>>>> > >>>>>>> (snip...) > >>>>>>> > >>>>>>>> - 702 > >>>>>>>> > >>>>>>>> * CI fails > >>>>>>> > >>>>>>> Just pushed and it is failing for non R related reasons... > >>>>>>> > >>>>>>> Most importantly, I have seen since a few days that the test are no > >>>>> more > >>>>>>> executed for the spark interpreter for all PR builds > >>>>>>> > >>>>>>> [INFO] --- maven-surefire-plugin:2.17:test (default-test) @ > >>>>>>> zeppelin-spark --- > >>>>>>> [INFO] Tests are skipped. > >>>>>>> > >>>>>>> Will have a look at it. > >>>>>>> > >>>>>>>> * no tests > >>>>>>> > >>>>>>> There is some test > >>> > https://github.com/datalayer/zeppelin-datalayer/blob/rscala-z/spark/src/te > >>>>>>> st/java/org/apache/zeppelin/spark/SparkRInterpreterTest.java> > >>>>>>>> * no docs > >>>>>>> > >>>>>>> There is some doc > >>> > https://github.com/datalayer/zeppelin-datalayer/blob/rscala-z/docs/interpr > >>>>>>> eter/R.md> > >>>>>>>> That being said, my personal opinion is that we should follow C, > and > >>>>>>>> #208 > >>>>>>>> there has more chances of being merged first. > >>>>>>>> > >>>>>>>> Again, the goal is not to compare both contributions in terms of > >>>>>>>> features/merit and decide here which is better, but to build a > >>>>> consensus > >>>>>>> > >>>>>>> on > >>>>>>> > >>>>>>>> how we as a community proceed in situation of two contributions of > >>>>> same > >>>>>>>> pluggable feature. In this thread, it means to have no -1s for > for at > >>>>>>> > >>>>>>> least > >>>>>>> > >>>>>>>> one option, though a thoughtful compromise from all sides. > >>>>>>>> > >>>>>>>> What do you guys think? > >>>>>>> > >>>>>>> I would favor b) but this may take too much time, so to get users > the > >>>>>>> best choice as soon as possible, c) sounds to me like the way to > go. > >>>>>>> > >>>>>>>> With PPMC hat on, I feel that we may need to start a separate > thread > >>>>> for > >>>>>>> > >>>>>>> a > >>>>>>> > >>>>>>>> generalised decidion-making process in such situation, irrigating > of > >>>>>>>> current state of issue with R interpreter. And after a making a > >>>>> decision > >>>>>>>> there, we could use the same guiding principle to resolve this > >>>>> issue, as > >>>>>>>> well as any other one in the future. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Alex > >>>>>>>> > >>>>>>>> On Tue, Mar 8, 2016 at 2:45 PM, Jeff Steinmetz < > >>>>>>> > >>>>>>> jeffrey.steinm...@gmail.com> > >>>>>>> > >>>>>>>> wrote: > >>>>>>>>> I should clarify my preference regarding Plan A (to only merge 1 > - > >>>>> at > >>>>>>>>> least initially). > >>>>>>>>> “Which” PR to merge (or merge first) is TBD - at least for > myself. > >>>>> I’m > >>>>>>>>> still testing both PR options. > >>>>>>>>> Since the original request was not to debate the > >>>>> fate\merit\features of > >>>>>>>>> any particular contribution in this thread, I’ll post my 702 PR > >>>>>>>>> findings > >>>>>>>>> separately. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ---- > >>>>>>>>> Jeff Steinmetz > >>>>>>>>> Principal Architect > >>>>>>>>> Akili Interactive > >>>>>>>>> www.akiliinteractive.com <http://www.akiliinteractive.com/> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 3/2/16, 9:12 PM, "Jeff Steinmetz" < > jeffrey.steinm...@gmail.com> > >>>>>>> > >>>>>>> wrote: > >>>>>>>>>> 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. > >>> > > > >
