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. > > > >> >>> > > > >> >> > > > >> > > > >> > > > > > > > > > -- -- Kind regards, Alexander.
