[GitHub] zeppelin pull request #2708: [Zeppelin-3095] Fix UI when all paragraphs exec...
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-dwhDate: 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...
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...
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
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
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
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
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 LeeDate: 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...
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...
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 ...
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 ...
Github user weand commented on the issue: https://github.com/apache/zeppelin/pull/2706 how can I retrigger CI? ---
Re: [DISCUSS] Review process
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 Cheungwrote: > +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
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
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
+1 What would be the rough heuristic people will be comfortable with- what is small and what is big? _ From: Anthony CorbachoSent: 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
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 ZhangDate: 2017-07-17T05:02:09Z ZEPPEIN-3111. Refactor SparkInterpreter ---
[jira] [Created] (ZEPPELIN-3111) Refactor SparkInterpreter
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...
Github user tinkoff-dwh commented on the issue: https://github.com/apache/zeppelin/pull/2708 @felixcheung I fixed it ---