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