[GitHub] zeppelin pull request #2708: [Zeppelin-3095] Fix UI when all paragraphs exec...

2017-12-19 Thread tinkoff-dwh
GitHub user tinkoff-dwh reopened a pull request:

https://github.com/apache/zeppelin/pull/2708

[Zeppelin-3095] Fix UI when all paragraphs executing sequentially

### What is this PR for?
This PR fixes the incorrect behavior of UI during the execution of the 
RunAllParagraphs. 
Including: allows you to copy the note at runtime (before that, the new 
note was created only after the end of runAllParagraph), blocks some interface 
elements.
The following items are blocked:

**Paragraphs Control :**
* Move up
* Move down
* Insert new
* Clone paragraph
* Run all above
* Run all below
* Disable run
* Remove

**Note :**
* Insert new paragraph

### What type of PR is it?
Improvement

### What is the Jira issue?
[Zeppelin-3095](https://issues.apache.org/jira/browse/ZEPPELIN-3095)

### How should this be tested?
Run the paragraphs by clicking the "run all paragraphs" button
Ensures that the required items are locked

### Questions:
* Does the licenses files need update? no
* Is there breaking changes for older versions? no
* Does this needs documentation? no


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tinkoff-dwh/zeppelin ZEPPELIN-3095

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/zeppelin/pull/2708.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2708


commit ca4c2d068cdef53146cd24649e3e85493667d74e
Author: tinkoff-dwh 
Date:   2017-12-07T14:30:27Z

[ZEPPELIN-3095] fix UI when paragraphs run sequential

commit 793e996c9f89307233857570dce8fc83228b499a
Author: tinkoff-dwh 
Date:   2017-12-11T14:34:19Z

[ZEPPELIN-3095] runAllParagraphs() moved to a separate thread

commit b32ab091fee272345b01731c364a65d6b561140c
Author: tinkoff-dwh 
Date:   2017-12-12T08:06:17Z

[ZEPPELIN-3095] code style fix

commit bfc7fca136760b193a2392e3f2b24eb21b1356a2
Author: tinkoff-dwh 
Date:   2017-12-14T06:37:23Z

[ZEPPELIN-3095] fix runAllParagraphs

commit ce95ad35db9a36079db200c55e5255118f36bc88
Author: tinkoff-dwh 
Date:   2017-12-14T07:16:41Z

Merge branch 'master' into ZEPPELIN-3095

# Conflicts:
#   zeppelin-web/src/app/notebook/paragraph/paragraph-control.html

commit a22c46e3ea306874848e13b773fc873d1980c146
Author: tinkoff-dwh 
Date:   2017-12-14T08:06:36Z

[ZEPPELIN-3095] add runAllToThis() and runAllFromThis() to lock

commit 6351cb3221124c7334824c91b5934ea9249fabc8
Author: tinkoff-dwh 
Date:   2017-12-18T08:03:02Z

[ZEPPELIN-3095] small fix. test repair.

commit 653755a989affcd3abe517f407ecfc03e5e52ff8
Author: tinkoff-dwh 
Date:   2017-12-18T11:26:53Z

[ZEPPELIN-3095] change update info method

commit 573ebba35f1180d3c04ea1fed4cb98be29d03d1f
Author: tinkoff-dwh 
Date:   2017-12-18T12:16:33Z

[ZEPPELIN-3095] fix test

commit 81c1a63c608dcdd7ca79ba1250663d7645c9e8b1
Author: tinkoff-dwh 
Date:   2017-12-18T15:02:22Z

[ZEPPELIN-3095] fix test

commit da9517b9b53100f4db883a99ce69a39028e9cb86
Author: tinkoff-dwh 
Date:   2017-12-18T15:04:57Z

[ZEPPELIN-3095] fix test. again

commit a15ee6ac1ac5e9cf71eb0108cc18b200324bf38d
Author: tinkoff-dwh 
Date:   2017-12-19T10:03:17Z

[Zeppelin-3095] small fix




---


[GitHub] zeppelin pull request #2708: [Zeppelin-3095] Fix UI when all paragraphs exec...

2017-12-19 Thread tinkoff-dwh
Github user tinkoff-dwh closed the pull request at:

https://github.com/apache/zeppelin/pull/2708


---


[GitHub] zeppelin issue #2653: [ZEPPELIN-3038] Network visualization not show "source...

2017-12-19 Thread conker84
Github user conker84 commented on the issue:

https://github.com/apache/zeppelin/pull/2653
  
hi guys, any news?


---


[GitHub] zeppelin pull request #2710: [MINOR] Remove r from zeppelin-web test

2017-12-19 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/zeppelin/pull/2710


---


[GitHub] zeppelin issue #2710: [MINOR] Remove r from zeppelin-web test

2017-12-19 Thread jongyoul
Github user jongyoul commented on the issue:

https://github.com/apache/zeppelin/pull/2710
  
Thanks. Will merge it


---


[GitHub] zeppelin issue #2710: [MINOR] Remove r from zeppelin-web test

2017-12-19 Thread tinkoff-dwh
Github user tinkoff-dwh commented on the issue:

https://github.com/apache/zeppelin/pull/2710
  
LGTM


---


[GitHub] zeppelin pull request #2710: Removed r from zeppelin-web test

2017-12-19 Thread jongyoul
GitHub user jongyoul opened a pull request:

https://github.com/apache/zeppelin/pull/2710

Removed r from zeppelin-web test

### What is this PR for?
Reducing test time to remove unused dependencies from some profile. We will 
reduce whole test time by removing some unused packages.

### What type of PR is it?
[Improvement]

### Todos
* [x] - Remove R related packages from some profiles

### What is the Jira issue?
* MINOR

### How should this be tested?
* Check the CI

### Screenshots (if appropriate)
Before:

![image](https://user-images.githubusercontent.com/3612566/34191013-676b2958-e587-11e7-8e05-b6bd0df40ede.png)

After:

![image](https://user-images.githubusercontent.com/3612566/34191029-73619760-e587-11e7-926d-cfc0040d95e5.png)


### Questions:
* Does the licenses files need update? No
* Is there breaking changes for older versions? No
* Does this needs documentation? No


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jongyoul/zeppelin minor/remove-unused-r-in-ci

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/zeppelin/pull/2710.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2710


commit 64d765cd6d1744eabef16e9b2e5b7c0115c2f97a
Author: Jongyoul Lee 
Date:   2017-12-18T10:06:47Z

Removed r from zeppelin-web test




---


[GitHub] zeppelin pull request #2687: [ZEPPELIN-3077] Cron scheduler is easy to get s...

2017-12-19 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/zeppelin/pull/2687


---


[GitHub] zeppelin pull request #2698: [ZEPPELIN-3007] display a note name without any...

2017-12-19 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/zeppelin/pull/2698


---


[GitHub] zeppelin issue #2706: ZEPPELIN-3105 Notebook not running via REST API after ...

2017-12-19 Thread weand
Github user weand commented on the issue:

https://github.com/apache/zeppelin/pull/2706
  
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 164.418 sec 
<<< FAILURE! - in org.apache.zeppelin.integration.InterpreterModeActionsIT

seems to be a flaky test, see log 
[here](https://travis-ci.org/weand/zeppelin/jobs/318812306)


---


[GitHub] zeppelin issue #2706: ZEPPELIN-3105 Notebook not running via REST API after ...

2017-12-19 Thread weand
Github user weand commented on the issue:

https://github.com/apache/zeppelin/pull/2706
  
how can I retrigger CI? 


---


Re: [DISCUSS] Review process

2017-12-19 Thread Jongyoul Lee
I agree with some large PR should be delayed a bit longer. What I meant is
we don't have to wait for all kind of PRs.

On Wed, Dec 20, 2017 at 2:11 AM, Felix Cheung 
wrote:

> +1
> What would be the rough heuristic people will be comfortable with- what is
> small and what is big?
>
> _
> From: Anthony Corbacho 
> Sent: Monday, December 18, 2017 3:02 PM
> Subject: Re: [DISCUSS] Review process
> To: 
>
>
> I think for large PR (new feature or big change) we should still keep more
> than one approval before merging it since this will require more attension.
>
> But for bug fix i think one approval should be enough.
>
> On Tue, 19 Dec 2017 at 7:49 AM Jeff Zhang  wrote:
>
> > Agree with @Felix, especially for the large PR and PR of new features it
> > is still necessary to have more than +1.
> >
> > I think committer have the ability to identity whether this PR is
> > complicated enough that needs another committer's review. As long we as
> > have consensus, we could commit some PR without delay and some PR for
> more
> > reviews. So that we can balance the development speed and code quality.
> >
> >
> >
> > Miquel Angel Andreu Febrer 于2017年12月19日周二
> > 上午2:07写道:
> >
> > > You can automate that process in jenkins and manage the delay time of
> > > merging a pull request
> > >
> > > El 18 dic. 2017 18:03, "Felix Cheung" 
> > > escribió:
> > >
> > > > I think it is still useful to have a time delay after one approve
> since
> > > > often time there are very feedback and updates after one committer
> > > approval.
> > > >
> > > > Also github has a tab for all PRs you are subscribed to, it shouldn’t
> > be
> > > > very hard to review all the approved ones again.
> > > >
> > > > 
> > > > From: Jongyoul Lee 
> > > > Sent: Monday, December 18, 2017 8:04:51 AM
> > > > To: dev@zeppelin.apache.org
> > > > Subject: Re: [DISCUSS] Review process
> > > >
> > > > Good for summary. But actually, no committer merges without delay
> after
> > > > reviewing it. So I thought we should clarify it officially.
> > > >
> > > > Now, some committers, including me, will be able to merge some PRs
> > > without
> > > > delay and burden.
> > > >
> > > > On Mon, 18 Dec 2017 at 11:27 PM moon soo Lee 
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Current review process[1] does require either at least a +1 from
> > > > committer
> > > > > or 24 hours for lazy consensus.
> > > > >
> > > > > Pullrequest can be open for 1 or 2 days for additional review, but
> i
> > > > think
> > > > > they're not hard requirements. (e.g. Hotfixes are already being
> > merged
> > > > > without waiting additional review)
> > > > >
> > > > > So, technically, current policy allows any committer can start
> > review,
> > > > mark
> > > > > +1 and merge immediately without any delay if necessary.
> > > > >
> > > > > Thanks,
> > > > > moon
> > > > >
> > > > > [1]
> > > > >
> > > > > http://zeppelin.apache.org/contribution/contributions.
> > > > html#the-review-process
> > > > >
> > > > >
> > > > > On Mon, Dec 18, 2017 at 2:13 AM Belousov Maksim Eduardovich <
> > > > > m.belou...@tinkoff.ru> wrote:
> > > > >
> > > > > > +1 for non-delay merging.
> > > > > > Our team have opened approved PR [1] for 5 days.
> > > > > >
> > > > > > I didn't find any pages with `consensus how to review and merge
> > > > > > contributions`.
> > > > > > It would be nice to write a check list for reviewer.
> > > > > >
> > > > > > The development of Zeppelin is very important for us and we want
> to
> > > > > review
> > > > > > new commits.
> > > > > >
> > > > > >
> > > > > > [1] https://github.com/apache/zeppelin/pull/2697
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Maksim Belousov
> > > > > >
> > > > > > -Original Message-
> > > > > > From: Jongyoul Lee [mailto:jongy...@gmail.com]
> > > > > > Sent: Monday, December 18, 2017 12:12 PM
> > > > > > To: dev 
> > > > > > Subject: Re: [DISCUSS] Review process
> > > > > >
> > > > > > Thank you for the replying it. I think so
> > > > > >
> > > > > > On Mon, Dec 18, 2017 at 3:15 PM, Miquel Angel Andreu Febrer <
> > > > > > miquelangeland...@gmail.com> wrote:
> > > > > >
> > > > > > > I agree, ig is necessary to have no delay afternoon merging. I
> > > think
> > > > > > > it will help speed up processes and help contributors
> > > > > > >
> > > > > > > El 18 dic. 2017 4:33, "Jongyoul Lee" 
> > > escribió:
> > > > > > >
> > > > > > > Hi committers,
> > > > > > >
> > > > > > > I want to suggest one thing about our reviewing process. We
> have
> > > the
> > > > > > > policy to wait for one-day before merging some PRs. AFAIK, It's
> > > > > > > because we reduce mistakes and prevent abuses from committing
> by
> > > > owner
> > > > > > > 

[GitHub] zeppelin pull request #2707: [ZEPPELIN-3100] Upgrade node and npm version

2017-12-19 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/zeppelin/pull/2707


---


[GitHub] zeppelin issue #2707: [ZEPPELIN-3100] Upgrade node and npm version

2017-12-19 Thread jongyoul
Github user jongyoul commented on the issue:

https://github.com/apache/zeppelin/pull/2707
  
@felixcheung Yes, yarn is faster than npm4 but recently, npm5 is much 
faster than yarn. FE moves so fast :-)


---


Re: [DISCUSS] Review process

2017-12-19 Thread Felix Cheung
+1
What would be the rough heuristic people will be comfortable with- what is 
small and what is big?

_
From: Anthony Corbacho 
Sent: Monday, December 18, 2017 3:02 PM
Subject: Re: [DISCUSS] Review process
To: 


I think for large PR (new feature or big change) we should still keep more
than one approval before merging it since this will require more attension.

But for bug fix i think one approval should be enough.

On Tue, 19 Dec 2017 at 7:49 AM Jeff Zhang  wrote:

> Agree with @Felix, especially for the large PR and PR of new features it
> is still necessary to have more than +1.
>
> I think committer have the ability to identity whether this PR is
> complicated enough that needs another committer's review. As long we as
> have consensus, we could commit some PR without delay and some PR for more
> reviews. So that we can balance the development speed and code quality.
>
>
>
> Miquel Angel Andreu Febrer 于2017年12月19日周二
> 上午2:07写道:
>
> > You can automate that process in jenkins and manage the delay time of
> > merging a pull request
> >
> > El 18 dic. 2017 18:03, "Felix Cheung" 
> > escribió:
> >
> > > I think it is still useful to have a time delay after one approve since
> > > often time there are very feedback and updates after one committer
> > approval.
> > >
> > > Also github has a tab for all PRs you are subscribed to, it shouldn’t
> be
> > > very hard to review all the approved ones again.
> > >
> > > 
> > > From: Jongyoul Lee 
> > > Sent: Monday, December 18, 2017 8:04:51 AM
> > > To: dev@zeppelin.apache.org
> > > Subject: Re: [DISCUSS] Review process
> > >
> > > Good for summary. But actually, no committer merges without delay after
> > > reviewing it. So I thought we should clarify it officially.
> > >
> > > Now, some committers, including me, will be able to merge some PRs
> > without
> > > delay and burden.
> > >
> > > On Mon, 18 Dec 2017 at 11:27 PM moon soo Lee  wrote:
> > >
> > > > Hi,
> > > >
> > > > Current review process[1] does require either at least a +1 from
> > > committer
> > > > or 24 hours for lazy consensus.
> > > >
> > > > Pullrequest can be open for 1 or 2 days for additional review, but i
> > > think
> > > > they're not hard requirements. (e.g. Hotfixes are already being
> merged
> > > > without waiting additional review)
> > > >
> > > > So, technically, current policy allows any committer can start
> review,
> > > mark
> > > > +1 and merge immediately without any delay if necessary.
> > > >
> > > > Thanks,
> > > > moon
> > > >
> > > > [1]
> > > >
> > > > http://zeppelin.apache.org/contribution/contributions.
> > > html#the-review-process
> > > >
> > > >
> > > > On Mon, Dec 18, 2017 at 2:13 AM Belousov Maksim Eduardovich <
> > > > m.belou...@tinkoff.ru> wrote:
> > > >
> > > > > +1 for non-delay merging.
> > > > > Our team have opened approved PR [1] for 5 days.
> > > > >
> > > > > I didn't find any pages with `consensus how to review and merge
> > > > > contributions`.
> > > > > It would be nice to write a check list for reviewer.
> > > > >
> > > > > The development of Zeppelin is very important for us and we want to
> > > > review
> > > > > new commits.
> > > > >
> > > > >
> > > > > [1] https://github.com/apache/zeppelin/pull/2697
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Maksim Belousov
> > > > >
> > > > > -Original Message-
> > > > > From: Jongyoul Lee [mailto:jongy...@gmail.com]
> > > > > Sent: Monday, December 18, 2017 12:12 PM
> > > > > To: dev 
> > > > > Subject: Re: [DISCUSS] Review process
> > > > >
> > > > > Thank you for the replying it. I think so
> > > > >
> > > > > On Mon, Dec 18, 2017 at 3:15 PM, Miquel Angel Andreu Febrer <
> > > > > miquelangeland...@gmail.com> wrote:
> > > > >
> > > > > > I agree, ig is necessary to have no delay afternoon merging. I
> > think
> > > > > > it will help speed up processes and help contributors
> > > > > >
> > > > > > El 18 dic. 2017 4:33, "Jongyoul Lee" 
> > escribió:
> > > > > >
> > > > > > Hi committers,
> > > > > >
> > > > > > I want to suggest one thing about our reviewing process. We have
> > the
> > > > > > policy to wait for one-day before merging some PRs. AFAIK, It's
> > > > > > because we reduce mistakes and prevent abuses from committing by
> > > owner
> > > > > > without reviewing it concretely. I would like to change this
> policy
> > > to
> > > > > > remove delay after merging it. We, recently, don't have much
> > > reviewers
> > > > > > and committers who can merge continuously, and in my case, I,
> > > > > > sometimes, forget some PRs that I have to merge. And I also
> believe
> > > > > > all committers have consensus how to review and merge
> > contributions.
> > > > > >
> > > > > > How do you think of it?
> > > > > >
> > > > > > 

[GitHub] zeppelin pull request #2709: ZEPPEIN-3111. Refactor SparkInterpreter

2017-12-19 Thread zjffdu
GitHub user zjffdu opened a pull request:

https://github.com/apache/zeppelin/pull/2709

ZEPPEIN-3111. Refactor SparkInterpreter

### What is this PR for?
This is for the refactoring of SparkInterpreter. See design doc. 
https://docs.google.com/document/d/1AfGg3aGXonDyri1jrP4MMFT4Y4j3wpN1t8kL-GAKSUc/edit?usp=sharing


### What type of PR is it?
[Refactoring]

### Todos
* [ ] - Task

### What is the Jira issue?
* https://issues.apache.org/jira/browse/ZEPPELIN-3111

### How should this be tested?
* Unit test is added. 

### Screenshots (if appropriate)

### Questions:
* Does the licenses files need update? No
* Is there breaking changes for older versions? No
* Does this needs documentation? No


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zjffdu/zeppelin ZEPPELIN-3111

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/zeppelin/pull/2709.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2709


commit 72096ef5e959d0da0779634b461deed6c38f772c
Author: Jeff Zhang 
Date:   2017-07-17T05:02:09Z

ZEPPEIN-3111. Refactor SparkInterpreter




---


[jira] [Created] (ZEPPELIN-3111) Refactor SparkInterpreter

2017-12-19 Thread Jeff Zhang (JIRA)
Jeff Zhang created ZEPPELIN-3111:


 Summary: Refactor SparkInterpreter
 Key: ZEPPELIN-3111
 URL: https://issues.apache.org/jira/browse/ZEPPELIN-3111
 Project: Zeppelin
  Issue Type: Improvement
Reporter: Jeff Zhang






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[GitHub] zeppelin issue #2708: [Zeppelin-3095] Fix UI when all paragraphs executing s...

2017-12-19 Thread tinkoff-dwh
Github user tinkoff-dwh commented on the issue:

https://github.com/apache/zeppelin/pull/2708
  
@felixcheung 
I fixed it


---