Here's technical differences between 208 and 702. - 208 includes rscala depenency as a source, 702 download dependency library on buildtime - 208 placed in separate maven sub module r, 702 placed in existing spark submodule. - 208 creates another socket to communicate to interpreter, 702 does not - many more
It's enough to say implementations are technically different. Once they both merged, we can take each implementation's advantage and improve each other. If community want, they'll be eventually merged. If community see advantage of keeping both, they'll be co-exists. Multiple implementation for similar function can make some confusion. But confusion can be minimized in many different ways. e.g. Good documentation, build-time option, runtime option, etc. For this reason, I don't see any big problem on c) merging both 208 and 702 both, and possible different interpreter implementations in the future. Amos, Regarding progress of 208, 208 is not an exceptional PR that can be merged without CI pass. Could you accept this simple rule? I tried to help 208 making pass the test and shared my progress https://github.com/apache/incubator-zeppelin/pull/208#issuecomment-173423103 which passes CI with one profile. But you seems not like it. Okay. Then it has been always open you or anyone fix the problem 208 for last 6 months. and it'll always be. Nothing blocks anyone working on 208. Thanks, moon On Mon, Mar 7, 2016 at 12:30 PM Amos B. Elberg <amos.elb...@gmail.com> wrote: > Yes I do - I don’t see that there’s been *any* technical reason at all > raised in your email below, or in Alex’s. > > I think statements like this: “Technically implementation of 208 and 702 > are different. No reason to reject one because of the other while they're > not identical.” are nonsense. > > The burden is on you to explain the technical reason why 208 hasn’t been > merged already. Because all I see are delays and excuses. > > What are the objections to 208? The only objection came from, originally, > Felix Cheung, who came to you privately and asked you to hold-up the PR > because he wanted credit for work he hadn’t done so you would think that > he’s a programmer. > > So why hasn’t 208 been merged? Over the past six months, how many of my > “what remains to be done so this can be merged?” messages have been > ignored? > > Your explanation used to be because of CI. But, you committed to fix CI, > and then didn’t look at it. More recently Alex took a look, but hasn’t > made any progress. And now you want to merge 702, but 702 only looks like > it passes CI because it doesn’t have a testing suite! > > All this stuff about 702 is nonsense. 702 has no functionality not > present in 208. 702 is *based* on 208. 208 has functionality 702 does > not. 208 has been stable since September; 702 has broken, and had to have > its architecture reengineered to be more like 208, at least once. 208 has > a user base; 702 does not. > > *Numerous* users have asked specifically for 208. The only user requests > concerning 702, are people complaining they are confused because of two PRs > with similar functionality. How would merging both PRs make any sense? It > would only create more confusion. > > So why are you continuing to hold-up 208? > > -- > Amos Elberg > Sent with Airmail > > From: moon soo Lee <m...@apache.org> <m...@apache.org> > Reply: dev@zeppelin.incubator.apache.org > <dev@zeppelin.incubator.apache.org> <dev@zeppelin.incubator.apache.org> > Date: March 7, 2016 at 2:19:57 PM > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org> > <dev@zeppelin.incubator.apache.org> > Subject: Re: R interpreter in Zeppelin: further steps > > Amos, > > Do you see any single non technical reason being discussed for not merging > 208, in this thread or anywhere else? Please share them if you have. > > Thanks, > moon > > On Mon, Mar 7, 2016 at 10:21 AM Amos B. Elberg <amos.elb...@gmail.com> > wrote: > > > Moon, I thought you were staying out of this? > > > > It sure sounds like we're back on the same path we were on before, where > > there's just a series of excuses for not merging 208, none of which have > > any technical justification. > > > > > On Mar 7, 2016, at 1:11 PM, moon soo Lee <m...@apache.org> wrote: > > > > > > Hi, > > > > > > I agree on c), merge both, in my strong opinion. > > > > > > Regarding a) I agree on Eran, it's better let user and contributor > decide > > > them selves. > > > > > > For example, there can be other spark, sparkR interpreter > implementation > > > based on Apache Toree (incubating) [1] or Livy[2]. If someone > contribute > > > spark, sparkR interpreter based them, will we reject the contribution > > > because of existing one? No, absolutely. > > > > > > Technically implementation of 208 and 702 are different. No reason to > > > reject one because of the other while they're not identical. > > > > > > > > > Regarding b), Not only before we merge, we can always collaborate > after > > > merge both, to come up with one. Like JDBC interpreter trying to merge > > > every JDBC driver based interpreters. > > > > > > Thanks, > > > moon > > > > > > [1] http://toree.incubator.apache.org/ > > > [2] https://github.com/cloudera/hue/tree/master/apps/spark/java > > > > > > > > >> On Thu, Mar 3, 2016 at 5:41 PM Alexander Bezzubov <b...@apache.org> > > wrote: > > >> > > >> Thank you for sharing Jeff! > > >> > > >> Now it's time to speak out for anybody, who have strong opinion > against > > >> plan A, aka just merging #208 and moving on. > > >> > > >> I agree with Eran and Enzo - as we just building a community over > code > > >> here, > > >> passing judgements is not the best way to do it and it's up to users > to > > >> decide which option > > >> they are willing to use and for developers which one they want to > > >> contribute (given it has technical merit). > > >> > > >> I also like DuyHai approach, but making people do things does not > seem > > >> possible (at least for me). > > >> > > >> More important thing here is our ability to be an inclusive > meritocratic > > >> community, polite and respectful to individual members, and ability > to > > >> reach a consensus. > > >> > > >> > > >> So question: are there anybody, who have strong opinions against > going > > on > > >> with plan A? > > >> > > >> > > >> -- > > >> Alex > > >> > > >> On Thu, Mar 3, 2016 at 2: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. > > >>>> > > >>> > > >>> > > >> > > > >
