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