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