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