R interpreter in Zeppelin: further steps

[Alexander Bezzubov <bz...@apache.org>]

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.

Re: R interpreter in Zeppelin: further steps

[Amos Elberg <am...@gmail.com>]

I want to explain the issue that @enzo raises regarding htmlwidgets.  

Both R interpreters support a variety of html widgets, because they use the 
"knitr" package, which acts as a bridge for many interactive vis packages.

Neither, however, supports the "htmlwidgets" R package.  The reason is that 
"htmlwidgets" visualizations use javascript and css that has indirect 
dependencies, which knitr does not handle.  When people use the htmlwidgets 
package in R, they typically use a package called "rmarkdown." rmarkdown wraps 
knitr and passes content through pandoc, which imports the indirect 
dependencies.  

I looked, but have not been able to find an external library that could handle 
the indirect dependencies, other than pandoc.  The issue with pandoc is that 
it is a heavy package that writes a lot of temp files to disc, and the 
performance impact is significant.  If there is demand for this, I did have it 
working at one point.  

I also spent a good amount of time trying to implement code to handle the 
indirect dependencies in R or scala.  It's a highly non-trivial problem. 

There is also a third kind of R interactive vis package, packages based on the 
"shiny" R package.  shiny widgets have to be able to communicate with a 
running R instance through websockets.  Since R is not multi-threaded, the 
same R process that communicates with Zeppelin can't be used as a shiny 
server.  We could try to spawn a separate process, but then how would we keep 
a consistent environment among notebook cells?  

The potential payoff from supporting shiny is, I think, pretty huge.  But 
finding a way to support it is challenging.  My intention has been, after the 
interpreter is merged, to reach out to the authors of shiny, and see if there 
is an interest in collaborating to solve the problem. 

On Monday, February 29, 2016 01:04:47 PM enzo 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
> enzo@smartinsightsfromdata.com
> 
> > On 29 Feb 2016, at 12:36, Eran Witkon <er...@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 <do...@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 <bz...@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.

Re: R interpreter in Zeppelin: further steps

["Amos B. Elberg" <am...@gmail.com>]

Alex - what is the eta on the work on ci for 208? This has been (supposedly) preventing merge since September, and we haven't seen any progress at all. 

Fixing ci does not need to wait on changes to address the recent re-engineering of the Interpreter architecture. 

208 should not be forced to wait for 702. 

> On Mar 10, 2016, at 7:30 AM, Alexander Bezzubov <bz...@apache.org> wrote:
> 
> Thank you everybody for expressing valuable opinions: Enzo, Amos, Jeff,
> Eran, Damien, Eric, Sourav, Luciano, DuyHai, Moon - I'm very glad to see
> the misunderstanding being finally resolved.
> 
> The solely purpose of this thread was to _document the community consensus_
> and please correct me if I'm wrong, one can clearly see it here now: as Enzo
> suggested, let’s bygones be bygones and let's integrate these PRs asap in
> the usual way (which I tried to describe above as option C).
> 
> Without any further delay, I'm happy to be able to spend time working on
> making R interpreters to meet a very few project's technical requirements
> that are left (tracked in PRs themselves) in order to get it merged.
> 
> Thank you guys very much!
> 
> --
> Alex
> 
> 
> 
>> On Wed, Mar 9, 2016 at 9:04 PM, enzo <en...@smartinsightsfromdata.com> wrote:
>> 
>> I would like to re-express how I see the issue of a R interpreter in
>> Zeppelin.
>> 
>> First of all I think it would be incredibly useful to have this
>> functionality: the ability of Zeppelin to select an interpreter at the cell
>> level, associated with the ability to “map” data from one interpreter to
>> the other brings Zeppelin to the forefront of the notebook movement.
>> Further delays could harm the success Zeppelin deserves (and the
>> competition is lurking).
>> 
>> I expressed - and confirm - my favour for option c: merge PR 208 and 702
>> ASAP (as in , yesterday?), then with extensive real road testing on each,
>> ideally decide to merge both into one solution in a year or so (maybe a
>> merged solution where you can select slightly different approaches using
>> interpreters parameters, or at least configuration parameters).
>> 
>> Please note that my position is mainly driven by pragmatism:
>> From what I could test, from a R user point of view I consider the two PR
>> too similar to decide for one or the other.
>> On the other hand there are (minor) differences of approach that I would
>> like to explore more in-depth: I reserve to express my opinion at a later
>> stage after say writing >1,000 lines of code or more with each of them.
>> There is no chance with the heated debates we are currently have to come
>> up with a merged solution now. Besides, it would take too long (e.g.
>> debating incessantly over every single line of code).  It would be great
>> but it is just not going to happen very soon.
>> 
>> Abrasiveness aside, I also think that the community should recognise Amos
>> contribution on the R interpreter: regardless on any final decision on any
>> line of code (or PR) I think he has been a pioneer in developing this
>> functionality.  Sadly with inexplicable delays etc. I am left with the
>> impression that he got a rough deal.
>> 
>> But the community needs to move on: let’s bygones be bygones and let's
>> integrate these PRs (fast, please?).
>> 
>> Enzo
>> enzo@smartinsightsfromdata.com
>> 
>> 
>> 
>>> On 8 Mar 2016, at 20:05, Amos B. Elberg <am...@gmail.com> wrote:
>>> 
>>> Those are not the options people were voting on before, and they frankly
>> don't make sense.  What was plan "a" before, was to merge 208 without
>> further delay. That's what people were voting for.
>>> 
>>> The three new "options" leave out the one I had proposed, and which
>> people had voted for: merge 208 without more delay. If Eric or someone else
>> thinks it should be different, they can make a PR to change it.
>>> 
>>> The only person who objected to that plan was Moon.
>>> 
>>> That would be the normal way to do things.  The normal way to do things
>> is to take a PR when it's ready, and if someone wants to make a change or
>> thinks it should be done differently, that's just another PR.  Your options
>> "a" and "c" are therefore the same thing. What I proposed, and people voted
>> for, was exactly that, but also adding that 208 should be merged without
>> further delay.
>>> 
>>> Option B, Eric rejected. In addition, 208 is only waiting on the ppmc to
>> fix CI and merge, so there's no reason for it now.
>>> 
>>> I still don't see that there's been any purpose to this discussion.  The
>> normal way to things, 208 should have been merged months ago.
>>> 
>>> 
>>>> On Mar 8, 2016, at 11:29 AM, Alexander Bezzubov <bz...@apache.org> wrote:
>>>> 
>>>> As we are waiting for answers on 2 question from prev. email (only from
>>>> those who _strongly disagres_ with plan C)
>>>> I have realized that one possible way of explanation for the lack of
>>>> consensus here may be the poor wording in the initial email that I used.
>>>> 
>>>> Just want to clarify the discussed options, to make sure we all are on
>> the
>>>> same page:
>>>> 
>>>> - A. Pick _only_ one of those and merge only it, discarding the second
>>>> option
>>>> 
>>>> *Action items*: us, having a separate discussion thread (out of scope of
>>>> this thread), with very carefull comparison of both of them to pick the
>> one
>>>> to merge, which will take time and a lot of effort.
>>>> *Price for community**:* Huge.
>>>> Non-collaborative nature of this approach requires us, including PPMCs,
>> to
>>>> pass strong judgments and oppinions far beyond of basic requirements of
>>>> just getting code merge. This is counter-productive. As it is a
>> non-trivial
>>>> feature in question - it will require sharp expert opinions to build
>>>> a consensus, and potentially encourage more finger-pointing and blaming
>>>> instead of help and collaboration.
>>>> *Main benefit:* avoids user confusion? (not sure how big is that, as
>>>> there are plenty of other places for user confusion in Zeppelin as well)
>>>> 
>>>> - B. ask authors of both of them to collaborate together
>>>> 
>>>> *Action items:* authors collaborate in order to come up with a single
>>>> contribution that has benefit of not confusing user and have strengths
>> of
>>>> both contributions.
>>>> *Main benefit: *meritocratic, shows healthy collaboration between
>>>> community members, avoids user confusion
>>>> *Price **for comunity**: *unknown. Requires time for waiting for
>>>> collaboration to happen one day.
>>>> 
>>>> - C. merge (potentially) each of them, but at least one, depending which
>>>> one is ready first and then let users\maintainers decide which one is
>>>> actually the best
>>>> *Action items: *just merge things as they are ready
>>>> (CI\doc\test\licensing).
>>>> *Price for community:* small\tolerable. A small price of user confusion
>>>> at first (very easy to overcome with docs), it also has a tolerable
>> price
>>>> of developers potentially maintaining both of them for a while.
>>>> *Main benefit* - Huge.
>>>> It is meritocratic, meaning that it shows that any contribution, given
>> that
>>>> it has technical merit, got accepted as soon as they meet basic project
>>>> quality requirements, after authors spend their time and effort on
>> building
>>>> something useful for a user.
>>>> 
>>>> 
>>>> I hope our mentors will correct me here if I'm wrong, but options "B"
>> and
>>>> "C" sounds like following the Apache Way to me.
>>>> "A" sounds like we need to start telling people what to do and judge
>> them,
>>>> instead of being open, inclusive "community over code".
>>>> 
>>>> Sorry for the noise if that does not add anything, but hope that helps
>> to
>>>> clarify current situation.
>>>> 
>>>> That being said, we are now waiting for an answers on 2 question from
>> prev.
>>>> email from people who _strongly disagres_ with plan C.
>>>> 
>>>> --
>>>> Alex
>>>> 
>>>> On Wed, Mar 9, 2016 at 12:37 AM, Sourav Mazumder <
>>>> sourav.mazumder00@gmail.com> wrote:
>>>> 
>>>>> Hi Alex,
>>>>> 
>>>>> In case it helps taking the decision fast my vote would be for option a
>>>>> (pr 208).
>>>>> 
>>>>> I thought one has to vote only if he/she is against option a.
>>>>> 
>>>>> Regards,
>>>>> Sourav
>>>>> 
>>>>>> On Mar 8, 2016, at 2:59 AM, Alexander Bezzubov <bz...@apache.org>
>> wrote:
>>>>>> 
>>>>>> 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 <am...@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 <er...@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.steinmetz@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.steinmetz@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" <am...@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.elberg@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 <
>>>>>>> bzz@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.steinmetz@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.mazumder00@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 <
>>>>>>>>>>> 
>>>>>>>>>>> enzo@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
>>>>>>>>>>>>>>>>>>> enzo@smartinsightsfromdata.com
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
>>>>>>> eranwitkon@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 <
>>>>>>>>>>> 
>>>>>>>>>>> doanduyhai@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 <
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> bzz@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.
>> 
>> 

Re: R interpreter in Zeppelin: further steps

[Alexander Bezzubov <bz...@apache.org>]

Thank you everybody for expressing valuable opinions: Enzo, Amos, Jeff,
Eran, Damien, Eric, Sourav, Luciano, DuyHai, Moon - I'm very glad to see
the misunderstanding being finally resolved.

The solely purpose of this thread was to _document the community consensus_
and please correct me if I'm wrong, one can clearly see it here now: as Enzo
suggested, let’s bygones be bygones and let's integrate these PRs asap in
the usual way (which I tried to describe above as option C).

Without any further delay, I'm happy to be able to spend time working on
making R interpreters to meet a very few project's technical requirements
that are left (tracked in PRs themselves) in order to get it merged.

Thank you guys very much!

--
Alex



On Wed, Mar 9, 2016 at 9:04 PM, enzo <en...@smartinsightsfromdata.com> wrote:

> I would like to re-express how I see the issue of a R interpreter in
> Zeppelin.
>
> First of all I think it would be incredibly useful to have this
> functionality: the ability of Zeppelin to select an interpreter at the cell
> level, associated with the ability to “map” data from one interpreter to
> the other brings Zeppelin to the forefront of the notebook movement.
> Further delays could harm the success Zeppelin deserves (and the
> competition is lurking).
>
> I expressed - and confirm - my favour for option c: merge PR 208 and 702
> ASAP (as in , yesterday?), then with extensive real road testing on each,
> ideally decide to merge both into one solution in a year or so (maybe a
> merged solution where you can select slightly different approaches using
> interpreters parameters, or at least configuration parameters).
>
> Please note that my position is mainly driven by pragmatism:
> From what I could test, from a R user point of view I consider the two PR
> too similar to decide for one or the other.
> On the other hand there are (minor) differences of approach that I would
> like to explore more in-depth: I reserve to express my opinion at a later
> stage after say writing >1,000 lines of code or more with each of them.
> There is no chance with the heated debates we are currently have to come
> up with a merged solution now. Besides, it would take too long (e.g.
> debating incessantly over every single line of code).  It would be great
> but it is just not going to happen very soon.
>
> Abrasiveness aside, I also think that the community should recognise Amos
> contribution on the R interpreter: regardless on any final decision on any
> line of code (or PR) I think he has been a pioneer in developing this
> functionality.  Sadly with inexplicable delays etc. I am left with the
> impression that he got a rough deal.
>
> But the community needs to move on: let’s bygones be bygones and let's
> integrate these PRs (fast, please?).
>
> Enzo
> enzo@smartinsightsfromdata.com
>
>
>
> > On 8 Mar 2016, at 20:05, Amos B. Elberg <am...@gmail.com> wrote:
> >
> > Those are not the options people were voting on before, and they frankly
> don't make sense.  What was plan "a" before, was to merge 208 without
> further delay. That's what people were voting for.
> >
> > The three new "options" leave out the one I had proposed, and which
> people had voted for: merge 208 without more delay. If Eric or someone else
> thinks it should be different, they can make a PR to change it.
> >
> > The only person who objected to that plan was Moon.
> >
> > That would be the normal way to do things.  The normal way to do things
> is to take a PR when it's ready, and if someone wants to make a change or
> thinks it should be done differently, that's just another PR.  Your options
> "a" and "c" are therefore the same thing. What I proposed, and people voted
> for, was exactly that, but also adding that 208 should be merged without
> further delay.
> >
> > Option B, Eric rejected. In addition, 208 is only waiting on the ppmc to
> fix CI and merge, so there's no reason for it now.
> >
> > I still don't see that there's been any purpose to this discussion.  The
> normal way to things, 208 should have been merged months ago.
> >
> >
> >> On Mar 8, 2016, at 11:29 AM, Alexander Bezzubov <bz...@apache.org> wrote:
> >>
> >> As we are waiting for answers on 2 question from prev. email (only from
> >> those who _strongly disagres_ with plan C)
> >> I have realized that one possible way of explanation for the lack of
> >> consensus here may be the poor wording in the initial email that I used.
> >>
> >> Just want to clarify the discussed options, to make sure we all are on
> the
> >> same page:
> >>
> >> - A. Pick _only_ one of those and merge only it, discarding the second
> >> option
> >>
> >> *Action items*: us, having a separate discussion thread (out of scope of
> >> this thread), with very carefull comparison of both of them to pick the
> one
> >> to merge, which will take time and a lot of effort.
> >> *Price for community**:* Huge.
> >> Non-collaborative nature of this approach requires us, including PPMCs,
> to
> >> pass strong judgments and oppinions far beyond of basic requirements of
> >> just getting code merge. This is counter-productive. As it is a
> non-trivial
> >> feature in question - it will require sharp expert opinions to build
> >> a consensus, and potentially encourage more finger-pointing and blaming
> >> instead of help and collaboration.
> >> *Main benefit:* avoids user confusion? (not sure how big is that, as
> >> there are plenty of other places for user confusion in Zeppelin as well)
> >>
> >> - B. ask authors of both of them to collaborate together
> >>
> >>  *Action items:* authors collaborate in order to come up with a single
> >> contribution that has benefit of not confusing user and have strengths
> of
> >> both contributions.
> >>  *Main benefit: *meritocratic, shows healthy collaboration between
> >> community members, avoids user confusion
> >>  *Price **for comunity**: *unknown. Requires time for waiting for
> >> collaboration to happen one day.
> >>
> >> - C. merge (potentially) each of them, but at least one, depending which
> >> one is ready first and then let users\maintainers decide which one is
> >> actually the best
> >>  *Action items: *just merge things as they are ready
> >> (CI\doc\test\licensing).
> >>  *Price for community:* small\tolerable. A small price of user confusion
> >> at first (very easy to overcome with docs), it also has a tolerable
> price
> >> of developers potentially maintaining both of them for a while.
> >>  *Main benefit* - Huge.
> >> It is meritocratic, meaning that it shows that any contribution, given
> that
> >> it has technical merit, got accepted as soon as they meet basic project
> >> quality requirements, after authors spend their time and effort on
> building
> >> something useful for a user.
> >>
> >>
> >> I hope our mentors will correct me here if I'm wrong, but options "B"
> and
> >> "C" sounds like following the Apache Way to me.
> >> "A" sounds like we need to start telling people what to do and judge
> them,
> >> instead of being open, inclusive "community over code".
> >>
> >> Sorry for the noise if that does not add anything, but hope that helps
> to
> >> clarify current situation.
> >>
> >> That being said, we are now waiting for an answers on 2 question from
> prev.
> >> email from people who _strongly disagres_ with plan C.
> >>
> >> --
> >> Alex
> >>
> >> On Wed, Mar 9, 2016 at 12:37 AM, Sourav Mazumder <
> >> sourav.mazumder00@gmail.com> wrote:
> >>
> >>> Hi Alex,
> >>>
> >>> In case it helps taking the decision fast my vote would be for option a
> >>> (pr 208).
> >>>
> >>> I thought one has to vote only if he/she is against option a.
> >>>
> >>> Regards,
> >>> Sourav
> >>>
> >>>> On Mar 8, 2016, at 2:59 AM, Alexander Bezzubov <bz...@apache.org>
> wrote:
> >>>>
> >>>> 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 <am...@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 <er...@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.steinmetz@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.steinmetz@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" <am...@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.elberg@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 <
> >>>>> bzz@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.steinmetz@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.mazumder00@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 <
> >>>>>>>>>
> >>>>>>>>> enzo@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
> >>>>>>>>>>>>>>>>> enzo@smartinsightsfromdata.com
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
> >>>>> eranwitkon@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 <
> >>>>>>>>>
> >>>>>>>>> doanduyhai@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 <
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> bzz@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.
> >>>
> >
>
>

Re: R interpreter in Zeppelin: further steps

[enzo <en...@smartinsightsfromdata.com>]

I would like to re-express how I see the issue of a R interpreter in Zeppelin.

First of all I think it would be incredibly useful to have this functionality: the ability of Zeppelin to select an interpreter at the cell level, associated with the ability to “map” data from one interpreter to the other brings Zeppelin to the forefront of the notebook movement. Further delays could harm the success Zeppelin deserves (and the competition is lurking).

I expressed - and confirm - my favour for option c: merge PR 208 and 702 ASAP (as in , yesterday?), then with extensive real road testing on each, ideally decide to merge both into one solution in a year or so (maybe a merged solution where you can select slightly different approaches using interpreters parameters, or at least configuration parameters).

Please note that my position is mainly driven by pragmatism:
From what I could test, from a R user point of view I consider the two PR too similar to decide for one or the other.
On the other hand there are (minor) differences of approach that I would like to explore more in-depth: I reserve to express my opinion at a later stage after say writing >1,000 lines of code or more with each of them.
There is no chance with the heated debates we are currently have to come up with a merged solution now. Besides, it would take too long (e.g. debating incessantly over every single line of code).  It would be great but it is just not going to happen very soon.

Abrasiveness aside, I also think that the community should recognise Amos contribution on the R interpreter: regardless on any final decision on any line of code (or PR) I think he has been a pioneer in developing this functionality.  Sadly with inexplicable delays etc. I am left with the impression that he got a rough deal.

But the community needs to move on: let’s bygones be bygones and let's  integrate these PRs (fast, please?).

Enzo
enzo@smartinsightsfromdata.com



> On 8 Mar 2016, at 20:05, Amos B. Elberg <am...@gmail.com> wrote:
> 
> Those are not the options people were voting on before, and they frankly don't make sense.  What was plan "a" before, was to merge 208 without further delay. That's what people were voting for.  
> 
> The three new "options" leave out the one I had proposed, and which people had voted for: merge 208 without more delay. If Eric or someone else thinks it should be different, they can make a PR to change it.
> 
> The only person who objected to that plan was Moon.
> 
> That would be the normal way to do things.  The normal way to do things is to take a PR when it's ready, and if someone wants to make a change or thinks it should be done differently, that's just another PR.  Your options "a" and "c" are therefore the same thing. What I proposed, and people voted for, was exactly that, but also adding that 208 should be merged without further delay.
> 
> Option B, Eric rejected. In addition, 208 is only waiting on the ppmc to fix CI and merge, so there's no reason for it now.
> 
> I still don't see that there's been any purpose to this discussion.  The normal way to things, 208 should have been merged months ago. 
> 
> 
>> On Mar 8, 2016, at 11:29 AM, Alexander Bezzubov <bz...@apache.org> wrote:
>> 
>> As we are waiting for answers on 2 question from prev. email (only from
>> those who _strongly disagres_ with plan C)
>> I have realized that one possible way of explanation for the lack of
>> consensus here may be the poor wording in the initial email that I used.
>> 
>> Just want to clarify the discussed options, to make sure we all are on the
>> same page:
>> 
>> - A. Pick _only_ one of those and merge only it, discarding the second
>> option
>> 
>> *Action items*: us, having a separate discussion thread (out of scope of
>> this thread), with very carefull comparison of both of them to pick the one
>> to merge, which will take time and a lot of effort.
>> *Price for community**:* Huge.
>> Non-collaborative nature of this approach requires us, including PPMCs, to
>> pass strong judgments and oppinions far beyond of basic requirements of
>> just getting code merge. This is counter-productive. As it is a non-trivial
>> feature in question - it will require sharp expert opinions to build
>> a consensus, and potentially encourage more finger-pointing and blaming
>> instead of help and collaboration.
>> *Main benefit:* avoids user confusion? (not sure how big is that, as
>> there are plenty of other places for user confusion in Zeppelin as well)
>> 
>> - B. ask authors of both of them to collaborate together
>> 
>>  *Action items:* authors collaborate in order to come up with a single
>> contribution that has benefit of not confusing user and have strengths of
>> both contributions.
>>  *Main benefit: *meritocratic, shows healthy collaboration between
>> community members, avoids user confusion
>>  *Price **for comunity**: *unknown. Requires time for waiting for
>> collaboration to happen one day.
>> 
>> - C. merge (potentially) each of them, but at least one, depending which
>> one is ready first and then let users\maintainers decide which one is
>> actually the best
>>  *Action items: *just merge things as they are ready
>> (CI\doc\test\licensing).
>>  *Price for community:* small\tolerable. A small price of user confusion
>> at first (very easy to overcome with docs), it also has a tolerable price
>> of developers potentially maintaining both of them for a while.
>>  *Main benefit* - Huge.
>> It is meritocratic, meaning that it shows that any contribution, given that
>> it has technical merit, got accepted as soon as they meet basic project
>> quality requirements, after authors spend their time and effort on building
>> something useful for a user.
>> 
>> 
>> I hope our mentors will correct me here if I'm wrong, but options "B" and
>> "C" sounds like following the Apache Way to me.
>> "A" sounds like we need to start telling people what to do and judge them,
>> instead of being open, inclusive "community over code".
>> 
>> Sorry for the noise if that does not add anything, but hope that helps to
>> clarify current situation.
>> 
>> That being said, we are now waiting for an answers on 2 question from prev.
>> email from people who _strongly disagres_ with plan C.
>> 
>> --
>> Alex
>> 
>> On Wed, Mar 9, 2016 at 12:37 AM, Sourav Mazumder <
>> sourav.mazumder00@gmail.com> wrote:
>> 
>>> Hi Alex,
>>> 
>>> In case it helps taking the decision fast my vote would be for option a
>>> (pr 208).
>>> 
>>> I thought one has to vote only if he/she is against option a.
>>> 
>>> Regards,
>>> Sourav
>>> 
>>>> On Mar 8, 2016, at 2:59 AM, Alexander Bezzubov <bz...@apache.org> wrote:
>>>> 
>>>> 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 <am...@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 <er...@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.steinmetz@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" <je...@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" <am...@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.elberg@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 <
>>>>> bzz@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.steinmetz@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.mazumder00@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 <
>>>>>>>>> 
>>>>>>>>> enzo@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
>>>>>>>>>>>>>>>>> enzo@smartinsightsfromdata.com
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
>>>>> eranwitkon@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 <
>>>>>>>>> 
>>>>>>>>> doanduyhai@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 <
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> bzz@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.
>>> 
> 

Re: R interpreter in Zeppelin: further steps

["Amos B. Elberg" <am...@gmail.com>]

Those are not the options people were voting on before, and they frankly don't make sense.  What was plan "a" before, was to merge 208 without further delay. That's what people were voting for.  

The three new "options" leave out the one I had proposed, and which people had voted for: merge 208 without more delay. If Eric or someone else thinks it should be different, they can make a PR to change it.

The only person who objected to that plan was Moon.

That would be the normal way to do things.  The normal way to do things is to take a PR when it's ready, and if someone wants to make a change or thinks it should be done differently, that's just another PR.  Your options "a" and "c" are therefore the same thing. What I proposed, and people voted for, was exactly that, but also adding that 208 should be merged without further delay.

Option B, Eric rejected. In addition, 208 is only waiting on the ppmc to fix CI and merge, so there's no reason for it now.

I still don't see that there's been any purpose to this discussion.  The normal way to things, 208 should have been merged months ago. 


> On Mar 8, 2016, at 11:29 AM, Alexander Bezzubov <bz...@apache.org> wrote:
> 
> As we are waiting for answers on 2 question from prev. email (only from
> those who _strongly disagres_ with plan C)
> I have realized that one possible way of explanation for the lack of
> consensus here may be the poor wording in the initial email that I used.
> 
> Just want to clarify the discussed options, to make sure we all are on the
> same page:
> 
> - A. Pick _only_ one of those and merge only it, discarding the second
> option
> 
>  *Action items*: us, having a separate discussion thread (out of scope of
> this thread), with very carefull comparison of both of them to pick the one
> to merge, which will take time and a lot of effort.
>  *Price for community**:* Huge.
> Non-collaborative nature of this approach requires us, including PPMCs, to
> pass strong judgments and oppinions far beyond of basic requirements of
> just getting code merge. This is counter-productive. As it is a non-trivial
> feature in question - it will require sharp expert opinions to build
> a consensus, and potentially encourage more finger-pointing and blaming
> instead of help and collaboration.
>  *Main benefit:* avoids user confusion? (not sure how big is that, as
> there are plenty of other places for user confusion in Zeppelin as well)
> 
> - B. ask authors of both of them to collaborate together
> 
>   *Action items:* authors collaborate in order to come up with a single
> contribution that has benefit of not confusing user and have strengths of
> both contributions.
>   *Main benefit: *meritocratic, shows healthy collaboration between
> community members, avoids user confusion
>   *Price **for comunity**: *unknown. Requires time for waiting for
> collaboration to happen one day.
> 
> - C. merge (potentially) each of them, but at least one, depending which
> one is ready first and then let users\maintainers decide which one is
> actually the best
>   *Action items: *just merge things as they are ready
> (CI\doc\test\licensing).
>   *Price for community:* small\tolerable. A small price of user confusion
> at first (very easy to overcome with docs), it also has a tolerable price
> of developers potentially maintaining both of them for a while.
>   *Main benefit* - Huge.
> It is meritocratic, meaning that it shows that any contribution, given that
> it has technical merit, got accepted as soon as they meet basic project
> quality requirements, after authors spend their time and effort on building
> something useful for a user.
> 
> 
> I hope our mentors will correct me here if I'm wrong, but options "B" and
> "C" sounds like following the Apache Way to me.
> "A" sounds like we need to start telling people what to do and judge them,
> instead of being open, inclusive "community over code".
> 
> Sorry for the noise if that does not add anything, but hope that helps to
> clarify current situation.
> 
> That being said, we are now waiting for an answers on 2 question from prev.
> email from people who _strongly disagres_ with plan C.
> 
> --
> Alex
> 
> On Wed, Mar 9, 2016 at 12:37 AM, Sourav Mazumder <
> sourav.mazumder00@gmail.com> wrote:
> 
>> Hi Alex,
>> 
>> In case it helps taking the decision fast my vote would be for option a
>> (pr 208).
>> 
>> I thought one has to vote only if he/she is against option a.
>> 
>> Regards,
>> Sourav
>> 
>>> On Mar 8, 2016, at 2:59 AM, Alexander Bezzubov <bz...@apache.org> wrote:
>>> 
>>> 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 <am...@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 <er...@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.steinmetz@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" <je...@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" <am...@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.elberg@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 <
>>>> bzz@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.steinmetz@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.mazumder00@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 <
>>>>>>>> 
>>>>>>>> enzo@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
>>>>>>>>>>>>>>>> enzo@smartinsightsfromdata.com
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
>>>> eranwitkon@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 <
>>>>>>>> 
>>>>>>>> doanduyhai@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 <
>>>>>>>>>>>>> 
>>>>>>>>>>>>> bzz@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.
>> 

Re: R interpreter in Zeppelin: further steps

[Jeff Steinmetz <je...@gmail.com>]

I finally had some time to put aside a good chunk of dedicated, uninterrupted time to review both PRs.

Now that I had time to dig into both PRs, Plan C works as well for me.  
Each PR had pros and cons (neither was a slam dunk - but both very close).
I will comment within each PR providing my thoughts (outside of this thread).  

So my new preference is merge “something”, the first that is ready or both.  
Which is Plan C now that I read Alex's clarification (with the hope that Plan B is still a potential based on contributor willingness).

Jeff




On 3/8/16, 8:29 AM, "Alexander Bezzubov" <bz...@apache.org> wrote:

>As we are waiting for answers on 2 question from prev. email (only from
>those who _strongly disagres_ with plan C)
>I have realized that one possible way of explanation for the lack of
>consensus here may be the poor wording in the initial email that I used.
>
>Just want to clarify the discussed options, to make sure we all are on the
>same page:
>
> - A. Pick _only_ one of those and merge only it, discarding the second
>option
>
>  *Action items*: us, having a separate discussion thread (out of scope of
>this thread), with very carefull comparison of both of them to pick the one
>to merge, which will take time and a lot of effort.
>  *Price for community**:* Huge.
>Non-collaborative nature of this approach requires us, including PPMCs, to
>pass strong judgments and oppinions far beyond of basic requirements of
>just getting code merge. This is counter-productive. As it is a non-trivial
>feature in question - it will require sharp expert opinions to build
>a consensus, and potentially encourage more finger-pointing and blaming
>instead of help and collaboration.
>  *Main benefit:* avoids user confusion? (not sure how big is that, as
>there are plenty of other places for user confusion in Zeppelin as well)
>
> - B. ask authors of both of them to collaborate together
>
>   *Action items:* authors collaborate in order to come up with a single
>contribution that has benefit of not confusing user and have strengths of
>both contributions.
>   *Main benefit: *meritocratic, shows healthy collaboration between
>community members, avoids user confusion
>   *Price **for comunity**: *unknown. Requires time for waiting for
>collaboration to happen one day.
>
> - C. merge (potentially) each of them, but at least one, depending which
>one is ready first and then let users\maintainers decide which one is
>actually the best
>   *Action items: *just merge things as they are ready
>(CI\doc\test\licensing).
>   *Price for community:* small\tolerable. A small price of user confusion
>at first (very easy to overcome with docs), it also has a tolerable price
>of developers potentially maintaining both of them for a while.
>   *Main benefit* - Huge.
>It is meritocratic, meaning that it shows that any contribution, given that
>it has technical merit, got accepted as soon as they meet basic project
>quality requirements, after authors spend their time and effort on building
>something useful for a user.
>
>
>I hope our mentors will correct me here if I'm wrong, but options "B" and
>"C" sounds like following the Apache Way to me.
>"A" sounds like we need to start telling people what to do and judge them,
>instead of being open, inclusive "community over code".
>
>Sorry for the noise if that does not add anything, but hope that helps to
>clarify current situation.
>
>That being said, we are now waiting for an answers on 2 question from prev.
>email from people who _strongly disagres_ with plan C.
>
>--
>Alex
>
>On Wed, Mar 9, 2016 at 12:37 AM, Sourav Mazumder <
>sourav.mazumder00@gmail.com> wrote:
>
>> Hi Alex,
>>
>> In case it helps taking the decision fast my vote would be for option a
>> (pr 208).
>>
>> I thought one has to vote only if he/she is against option a.
>>
>> Regards,
>> Sourav
>>
>> > On Mar 8, 2016, at 2:59 AM, Alexander Bezzubov <bz...@apache.org> wrote:
>> >
>> > 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 <am...@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 <er...@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.steinmetz@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" <je...@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" <am...@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.elberg@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 <
>> >> bzz@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.steinmetz@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.mazumder00@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 <
>> >>>>>>
>> >>>>>> enzo@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
>> >>>>>>>>>>>>>> enzo@smartinsightsfromdata.com
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
>> >> eranwitkon@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 <
>> >>>>>>
>> >>>>>> doanduyhai@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 <
>> >>>>>>>>>>>
>> >>>>>>>>>>> bzz@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.
>> >>
>> >>
>>

Re: R interpreter in Zeppelin: further steps

[Eran Witkon <er...@gmail.com>]

That's a good clarification mail. As you know I "vote" for option C the
only real issue here is the question of the CI. As I understand from the
different mail thread we don't have a consensus that with the state of the
CI (stability and such), and if passing CI is a must for merging. To my
understanding, Amos see the "fixing the CI" as out of scope.

My view is :
1) Even if CI is broken, unless the community decides that we can do
without CI or have an alternative CI tool, this is our CI and we all have
to work\fix it and can't merge ANY PR without it.
2) If one wants to help move this community forward and thinks that the CI
is a blocking issue then he should put all of his energy and time into
fixing it or use it as it is without complaining.

Eran

On Tue, Mar 8, 2016 at 6:30 PM Alexander Bezzubov <bz...@apache.org> wrote:

> As we are waiting for answers on 2 question from prev. email (only from
> those who _strongly disagres_ with plan C)
> I have realized that one possible way of explanation for the lack of
> consensus here may be the poor wording in the initial email that I used.
>
> Just want to clarify the discussed options, to make sure we all are on the
> same page:
>
>  - A. Pick _only_ one of those and merge only it, discarding the second
> option
>
>   *Action items*: us, having a separate discussion thread (out of scope of
> this thread), with very carefull comparison of both of them to pick the one
> to merge, which will take time and a lot of effort.
>   *Price for community**:* Huge.
> Non-collaborative nature of this approach requires us, including PPMCs, to
> pass strong judgments and oppinions far beyond of basic requirements of
> just getting code merge. This is counter-productive. As it is a non-trivial
> feature in question - it will require sharp expert opinions to build
> a consensus, and potentially encourage more finger-pointing and blaming
> instead of help and collaboration.
>   *Main benefit:* avoids user confusion? (not sure how big is that, as
> there are plenty of other places for user confusion in Zeppelin as well)
>
>  - B. ask authors of both of them to collaborate together
>
>    *Action items:* authors collaborate in order to come up with a single
> contribution that has benefit of not confusing user and have strengths of
> both contributions.
>    *Main benefit: *meritocratic, shows healthy collaboration between
> community members, avoids user confusion
>    *Price **for comunity**: *unknown. Requires time for waiting for
> collaboration to happen one day.
>
>  - C. merge (potentially) each of them, but at least one, depending which
> one is ready first and then let users\maintainers decide which one is
> actually the best
>    *Action items: *just merge things as they are ready
> (CI\doc\test\licensing).
>    *Price for community:* small\tolerable. A small price of user confusion
> at first (very easy to overcome with docs), it also has a tolerable price
> of developers potentially maintaining both of them for a while.
>    *Main benefit* - Huge.
> It is meritocratic, meaning that it shows that any contribution, given that
> it has technical merit, got accepted as soon as they meet basic project
> quality requirements, after authors spend their time and effort on building
> something useful for a user.
>
>
> I hope our mentors will correct me here if I'm wrong, but options "B" and
> "C" sounds like following the Apache Way to me.
> "A" sounds like we need to start telling people what to do and judge them,
> instead of being open, inclusive "community over code".
>
> Sorry for the noise if that does not add anything, but hope that helps to
> clarify current situation.
>
> That being said, we are now waiting for an answers on 2 question from prev.
> email from people who _strongly disagres_ with plan C.
>
> --
> Alex
>
> On Wed, Mar 9, 2016 at 12:37 AM, Sourav Mazumder <
> sourav.mazumder00@gmail.com> wrote:
>
> > Hi Alex,
> >
> > In case it helps taking the decision fast my vote would be for option a
> > (pr 208).
> >
> > I thought one has to vote only if he/she is against option a.
> >
> > Regards,
> > Sourav
> >
> > > On Mar 8, 2016, at 2:59 AM, Alexander Bezzubov <bz...@apache.org> wrote:
> > >
> > > 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 <am...@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 <er...@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.steinmetz@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.steinmetz@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" <am...@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.elberg@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 <
> > >> bzz@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.steinmetz@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.mazumder00@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 <
> > >>>>>>
> > >>>>>> enzo@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
> > >>>>>>>>>>>>>> enzo@smartinsightsfromdata.com
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
> > >> eranwitkon@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 <
> > >>>>>>
> > >>>>>> doanduyhai@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 <
> > >>>>>>>>>>>
> > >>>>>>>>>>> bzz@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.
> > >>
> > >>
> >
>

Re: R interpreter in Zeppelin: further steps

[Alexander Bezzubov <bz...@apache.org>]

As we are waiting for answers on 2 question from prev. email (only from
those who _strongly disagres_ with plan C)
I have realized that one possible way of explanation for the lack of
consensus here may be the poor wording in the initial email that I used.

Just want to clarify the discussed options, to make sure we all are on the
same page:

 - A. Pick _only_ one of those and merge only it, discarding the second
option

  *Action items*: us, having a separate discussion thread (out of scope of
this thread), with very carefull comparison of both of them to pick the one
to merge, which will take time and a lot of effort.
  *Price for community**:* Huge.
Non-collaborative nature of this approach requires us, including PPMCs, to
pass strong judgments and oppinions far beyond of basic requirements of
just getting code merge. This is counter-productive. As it is a non-trivial
feature in question - it will require sharp expert opinions to build
a consensus, and potentially encourage more finger-pointing and blaming
instead of help and collaboration.
  *Main benefit:* avoids user confusion? (not sure how big is that, as
there are plenty of other places for user confusion in Zeppelin as well)

 - B. ask authors of both of them to collaborate together

   *Action items:* authors collaborate in order to come up with a single
contribution that has benefit of not confusing user and have strengths of
both contributions.
   *Main benefit: *meritocratic, shows healthy collaboration between
community members, avoids user confusion
   *Price **for comunity**: *unknown. Requires time for waiting for
collaboration to happen one day.

 - C. merge (potentially) each of them, but at least one, depending which
one is ready first and then let users\maintainers decide which one is
actually the best
   *Action items: *just merge things as they are ready
(CI\doc\test\licensing).
   *Price for community:* small\tolerable. A small price of user confusion
at first (very easy to overcome with docs), it also has a tolerable price
of developers potentially maintaining both of them for a while.
   *Main benefit* - Huge.
It is meritocratic, meaning that it shows that any contribution, given that
it has technical merit, got accepted as soon as they meet basic project
quality requirements, after authors spend their time and effort on building
something useful for a user.


I hope our mentors will correct me here if I'm wrong, but options "B" and
"C" sounds like following the Apache Way to me.
"A" sounds like we need to start telling people what to do and judge them,
instead of being open, inclusive "community over code".

Sorry for the noise if that does not add anything, but hope that helps to
clarify current situation.

That being said, we are now waiting for an answers on 2 question from prev.
email from people who _strongly disagres_ with plan C.

--
Alex

On Wed, Mar 9, 2016 at 12:37 AM, Sourav Mazumder <
sourav.mazumder00@gmail.com> wrote:

> Hi Alex,
>
> In case it helps taking the decision fast my vote would be for option a
> (pr 208).
>
> I thought one has to vote only if he/she is against option a.
>
> Regards,
> Sourav
>
> > On Mar 8, 2016, at 2:59 AM, Alexander Bezzubov <bz...@apache.org> wrote:
> >
> > 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 <am...@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 <er...@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.steinmetz@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" <je...@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" <am...@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.elberg@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 <
> >> bzz@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.steinmetz@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.mazumder00@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 <
> >>>>>>
> >>>>>> enzo@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
> >>>>>>>>>>>>>> enzo@smartinsightsfromdata.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
> >> eranwitkon@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 <
> >>>>>>
> >>>>>> doanduyhai@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 <
> >>>>>>>>>>>
> >>>>>>>>>>> bzz@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.
> >>
> >>
>

Re: R interpreter in Zeppelin: further steps

[Sourav Mazumder <so...@gmail.com>]

Hi Alex,

In case it helps taking the decision fast my vote would be for option a (pr 208).

I thought one has to vote only if he/she is against option a.

Regards,
Sourav

> On Mar 8, 2016, at 2:59 AM, Alexander Bezzubov <bz...@apache.org> wrote:
> 
> 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 <am...@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 <er...@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.steinmetz@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" <je...@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" <am...@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.elberg@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 <
>> bzz@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.steinmetz@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.mazumder00@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 <
>>>>>> 
>>>>>> enzo@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
>>>>>>>>>>>>>> enzo@smartinsightsfromdata.com
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
>> eranwitkon@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 <
>>>>>> 
>>>>>> doanduyhai@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 <
>>>>>>>>>>> 
>>>>>>>>>>> bzz@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.
>> 
>> 

Re: R interpreter in Zeppelin: further steps

[Alexander Bezzubov <bz...@apache.org>]

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 <am...@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 <er...@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.steinmetz@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" <je...@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" <am...@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.elberg@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 <
> bzz@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.steinmetz@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.mazumder00@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 <
> > > >>
> > > >> enzo@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
> > > >>>>>>>>>> enzo@smartinsightsfromdata.com
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
> eranwitkon@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 <
> > > >>
> > > >> doanduyhai@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 <
> > > >>>>>>>
> > > >>>>>>> bzz@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.
>
>

Re: R interpreter in Zeppelin: further steps

[Amos Elberg <am...@gmail.com>]

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 <er...@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.steinmetz@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" <je...@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" <am...@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 <am...@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 <bz...@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.steinmetz@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.mazumder00@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 <
> > >> 
> > >> enzo@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
> > >>>>>>>>>> enzo@smartinsightsfromdata.com
> > >>>>>>>>>> 
> > >>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <eranwitkon@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 <
> > >> 
> > >> doanduyhai@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 <
> > >>>>>>> 
> > >>>>>>> bzz@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.

Re: R interpreter in Zeppelin: further steps

[Luciano Resende <lu...@gmail.com>]

On Tue, Mar 8, 2016 at 12:11 AM, Alexander Bezzubov <bz...@apache.org> 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



Looks like R support is something the community really wants, and I am sure
others are willing to help bring one or even both interpreters to a status
where it conforms with the project quality standards (e.g. test coverage
and CI Builds passing).

What is the problem with merging this (or these) now, and not add to the
build reactor, so that others can collaborate with PRs to make progress to
the R interpreter ?


-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: R interpreter in Zeppelin: further steps

[Alexander Bezzubov <bz...@apache.org>]

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 <er...@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/test/java/org/apache/zeppelin/spark/SparkRInterpreterTest.java
>
> >    * no docs
> >
>
> There is some doc
>
>
> https://github.com/datalayer/zeppelin-datalayer/blob/rscala-z/docs/interpreter/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.steinmetz@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" <je...@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" <am...@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 <am...@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 <bz...@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.steinmetz@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.mazumder00@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 <
> >> enzo@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
> >>>>>>>>>> enzo@smartinsightsfromdata.com
> >>>>>>>>>>
> >>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <eranwitkon@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 <
> >> doanduyhai@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 <
> >>>>>>>
> >>>>>>> bzz@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.
> >>>>
> >>>
> >>
> >>
> >
>

Re: R interpreter in Zeppelin: further steps

[Jeff Steinmetz <je...@gmail.com>]

Eric, 
There are elements in 702 that I think would be great to see in the final merge!
Great to hear your open to Plan B.

Jeff





On 3/7/16, 11:20 PM, "Eric Charles" <er...@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/test/java/org/apache/zeppelin/spark/SparkRInterpreterTest.java
>
>>    * no docs
>>
>
>There is some doc
>
>https://github.com/datalayer/zeppelin-datalayer/blob/rscala-z/docs/interpreter/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 <je...@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" <je...@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" <am...@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 <am...@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 <bz...@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.steinmetz@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.mazumder00@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 <
>>> enzo@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
>>>>>>>>>>> enzo@smartinsightsfromdata.com
>>>>>>>>>>>
>>>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <eranwitkon@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 <
>>> doanduyhai@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 <
>>>>>>>>
>>>>>>>> bzz@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.
>>>>>
>>>>
>>>
>>>
>>

Re: R interpreter in Zeppelin: further steps

[Eric Charles <er...@apache.org>]

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/test/java/org/apache/zeppelin/spark/SparkRInterpreterTest.java

>    * no docs
>

There is some doc

https://github.com/datalayer/zeppelin-datalayer/blob/rscala-z/docs/interpreter/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 <je...@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" <je...@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" <am...@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 <am...@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 <bz...@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.steinmetz@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.mazumder00@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 <
>> enzo@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
>>>>>>>>>> enzo@smartinsightsfromdata.com
>>>>>>>>>>
>>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <eranwitkon@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 <
>> doanduyhai@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 <
>>>>>>>
>>>>>>> bzz@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.
>>>>
>>>
>>
>>
>

Re: R interpreter in Zeppelin: further steps

["Amos B. Elberg" <am...@gmail.com>]

That's not the current vote. The vote for C is 1, which is alex. 

> On Mar 8, 2016, at 1:15 AM, Alexander Bezzubov <bz...@apache.org> wrote:
> 
> Ok, thank you all for participating in this public discussion - there is no
> reason for anybody to stay out of it, community opinions are very welcome.
> 
> To summarize, here is the tally I can see:
> 
> a) for picking ONLY 208, as soon as it is ready: +2 Amos, Jeff
> b) for asking both authors to come up with only 1: +1 DuyHai
> c) for merging whatever is ready first, as soon as it ready and is useful,
> and then let users\community decide what works\is supported\have less bugs:
>     +5 Damien, Moon, Alex, Enzo, Eran
>     -1 Amos
> 
> As this is not a vote, it is just to summarize the current state of
> discussion, and please correct me if I'm wrong here.
> 
> High-level summary of the state of contributions are:
> 
> - 208
>  * CI fails
>  * have tests
>  * have docs
> 
> - 702
>  * CI fails
>  * no tests
>  * no docs
> 
> 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?
> 
> 
> 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 <je...@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" <je...@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" <am...@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 <am...@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 <bz...@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.steinmetz@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.mazumder00@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 <
>> enzo@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
>>>>>>>>>> enzo@smartinsightsfromdata.com
>>>>>>>>>> 
>>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <eranwitkon@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 <
>> doanduyhai@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 <
>>>>>>> 
>>>>>>> bzz@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.
>> 
>> 

Re: R interpreter in Zeppelin: further steps

[Alexander Bezzubov <bz...@apache.org>]

Ok, thank you all for participating in this public discussion - there is no
reason for anybody to stay out of it, community opinions are very welcome.

To summarize, here is the tally I can see:

 a) for picking ONLY 208, as soon as it is ready: +2 Amos, Jeff
 b) for asking both authors to come up with only 1: +1 DuyHai
 c) for merging whatever is ready first, as soon as it ready and is useful,
and then let users\community decide what works\is supported\have less bugs:
     +5 Damien, Moon, Alex, Enzo, Eran
     -1 Amos

As this is not a vote, it is just to summarize the current state of
discussion, and please correct me if I'm wrong here.

High-level summary of the state of contributions are:

 - 208
  * CI fails
  * have tests
  * have docs

 - 702
  * CI fails
  * no tests
  * no docs

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?


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 <je...@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" <je...@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" <am...@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 <am...@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 <bz...@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.steinmetz@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.mazumder00@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 <
> enzo@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
> >>> > > > >> enzo@smartinsightsfromdata.com
> >>> > > > >>
> >>> > > > >> > On 29 Feb 2016, at 12:36, Eran Witkon <eranwitkon@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 <
> doanduyhai@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 <
> >>> > >
> >>> > > bzz@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.
> >>
> >
>
>

Re: R interpreter in Zeppelin: further steps

[Jeff Steinmetz <je...@gmail.com>]

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" <je...@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" <am...@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 <am...@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 <bz...@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.steinmetz@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" <so...@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 <enzo@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
>>> > > > >> enzo@smartinsightsfromdata.com
>>> > > > >> 
>>> > > > >> > On 29 Feb 2016, at 12:36, Eran Witkon <er...@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 <doanduyhai@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 <
>>> > > 
>>> > > bzz@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.
>>
>

R interpreter in Zeppelin: further steps

[moon soo Lee <mo...@apache.org>]

---------- Forwarded message ---------
From: Amos Elberg <am...@gmail.com>
Date: Mon, Mar 7, 2016 at 4:12 PM
Subject: Re: R interpreter in Zeppelin: further steps
To: moon soo Lee <mo...@apache.org>


Moon - No, I do not accept what you just wrote.  None of the 'technical'
claims in your email are correct.  In addition, your description of what you
have done regarding 208, is not true.

I think you don't want to merge 208 because the whole thing is embarrassing
for you.  Alex committed to try to merge 208, and we made progress.  But, as
soon as it was done, and all outstanding tasks were complete, then out of
nowhere Alex opened this discussion and tried to steer the community into
accepting "both."  But it didn't work - the community didn't want it.
No-one
supported the proposal.  Now a few days go by, it would be time to declare
"lazy consensus," but the community didn't do what you wanted so now you
want
to overrule the community's decision.

This relates directly to the problem of whether this project is being run by
the community, or by Moon with his employees and friends --- it seems that
this is only a "community" project when the community does what you prefer.
If the community disagrees, you don't allow the discussion to end.  It just
comes back again and again until you get what you want.

Below, I go through your email in detail, to show that the "technical"
claims
you made are false:

> - 208 includes rscala depenency as a source, 702 download dependency
> library on buildtime

Wrong. 208 uses code forked from rscala. 702 *bundles* *part* of rscala.
702
*used to* download rscala.  But doing that *broke* 702 when rscala changed.
Now 702 bundles it.  But only *part* -- which will cause it to break if the
user happens to have rscala installed in their *R* library.

I have explained this several times.

> - 208 placed in separate maven sub module r, 702 placed in existing spark
> submodule.

This is the issue of whether the *source code* should be stored under a a
directory with one name or another name.  Everyone agrees this is cosmetic.

> - 208 creates another socket to communicate to interpreter, 702 does not

Not correct.  702 connects to the interpreter the same way 208 does - the
reason is that 702 is based on 208.

> - many more

In any two implementations, there will be differences.  What *material*,
*relevant*, *significant* technical *advantage*

> 208 is not an exceptional PR that can be merged without CI pass. Could you
> accept this simple rule?

That's not true, Moon. We say not passing CI is "irrelevant" and merge many
pulls.

It also not honest.  702 only "passes" CI because it doesn't have tests.  If
that is enough "passing" for you, then we could take the tests out of 208 --
and we could have done it back in December.

> I tried to help 208 making pass the test and shared my progress
>
https://github.com/apache/incubator-zeppelin/pull/208#issuecomment-173423103
> which passes CI with one profile. But you seems not like it. Okay.

Not true.  In *3 months* when you had promised the community that you would
look into the CI issues, the only thing you did was try the PR with a CI
profile that didn't load the PR code.  You also held the PR up since
September
- because Felix asked you to.

On Monday, March 07, 2016 11:06:19 PM you wrote:
> Here's technical differences between 208 and 702.
>
> - 208 includes rscala depenency as a source, 702 download dependency
> library on buildtime
> - 208 placed in separate maven sub module r, 702 placed in existing spark
> submodule.
> - 208 creates another socket to communicate to interpreter, 702 does not
> - many more
>
> It's enough to say implementations are technically different.
> Once they both merged, we can take each implementation's advantage and
> improve each other. If community want, they'll be eventually merged. If
> community see advantage of keeping both, they'll be co-exists.
>
> Multiple implementation for similar function can make some confusion. But
> confusion can be minimized in many different ways. e.g. Good
documentation,
> build-time option, runtime option, etc.
>
> For this reason, I don't see any big problem on c) merging both 208 and
702
> both, and possible different interpreter implementations in the future.
>
>
> Amos, Regarding progress of 208,
>
> 208 is not an exceptional PR that can be merged without CI pass. Could you
> accept this simple rule?
>
> I tried to help 208 making pass the test and shared my progress
>
https://github.com/apache/incubator-zeppelin/pull/208#issuecomment-173423103
> which
> passes CI with one profile. But you seems not like it. Okay.
>
> Then it has been always open you or anyone fix the problem 208 for last 6
> months. and it'll always be. Nothing blocks anyone working on 208.
>
> Thanks,
> moon
>
> On Mon, Mar 7, 2016 at 12:30 PM Amos B. Elberg <am...@gmail.com>
>
> wrote:
> > Yes I do - I don’t see that there’s been *any* technical reason at all
> > raised in your email below, or in Alex’s.
> >
> > I think statements like this: “Technically implementation of 208 and 702
> > are different. No reason to reject one because of the other while
they're
> > not identical.” are nonsense.
> >
> > The burden is on you to explain the technical reason why 208 hasn’t been
> > merged already.  Because all I see are delays and excuses.
> >
> > What are the objections to 208?  The only objection came from,
originally,
> > Felix Cheung, who came to you privately and asked you to hold-up the PR
> > because he wanted credit for work he hadn’t done so you would think that
> > he’s a programmer.
> >
> > So why hasn’t 208 been merged?  Over the past six months, how many of my
> > “what remains to be done so this can be merged?” messages have been
> > ignored?
> >
> > Your explanation used to be because of CI.  But, you committed to fix
CI,
> > and then didn’t look at it.  More recently Alex took a look, but hasn’t
> > made any progress.  And now you want to merge 702, but 702 only looks
like
> > it passes CI because it doesn’t have a testing suite!
> >
> > All this stuff about 702 is nonsense.  702 has no functionality not
> > present in 208.  702 is *based* on 208.  208 has functionality 702 does
> > not.  208 has been stable since September; 702 has broken, and had to
have
> > its architecture reengineered to be more like 208, at least once.  208
has
> > a user base; 702 does not.
> >
> > *Numerous* users have asked specifically for 208.  The only user
requests
> > concerning 702, are people complaining they are confused because of two
> > PRs
> > with similar functionality.  How would merging both PRs make any sense?
> > It
> > would only create more confusion.
> >
> > So why are you continuing to hold-up 208?
> >
> > --
> > Amos Elberg
> > Sent with Airmail
> >
> > From: moon soo Lee <mo...@apache.org> <mo...@apache.org>
> > Reply: dev@zeppelin.incubator.apache.org
> > <de...@zeppelin.incubator.apache.org> <de...@zeppelin.incubator.apache.org>
> > Date: March 7, 2016 at 2:19:57 PM
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
>
> > <de...@zeppelin.incubator.apache.org>
> > Subject:  Re: R interpreter in Zeppelin: further steps
> >
> > Amos,
> >
> > Do you see any single non technical reason being discussed for not
merging
> > 208, in this thread or anywhere else? Please share them if you have.
> >
> > Thanks,
> > moon
> >
> > On Mon, Mar 7, 2016 at 10:21 AM Amos B. Elberg <am...@gmail.com>
> >
> > wrote:
> > > 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 <mo...@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 <bz...@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.steinmetz@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" <am...@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.elberg@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 <
> >
> > bzz@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.steinmetz@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.mazumder00@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 <
> > > >>>
> > > >>> enzo@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
> > > >>>>>>>>>> enzo@smartinsightsfromdata.com
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
> > > >>
> > > >> eranwitkon@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 <
> > > >>>
> > > >>> doanduyhai@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 <
> > > >>>>>>>
> > > >>>>>>> bzz@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.

Re: R interpreter in Zeppelin: further steps

[Corneau Damien <co...@apache.org>]

c) was more a way of saying that there could be multiple interpreters for
the same technology.
There was multiple discussions about trying to have interpreters outside of
the project core, and it could probably be easier for it to happen at that
time.

I think that a) or c) doesn't matter since it doesn't change much to
current status of those PR.
So far 208 has been the closest to master readiness, and there is effort
from @alex to help it being merged soon.

On Tue, Mar 8, 2016 at 8:06 AM, moon soo Lee <mo...@apache.org> wrote:

> Here's technical differences between 208 and 702.
>
> - 208 includes rscala depenency as a source, 702 download dependency
> library on buildtime
> - 208 placed in separate maven sub module r, 702 placed in existing spark
> submodule.
> - 208 creates another socket to communicate to interpreter, 702 does not
> - many more
>
> It's enough to say implementations are technically different.
> Once they both merged, we can take each implementation's advantage and
> improve each other. If community want, they'll be eventually merged. If
> community see advantage of keeping both, they'll be co-exists.
>
> Multiple implementation for similar function can make some confusion. But
> confusion can be minimized in many different ways. e.g. Good documentation,
> build-time option, runtime option, etc.
>
> For this reason, I don't see any big problem on c) merging both 208 and 702
> both, and possible different interpreter implementations in the future.
>
>
> Amos, Regarding progress of 208,
>
> 208 is not an exceptional PR that can be merged without CI pass. Could you
> accept this simple rule?
>
> I tried to help 208 making pass the test and shared my progress
>
> https://github.com/apache/incubator-zeppelin/pull/208#issuecomment-173423103
> which
> passes CI with one profile. But you seems not like it. Okay.
>
> Then it has been always open you or anyone fix the problem 208 for last 6
> months. and it'll always be. Nothing blocks anyone working on 208.
>
> Thanks,
> moon
>
> On Mon, Mar 7, 2016 at 12:30 PM Amos B. Elberg <am...@gmail.com>
> wrote:
>
> > Yes I do - I don’t see that there’s been *any* technical reason at all
> > raised in your email below, or in Alex’s.
> >
> > I think statements like this: “Technically implementation of 208 and 702
> > are different. No reason to reject one because of the other while they're
> > not identical.” are nonsense.
> >
> > The burden is on you to explain the technical reason why 208 hasn’t been
> > merged already.  Because all I see are delays and excuses.
> >
> > What are the objections to 208?  The only objection came from,
> originally,
> > Felix Cheung, who came to you privately and asked you to hold-up the PR
> > because he wanted credit for work he hadn’t done so you would think that
> > he’s a programmer.
> >
> > So why hasn’t 208 been merged?  Over the past six months, how many of my
> > “what remains to be done so this can be merged?” messages have been
> > ignored?
> >
> > Your explanation used to be because of CI.  But, you committed to fix CI,
> > and then didn’t look at it.  More recently Alex took a look, but hasn’t
> > made any progress.  And now you want to merge 702, but 702 only looks
> like
> > it passes CI because it doesn’t have a testing suite!
> >
> > All this stuff about 702 is nonsense.  702 has no functionality not
> > present in 208.  702 is *based* on 208.  208 has functionality 702 does
> > not.  208 has been stable since September; 702 has broken, and had to
> have
> > its architecture reengineered to be more like 208, at least once.  208
> has
> > a user base; 702 does not.
> >
> > *Numerous* users have asked specifically for 208.  The only user requests
> > concerning 702, are people complaining they are confused because of two
> PRs
> > with similar functionality.  How would merging both PRs make any sense?
> It
> > would only create more confusion.
> >
> > So why are you continuing to hold-up 208?
> >
> > --
> > Amos Elberg
> > Sent with Airmail
> >
> > From: moon soo Lee <mo...@apache.org> <mo...@apache.org>
> > Reply: dev@zeppelin.incubator.apache.org
> > <de...@zeppelin.incubator.apache.org> <de...@zeppelin.incubator.apache.org>
> > Date: March 7, 2016 at 2:19:57 PM
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > <de...@zeppelin.incubator.apache.org>
> > Subject:  Re: R interpreter in Zeppelin: further steps
> >
> > Amos,
> >
> > Do you see any single non technical reason being discussed for not
> merging
> > 208, in this thread or anywhere else? Please share them if you have.
> >
> > Thanks,
> > moon
> >
> > On Mon, Mar 7, 2016 at 10:21 AM Amos B. Elberg <am...@gmail.com>
> > wrote:
> >
> > > 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 <mo...@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 <bz...@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.steinmetz@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" <am...@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.elberg@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 <
> > bzz@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.steinmetz@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.mazumder00@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 <
> > > >>> enzo@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
> > > >>>>>>>>>> enzo@smartinsightsfromdata.com
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
> > > >> eranwitkon@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 <
> > > >>> doanduyhai@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 <
> > > >>>>>>>
> > > >>>>>>> bzz@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.
> > > >>>>
> > > >>>
> > > >>>
> > > >>
> > >
> >
> >
>

Re: R interpreter in Zeppelin: further steps

[moon soo Lee <mo...@apache.org>]

Here's technical differences between 208 and 702.

- 208 includes rscala depenency as a source, 702 download dependency
library on buildtime
- 208 placed in separate maven sub module r, 702 placed in existing spark
submodule.
- 208 creates another socket to communicate to interpreter, 702 does not
- many more

It's enough to say implementations are technically different.
Once they both merged, we can take each implementation's advantage and
improve each other. If community want, they'll be eventually merged. If
community see advantage of keeping both, they'll be co-exists.

Multiple implementation for similar function can make some confusion. But
confusion can be minimized in many different ways. e.g. Good documentation,
build-time option, runtime option, etc.

For this reason, I don't see any big problem on c) merging both 208 and 702
both, and possible different interpreter implementations in the future.


Amos, Regarding progress of 208,

208 is not an exceptional PR that can be merged without CI pass. Could you
accept this simple rule?

I tried to help 208 making pass the test and shared my progress
https://github.com/apache/incubator-zeppelin/pull/208#issuecomment-173423103
which
passes CI with one profile. But you seems not like it. Okay.

Then it has been always open you or anyone fix the problem 208 for last 6
months. and it'll always be. Nothing blocks anyone working on 208.

Thanks,
moon

On Mon, Mar 7, 2016 at 12:30 PM Amos B. Elberg <am...@gmail.com>
wrote:

> Yes I do - I don’t see that there’s been *any* technical reason at all
> raised in your email below, or in Alex’s.
>
> I think statements like this: “Technically implementation of 208 and 702
> are different. No reason to reject one because of the other while they're
> not identical.” are nonsense.
>
> The burden is on you to explain the technical reason why 208 hasn’t been
> merged already.  Because all I see are delays and excuses.
>
> What are the objections to 208?  The only objection came from, originally,
> Felix Cheung, who came to you privately and asked you to hold-up the PR
> because he wanted credit for work he hadn’t done so you would think that
> he’s a programmer.
>
> So why hasn’t 208 been merged?  Over the past six months, how many of my
> “what remains to be done so this can be merged?” messages have been
> ignored?
>
> Your explanation used to be because of CI.  But, you committed to fix CI,
> and then didn’t look at it.  More recently Alex took a look, but hasn’t
> made any progress.  And now you want to merge 702, but 702 only looks like
> it passes CI because it doesn’t have a testing suite!
>
> All this stuff about 702 is nonsense.  702 has no functionality not
> present in 208.  702 is *based* on 208.  208 has functionality 702 does
> not.  208 has been stable since September; 702 has broken, and had to have
> its architecture reengineered to be more like 208, at least once.  208 has
> a user base; 702 does not.
>
> *Numerous* users have asked specifically for 208.  The only user requests
> concerning 702, are people complaining they are confused because of two PRs
> with similar functionality.  How would merging both PRs make any sense?  It
> would only create more confusion.
>
> So why are you continuing to hold-up 208?
>
> --
> Amos Elberg
> Sent with Airmail
>
> From: moon soo Lee <mo...@apache.org> <mo...@apache.org>
> Reply: dev@zeppelin.incubator.apache.org
> <de...@zeppelin.incubator.apache.org> <de...@zeppelin.incubator.apache.org>
> Date: March 7, 2016 at 2:19:57 PM
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> <de...@zeppelin.incubator.apache.org>
> Subject:  Re: R interpreter in Zeppelin: further steps
>
> Amos,
>
> Do you see any single non technical reason being discussed for not merging
> 208, in this thread or anywhere else? Please share them if you have.
>
> Thanks,
> moon
>
> On Mon, Mar 7, 2016 at 10:21 AM Amos B. Elberg <am...@gmail.com>
> wrote:
>
> > 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 <mo...@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 <bz...@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.steinmetz@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" <am...@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.elberg@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 <
> bzz@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.steinmetz@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.mazumder00@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 <
> > >>> enzo@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
> > >>>>>>>>>> enzo@smartinsightsfromdata.com
> > >>>>>>>>>>
> > >>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
> > >> eranwitkon@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 <
> > >>> doanduyhai@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 <
> > >>>>>>>
> > >>>>>>> bzz@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.
> > >>>>
> > >>>
> > >>>
> > >>
> >
>
>

Re: R interpreter in Zeppelin: further steps

["Amos B. Elberg" <am...@gmail.com>]

Yes I do - I don’t see that there’s been *any* technical reason at all raised in your email below, or in Alex’s.  

I think statements like this: “Technically implementation of 208 and 702 are different. No reason to reject one because of the other while they're not identical.” are nonsense.  

The burden is on you to explain the technical reason why 208 hasn’t been merged already.  Because all I see are delays and excuses. 

What are the objections to 208?  The only objection came from, originally, Felix Cheung, who came to you privately and asked you to hold-up the PR because he wanted credit for work he hadn’t done so you would think that he’s a programmer. 

So why hasn’t 208 been merged?  Over the past six months, how many of my “what remains to be done so this can be merged?” messages have been ignored? 

Your explanation used to be because of CI.  But, you committed to fix CI, and then didn’t look at it.  More recently Alex took a look, but hasn’t made any progress.  And now you want to merge 702, but 702 only looks like it passes CI because it doesn’t have a testing suite!  

All this stuff about 702 is nonsense.  702 has no functionality not present in 208.  702 is *based* on 208.  208 has functionality 702 does not.  208 has been stable since September; 702 has broken, and had to have its architecture reengineered to be more like 208, at least once.  208 has a user base; 702 does not. 

*Numerous* users have asked specifically for 208.  The only user requests concerning 702, are people complaining they are confused because of two PRs with similar functionality.  How would merging both PRs make any sense?  It would only create more confusion.  

So why are you continuing to hold-up 208?  

-- 
Amos Elberg
Sent with Airmail

From: moon soo Lee <mo...@apache.org>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: March 7, 2016 at 2:19:57 PM
To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: R interpreter in Zeppelin: further steps  

Amos,  

Do you see any single non technical reason being discussed for not merging  
208, in this thread or anywhere else? Please share them if you have.  

Thanks,  
moon  

On Mon, Mar 7, 2016 at 10:21 AM Amos B. Elberg <am...@gmail.com>  
wrote:  

> 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 <mo...@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 <bz...@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.steinmetz@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" <am...@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 <am...@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 <bz...@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.steinmetz@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.mazumder00@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 <  
> >>> enzo@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  
> >>>>>>>>>> enzo@smartinsightsfromdata.com  
> >>>>>>>>>>  
> >>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <  
> >> eranwitkon@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 <  
> >>> doanduyhai@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 <  
> >>>>>>>  
> >>>>>>> bzz@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.  
> >>>>  
> >>>  
> >>>  
> >>  
>  

Re: R interpreter in Zeppelin: further steps

[moon soo Lee <mo...@apache.org>]

Amos,

Do you see any single non technical reason being discussed for not merging
208, in this thread or anywhere else? Please share them if you have.

Thanks,
moon

On Mon, Mar 7, 2016 at 10:21 AM Amos B. Elberg <am...@gmail.com>
wrote:

> 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 <mo...@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 <bz...@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.steinmetz@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" <am...@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 <am...@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 <bz...@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.steinmetz@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.mazumder00@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 <
> >>> enzo@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
> >>>>>>>>>> enzo@smartinsightsfromdata.com
> >>>>>>>>>>
> >>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
> >> eranwitkon@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 <
> >>> doanduyhai@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 <
> >>>>>>>
> >>>>>>> bzz@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.
> >>>>
> >>>
> >>>
> >>
>

Re: R interpreter in Zeppelin: further steps

["Amos B. Elberg" <am...@gmail.com>]

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 <mo...@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 <bz...@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.steinmetz@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" <am...@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 <am...@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 <bz...@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.steinmetz@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.mazumder00@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 <
>>> enzo@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
>>>>>>>>>> enzo@smartinsightsfromdata.com
>>>>>>>>>> 
>>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <
>> eranwitkon@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 <
>>> doanduyhai@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 <
>>>>>>> 
>>>>>>> bzz@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.
>>>> 
>>> 
>>> 
>> 

Re: R interpreter in Zeppelin: further steps

[moon soo Lee <mo...@apache.org>]

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 <bz...@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.steinmetz@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" <am...@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 <am...@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 <bz...@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.steinmetz@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.mazumder00@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 <
> > enzo@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
> > >> > > > >> enzo@smartinsightsfromdata.com
> > >> > > > >>
> > >> > > > >> > On 29 Feb 2016, at 12:36, Eran Witkon <
> eranwitkon@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 <
> > doanduyhai@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 <
> > >> > >
> > >> > > bzz@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.
> > >
> >
> >
>

Re: R interpreter in Zeppelin: further steps

[Alexander Bezzubov <bz...@apache.org>]

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 <je...@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" <am...@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 <am...@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 <bz...@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.steinmetz@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.mazumder00@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 <
> enzo@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
> >> > > > >> enzo@smartinsightsfromdata.com
> >> > > > >>
> >> > > > >> > On 29 Feb 2016, at 12:36, Eran Witkon <er...@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 <
> doanduyhai@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 <
> >> > >
> >> > > bzz@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.
> >
>
>

Re: R interpreter in Zeppelin: further steps

[Jeff Steinmetz <je...@gmail.com>]

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" <am...@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 <am...@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 <bz...@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.steinmetz@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" <so...@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 <enzo@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
>> > > > >> enzo@smartinsightsfromdata.com
>> > > > >> 
>> > > > >> > On 29 Feb 2016, at 12:36, Eran Witkon <er...@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 <doanduyhai@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 <
>> > > 
>> > > bzz@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.
>

Re: R interpreter in Zeppelin: further steps

[Amos Elberg <am...@gmail.com>]

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 <am...@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 <bz...@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.steinmetz@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" <so...@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 <enzo@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
> > > > >> enzo@smartinsightsfromdata.com
> > > > >> 
> > > > >> > On 29 Feb 2016, at 12:36, Eran Witkon <er...@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 <doanduyhai@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 <
> > > 
> > > bzz@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.

Re: R interpreter in Zeppelin: further steps

[Alexander Bezzubov <ab...@nflabs.com>]

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 <am...@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 <bz...@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.steinmetz@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" <so...@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 <enzo@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
> > > >> enzo@smartinsightsfromdata.com
> > > >>
> > > >>
> > > >>
> > > >> > On 29 Feb 2016, at 12:36, Eran Witkon <er...@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 <doanduyhai@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 <
> > bzz@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.

Re: R interpreter in Zeppelin: further steps

[Amos Elberg <am...@gmail.com>]

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 <bz...@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.steinmetz@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" <so...@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 <en...@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
> > >> enzo@smartinsightsfromdata.com
> > >>
> > >>
> > >>
> > >> > On 29 Feb 2016, at 12:36, Eran Witkon <er...@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 <do...@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 <
> bzz@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.
> > >> >>>
> > >> >>
> > >>
> > >>
> >
> >
>

Re: R interpreter in Zeppelin: further steps

[Alexander Bezzubov <bz...@apache.org>]

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 <je...@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" <so...@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 <en...@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
> >> enzo@smartinsightsfromdata.com
> >>
> >>
> >>
> >> > On 29 Feb 2016, at 12:36, Eran Witkon <er...@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 <do...@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 <bz...@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.
> >> >>>
> >> >>
> >>
> >>
>
>

Re: R interpreter in Zeppelin: further steps

[Jeff Steinmetz <je...@gmail.com>]

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" <so...@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 <en...@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
>> enzo@smartinsightsfromdata.com
>>
>>
>>
>> > On 29 Feb 2016, at 12:36, Eran Witkon <er...@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 <do...@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 <bz...@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.
>> >>>
>> >>
>>
>>

Re: R interpreter in Zeppelin: further steps

[Sourav Mazumder <so...@gmail.com>]

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 <en...@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
> enzo@smartinsightsfromdata.com
>
>
>
> > On 29 Feb 2016, at 12:36, Eran Witkon <er...@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 <do...@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 <bz...@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.
> >>>
> >>
>
>

Re: R interpreter in Zeppelin: further steps

[enzo <en...@smartinsightsfromdata.com>]

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
enzo@smartinsightsfromdata.com



> On 29 Feb 2016, at 12:36, Eran Witkon <er...@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 <do...@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 <bz...@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.
>>> 
>> 

Re: R interpreter in Zeppelin: further steps

[Eran Witkon <er...@gmail.com>]

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 <do...@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 <bz...@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.
> >
>

Re: R interpreter in Zeppelin: further steps

[DuyHai Doan <do...@gmail.com>]

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