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