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. >>
