You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zeppelin.apache.org by moon soo Lee <mo...@apache.org> on 2015/12/30 04:00:48 UTC

[DISCUSS] Release 0.5.6-incubating

Hi folks,

How about we make release 0.5.6-incubating?

Since last release, more than 100 pull requests are merged and more than 80
issues are resolved.

It's including new interpreters, a lot of new features and improvement on
GUI with much improved stability thanks to lots of bug fixes.

Also it's great time to have a Zeppelin release that support Spark 1.6 (
ZEPPELIN-395), which about to be released.

Once we branch for 0.5.6-incubating release, it's more safe to make large
code base change such as "Added Shiro security" (
https://github.com/apache/incubator-zeppelin/pull/53) and many other
planned feature in 0.6.0 roadmap, that will require lots of internal API
updates.

What do you think?

Thanks,
moon

Re: [DISCUSS] Release 0.5.6-incubating

Posted by moon soo Lee <mo...@apache.org>.
Amos,

I'm proposing a 0.5.6-incubating release from current "master" branch.
At the moment, since last release, it's got 140 patches from 31 different
contributors. I think they're really really really meaningful whatever it
is planned or not.

Features,improvements,fixes planned to be included in the 0.5.6-incubating
release is very beneficial, i don't see any good reason to not including
them in the release.

And 0.5.6-incubating was planned formal/informal way, even before release
of 0.5.5-incubating. see
https://issues.apache.org/jira/browse/ZEPPELIN-417
http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Zeppelin-0-5-5-incubating-release-and-next-release-td2629.html


Problem of current CI is some tests are flickering. Nothing more.
If you find anything other than flickering test, please report it.
I don't think this is blocking issue for the release.

And as i described in the beginning, releasing from current master will
make community able to more quickly address PR that brings large code base
change. that will help making progress to the 0.6.0 release.

Thanks,
moon

On Tue, Dec 29, 2015 at 9:17 PM Amos B. Elberg <am...@gmail.com>
wrote:

> My suggestion is that we do a 0.5.6 that just has the bare minimal changes
> necessary for Spark 1.6 and Ignite and nothing else.
>
> That way we provide “must have” features while minimizing risk.
>
> Other than that, yes:  I think we should keep our current release plan and
> not make a release for “nice to have” changes until CI is fixed.
>
> The main purpose of making a new minor release should be whether already
> merged features are meaningful to make a minor release even if any major
> issues are on going, isn't it?
>
> I’m not sure that I understand what you are asking.
>
> We have a planned 0.6 release.  We just did an unplanned “minor” 0.5.5
> release.  It feels like only a few weeks ago.  I voted for it because it
> seemed that it would stabilize the codebase and provide a maintainable
> interim foundation.
>
> I do not think any of the features since 0.5.5 are “meaningful” enough to
> justify changing the release plan.  Not even close.  I think it is rare
> that any off-roadmap “nice to have” feature would ever be a good reason to
> change a release plan.  Especially when our CI “house” is not in order.
>
> We’re an Apache project — we need to be stable, maintainable, reliable,
> predictable.
>
> Is there any merged PR that is so important it can’t wait for 0.6?
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 29, 2015 at 11:54:35 PM
> To: Amos B. Elberg <am...@gmail.com>
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Okay, Amos,
>
> Do you propose Zeppelin should not have another release before fix CI
> issue? I think even though CI has some problems, another minors fixes is
> meaningful to make a new minor release. Do you agree with that? Or don't
> you agree that it's enough? The main purpose of making a new minor release
> should be whether already merged features are meaningful to make a minor
> release even if any major issues are on going, isn't it?
>
> Regards,
> Jongyoul
>
> On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> Hah!
>
> I promise you, an hour after a 0.5.6 comes out, I will have emails asking
> me when I will support 0.5.6, even if no-one actually needs any 0.5.6
> changes or even knows what they are!
>
> I want to be clear though:   My primary issue for 0.5.6 is not whether to
> merge the R interpreter.
>
> My issues are I think we need to fix CI in general, and I’m loathe to have
> more releases with that dammed spark-under-zeppelin code, which is the root
> of many other issues.
>
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 29, 2015 at 11:21:00 PM
> To: Amos B. Elberg <am...@gmail.com>,
> dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Okay, I understand your situation. If you rebased your PR from master, you
> can rebased your PR only once but I also know why you had to do that. I
> think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
> about you?
>
> On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> Jongyoul - the reason we have to rebase twice is that the changes in
> zeppelin-master will break the R interpreter.
>
> So I’ll have to rebase once so that I’m based off of 0.5.6 and people can
> use the code.  Then rebase again for 0.6.0.
>
> Remember, I have a user base I need to support — there are a lot of people
> using the R interpreter now.  So its not just a PR where I can ignore it
> until its ready to merge.
>
> The changes have already broken the shiro PR apparently quite often.
>
> I made a “release” of the R Interpreter just so I could stop rebasing
> against Zeppelin master.   I spent > 60 hours dealing with this for the
> changes leading up to 0.5 and 0.5.5.
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 29, 2015 at 11:08:36 PM
> To: Amos B. Elberg <am...@gmail.com>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> I don't know why you should rebased twice. If you can make a PR from
> current master, almost changes merged without rebasing and if a committer
> asks to rebase your PR, this is because you and another contributors
> changes the same codes and another contributions is merged before your PR.
> In specific R case, Moon want you to rebase because he tries to fix the
> testing codes so rebasing your PR will accepts their changes. In most case,
> contributors don't need to rebase their PR before merge because committer
> commit someone's PR by doing cherry-pick. We also felt sorry that you were
> bothered by testing issue and Moon is fighting to fix the testing infra.
> However all of PRs shouldn't be rebased.
>
> On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> I think there is no big pain because whole changes to be merged
> into 0.5.6 will be also merged into 0.6.0.
>
> If we make another release now, the PRs will have to be rebased *twice*,
> once for 0.5.6, and once again for 0.6.
>
> Also - since this is now the second e-mail from a committer to do the same
> thing — is there a reason you guys are leaving R out of the agenda for the
> next release?  I understood the PR had been accepted and was pending only
> Moon fixing the testing infrastructure.
>
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 29, 2015 at 10:56:33 PM
>
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Good idea!
>
> 0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I
> also think 0.6.0 should have major changes like supporting spark 1.6 and
> Shiro security and improving testing infra. And concerning rebasing and
> committing, I think there is no big pain because whole changes to be merged
> into 0.5.6 will be also merged into 0.6.0.
>
> JL
>
> On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
>
> > I don’t want to come off as the naysayer here, but I think the effort
> that
> > would go into a release would be better spent on the testing
> infrastructure
> > and outstanding PRs.
> >
> > If we feel we need a release for 1.6 and Ignite, I suggest we make a
> > release that *only* includes the absolute minimal changes required to do
> > that.
> >
> > There was one PR for 1.6 support that didn’t really work and is going to
> > break anything built against the current codebase. Except for a change in
> > the name of one method called by one class, all of the changes seem to
> > involve support for spark-under-zeppelin, which is something we want to
> > take out.
> >
> > We also don’t currently have a working testing framework. A lot of PRs
> > have been committed under the “ignore travis its broken” theory. I’m
> > loathe to make a release that hasn’t really been tested, and it doesn’t
> > seem we’re in a position to do that.
> >
> > While there have been a lot of merged PRs, I don’t think any of them are
> > on-roadmap. They mostly seem to be very minor, like fixing typos and
> > changing which text box gets highlighted. Those are important things, of
> > course, but not major enough to justify the effort involved in a release.
> >
> > Another release will not make it easier to integrate the larger PRs. It
> > will have the opposite effect. Developers will have to rebase against
> > whatever gets broken by 1.6 and other changes.
> >
> > I suggest we wait to do a significant release until we can take out the
> > legacy spark-under-zeppelin code that has caused so many issues, have a
> > working testing framework, and integrate the major outstanding PRs.
> >
> > So, again, if we want a release, I suggest we include the absolute
> minimum
> > changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> > maintenance release.
> >
> >
> > From: Konstantin Boudnik <co...@apache.org>
> > Reply: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>
> > Date: December 29, 2015 at 10:05:36 PM
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
> > make
> > sense to add this to the latest release of Zeppelin. I will open a JIRA
> and
> > supply a patch for it, if there's no objections.
> >
> > Cos
> >
> > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > Hi folks,
> > >
> > > How about we make release 0.5.6-incubating?
> > >
> > > Since last release, more than 100 pull requests are merged and more
> than
> > 80
> > > issues are resolved.
> > >
> > > It's including new interpreters, a lot of new features and improvement
> on
> > > GUI with much improved stability thanks to lots of bug fixes.
> > >
> > > Also it's great time to have a Zeppelin release that support Spark 1.6
> (
> > > ZEPPELIN-395), which about to be released.
> > >
> > > Once we branch for 0.5.6-incubating release, it's more safe to make
> large
> > > code base change such as "Added Shiro security" (
> > > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > > planned feature in 0.6.0 roadmap, that will require lots of internal
> API
> > > updates.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > moon
> >
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Jongyoul Lee <jo...@gmail.com>.
Amos,

First of all, 0.5.6 is based from Zeppelin master, most of PR doesn't need
to be rebased, and more importantly, that release doesn't effect Zeppelin
"codebase". why do you believe a minor release makes Zeppelin master
unstable? And there are samples to improve stability from the latest
commits:

(45ce8a2) Auto-restart interpreters on cron execution.
(f8aeee1) [ZEPPELIN-535] "scheduler already terminated" occurs when
RemoteInterpreter.close() doesn't succeed
(927f482) ZEPPELIN-527 Fix NPE while retrieving job status from notebook
(4c269e6) ZEPPELIN-312: fix a bug with blocking websocket broadcast

If you want more, I can waste my precious time to pick these.

And if you don't believe the result of CI, why do you cling to CI? And CI
is getting better.

Regards,
Jongyoul

On Wed, Dec 30, 2015 at 3:17 PM, Amos B. Elberg <am...@gmail.com>
wrote:

> Do you want me to explain the commits after 0.5.5 in details?
>
> I want you to provide an example of any feature that justifies the effort
> that will be put into making a release, delaying 0.6 and CI and everything
> else, and rebasing the outstanding major PRs.
> I will settle for *one* example.  Just one!
>
> And what is your answer that why minor release has a important feature and
> what the difference between major and minor is?
>
> My view is that a “minor” release is one that doesn’t require changes in
> code built against the release other than recompiling.  “Major” means
> people have to work to update their code because of the release.
>
> I don't know why you oppose a new minor release including minor bug fixes.
>
> I’m not even sure these count as “bug fixes” :p  A change to the shading
> of a window so it matches other windows is nice, but its hardly a “bug
> fix.”
>
> Anyway I don’t think this release will really be limited to UI and “minor”
> changes.  I think there will be changes to the core code — like the 1.6 PR
> — that will actually be problems disguised as minor changes.  And i don’t
> think we can test for that without CI.
>
> And What kind of aspects are less maintainable between 0.5.5 and 0.5.6?
>
> The fact of the change is what makes it less maintainable!
>
> And what kind of fixes makes Zeppelin less stable?
>
> The *codebase* is definitely less stable.
>
> Do you believe that some PR is unstable because of failing CI?
>
>
> Since CI is failing, how do I know if any PRs are stable or not?
>
>
> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
> Date: December 30, 2015 at 1:05:55 AM
>
> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Do you want me to explain the commits after 0.5.5 in details? And what is
> your answer that why minor release has a important feature and what the
> difference between major and minor is? I also think it's good to fix
> version up for ignite but this is not a major feature.  I don't know why
> you oppose a new minor release including minor bug fixes. And What kind of
> aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6 is less
> maintainable, we should revert that commit because it's harmful to
> Zeppelin. And what kind of fixes makes Zeppelin less stable? I would like
> to show me that commit number or issue number. And finally, Moon admitted
> CI had some flakey tests and have tried to remove or fix that tests. Do you
> believe that some PR is unstable because of failing CI?
>
> On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
>
>> A codebase that often changes in ways that break other code is an
>> unstable codebase, by definition.
>>
>> I don’t think it will be more stable at runtime, especially since CI
>> isn’t working.
>>
>> It definitely won’t be more maintainable.  The key problematic code is
>> still in.
>>
>> Other than Spark 1.6 and Ignite, I don’t see any reason at all for a
>> 0.5.6 release.  (Konstantin was right — it is good for Apache releases to
>> maintain version compatibility with new versions of other Apache software.
>> That is Apache projects helping each other.)
>>
>> What feature do you feel justifies a 0.5.6 release?  What feature other
>> than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
>>
>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>> Date: December 30, 2015 at 12:32:01 AM
>>
>> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>
>> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>> <de...@zeppelin.incubator.apache.org>
>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>
>> Amos,
>>
>> I don't think we have a strict plan for making a minor release and we
>> have a roadmap for major release. And ignite and Spark 1.6 is not a key
>> feature of 0.5.6. Konstantin just wanted to be merged that contribution if
>> that voting is finished until we make a release. And Spark 1.6 is on going.
>> As you told, we are an Apache project. 0.5.6 will be stable and
>> maintainable. If 0.5.6 has an experimental features, I don't agree to make
>> a release. 0.5.6 will be more stable version of 0.5.5. And of course, the
>> most people like more stable version. Isn't it enough?
>>
>> Regards,
>> Jongyoul
>>
>> On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>
>> wrote:
>>
>>> My suggestion is that we do a 0.5.6 that just has the bare minimal
>>> changes necessary for Spark 1.6 and Ignite and nothing else.
>>>
>>> That way we provide “must have” features while minimizing risk.
>>>
>>> Other than that, yes:  I think we should keep our current release plan
>>> and not make a release for “nice to have” changes until CI is fixed.
>>>
>>> The main purpose of making a new minor release should be whether already
>>> merged features are meaningful to make a minor release even if any major
>>> issues are on going, isn't it?
>>>
>>>
>>> I’m not sure that I understand what you are asking.
>>>
>>> We have a planned 0.6 release.  We just did an unplanned “minor” 0.5.5
>>> release.  It feels like only a few weeks ago.  I voted for it because it
>>> seemed that it would stabilize the codebase and provide a maintainable
>>> interim foundation.
>>>
>>> I do not think any of the features since 0.5.5 are “meaningful” enough
>>> to justify changing the release plan.  Not even close.  I think it is rare
>>> that any off-roadmap “nice to have” feature would ever be a good reason to
>>> change a release plan.  Especially when our CI “house” is not in order.
>>>
>>> We’re an Apache project — we need to be stable, maintainable, reliable,
>>> predictable.
>>>
>>> Is there any merged PR that is so important it can’t wait for 0.6?
>>>
>>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>> Date: December 29, 2015 at 11:54:35 PM
>>> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>
>>> CC: dev@zeppelin.incubator.apache.org
>>> <de...@zeppelin.incubator.apache.org> <de...@zeppelin.incubator.apache.org>
>>>
>>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>>
>>> Okay, Amos,
>>>
>>> Do you propose Zeppelin should not have another release before fix CI
>>> issue? I think even though CI has some problems, another minors fixes is
>>> meaningful to make a new minor release. Do you agree with that? Or don't
>>> you agree that it's enough? The main purpose of making a new minor release
>>> should be whether already merged features are meaningful to make a minor
>>> release even if any major issues are on going, isn't it?
>>>
>>> Regards,
>>> Jongyoul
>>>
>>> On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>
>>> wrote:
>>>
>>>> Hah!
>>>>
>>>> I promise you, an hour after a 0.5.6 comes out, I will have emails
>>>> asking me when I will support 0.5.6, even if no-one actually needs any
>>>> 0.5.6 changes or even knows what they are!
>>>>
>>>> I want to be clear though:   My primary issue for 0.5.6 is not whether
>>>> to merge the R interpreter.
>>>>
>>>> My issues are I think we need to fix CI in general, and I’m loathe to
>>>> have more releases with that dammed spark-under-zeppelin code, which is the
>>>> root of many other issues.
>>>>
>>>>
>>>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>>> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>>> Date: December 29, 2015 at 11:21:00 PM
>>>> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>,
>>>> dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>>>> <de...@zeppelin.incubator.apache.org>
>>>>
>>>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>>>
>>>> Okay, I understand your situation. If you rebased your PR from master,
>>>> you can rebased your PR only once but I also know why you had to do that. I
>>>> think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
>>>> about you?
>>>>
>>>> On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
>>>> wrote:
>>>>
>>>>> Jongyoul - the reason we have to rebase twice is that the changes in
>>>>> zeppelin-master will break the R interpreter.
>>>>>
>>>>> So I’ll have to rebase once so that I’m based off of 0.5.6 and people
>>>>> can use the code.  Then rebase again for 0.6.0.
>>>>>
>>>>> Remember, I have a user base I need to support — there are a lot of
>>>>> people using the R interpreter now.  So its not just a PR where I can
>>>>> ignore it until its ready to merge.
>>>>>
>>>>> The changes have already broken the shiro PR apparently quite often.
>>>>>
>>>>> I made a “release” of the R Interpreter just so I could stop rebasing
>>>>> against Zeppelin master.   I spent > 60 hours dealing with this for the
>>>>> changes leading up to 0.5 and 0.5.5.
>>>>>
>>>>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>>>> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>>>> Date: December 29, 2015 at 11:08:36 PM
>>>>> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>
>>>>>
>>>>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>>>>
>>>>> I don't know why you should rebased twice. If you can make a PR from
>>>>> current master, almost changes merged without rebasing and if a committer
>>>>> asks to rebase your PR, this is because you and another contributors
>>>>> changes the same codes and another contributions is merged before your PR.
>>>>> In specific R case, Moon want you to rebase because he tries to fix the
>>>>> testing codes so rebasing your PR will accepts their changes. In most case,
>>>>> contributors don't need to rebase their PR before merge because committer
>>>>> commit someone's PR by doing cherry-pick. We also felt sorry that you were
>>>>> bothered by testing issue and Moon is fighting to fix the testing infra.
>>>>> However all of PRs shouldn't be rebased.
>>>>>
>>>>> On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <
>>>>> amos.elberg@gmail.com> wrote:
>>>>>
>>>>>> I think there is no big pain because whole changes to be merged
>>>>>> into 0.5.6 will be also merged into 0.6.0.
>>>>>>
>>>>>>
>>>>>> If we make another release now, the PRs will have to be rebased
>>>>>> *twice*, once for 0.5.6, and once again for 0.6.
>>>>>>
>>>>>> Also - since this is now the second e-mail from a committer to do the
>>>>>> same thing — is there a reason you guys are leaving R out of the agenda for
>>>>>> the next release?  I understood the PR had been accepted and was pending
>>>>>> only Moon fixing the testing infrastructure.
>>>>>>
>>>>>>
>>>>>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>>>>> Reply: dev@zeppelin.incubator.apache.org
>>>>>> <de...@zeppelin.incubator.apache.org>
>>>>>> <de...@zeppelin.incubator.apache.org>
>>>>>> Date: December 29, 2015 at 10:56:33 PM
>>>>>>
>>>>>> To: dev@zeppelin.incubator.apache.org
>>>>>> <de...@zeppelin.incubator.apache.org>
>>>>>> <de...@zeppelin.incubator.apache.org>
>>>>>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>>>>>
>>>>>> Good idea!
>>>>>>
>>>>>> 0.5.6 is a minor release thus fixing minor bugs and typos is enough.
>>>>>> But I
>>>>>> also think 0.6.0 should have major changes like supporting spark 1.6
>>>>>> and
>>>>>> Shiro security and improving testing infra. And concerning rebasing
>>>>>> and
>>>>>> committing, I think there is no big pain because whole changes to be
>>>>>> merged
>>>>>> into 0.5.6 will be also merged into 0.6.0.
>>>>>>
>>>>>> JL
>>>>>>
>>>>>> On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <
>>>>>> amos.elberg@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> > I don’t want to come off as the naysayer here, but I think the
>>>>>> effort that
>>>>>> > would go into a release would be better spent on the testing
>>>>>> infrastructure
>>>>>> > and outstanding PRs.
>>>>>> >
>>>>>> > If we feel we need a release for 1.6 and Ignite, I suggest we make a
>>>>>> > release that *only* includes the absolute minimal changes required
>>>>>> to do
>>>>>> > that.
>>>>>> >
>>>>>> > There was one PR for 1.6 support that didn’t really work and is
>>>>>> going to
>>>>>> > break anything built against the current codebase. Except for a
>>>>>> change in
>>>>>> > the name of one method called by one class, all of the changes seem
>>>>>> to
>>>>>> > involve support for spark-under-zeppelin, which is something we
>>>>>> want to
>>>>>> > take out.
>>>>>> >
>>>>>> > We also don’t currently have a working testing framework. A lot of
>>>>>> PRs
>>>>>> > have been committed under the “ignore travis its broken” theory. I’m
>>>>>> > loathe to make a release that hasn’t really been tested, and it
>>>>>> doesn’t
>>>>>> > seem we’re in a position to do that.
>>>>>> >
>>>>>> > While there have been a lot of merged PRs, I don’t think any of
>>>>>> them are
>>>>>> > on-roadmap. They mostly seem to be very minor, like fixing typos and
>>>>>> > changing which text box gets highlighted. Those are important
>>>>>> things, of
>>>>>> > course, but not major enough to justify the effort involved in a
>>>>>> release.
>>>>>> >
>>>>>> > Another release will not make it easier to integrate the larger
>>>>>> PRs. It
>>>>>> > will have the opposite effect. Developers will have to rebase
>>>>>> against
>>>>>> > whatever gets broken by 1.6 and other changes.
>>>>>> >
>>>>>> > I suggest we wait to do a significant release until we can take out
>>>>>> the
>>>>>> > legacy spark-under-zeppelin code that has caused so many issues,
>>>>>> have a
>>>>>> > working testing framework, and integrate the major outstanding PRs.
>>>>>> >
>>>>>> > So, again, if we want a release, I suggest we include the absolute
>>>>>> minimum
>>>>>> > changes necessary for 1.6 and Ignite, and perhaps call it an
>>>>>> interim or
>>>>>> > maintenance release.
>>>>>> >
>>>>>> >
>>>>>> > From: Konstantin Boudnik <co...@apache.org>
>>>>>> > Reply: dev@zeppelin.incubator.apache.org <
>>>>>> > dev@zeppelin.incubator.apache.org>,
>>>>>> dev@zeppelin.incubator.apache.org <
>>>>>> > dev@zeppelin.incubator.apache.org>
>>>>>> > Date: December 29, 2015 at 10:05:36 PM
>>>>>> > To: dev@zeppelin.incubator.apache.org <
>>>>>> dev@zeppelin.incubator.apache.org>
>>>>>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
>>>>>> >
>>>>>> > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -
>>>>>> would
>>>>>> > make
>>>>>> > sense to add this to the latest release of Zeppelin. I will open a
>>>>>> JIRA and
>>>>>> > supply a patch for it, if there's no objections.
>>>>>> >
>>>>>> > Cos
>>>>>> >
>>>>>> > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
>>>>>> > > Hi folks,
>>>>>> > >
>>>>>> > > How about we make release 0.5.6-incubating?
>>>>>> > >
>>>>>> > > Since last release, more than 100 pull requests are merged and
>>>>>> more than
>>>>>> > 80
>>>>>> > > issues are resolved.
>>>>>> > >
>>>>>> > > It's including new interpreters, a lot of new features and
>>>>>> improvement on
>>>>>> > > GUI with much improved stability thanks to lots of bug fixes.
>>>>>> > >
>>>>>> > > Also it's great time to have a Zeppelin release that support
>>>>>> Spark 1.6 (
>>>>>> > > ZEPPELIN-395), which about to be released.
>>>>>> > >
>>>>>> > > Once we branch for 0.5.6-incubating release, it's more safe to
>>>>>> make large
>>>>>> > > code base change such as "Added Shiro security" (
>>>>>> > > https://github.com/apache/incubator-zeppelin/pull/53) and many
>>>>>> other
>>>>>> > > planned feature in 0.6.0 roadmap, that will require lots of
>>>>>> internal API
>>>>>> > > updates.
>>>>>> > >
>>>>>> > > What do you think?
>>>>>> > >
>>>>>> > > Thanks,
>>>>>> > > moon
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 이종열, Jongyoul Lee, 李宗烈
>>>>>> http://madeng.net
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 이종열, Jongyoul Lee, 李宗烈
>>>>> http://madeng.net
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 이종열, Jongyoul Lee, 李宗烈
>>>> http://madeng.net
>>>>
>>>>
>>>
>>>
>>> --
>>> 이종열, Jongyoul Lee, 李宗烈
>>> http://madeng.net
>>>
>>>
>>
>>
>> --
>> 이종열, Jongyoul Lee, 李宗烈
>> http://madeng.net
>>
>>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>


-- 
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Jongyoul Lee <jo...@gmail.com>.
Rotating release manager looks like a good idea. :-)

On Tue, Jan 5, 2016 at 3:19 PM, moon soo Lee <mo...@apache.org> wrote:

> Really appreciated taking release manager for 0.5.6-incubating release :-)
>
> On Mon, Jan 4, 2016 at 10:12 PM Alexander Bezzubov <bz...@apache.org> wrote:
>
> > Hi Moon,
> >
> > as mentioned before, I think rotating release management responsibilities
> > is a great idea!
> > Will be happy to volunteer and cut 0.5.6-incubating release.
> >
> > On Tue, Jan 5, 2016 at 3:02 PM, moon soo Lee <mo...@apache.org> wrote:
> >
> > > I've been release manager for 0.5.0-incubating and 0.5.5-incubating.
> > > Any committer volunteer the release manager for 0.5.6-incubating
> release?
> > >
> > > Thanks,
> > > moon
> > >
> > > On Mon, Jan 4, 2016 at 9:52 PM Alexander Bezzubov <bz...@apache.org>
> > wrote:
> > >
> > > > +1 for 0.5.6 release from maser
> > > >
> > > > On Wed, Dec 30, 2015 at 9:51 PM, Khalid Huseynov <
> khalidhnv@nflabs.com
> > >
> > > > wrote:
> > > >
> > > > > +1 for 0.5.6 release with current improvements/fixes.
> > > > >
> > > > >
> > > > > On Wed, Dec 30, 2015 at 4:10 PM, moon soo Lee <mo...@apache.org>
> > wrote:
> > > > >
> > > > > > Amos,
> > > > > >
> > > > > > Who started the word "meaningful" is not important.
> > > > > > Release discussion will not be judgement of how
> > meaningful/major/big
> > > > the
> > > > > > contributions are.
> > > > > >
> > > > > > CI problem i have describe about R interpreter PR [1] is not
> > related
> > > > with
> > > > > > any other contribution that we're trying to release.
> > > > > >
> > > > > > CI test does not have any known false negative, and we force
> > > > contributor
> > > > > > rerun the test until false positive disappear. So logically, we
> can
> > > > > > guarantee that every contribution has passed the CI test
> correctly.
> > > > > >
> > > > > > Also Testis being done not only by CI but also all Zeppelin
> users.
> > > > > > If users see serious problem in the release candidate, they'll
> > block
> > > > the
> > > > > > release vote during release candidate verification.
> > > > > >
> > > > > > Hope this make you feel more confident about the code we're
> trying
> > to
> > > > > > release.
> > > > > >
> > > > > > Thanks,
> > > > > > moon
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/GitHub-incubator-zeppelin-pull-request-R-Interpreter-for-Zeppelin-tp956p4623.html
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 29, 2015 at 10:53 PM Amos B. Elberg <
> > > amos.elberg@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > You did reply to both.  Let me try to clarify the problem with
> > CI:
> > > > > > >
> > > > > > > The problem is *not* that particular PRs cause instability at
> > > > runtime.
> > > > > > >
> > > > > > > The problem with CI is that if CI is not working properly, then
> > *we
> > > > > can’t
> > > > > > > know* whether PRs will cause instability.  Or what that
> connects
> > to
> > > > > > > Zeppelin will break.
> > > > > > >
> > > > > > > CI is our own standard of testability.
> > > > > > >
> > > > > > > It is very common in organizations that they establish a
> standard
> > > of
> > > > > > > reliability.  But, when things become difficult, or there is a
> > > > problem
> > > > > > with
> > > > > > > the standard, the organization comes under pressure to bend or
> > flex
> > > > the
> > > > > > > standard.
> > > > > > >
> > > > > > > In my experience, when organizations violate their own
> standards
> > > for
> > > > > the
> > > > > > > sake of expedience, it is a recipe for trouble 100% of the
> time.
> > > > > > >
> > > > > > > —
> > > > > > >
> > > > > > > I just reviewed the changes Jongyoul posted.  One of them
> relates
> > > to
> > > > a
> > > > > > bug
> > > > > > > that was reported in September that has become an issue at
> > Twitter.
> > > > > That
> > > > > > > seems to me to be a justification for a “hot fix” to the bug.
> > > > > > >
> > > > > > > I still don’t see any justification for a release though.
> > > > > > >
> > > > > > >
> > > > > > > From: moon soo Lee <mo...@apache.org>
> > > > > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > > > > dev@zeppelin.incubator.apache.org>
> > > > > > > Date: December 30, 2015 at 1:36:58 AM
> > > > > > > To: dev@zeppelin.incubator.apache.org <
> > > > > dev@zeppelin.incubator.apache.org
> > > > > > >
> > > > > > > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > >
> > > > > > > Amos,
> > > > > > >
> > > > > > > If i summarize why you against 0.5.6-incubating release,
> > > > > > >
> > > > > > > * CI is not working
> > > > > > > * Does not have meaningful or major features to be released
> > > > > > >
> > > > > > > these two, right? I replied answer for both of them
> > > > > > >
> > > > > > > Here
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4763.html
> > > > > > > and here
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4765.html
> > > > > > >
> > > > > > > I'm listening and respect your opinion. Please check my reply
> and
> > > > tell
> > > > > me
> > > > > > > if you have different opinion, but please include REASON WHY
> you
> > > > think
> > > > > in
> > > > > > > that way otherwise it's hard to understand what you're
> thinking.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > moon
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Dec 29, 2015 at 10:18 PM Amos B. Elberg <
> > > > amos.elberg@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Do you want me to explain the commits after 0.5.5 in details?
> > > > > > > > I want you to provide an example of any feature that
> justifies
> > > the
> > > > > > effort
> > > > > > > > that will be put into making a release, delaying 0.6 and CI
> and
> > > > > > > everything
> > > > > > > > else, and rebasing the outstanding major PRs.
> > > > > > > >
> > > > > > > > I will settle for *one* example. Just one!
> > > > > > > >
> > > > > > > > And what is your answer that why minor release has a
> important
> > > > > feature
> > > > > > > and
> > > > > > > > what the difference between major and minor is?
> > > > > > > > My view is that a “minor” release is one that doesn’t require
> > > > changes
> > > > > > in
> > > > > > > > code built against the release other than recompiling.
> “Major”
> > > > means
> > > > > > > > people have to work to update their code because of the
> > release.
> > > > > > > >
> > > > > > > > I don't know why you oppose a new minor release including
> minor
> > > bug
> > > > > > > fixes.
> > > > > > > > I’m not even sure these count as “bug fixes” :p A change to
> the
> > > > > shading
> > > > > > > > of a window so it matches other windows is nice, but its
> > hardly a
> > > > > “bug
> > > > > > > > fix.”
> > > > > > > >
> > > > > > > > Anyway I don’t think this release will really be limited to
> UI
> > > and
> > > > > > > “minor”
> > > > > > > > changes. I think there will be changes to the core code —
> like
> > > the
> > > > > 1.6
> > > > > > PR
> > > > > > > > — that will actually be problems disguised as minor changes.
> > And
> > > i
> > > > > > don’t
> > > > > > > > think we can test for that without CI.
> > > > > > > >
> > > > > > > > And What kind of aspects are less maintainable between 0.5.5
> > and
> > > > > 0.5.6?
> > > > > > > > The fact of the change is what makes it less maintainable!
> > > > > > > >
> > > > > > > > And what kind of fixes makes Zeppelin less stable?
> > > > > > > > The *codebase* is definitely less stable.
> > > > > > > >
> > > > > > > > Do you believe that some PR is unstable because of failing
> CI?
> > > > > > > >
> > > > > > > > Since CI is failing, how do I know if any PRs are stable or
> > not?
> > > > > > > >
> > > > > > > >
> > > > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > > > Date: December 30, 2015 at 1:05:55 AM
> > > > > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > > > > CC: dev@zeppelin.incubator.apache.org <
> > > > > > dev@zeppelin.incubator.apache.org
> > > > > > > >
> > > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > > >
> > > > > > > > Do you want me to explain the commits after 0.5.5 in details?
> > And
> > > > > what
> > > > > > is
> > > > > > > > your answer that why minor release has a important feature
> and
> > > what
> > > > > the
> > > > > > > > difference between major and minor is? I also think it's good
> > to
> > > > fix
> > > > > > > > version up for ignite but this is not a major feature. I
> don't
> > > know
> > > > > why
> > > > > > > > you oppose a new minor release including minor bug fixes. And
> > > What
> > > > > kind
> > > > > > > of
> > > > > > > > aspects are less maintainable between 0.5.5 and 0.5.6? If
> 0.5.6
> > > is
> > > > > less
> > > > > > > > maintainable, we should revert that commit because it's
> harmful
> > > to
> > > > > > > > Zeppelin. And what kind of fixes makes Zeppelin less stable?
> I
> > > > would
> > > > > > like
> > > > > > > > to show me that commit number or issue number. And finally,
> > Moon
> > > > > > admitted
> > > > > > > > CI had some flakey tests and have tried to remove or fix that
> > > > tests.
> > > > > Do
> > > > > > > you
> > > > > > > > believe that some PR is unstable because of failing CI?
> > > > > > > >
> > > > > > > > On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <
> > > > > amos.elberg@gmail.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > > A codebase that often changes in ways that break other code
> is
> > an
> > > > > > > unstable
> > > > > > > > codebase, by definition.
> > > > > > > >
> > > > > > > > I don’t think it will be more stable at runtime, especially
> > since
> > > > CI
> > > > > > > isn’t
> > > > > > > > working.
> > > > > > > >
> > > > > > > > It definitely won’t be more maintainable. The key problematic
> > > code
> > > > is
> > > > > > > > still in.
> > > > > > > >
> > > > > > > > Other than Spark 1.6 and Ignite, I don’t see any reason at
> all
> > > for
> > > > a
> > > > > > > 0.5.6
> > > > > > > > release. (Konstantin was right — it is good for Apache
> releases
> > > to
> > > > > > > > maintain version compatibility with new versions of other
> > Apache
> > > > > > > software.
> > > > > > > > That is Apache projects helping each other.)
> > > > > > > >
> > > > > > > > What feature do you feel justifies a 0.5.6 release? What
> > feature
> > > > > other
> > > > > > > > than 1.6 and Ignite does anyone feel justifies a 0.5.6
> release?
> > > > > > > >
> > > > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > > > Date: December 30, 2015 at 12:32:01 AM
> > > > > > > >
> > > > > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > > > > CC: dev@zeppelin.incubator.apache.org <
> > > > > > dev@zeppelin.incubator.apache.org
> > > > > > > >
> > > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > > >
> > > > > > > > Amos,
> > > > > > > >
> > > > > > > > I don't think we have a strict plan for making a minor
> release
> > > and
> > > > we
> > > > > > > have
> > > > > > > > a roadmap for major release. And ignite and Spark 1.6 is not
> a
> > > key
> > > > > > > feature
> > > > > > > > of 0.5.6. Konstantin just wanted to be merged that
> contribution
> > > if
> > > > > that
> > > > > > > > voting is finished until we make a release. And Spark 1.6 is
> on
> > > > > going.
> > > > > > As
> > > > > > > > you told, we are an Apache project. 0.5.6 will be stable and
> > > > > > > maintainable.
> > > > > > > > If 0.5.6 has an experimental features, I don't agree to make
> a
> > > > > release.
> > > > > > > > 0.5.6 will be more stable version of 0.5.5. And of course,
> the
> > > most
> > > > > > > people
> > > > > > > > like more stable version. Isn't it enough?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Jongyoul
> > > > > > > >
> > > > > > > > On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <
> > > > > amos.elberg@gmail.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > > My suggestion is that we do a 0.5.6 that just has the bare
> > > minimal
> > > > > > > changes
> > > > > > > > necessary for Spark 1.6 and Ignite and nothing else.
> > > > > > > >
> > > > > > > > That way we provide “must have” features while minimizing
> risk.
> > > > > > > >
> > > > > > > > Other than that, yes: I think we should keep our current
> > release
> > > > plan
> > > > > > and
> > > > > > > > not make a release for “nice to have” changes until CI is
> > fixed.
> > > > > > > >
> > > > > > > > The main purpose of making a new minor release should be
> > whether
> > > > > > already
> > > > > > > > merged features are meaningful to make a minor release even
> if
> > > any
> > > > > > major
> > > > > > > > issues are on going, isn't it?
> > > > > > > >
> > > > > > > > I’m not sure that I understand what you are asking.
> > > > > > > >
> > > > > > > > We have a planned 0.6 release. We just did an unplanned
> “minor”
> > > > 0.5.5
> > > > > > > > release. It feels like only a few weeks ago. I voted for it
> > > because
> > > > > it
> > > > > > > > seemed that it would stabilize the codebase and provide a
> > > > > maintainable
> > > > > > > > interim foundation.
> > > > > > > >
> > > > > > > > I do not think any of the features since 0.5.5 are
> “meaningful”
> > > > > enough
> > > > > > to
> > > > > > > > justify changing the release plan. Not even close. I think it
> > is
> > > > rare
> > > > > > > > that any off-roadmap “nice to have” feature would ever be a
> > good
> > > > > reason
> > > > > > > to
> > > > > > > > change a release plan. Especially when our CI “house” is not
> in
> > > > > order.
> > > > > > > >
> > > > > > > > We’re an Apache project — we need to be stable, maintainable,
> > > > > reliable,
> > > > > > > > predictable.
> > > > > > > >
> > > > > > > > Is there any merged PR that is so important it can’t wait for
> > > 0.6?
> > > > > > > >
> > > > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > > > Date: December 29, 2015 at 11:54:35 PM
> > > > > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > > > > CC: dev@zeppelin.incubator.apache.org <
> > > > > > dev@zeppelin.incubator.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > > >
> > > > > > > > Okay, Amos,
> > > > > > > >
> > > > > > > > Do you propose Zeppelin should not have another release
> before
> > > fix
> > > > CI
> > > > > > > > issue? I think even though CI has some problems, another
> minors
> > > > fixes
> > > > > > is
> > > > > > > > meaningful to make a new minor release. Do you agree with
> that?
> > > Or
> > > > > > don't
> > > > > > > > you agree that it's enough? The main purpose of making a new
> > > minor
> > > > > > > release
> > > > > > > > should be whether already merged features are meaningful to
> > make
> > > a
> > > > > > minor
> > > > > > > > release even if any major issues are on going, isn't it?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Jongyoul
> > > > > > > >
> > > > > > > > On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <
> > > > > amos.elberg@gmail.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > > Hah!
> > > > > > > >
> > > > > > > > I promise you, an hour after a 0.5.6 comes out, I will have
> > > emails
> > > > > > asking
> > > > > > > > me when I will support 0.5.6, even if no-one actually needs
> any
> > > > 0.5.6
> > > > > > > > changes or even knows what they are!
> > > > > > > >
> > > > > > > > I want to be clear though: My primary issue for 0.5.6 is not
> > > > whether
> > > > > to
> > > > > > > > merge the R interpreter.
> > > > > > > >
> > > > > > > > My issues are I think we need to fix CI in general, and I’m
> > > loathe
> > > > to
> > > > > > > have
> > > > > > > > more releases with that dammed spark-under-zeppelin code,
> which
> > > is
> > > > > the
> > > > > > > root
> > > > > > > > of many other issues.
> > > > > > > >
> > > > > > > >
> > > > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > > > Date: December 29, 2015 at 11:21:00 PM
> > > > > > > > To: Amos B. Elberg <am...@gmail.com>,
> > > > > > > > dev@zeppelin.incubator.apache.org <
> > > > dev@zeppelin.incubator.apache.org
> > > > > >
> > > > > > > >
> > > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > > >
> > > > > > > > Okay, I understand your situation. If you rebased your PR
> from
> > > > > master,
> > > > > > > you
> > > > > > > > can rebased your PR only once but I also know why you had to
> do
> > > > > that. I
> > > > > > > > think R is a roadmap for 0.6.0 and you'd better skip rebasing
> > > > 0.5.6.
> > > > > > How
> > > > > > > > about you?
> > > > > > > >
> > > > > > > > On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <
> > > > > amos.elberg@gmail.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > > Jongyoul - the reason we have to rebase twice is that the
> > changes
> > > > in
> > > > > > > > zeppelin-master will break the R interpreter.
> > > > > > > >
> > > > > > > > So I’ll have to rebase once so that I’m based off of 0.5.6
> and
> > > > people
> > > > > > can
> > > > > > > > use the code. Then rebase again for 0.6.0.
> > > > > > > >
> > > > > > > > Remember, I have a user base I need to support — there are a
> > lot
> > > of
> > > > > > > people
> > > > > > > > using the R interpreter now. So its not just a PR where I can
> > > > ignore
> > > > > it
> > > > > > > > until its ready to merge.
> > > > > > > >
> > > > > > > > The changes have already broken the shiro PR apparently quite
> > > > often.
> > > > > > > >
> > > > > > > > I made a “release” of the R Interpreter just so I could stop
> > > > rebasing
> > > > > > > > against Zeppelin master. I spent > 60 hours dealing with this
> > for
> > > > the
> > > > > > > > changes leading up to 0.5 and 0.5.5.
> > > > > > > >
> > > > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > > > Date: December 29, 2015 at 11:08:36 PM
> > > > > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > > > >
> > > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > > >
> > > > > > > > I don't know why you should rebased twice. If you can make a
> PR
> > > > from
> > > > > > > > current master, almost changes merged without rebasing and
> if a
> > > > > > committer
> > > > > > > > asks to rebase your PR, this is because you and another
> > > > contributors
> > > > > > > > changes the same codes and another contributions is merged
> > before
> > > > > your
> > > > > > > PR.
> > > > > > > > In specific R case, Moon want you to rebase because he tries
> to
> > > fix
> > > > > the
> > > > > > > > testing codes so rebasing your PR will accepts their changes.
> > In
> > > > most
> > > > > > > case,
> > > > > > > > contributors don't need to rebase their PR before merge
> because
> > > > > > committer
> > > > > > > > commit someone's PR by doing cherry-pick. We also felt sorry
> > that
> > > > you
> > > > > > > were
> > > > > > > > bothered by testing issue and Moon is fighting to fix the
> > testing
> > > > > > infra.
> > > > > > > > However all of PRs shouldn't be rebased.
> > > > > > > >
> > > > > > > > On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <
> > > > > > amos.elberg@gmail.com>
> > > > > > > > wrote:
> > > > > > > > I think there is no big pain because whole changes to be
> merged
> > > > > > > > into 0.5.6 will be also merged into 0.6.0.
> > > > > > > >
> > > > > > > > If we make another release now, the PRs will have to be
> rebased
> > > > > > *twice*,
> > > > > > > > once for 0.5.6, and once again for 0.6.
> > > > > > > >
> > > > > > > > Also - since this is now the second e-mail from a committer
> to
> > do
> > > > the
> > > > > > > same
> > > > > > > > thing — is there a reason you guys are leaving R out of the
> > > agenda
> > > > > for
> > > > > > > the
> > > > > > > > next release? I understood the PR had been accepted and was
> > > pending
> > > > > > only
> > > > > > > > Moon fixing the testing infrastructure.
> > > > > > > >
> > > > > > > >
> > > > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > > > > > dev@zeppelin.incubator.apache.org>
> > > > > > > > Date: December 29, 2015 at 10:56:33 PM
> > > > > > > >
> > > > > > > > To: dev@zeppelin.incubator.apache.org <
> > > > > > dev@zeppelin.incubator.apache.org
> > > > > > > >
> > > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > > >
> > > > > > > > Good idea!
> > > > > > > >
> > > > > > > > 0.5.6 is a minor release thus fixing minor bugs and typos is
> > > > enough.
> > > > > > But
> > > > > > > I
> > > > > > > > also think 0.6.0 should have major changes like supporting
> > spark
> > > > 1.6
> > > > > > and
> > > > > > > > Shiro security and improving testing infra. And concerning
> > > rebasing
> > > > > and
> > > > > > > > committing, I think there is no big pain because whole
> changes
> > to
> > > > be
> > > > > > > merged
> > > > > > > > into 0.5.6 will be also merged into 0.6.0.
> > > > > > > >
> > > > > > > > JL
> > > > > > > >
> > > > > > > > On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <
> > > > > > amos.elberg@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I don’t want to come off as the naysayer here, but I think
> > the
> > > > > effort
> > > > > > > > that
> > > > > > > > > would go into a release would be better spent on the
> testing
> > > > > > > > infrastructure
> > > > > > > > > and outstanding PRs.
> > > > > > > > >
> > > > > > > > > If we feel we need a release for 1.6 and Ignite, I suggest
> we
> > > > make
> > > > > a
> > > > > > > > > release that *only* includes the absolute minimal changes
> > > > required
> > > > > to
> > > > > > > do
> > > > > > > > > that.
> > > > > > > > >
> > > > > > > > > There was one PR for 1.6 support that didn’t really work
> and
> > is
> > > > > going
> > > > > > > to
> > > > > > > > > break anything built against the current codebase. Except
> > for a
> > > > > > change
> > > > > > > in
> > > > > > > > > the name of one method called by one class, all of the
> > changes
> > > > seem
> > > > > > to
> > > > > > > > > involve support for spark-under-zeppelin, which is
> something
> > we
> > > > > want
> > > > > > to
> > > > > > > > > take out.
> > > > > > > > >
> > > > > > > > > We also don’t currently have a working testing framework. A
> > lot
> > > > of
> > > > > > PRs
> > > > > > > > > have been committed under the “ignore travis its broken”
> > > theory.
> > > > > I’m
> > > > > > > > > loathe to make a release that hasn’t really been tested,
> and
> > it
> > > > > > doesn’t
> > > > > > > > > seem we’re in a position to do that.
> > > > > > > > >
> > > > > > > > > While there have been a lot of merged PRs, I don’t think
> any
> > of
> > > > > them
> > > > > > > are
> > > > > > > > > on-roadmap. They mostly seem to be very minor, like fixing
> > > typos
> > > > > and
> > > > > > > > > changing which text box gets highlighted. Those are
> important
> > > > > things,
> > > > > > > of
> > > > > > > > > course, but not major enough to justify the effort involved
> > in
> > > a
> > > > > > > release.
> > > > > > > > >
> > > > > > > > > Another release will not make it easier to integrate the
> > larger
> > > > > PRs.
> > > > > > It
> > > > > > > > > will have the opposite effect. Developers will have to
> rebase
> > > > > against
> > > > > > > > > whatever gets broken by 1.6 and other changes.
> > > > > > > > >
> > > > > > > > > I suggest we wait to do a significant release until we can
> > take
> > > > out
> > > > > > the
> > > > > > > > > legacy spark-under-zeppelin code that has caused so many
> > > issues,
> > > > > > have a
> > > > > > > > > working testing framework, and integrate the major
> > outstanding
> > > > PRs.
> > > > > > > > >
> > > > > > > > > So, again, if we want a release, I suggest we include the
> > > > absolute
> > > > > > > > minimum
> > > > > > > > > changes necessary for 1.6 and Ignite, and perhaps call it
> an
> > > > > interim
> > > > > > or
> > > > > > > > > maintenance release.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > From: Konstantin Boudnik <co...@apache.org>
> > > > > > > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > > > > > > dev@zeppelin.incubator.apache.org>,
> > > > > > dev@zeppelin.incubator.apache.org
> > > > > > > <
> > > > > > > > > dev@zeppelin.incubator.apache.org>
> > > > > > > > > Date: December 29, 2015 at 10:05:36 PM
> > > > > > > > > To: dev@zeppelin.incubator.apache.org <
> > > > > > > dev@zeppelin.incubator.apache.org
> > > > > > > > >
> > > > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > > > >
> > > > > > > > > Good idea! BTW, Apache Ignite is voting right now on
> > > 1.5.0.final
> > > > -
> > > > > > > would
> > > > > > > > > make
> > > > > > > > > sense to add this to the latest release of Zeppelin. I will
> > > open
> > > > a
> > > > > > JIRA
> > > > > > > > and
> > > > > > > > > supply a patch for it, if there's no objections.
> > > > > > > > >
> > > > > > > > > Cos
> > > > > > > > >
> > > > > > > > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > > > > > > > > Hi folks,
> > > > > > > > > >
> > > > > > > > > > How about we make release 0.5.6-incubating?
> > > > > > > > > >
> > > > > > > > > > Since last release, more than 100 pull requests are
> merged
> > > and
> > > > > more
> > > > > > > > than
> > > > > > > > > 80
> > > > > > > > > > issues are resolved.
> > > > > > > > > >
> > > > > > > > > > It's including new interpreters, a lot of new features
> and
> > > > > > > improvement
> > > > > > > > on
> > > > > > > > > > GUI with much improved stability thanks to lots of bug
> > fixes.
> > > > > > > > > >
> > > > > > > > > > Also it's great time to have a Zeppelin release that
> > support
> > > > > Spark
> > > > > > > 1.6
> > > > > > > > (
> > > > > > > > > > ZEPPELIN-395), which about to be released.
> > > > > > > > > >
> > > > > > > > > > Once we branch for 0.5.6-incubating release, it's more
> safe
> > > to
> > > > > make
> > > > > > > > large
> > > > > > > > > > code base change such as "Added Shiro security" (
> > > > > > > > > > https://github.com/apache/incubator-zeppelin/pull/53)
> and
> > > many
> > > > > > other
> > > > > > > > > > planned feature in 0.6.0 roadmap, that will require lots
> of
> > > > > > internal
> > > > > > > > API
> > > > > > > > > > updates.
> > > > > > > > > >
> > > > > > > > > > What do you think?
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > moon
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > > > http://madeng.net
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > > > http://madeng.net
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > > > http://madeng.net
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > > > http://madeng.net
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > > > http://madeng.net
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > > > http://madeng.net
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>



-- 
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

Re: [DISCUSS] Release 0.5.6-incubating

Posted by moon soo Lee <mo...@apache.org>.
Really appreciated taking release manager for 0.5.6-incubating release :-)

On Mon, Jan 4, 2016 at 10:12 PM Alexander Bezzubov <bz...@apache.org> wrote:

> Hi Moon,
>
> as mentioned before, I think rotating release management responsibilities
> is a great idea!
> Will be happy to volunteer and cut 0.5.6-incubating release.
>
> On Tue, Jan 5, 2016 at 3:02 PM, moon soo Lee <mo...@apache.org> wrote:
>
> > I've been release manager for 0.5.0-incubating and 0.5.5-incubating.
> > Any committer volunteer the release manager for 0.5.6-incubating release?
> >
> > Thanks,
> > moon
> >
> > On Mon, Jan 4, 2016 at 9:52 PM Alexander Bezzubov <bz...@apache.org>
> wrote:
> >
> > > +1 for 0.5.6 release from maser
> > >
> > > On Wed, Dec 30, 2015 at 9:51 PM, Khalid Huseynov <khalidhnv@nflabs.com
> >
> > > wrote:
> > >
> > > > +1 for 0.5.6 release with current improvements/fixes.
> > > >
> > > >
> > > > On Wed, Dec 30, 2015 at 4:10 PM, moon soo Lee <mo...@apache.org>
> wrote:
> > > >
> > > > > Amos,
> > > > >
> > > > > Who started the word "meaningful" is not important.
> > > > > Release discussion will not be judgement of how
> meaningful/major/big
> > > the
> > > > > contributions are.
> > > > >
> > > > > CI problem i have describe about R interpreter PR [1] is not
> related
> > > with
> > > > > any other contribution that we're trying to release.
> > > > >
> > > > > CI test does not have any known false negative, and we force
> > > contributor
> > > > > rerun the test until false positive disappear. So logically, we can
> > > > > guarantee that every contribution has passed the CI test correctly.
> > > > >
> > > > > Also Testis being done not only by CI but also all Zeppelin users.
> > > > > If users see serious problem in the release candidate, they'll
> block
> > > the
> > > > > release vote during release candidate verification.
> > > > >
> > > > > Hope this make you feel more confident about the code we're trying
> to
> > > > > release.
> > > > >
> > > > > Thanks,
> > > > > moon
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/GitHub-incubator-zeppelin-pull-request-R-Interpreter-for-Zeppelin-tp956p4623.html
> > > > >
> > > > >
> > > > > On Tue, Dec 29, 2015 at 10:53 PM Amos B. Elberg <
> > amos.elberg@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > You did reply to both.  Let me try to clarify the problem with
> CI:
> > > > > >
> > > > > > The problem is *not* that particular PRs cause instability at
> > > runtime.
> > > > > >
> > > > > > The problem with CI is that if CI is not working properly, then
> *we
> > > > can’t
> > > > > > know* whether PRs will cause instability.  Or what that connects
> to
> > > > > > Zeppelin will break.
> > > > > >
> > > > > > CI is our own standard of testability.
> > > > > >
> > > > > > It is very common in organizations that they establish a standard
> > of
> > > > > > reliability.  But, when things become difficult, or there is a
> > > problem
> > > > > with
> > > > > > the standard, the organization comes under pressure to bend or
> flex
> > > the
> > > > > > standard.
> > > > > >
> > > > > > In my experience, when organizations violate their own standards
> > for
> > > > the
> > > > > > sake of expedience, it is a recipe for trouble 100% of the time.
> > > > > >
> > > > > > —
> > > > > >
> > > > > > I just reviewed the changes Jongyoul posted.  One of them relates
> > to
> > > a
> > > > > bug
> > > > > > that was reported in September that has become an issue at
> Twitter.
> > > > That
> > > > > > seems to me to be a justification for a “hot fix” to the bug.
> > > > > >
> > > > > > I still don’t see any justification for a release though.
> > > > > >
> > > > > >
> > > > > > From: moon soo Lee <mo...@apache.org>
> > > > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > > > dev@zeppelin.incubator.apache.org>
> > > > > > Date: December 30, 2015 at 1:36:58 AM
> > > > > > To: dev@zeppelin.incubator.apache.org <
> > > > dev@zeppelin.incubator.apache.org
> > > > > >
> > > > > > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> > > > > >
> > > > > > Amos,
> > > > > >
> > > > > > If i summarize why you against 0.5.6-incubating release,
> > > > > >
> > > > > > * CI is not working
> > > > > > * Does not have meaningful or major features to be released
> > > > > >
> > > > > > these two, right? I replied answer for both of them
> > > > > >
> > > > > > Here
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4763.html
> > > > > > and here
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4765.html
> > > > > >
> > > > > > I'm listening and respect your opinion. Please check my reply and
> > > tell
> > > > me
> > > > > > if you have different opinion, but please include REASON WHY you
> > > think
> > > > in
> > > > > > that way otherwise it's hard to understand what you're thinking.
> > > > > >
> > > > > > Thanks,
> > > > > > moon
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 29, 2015 at 10:18 PM Amos B. Elberg <
> > > amos.elberg@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Do you want me to explain the commits after 0.5.5 in details?
> > > > > > > I want you to provide an example of any feature that justifies
> > the
> > > > > effort
> > > > > > > that will be put into making a release, delaying 0.6 and CI and
> > > > > > everything
> > > > > > > else, and rebasing the outstanding major PRs.
> > > > > > >
> > > > > > > I will settle for *one* example. Just one!
> > > > > > >
> > > > > > > And what is your answer that why minor release has a important
> > > > feature
> > > > > > and
> > > > > > > what the difference between major and minor is?
> > > > > > > My view is that a “minor” release is one that doesn’t require
> > > changes
> > > > > in
> > > > > > > code built against the release other than recompiling. “Major”
> > > means
> > > > > > > people have to work to update their code because of the
> release.
> > > > > > >
> > > > > > > I don't know why you oppose a new minor release including minor
> > bug
> > > > > > fixes.
> > > > > > > I’m not even sure these count as “bug fixes” :p A change to the
> > > > shading
> > > > > > > of a window so it matches other windows is nice, but its
> hardly a
> > > > “bug
> > > > > > > fix.”
> > > > > > >
> > > > > > > Anyway I don’t think this release will really be limited to UI
> > and
> > > > > > “minor”
> > > > > > > changes. I think there will be changes to the core code — like
> > the
> > > > 1.6
> > > > > PR
> > > > > > > — that will actually be problems disguised as minor changes.
> And
> > i
> > > > > don’t
> > > > > > > think we can test for that without CI.
> > > > > > >
> > > > > > > And What kind of aspects are less maintainable between 0.5.5
> and
> > > > 0.5.6?
> > > > > > > The fact of the change is what makes it less maintainable!
> > > > > > >
> > > > > > > And what kind of fixes makes Zeppelin less stable?
> > > > > > > The *codebase* is definitely less stable.
> > > > > > >
> > > > > > > Do you believe that some PR is unstable because of failing CI?
> > > > > > >
> > > > > > > Since CI is failing, how do I know if any PRs are stable or
> not?
> > > > > > >
> > > > > > >
> > > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > > Date: December 30, 2015 at 1:05:55 AM
> > > > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > > > CC: dev@zeppelin.incubator.apache.org <
> > > > > dev@zeppelin.incubator.apache.org
> > > > > > >
> > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > >
> > > > > > > Do you want me to explain the commits after 0.5.5 in details?
> And
> > > > what
> > > > > is
> > > > > > > your answer that why minor release has a important feature and
> > what
> > > > the
> > > > > > > difference between major and minor is? I also think it's good
> to
> > > fix
> > > > > > > version up for ignite but this is not a major feature. I don't
> > know
> > > > why
> > > > > > > you oppose a new minor release including minor bug fixes. And
> > What
> > > > kind
> > > > > > of
> > > > > > > aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6
> > is
> > > > less
> > > > > > > maintainable, we should revert that commit because it's harmful
> > to
> > > > > > > Zeppelin. And what kind of fixes makes Zeppelin less stable? I
> > > would
> > > > > like
> > > > > > > to show me that commit number or issue number. And finally,
> Moon
> > > > > admitted
> > > > > > > CI had some flakey tests and have tried to remove or fix that
> > > tests.
> > > > Do
> > > > > > you
> > > > > > > believe that some PR is unstable because of failing CI?
> > > > > > >
> > > > > > > On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <
> > > > amos.elberg@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > > A codebase that often changes in ways that break other code is
> an
> > > > > > unstable
> > > > > > > codebase, by definition.
> > > > > > >
> > > > > > > I don’t think it will be more stable at runtime, especially
> since
> > > CI
> > > > > > isn’t
> > > > > > > working.
> > > > > > >
> > > > > > > It definitely won’t be more maintainable. The key problematic
> > code
> > > is
> > > > > > > still in.
> > > > > > >
> > > > > > > Other than Spark 1.6 and Ignite, I don’t see any reason at all
> > for
> > > a
> > > > > > 0.5.6
> > > > > > > release. (Konstantin was right — it is good for Apache releases
> > to
> > > > > > > maintain version compatibility with new versions of other
> Apache
> > > > > > software.
> > > > > > > That is Apache projects helping each other.)
> > > > > > >
> > > > > > > What feature do you feel justifies a 0.5.6 release? What
> feature
> > > > other
> > > > > > > than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
> > > > > > >
> > > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > > Date: December 30, 2015 at 12:32:01 AM
> > > > > > >
> > > > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > > > CC: dev@zeppelin.incubator.apache.org <
> > > > > dev@zeppelin.incubator.apache.org
> > > > > > >
> > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > >
> > > > > > > Amos,
> > > > > > >
> > > > > > > I don't think we have a strict plan for making a minor release
> > and
> > > we
> > > > > > have
> > > > > > > a roadmap for major release. And ignite and Spark 1.6 is not a
> > key
> > > > > > feature
> > > > > > > of 0.5.6. Konstantin just wanted to be merged that contribution
> > if
> > > > that
> > > > > > > voting is finished until we make a release. And Spark 1.6 is on
> > > > going.
> > > > > As
> > > > > > > you told, we are an Apache project. 0.5.6 will be stable and
> > > > > > maintainable.
> > > > > > > If 0.5.6 has an experimental features, I don't agree to make a
> > > > release.
> > > > > > > 0.5.6 will be more stable version of 0.5.5. And of course, the
> > most
> > > > > > people
> > > > > > > like more stable version. Isn't it enough?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Jongyoul
> > > > > > >
> > > > > > > On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <
> > > > amos.elberg@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > > My suggestion is that we do a 0.5.6 that just has the bare
> > minimal
> > > > > > changes
> > > > > > > necessary for Spark 1.6 and Ignite and nothing else.
> > > > > > >
> > > > > > > That way we provide “must have” features while minimizing risk.
> > > > > > >
> > > > > > > Other than that, yes: I think we should keep our current
> release
> > > plan
> > > > > and
> > > > > > > not make a release for “nice to have” changes until CI is
> fixed.
> > > > > > >
> > > > > > > The main purpose of making a new minor release should be
> whether
> > > > > already
> > > > > > > merged features are meaningful to make a minor release even if
> > any
> > > > > major
> > > > > > > issues are on going, isn't it?
> > > > > > >
> > > > > > > I’m not sure that I understand what you are asking.
> > > > > > >
> > > > > > > We have a planned 0.6 release. We just did an unplanned “minor”
> > > 0.5.5
> > > > > > > release. It feels like only a few weeks ago. I voted for it
> > because
> > > > it
> > > > > > > seemed that it would stabilize the codebase and provide a
> > > > maintainable
> > > > > > > interim foundation.
> > > > > > >
> > > > > > > I do not think any of the features since 0.5.5 are “meaningful”
> > > > enough
> > > > > to
> > > > > > > justify changing the release plan. Not even close. I think it
> is
> > > rare
> > > > > > > that any off-roadmap “nice to have” feature would ever be a
> good
> > > > reason
> > > > > > to
> > > > > > > change a release plan. Especially when our CI “house” is not in
> > > > order.
> > > > > > >
> > > > > > > We’re an Apache project — we need to be stable, maintainable,
> > > > reliable,
> > > > > > > predictable.
> > > > > > >
> > > > > > > Is there any merged PR that is so important it can’t wait for
> > 0.6?
> > > > > > >
> > > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > > Date: December 29, 2015 at 11:54:35 PM
> > > > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > > > CC: dev@zeppelin.incubator.apache.org <
> > > > > dev@zeppelin.incubator.apache.org
> > > > > > >
> > > > > > >
> > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > >
> > > > > > > Okay, Amos,
> > > > > > >
> > > > > > > Do you propose Zeppelin should not have another release before
> > fix
> > > CI
> > > > > > > issue? I think even though CI has some problems, another minors
> > > fixes
> > > > > is
> > > > > > > meaningful to make a new minor release. Do you agree with that?
> > Or
> > > > > don't
> > > > > > > you agree that it's enough? The main purpose of making a new
> > minor
> > > > > > release
> > > > > > > should be whether already merged features are meaningful to
> make
> > a
> > > > > minor
> > > > > > > release even if any major issues are on going, isn't it?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Jongyoul
> > > > > > >
> > > > > > > On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <
> > > > amos.elberg@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > > Hah!
> > > > > > >
> > > > > > > I promise you, an hour after a 0.5.6 comes out, I will have
> > emails
> > > > > asking
> > > > > > > me when I will support 0.5.6, even if no-one actually needs any
> > > 0.5.6
> > > > > > > changes or even knows what they are!
> > > > > > >
> > > > > > > I want to be clear though: My primary issue for 0.5.6 is not
> > > whether
> > > > to
> > > > > > > merge the R interpreter.
> > > > > > >
> > > > > > > My issues are I think we need to fix CI in general, and I’m
> > loathe
> > > to
> > > > > > have
> > > > > > > more releases with that dammed spark-under-zeppelin code, which
> > is
> > > > the
> > > > > > root
> > > > > > > of many other issues.
> > > > > > >
> > > > > > >
> > > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > > Date: December 29, 2015 at 11:21:00 PM
> > > > > > > To: Amos B. Elberg <am...@gmail.com>,
> > > > > > > dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org
> > > > >
> > > > > > >
> > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > >
> > > > > > > Okay, I understand your situation. If you rebased your PR from
> > > > master,
> > > > > > you
> > > > > > > can rebased your PR only once but I also know why you had to do
> > > > that. I
> > > > > > > think R is a roadmap for 0.6.0 and you'd better skip rebasing
> > > 0.5.6.
> > > > > How
> > > > > > > about you?
> > > > > > >
> > > > > > > On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <
> > > > amos.elberg@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > > Jongyoul - the reason we have to rebase twice is that the
> changes
> > > in
> > > > > > > zeppelin-master will break the R interpreter.
> > > > > > >
> > > > > > > So I’ll have to rebase once so that I’m based off of 0.5.6 and
> > > people
> > > > > can
> > > > > > > use the code. Then rebase again for 0.6.0.
> > > > > > >
> > > > > > > Remember, I have a user base I need to support — there are a
> lot
> > of
> > > > > > people
> > > > > > > using the R interpreter now. So its not just a PR where I can
> > > ignore
> > > > it
> > > > > > > until its ready to merge.
> > > > > > >
> > > > > > > The changes have already broken the shiro PR apparently quite
> > > often.
> > > > > > >
> > > > > > > I made a “release” of the R Interpreter just so I could stop
> > > rebasing
> > > > > > > against Zeppelin master. I spent > 60 hours dealing with this
> for
> > > the
> > > > > > > changes leading up to 0.5 and 0.5.5.
> > > > > > >
> > > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > > Date: December 29, 2015 at 11:08:36 PM
> > > > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > > >
> > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > >
> > > > > > > I don't know why you should rebased twice. If you can make a PR
> > > from
> > > > > > > current master, almost changes merged without rebasing and if a
> > > > > committer
> > > > > > > asks to rebase your PR, this is because you and another
> > > contributors
> > > > > > > changes the same codes and another contributions is merged
> before
> > > > your
> > > > > > PR.
> > > > > > > In specific R case, Moon want you to rebase because he tries to
> > fix
> > > > the
> > > > > > > testing codes so rebasing your PR will accepts their changes.
> In
> > > most
> > > > > > case,
> > > > > > > contributors don't need to rebase their PR before merge because
> > > > > committer
> > > > > > > commit someone's PR by doing cherry-pick. We also felt sorry
> that
> > > you
> > > > > > were
> > > > > > > bothered by testing issue and Moon is fighting to fix the
> testing
> > > > > infra.
> > > > > > > However all of PRs shouldn't be rebased.
> > > > > > >
> > > > > > > On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <
> > > > > amos.elberg@gmail.com>
> > > > > > > wrote:
> > > > > > > I think there is no big pain because whole changes to be merged
> > > > > > > into 0.5.6 will be also merged into 0.6.0.
> > > > > > >
> > > > > > > If we make another release now, the PRs will have to be rebased
> > > > > *twice*,
> > > > > > > once for 0.5.6, and once again for 0.6.
> > > > > > >
> > > > > > > Also - since this is now the second e-mail from a committer to
> do
> > > the
> > > > > > same
> > > > > > > thing — is there a reason you guys are leaving R out of the
> > agenda
> > > > for
> > > > > > the
> > > > > > > next release? I understood the PR had been accepted and was
> > pending
> > > > > only
> > > > > > > Moon fixing the testing infrastructure.
> > > > > > >
> > > > > > >
> > > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > > > > dev@zeppelin.incubator.apache.org>
> > > > > > > Date: December 29, 2015 at 10:56:33 PM
> > > > > > >
> > > > > > > To: dev@zeppelin.incubator.apache.org <
> > > > > dev@zeppelin.incubator.apache.org
> > > > > > >
> > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > >
> > > > > > > Good idea!
> > > > > > >
> > > > > > > 0.5.6 is a minor release thus fixing minor bugs and typos is
> > > enough.
> > > > > But
> > > > > > I
> > > > > > > also think 0.6.0 should have major changes like supporting
> spark
> > > 1.6
> > > > > and
> > > > > > > Shiro security and improving testing infra. And concerning
> > rebasing
> > > > and
> > > > > > > committing, I think there is no big pain because whole changes
> to
> > > be
> > > > > > merged
> > > > > > > into 0.5.6 will be also merged into 0.6.0.
> > > > > > >
> > > > > > > JL
> > > > > > >
> > > > > > > On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <
> > > > > amos.elberg@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I don’t want to come off as the naysayer here, but I think
> the
> > > > effort
> > > > > > > that
> > > > > > > > would go into a release would be better spent on the testing
> > > > > > > infrastructure
> > > > > > > > and outstanding PRs.
> > > > > > > >
> > > > > > > > If we feel we need a release for 1.6 and Ignite, I suggest we
> > > make
> > > > a
> > > > > > > > release that *only* includes the absolute minimal changes
> > > required
> > > > to
> > > > > > do
> > > > > > > > that.
> > > > > > > >
> > > > > > > > There was one PR for 1.6 support that didn’t really work and
> is
> > > > going
> > > > > > to
> > > > > > > > break anything built against the current codebase. Except
> for a
> > > > > change
> > > > > > in
> > > > > > > > the name of one method called by one class, all of the
> changes
> > > seem
> > > > > to
> > > > > > > > involve support for spark-under-zeppelin, which is something
> we
> > > > want
> > > > > to
> > > > > > > > take out.
> > > > > > > >
> > > > > > > > We also don’t currently have a working testing framework. A
> lot
> > > of
> > > > > PRs
> > > > > > > > have been committed under the “ignore travis its broken”
> > theory.
> > > > I’m
> > > > > > > > loathe to make a release that hasn’t really been tested, and
> it
> > > > > doesn’t
> > > > > > > > seem we’re in a position to do that.
> > > > > > > >
> > > > > > > > While there have been a lot of merged PRs, I don’t think any
> of
> > > > them
> > > > > > are
> > > > > > > > on-roadmap. They mostly seem to be very minor, like fixing
> > typos
> > > > and
> > > > > > > > changing which text box gets highlighted. Those are important
> > > > things,
> > > > > > of
> > > > > > > > course, but not major enough to justify the effort involved
> in
> > a
> > > > > > release.
> > > > > > > >
> > > > > > > > Another release will not make it easier to integrate the
> larger
> > > > PRs.
> > > > > It
> > > > > > > > will have the opposite effect. Developers will have to rebase
> > > > against
> > > > > > > > whatever gets broken by 1.6 and other changes.
> > > > > > > >
> > > > > > > > I suggest we wait to do a significant release until we can
> take
> > > out
> > > > > the
> > > > > > > > legacy spark-under-zeppelin code that has caused so many
> > issues,
> > > > > have a
> > > > > > > > working testing framework, and integrate the major
> outstanding
> > > PRs.
> > > > > > > >
> > > > > > > > So, again, if we want a release, I suggest we include the
> > > absolute
> > > > > > > minimum
> > > > > > > > changes necessary for 1.6 and Ignite, and perhaps call it an
> > > > interim
> > > > > or
> > > > > > > > maintenance release.
> > > > > > > >
> > > > > > > >
> > > > > > > > From: Konstantin Boudnik <co...@apache.org>
> > > > > > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > > > > > dev@zeppelin.incubator.apache.org>,
> > > > > dev@zeppelin.incubator.apache.org
> > > > > > <
> > > > > > > > dev@zeppelin.incubator.apache.org>
> > > > > > > > Date: December 29, 2015 at 10:05:36 PM
> > > > > > > > To: dev@zeppelin.incubator.apache.org <
> > > > > > dev@zeppelin.incubator.apache.org
> > > > > > > >
> > > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > > >
> > > > > > > > Good idea! BTW, Apache Ignite is voting right now on
> > 1.5.0.final
> > > -
> > > > > > would
> > > > > > > > make
> > > > > > > > sense to add this to the latest release of Zeppelin. I will
> > open
> > > a
> > > > > JIRA
> > > > > > > and
> > > > > > > > supply a patch for it, if there's no objections.
> > > > > > > >
> > > > > > > > Cos
> > > > > > > >
> > > > > > > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > > > > > > > Hi folks,
> > > > > > > > >
> > > > > > > > > How about we make release 0.5.6-incubating?
> > > > > > > > >
> > > > > > > > > Since last release, more than 100 pull requests are merged
> > and
> > > > more
> > > > > > > than
> > > > > > > > 80
> > > > > > > > > issues are resolved.
> > > > > > > > >
> > > > > > > > > It's including new interpreters, a lot of new features and
> > > > > > improvement
> > > > > > > on
> > > > > > > > > GUI with much improved stability thanks to lots of bug
> fixes.
> > > > > > > > >
> > > > > > > > > Also it's great time to have a Zeppelin release that
> support
> > > > Spark
> > > > > > 1.6
> > > > > > > (
> > > > > > > > > ZEPPELIN-395), which about to be released.
> > > > > > > > >
> > > > > > > > > Once we branch for 0.5.6-incubating release, it's more safe
> > to
> > > > make
> > > > > > > large
> > > > > > > > > code base change such as "Added Shiro security" (
> > > > > > > > > https://github.com/apache/incubator-zeppelin/pull/53) and
> > many
> > > > > other
> > > > > > > > > planned feature in 0.6.0 roadmap, that will require lots of
> > > > > internal
> > > > > > > API
> > > > > > > > > updates.
> > > > > > > > >
> > > > > > > > > What do you think?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > moon
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > > http://madeng.net
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > > http://madeng.net
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > > http://madeng.net
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > > http://madeng.net
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > > http://madeng.net
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > > http://madeng.net
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Alexander Bezzubov <bz...@apache.org>.
Hi Moon,

as mentioned before, I think rotating release management responsibilities
is a great idea!
Will be happy to volunteer and cut 0.5.6-incubating release.

On Tue, Jan 5, 2016 at 3:02 PM, moon soo Lee <mo...@apache.org> wrote:

> I've been release manager for 0.5.0-incubating and 0.5.5-incubating.
> Any committer volunteer the release manager for 0.5.6-incubating release?
>
> Thanks,
> moon
>
> On Mon, Jan 4, 2016 at 9:52 PM Alexander Bezzubov <bz...@apache.org> wrote:
>
> > +1 for 0.5.6 release from maser
> >
> > On Wed, Dec 30, 2015 at 9:51 PM, Khalid Huseynov <kh...@nflabs.com>
> > wrote:
> >
> > > +1 for 0.5.6 release with current improvements/fixes.
> > >
> > >
> > > On Wed, Dec 30, 2015 at 4:10 PM, moon soo Lee <mo...@apache.org> wrote:
> > >
> > > > Amos,
> > > >
> > > > Who started the word "meaningful" is not important.
> > > > Release discussion will not be judgement of how meaningful/major/big
> > the
> > > > contributions are.
> > > >
> > > > CI problem i have describe about R interpreter PR [1] is not related
> > with
> > > > any other contribution that we're trying to release.
> > > >
> > > > CI test does not have any known false negative, and we force
> > contributor
> > > > rerun the test until false positive disappear. So logically, we can
> > > > guarantee that every contribution has passed the CI test correctly.
> > > >
> > > > Also Testis being done not only by CI but also all Zeppelin users.
> > > > If users see serious problem in the release candidate, they'll block
> > the
> > > > release vote during release candidate verification.
> > > >
> > > > Hope this make you feel more confident about the code we're trying to
> > > > release.
> > > >
> > > > Thanks,
> > > > moon
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/GitHub-incubator-zeppelin-pull-request-R-Interpreter-for-Zeppelin-tp956p4623.html
> > > >
> > > >
> > > > On Tue, Dec 29, 2015 at 10:53 PM Amos B. Elberg <
> amos.elberg@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > You did reply to both.  Let me try to clarify the problem with CI:
> > > > >
> > > > > The problem is *not* that particular PRs cause instability at
> > runtime.
> > > > >
> > > > > The problem with CI is that if CI is not working properly, then *we
> > > can’t
> > > > > know* whether PRs will cause instability.  Or what that connects to
> > > > > Zeppelin will break.
> > > > >
> > > > > CI is our own standard of testability.
> > > > >
> > > > > It is very common in organizations that they establish a standard
> of
> > > > > reliability.  But, when things become difficult, or there is a
> > problem
> > > > with
> > > > > the standard, the organization comes under pressure to bend or flex
> > the
> > > > > standard.
> > > > >
> > > > > In my experience, when organizations violate their own standards
> for
> > > the
> > > > > sake of expedience, it is a recipe for trouble 100% of the time.
> > > > >
> > > > > —
> > > > >
> > > > > I just reviewed the changes Jongyoul posted.  One of them relates
> to
> > a
> > > > bug
> > > > > that was reported in September that has become an issue at Twitter.
> > > That
> > > > > seems to me to be a justification for a “hot fix” to the bug.
> > > > >
> > > > > I still don’t see any justification for a release though.
> > > > >
> > > > >
> > > > > From: moon soo Lee <mo...@apache.org>
> > > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > > dev@zeppelin.incubator.apache.org>
> > > > > Date: December 30, 2015 at 1:36:58 AM
> > > > > To: dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org
> > > > >
> > > > > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> > > > >
> > > > > Amos,
> > > > >
> > > > > If i summarize why you against 0.5.6-incubating release,
> > > > >
> > > > > * CI is not working
> > > > > * Does not have meaningful or major features to be released
> > > > >
> > > > > these two, right? I replied answer for both of them
> > > > >
> > > > > Here
> > > > >
> > > > >
> > > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4763.html
> > > > > and here
> > > > >
> > > > >
> > > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4765.html
> > > > >
> > > > > I'm listening and respect your opinion. Please check my reply and
> > tell
> > > me
> > > > > if you have different opinion, but please include REASON WHY you
> > think
> > > in
> > > > > that way otherwise it's hard to understand what you're thinking.
> > > > >
> > > > > Thanks,
> > > > > moon
> > > > >
> > > > >
> > > > > On Tue, Dec 29, 2015 at 10:18 PM Amos B. Elberg <
> > amos.elberg@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Do you want me to explain the commits after 0.5.5 in details?
> > > > > > I want you to provide an example of any feature that justifies
> the
> > > > effort
> > > > > > that will be put into making a release, delaying 0.6 and CI and
> > > > > everything
> > > > > > else, and rebasing the outstanding major PRs.
> > > > > >
> > > > > > I will settle for *one* example. Just one!
> > > > > >
> > > > > > And what is your answer that why minor release has a important
> > > feature
> > > > > and
> > > > > > what the difference between major and minor is?
> > > > > > My view is that a “minor” release is one that doesn’t require
> > changes
> > > > in
> > > > > > code built against the release other than recompiling. “Major”
> > means
> > > > > > people have to work to update their code because of the release.
> > > > > >
> > > > > > I don't know why you oppose a new minor release including minor
> bug
> > > > > fixes.
> > > > > > I’m not even sure these count as “bug fixes” :p A change to the
> > > shading
> > > > > > of a window so it matches other windows is nice, but its hardly a
> > > “bug
> > > > > > fix.”
> > > > > >
> > > > > > Anyway I don’t think this release will really be limited to UI
> and
> > > > > “minor”
> > > > > > changes. I think there will be changes to the core code — like
> the
> > > 1.6
> > > > PR
> > > > > > — that will actually be problems disguised as minor changes. And
> i
> > > > don’t
> > > > > > think we can test for that without CI.
> > > > > >
> > > > > > And What kind of aspects are less maintainable between 0.5.5 and
> > > 0.5.6?
> > > > > > The fact of the change is what makes it less maintainable!
> > > > > >
> > > > > > And what kind of fixes makes Zeppelin less stable?
> > > > > > The *codebase* is definitely less stable.
> > > > > >
> > > > > > Do you believe that some PR is unstable because of failing CI?
> > > > > >
> > > > > > Since CI is failing, how do I know if any PRs are stable or not?
> > > > > >
> > > > > >
> > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > Date: December 30, 2015 at 1:05:55 AM
> > > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > > CC: dev@zeppelin.incubator.apache.org <
> > > > dev@zeppelin.incubator.apache.org
> > > > > >
> > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > >
> > > > > > Do you want me to explain the commits after 0.5.5 in details? And
> > > what
> > > > is
> > > > > > your answer that why minor release has a important feature and
> what
> > > the
> > > > > > difference between major and minor is? I also think it's good to
> > fix
> > > > > > version up for ignite but this is not a major feature. I don't
> know
> > > why
> > > > > > you oppose a new minor release including minor bug fixes. And
> What
> > > kind
> > > > > of
> > > > > > aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6
> is
> > > less
> > > > > > maintainable, we should revert that commit because it's harmful
> to
> > > > > > Zeppelin. And what kind of fixes makes Zeppelin less stable? I
> > would
> > > > like
> > > > > > to show me that commit number or issue number. And finally, Moon
> > > > admitted
> > > > > > CI had some flakey tests and have tried to remove or fix that
> > tests.
> > > Do
> > > > > you
> > > > > > believe that some PR is unstable because of failing CI?
> > > > > >
> > > > > > On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <
> > > amos.elberg@gmail.com
> > > > >
> > > > > > wrote:
> > > > > > A codebase that often changes in ways that break other code is an
> > > > > unstable
> > > > > > codebase, by definition.
> > > > > >
> > > > > > I don’t think it will be more stable at runtime, especially since
> > CI
> > > > > isn’t
> > > > > > working.
> > > > > >
> > > > > > It definitely won’t be more maintainable. The key problematic
> code
> > is
> > > > > > still in.
> > > > > >
> > > > > > Other than Spark 1.6 and Ignite, I don’t see any reason at all
> for
> > a
> > > > > 0.5.6
> > > > > > release. (Konstantin was right — it is good for Apache releases
> to
> > > > > > maintain version compatibility with new versions of other Apache
> > > > > software.
> > > > > > That is Apache projects helping each other.)
> > > > > >
> > > > > > What feature do you feel justifies a 0.5.6 release? What feature
> > > other
> > > > > > than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
> > > > > >
> > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > Date: December 30, 2015 at 12:32:01 AM
> > > > > >
> > > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > > CC: dev@zeppelin.incubator.apache.org <
> > > > dev@zeppelin.incubator.apache.org
> > > > > >
> > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > >
> > > > > > Amos,
> > > > > >
> > > > > > I don't think we have a strict plan for making a minor release
> and
> > we
> > > > > have
> > > > > > a roadmap for major release. And ignite and Spark 1.6 is not a
> key
> > > > > feature
> > > > > > of 0.5.6. Konstantin just wanted to be merged that contribution
> if
> > > that
> > > > > > voting is finished until we make a release. And Spark 1.6 is on
> > > going.
> > > > As
> > > > > > you told, we are an Apache project. 0.5.6 will be stable and
> > > > > maintainable.
> > > > > > If 0.5.6 has an experimental features, I don't agree to make a
> > > release.
> > > > > > 0.5.6 will be more stable version of 0.5.5. And of course, the
> most
> > > > > people
> > > > > > like more stable version. Isn't it enough?
> > > > > >
> > > > > > Regards,
> > > > > > Jongyoul
> > > > > >
> > > > > > On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <
> > > amos.elberg@gmail.com
> > > > >
> > > > > > wrote:
> > > > > > My suggestion is that we do a 0.5.6 that just has the bare
> minimal
> > > > > changes
> > > > > > necessary for Spark 1.6 and Ignite and nothing else.
> > > > > >
> > > > > > That way we provide “must have” features while minimizing risk.
> > > > > >
> > > > > > Other than that, yes: I think we should keep our current release
> > plan
> > > > and
> > > > > > not make a release for “nice to have” changes until CI is fixed.
> > > > > >
> > > > > > The main purpose of making a new minor release should be whether
> > > > already
> > > > > > merged features are meaningful to make a minor release even if
> any
> > > > major
> > > > > > issues are on going, isn't it?
> > > > > >
> > > > > > I’m not sure that I understand what you are asking.
> > > > > >
> > > > > > We have a planned 0.6 release. We just did an unplanned “minor”
> > 0.5.5
> > > > > > release. It feels like only a few weeks ago. I voted for it
> because
> > > it
> > > > > > seemed that it would stabilize the codebase and provide a
> > > maintainable
> > > > > > interim foundation.
> > > > > >
> > > > > > I do not think any of the features since 0.5.5 are “meaningful”
> > > enough
> > > > to
> > > > > > justify changing the release plan. Not even close. I think it is
> > rare
> > > > > > that any off-roadmap “nice to have” feature would ever be a good
> > > reason
> > > > > to
> > > > > > change a release plan. Especially when our CI “house” is not in
> > > order.
> > > > > >
> > > > > > We’re an Apache project — we need to be stable, maintainable,
> > > reliable,
> > > > > > predictable.
> > > > > >
> > > > > > Is there any merged PR that is so important it can’t wait for
> 0.6?
> > > > > >
> > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > Date: December 29, 2015 at 11:54:35 PM
> > > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > > CC: dev@zeppelin.incubator.apache.org <
> > > > dev@zeppelin.incubator.apache.org
> > > > > >
> > > > > >
> > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > >
> > > > > > Okay, Amos,
> > > > > >
> > > > > > Do you propose Zeppelin should not have another release before
> fix
> > CI
> > > > > > issue? I think even though CI has some problems, another minors
> > fixes
> > > > is
> > > > > > meaningful to make a new minor release. Do you agree with that?
> Or
> > > > don't
> > > > > > you agree that it's enough? The main purpose of making a new
> minor
> > > > > release
> > > > > > should be whether already merged features are meaningful to make
> a
> > > > minor
> > > > > > release even if any major issues are on going, isn't it?
> > > > > >
> > > > > > Regards,
> > > > > > Jongyoul
> > > > > >
> > > > > > On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <
> > > amos.elberg@gmail.com
> > > > >
> > > > > > wrote:
> > > > > > Hah!
> > > > > >
> > > > > > I promise you, an hour after a 0.5.6 comes out, I will have
> emails
> > > > asking
> > > > > > me when I will support 0.5.6, even if no-one actually needs any
> > 0.5.6
> > > > > > changes or even knows what they are!
> > > > > >
> > > > > > I want to be clear though: My primary issue for 0.5.6 is not
> > whether
> > > to
> > > > > > merge the R interpreter.
> > > > > >
> > > > > > My issues are I think we need to fix CI in general, and I’m
> loathe
> > to
> > > > > have
> > > > > > more releases with that dammed spark-under-zeppelin code, which
> is
> > > the
> > > > > root
> > > > > > of many other issues.
> > > > > >
> > > > > >
> > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > Date: December 29, 2015 at 11:21:00 PM
> > > > > > To: Amos B. Elberg <am...@gmail.com>,
> > > > > > dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org
> > > >
> > > > > >
> > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > >
> > > > > > Okay, I understand your situation. If you rebased your PR from
> > > master,
> > > > > you
> > > > > > can rebased your PR only once but I also know why you had to do
> > > that. I
> > > > > > think R is a roadmap for 0.6.0 and you'd better skip rebasing
> > 0.5.6.
> > > > How
> > > > > > about you?
> > > > > >
> > > > > > On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <
> > > amos.elberg@gmail.com
> > > > >
> > > > > > wrote:
> > > > > > Jongyoul - the reason we have to rebase twice is that the changes
> > in
> > > > > > zeppelin-master will break the R interpreter.
> > > > > >
> > > > > > So I’ll have to rebase once so that I’m based off of 0.5.6 and
> > people
> > > > can
> > > > > > use the code. Then rebase again for 0.6.0.
> > > > > >
> > > > > > Remember, I have a user base I need to support — there are a lot
> of
> > > > > people
> > > > > > using the R interpreter now. So its not just a PR where I can
> > ignore
> > > it
> > > > > > until its ready to merge.
> > > > > >
> > > > > > The changes have already broken the shiro PR apparently quite
> > often.
> > > > > >
> > > > > > I made a “release” of the R Interpreter just so I could stop
> > rebasing
> > > > > > against Zeppelin master. I spent > 60 hours dealing with this for
> > the
> > > > > > changes leading up to 0.5 and 0.5.5.
> > > > > >
> > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > > Date: December 29, 2015 at 11:08:36 PM
> > > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > >
> > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > >
> > > > > > I don't know why you should rebased twice. If you can make a PR
> > from
> > > > > > current master, almost changes merged without rebasing and if a
> > > > committer
> > > > > > asks to rebase your PR, this is because you and another
> > contributors
> > > > > > changes the same codes and another contributions is merged before
> > > your
> > > > > PR.
> > > > > > In specific R case, Moon want you to rebase because he tries to
> fix
> > > the
> > > > > > testing codes so rebasing your PR will accepts their changes. In
> > most
> > > > > case,
> > > > > > contributors don't need to rebase their PR before merge because
> > > > committer
> > > > > > commit someone's PR by doing cherry-pick. We also felt sorry that
> > you
> > > > > were
> > > > > > bothered by testing issue and Moon is fighting to fix the testing
> > > > infra.
> > > > > > However all of PRs shouldn't be rebased.
> > > > > >
> > > > > > On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <
> > > > amos.elberg@gmail.com>
> > > > > > wrote:
> > > > > > I think there is no big pain because whole changes to be merged
> > > > > > into 0.5.6 will be also merged into 0.6.0.
> > > > > >
> > > > > > If we make another release now, the PRs will have to be rebased
> > > > *twice*,
> > > > > > once for 0.5.6, and once again for 0.6.
> > > > > >
> > > > > > Also - since this is now the second e-mail from a committer to do
> > the
> > > > > same
> > > > > > thing — is there a reason you guys are leaving R out of the
> agenda
> > > for
> > > > > the
> > > > > > next release? I understood the PR had been accepted and was
> pending
> > > > only
> > > > > > Moon fixing the testing infrastructure.
> > > > > >
> > > > > >
> > > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > > > dev@zeppelin.incubator.apache.org>
> > > > > > Date: December 29, 2015 at 10:56:33 PM
> > > > > >
> > > > > > To: dev@zeppelin.incubator.apache.org <
> > > > dev@zeppelin.incubator.apache.org
> > > > > >
> > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > >
> > > > > > Good idea!
> > > > > >
> > > > > > 0.5.6 is a minor release thus fixing minor bugs and typos is
> > enough.
> > > > But
> > > > > I
> > > > > > also think 0.6.0 should have major changes like supporting spark
> > 1.6
> > > > and
> > > > > > Shiro security and improving testing infra. And concerning
> rebasing
> > > and
> > > > > > committing, I think there is no big pain because whole changes to
> > be
> > > > > merged
> > > > > > into 0.5.6 will be also merged into 0.6.0.
> > > > > >
> > > > > > JL
> > > > > >
> > > > > > On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <
> > > > amos.elberg@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I don’t want to come off as the naysayer here, but I think the
> > > effort
> > > > > > that
> > > > > > > would go into a release would be better spent on the testing
> > > > > > infrastructure
> > > > > > > and outstanding PRs.
> > > > > > >
> > > > > > > If we feel we need a release for 1.6 and Ignite, I suggest we
> > make
> > > a
> > > > > > > release that *only* includes the absolute minimal changes
> > required
> > > to
> > > > > do
> > > > > > > that.
> > > > > > >
> > > > > > > There was one PR for 1.6 support that didn’t really work and is
> > > going
> > > > > to
> > > > > > > break anything built against the current codebase. Except for a
> > > > change
> > > > > in
> > > > > > > the name of one method called by one class, all of the changes
> > seem
> > > > to
> > > > > > > involve support for spark-under-zeppelin, which is something we
> > > want
> > > > to
> > > > > > > take out.
> > > > > > >
> > > > > > > We also don’t currently have a working testing framework. A lot
> > of
> > > > PRs
> > > > > > > have been committed under the “ignore travis its broken”
> theory.
> > > I’m
> > > > > > > loathe to make a release that hasn’t really been tested, and it
> > > > doesn’t
> > > > > > > seem we’re in a position to do that.
> > > > > > >
> > > > > > > While there have been a lot of merged PRs, I don’t think any of
> > > them
> > > > > are
> > > > > > > on-roadmap. They mostly seem to be very minor, like fixing
> typos
> > > and
> > > > > > > changing which text box gets highlighted. Those are important
> > > things,
> > > > > of
> > > > > > > course, but not major enough to justify the effort involved in
> a
> > > > > release.
> > > > > > >
> > > > > > > Another release will not make it easier to integrate the larger
> > > PRs.
> > > > It
> > > > > > > will have the opposite effect. Developers will have to rebase
> > > against
> > > > > > > whatever gets broken by 1.6 and other changes.
> > > > > > >
> > > > > > > I suggest we wait to do a significant release until we can take
> > out
> > > > the
> > > > > > > legacy spark-under-zeppelin code that has caused so many
> issues,
> > > > have a
> > > > > > > working testing framework, and integrate the major outstanding
> > PRs.
> > > > > > >
> > > > > > > So, again, if we want a release, I suggest we include the
> > absolute
> > > > > > minimum
> > > > > > > changes necessary for 1.6 and Ignite, and perhaps call it an
> > > interim
> > > > or
> > > > > > > maintenance release.
> > > > > > >
> > > > > > >
> > > > > > > From: Konstantin Boudnik <co...@apache.org>
> > > > > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > > > > dev@zeppelin.incubator.apache.org>,
> > > > dev@zeppelin.incubator.apache.org
> > > > > <
> > > > > > > dev@zeppelin.incubator.apache.org>
> > > > > > > Date: December 29, 2015 at 10:05:36 PM
> > > > > > > To: dev@zeppelin.incubator.apache.org <
> > > > > dev@zeppelin.incubator.apache.org
> > > > > > >
> > > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > > >
> > > > > > > Good idea! BTW, Apache Ignite is voting right now on
> 1.5.0.final
> > -
> > > > > would
> > > > > > > make
> > > > > > > sense to add this to the latest release of Zeppelin. I will
> open
> > a
> > > > JIRA
> > > > > > and
> > > > > > > supply a patch for it, if there's no objections.
> > > > > > >
> > > > > > > Cos
> > > > > > >
> > > > > > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > > > > > > Hi folks,
> > > > > > > >
> > > > > > > > How about we make release 0.5.6-incubating?
> > > > > > > >
> > > > > > > > Since last release, more than 100 pull requests are merged
> and
> > > more
> > > > > > than
> > > > > > > 80
> > > > > > > > issues are resolved.
> > > > > > > >
> > > > > > > > It's including new interpreters, a lot of new features and
> > > > > improvement
> > > > > > on
> > > > > > > > GUI with much improved stability thanks to lots of bug fixes.
> > > > > > > >
> > > > > > > > Also it's great time to have a Zeppelin release that support
> > > Spark
> > > > > 1.6
> > > > > > (
> > > > > > > > ZEPPELIN-395), which about to be released.
> > > > > > > >
> > > > > > > > Once we branch for 0.5.6-incubating release, it's more safe
> to
> > > make
> > > > > > large
> > > > > > > > code base change such as "Added Shiro security" (
> > > > > > > > https://github.com/apache/incubator-zeppelin/pull/53) and
> many
> > > > other
> > > > > > > > planned feature in 0.6.0 roadmap, that will require lots of
> > > > internal
> > > > > > API
> > > > > > > > updates.
> > > > > > > >
> > > > > > > > What do you think?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > moon
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > http://madeng.net
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > http://madeng.net
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > http://madeng.net
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > http://madeng.net
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > http://madeng.net
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > > http://madeng.net
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by moon soo Lee <mo...@apache.org>.
I've been release manager for 0.5.0-incubating and 0.5.5-incubating.
Any committer volunteer the release manager for 0.5.6-incubating release?

Thanks,
moon

On Mon, Jan 4, 2016 at 9:52 PM Alexander Bezzubov <bz...@apache.org> wrote:

> +1 for 0.5.6 release from maser
>
> On Wed, Dec 30, 2015 at 9:51 PM, Khalid Huseynov <kh...@nflabs.com>
> wrote:
>
> > +1 for 0.5.6 release with current improvements/fixes.
> >
> >
> > On Wed, Dec 30, 2015 at 4:10 PM, moon soo Lee <mo...@apache.org> wrote:
> >
> > > Amos,
> > >
> > > Who started the word "meaningful" is not important.
> > > Release discussion will not be judgement of how meaningful/major/big
> the
> > > contributions are.
> > >
> > > CI problem i have describe about R interpreter PR [1] is not related
> with
> > > any other contribution that we're trying to release.
> > >
> > > CI test does not have any known false negative, and we force
> contributor
> > > rerun the test until false positive disappear. So logically, we can
> > > guarantee that every contribution has passed the CI test correctly.
> > >
> > > Also Testis being done not only by CI but also all Zeppelin users.
> > > If users see serious problem in the release candidate, they'll block
> the
> > > release vote during release candidate verification.
> > >
> > > Hope this make you feel more confident about the code we're trying to
> > > release.
> > >
> > > Thanks,
> > > moon
> > >
> > > [1]
> > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/GitHub-incubator-zeppelin-pull-request-R-Interpreter-for-Zeppelin-tp956p4623.html
> > >
> > >
> > > On Tue, Dec 29, 2015 at 10:53 PM Amos B. Elberg <amos.elberg@gmail.com
> >
> > > wrote:
> > >
> > > > You did reply to both.  Let me try to clarify the problem with CI:
> > > >
> > > > The problem is *not* that particular PRs cause instability at
> runtime.
> > > >
> > > > The problem with CI is that if CI is not working properly, then *we
> > can’t
> > > > know* whether PRs will cause instability.  Or what that connects to
> > > > Zeppelin will break.
> > > >
> > > > CI is our own standard of testability.
> > > >
> > > > It is very common in organizations that they establish a standard of
> > > > reliability.  But, when things become difficult, or there is a
> problem
> > > with
> > > > the standard, the organization comes under pressure to bend or flex
> the
> > > > standard.
> > > >
> > > > In my experience, when organizations violate their own standards for
> > the
> > > > sake of expedience, it is a recipe for trouble 100% of the time.
> > > >
> > > > —
> > > >
> > > > I just reviewed the changes Jongyoul posted.  One of them relates to
> a
> > > bug
> > > > that was reported in September that has become an issue at Twitter.
> > That
> > > > seems to me to be a justification for a “hot fix” to the bug.
> > > >
> > > > I still don’t see any justification for a release though.
> > > >
> > > >
> > > > From: moon soo Lee <mo...@apache.org>
> > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > dev@zeppelin.incubator.apache.org>
> > > > Date: December 30, 2015 at 1:36:58 AM
> > > > To: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org
> > > >
> > > > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> > > >
> > > > Amos,
> > > >
> > > > If i summarize why you against 0.5.6-incubating release,
> > > >
> > > > * CI is not working
> > > > * Does not have meaningful or major features to be released
> > > >
> > > > these two, right? I replied answer for both of them
> > > >
> > > > Here
> > > >
> > > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4763.html
> > > > and here
> > > >
> > > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4765.html
> > > >
> > > > I'm listening and respect your opinion. Please check my reply and
> tell
> > me
> > > > if you have different opinion, but please include REASON WHY you
> think
> > in
> > > > that way otherwise it's hard to understand what you're thinking.
> > > >
> > > > Thanks,
> > > > moon
> > > >
> > > >
> > > > On Tue, Dec 29, 2015 at 10:18 PM Amos B. Elberg <
> amos.elberg@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Do you want me to explain the commits after 0.5.5 in details?
> > > > > I want you to provide an example of any feature that justifies the
> > > effort
> > > > > that will be put into making a release, delaying 0.6 and CI and
> > > > everything
> > > > > else, and rebasing the outstanding major PRs.
> > > > >
> > > > > I will settle for *one* example. Just one!
> > > > >
> > > > > And what is your answer that why minor release has a important
> > feature
> > > > and
> > > > > what the difference between major and minor is?
> > > > > My view is that a “minor” release is one that doesn’t require
> changes
> > > in
> > > > > code built against the release other than recompiling. “Major”
> means
> > > > > people have to work to update their code because of the release.
> > > > >
> > > > > I don't know why you oppose a new minor release including minor bug
> > > > fixes.
> > > > > I’m not even sure these count as “bug fixes” :p A change to the
> > shading
> > > > > of a window so it matches other windows is nice, but its hardly a
> > “bug
> > > > > fix.”
> > > > >
> > > > > Anyway I don’t think this release will really be limited to UI and
> > > > “minor”
> > > > > changes. I think there will be changes to the core code — like the
> > 1.6
> > > PR
> > > > > — that will actually be problems disguised as minor changes. And i
> > > don’t
> > > > > think we can test for that without CI.
> > > > >
> > > > > And What kind of aspects are less maintainable between 0.5.5 and
> > 0.5.6?
> > > > > The fact of the change is what makes it less maintainable!
> > > > >
> > > > > And what kind of fixes makes Zeppelin less stable?
> > > > > The *codebase* is definitely less stable.
> > > > >
> > > > > Do you believe that some PR is unstable because of failing CI?
> > > > >
> > > > > Since CI is failing, how do I know if any PRs are stable or not?
> > > > >
> > > > >
> > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > Date: December 30, 2015 at 1:05:55 AM
> > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > CC: dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org
> > > > >
> > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > >
> > > > > Do you want me to explain the commits after 0.5.5 in details? And
> > what
> > > is
> > > > > your answer that why minor release has a important feature and what
> > the
> > > > > difference between major and minor is? I also think it's good to
> fix
> > > > > version up for ignite but this is not a major feature. I don't know
> > why
> > > > > you oppose a new minor release including minor bug fixes. And What
> > kind
> > > > of
> > > > > aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6 is
> > less
> > > > > maintainable, we should revert that commit because it's harmful to
> > > > > Zeppelin. And what kind of fixes makes Zeppelin less stable? I
> would
> > > like
> > > > > to show me that commit number or issue number. And finally, Moon
> > > admitted
> > > > > CI had some flakey tests and have tried to remove or fix that
> tests.
> > Do
> > > > you
> > > > > believe that some PR is unstable because of failing CI?
> > > > >
> > > > > On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <
> > amos.elberg@gmail.com
> > > >
> > > > > wrote:
> > > > > A codebase that often changes in ways that break other code is an
> > > > unstable
> > > > > codebase, by definition.
> > > > >
> > > > > I don’t think it will be more stable at runtime, especially since
> CI
> > > > isn’t
> > > > > working.
> > > > >
> > > > > It definitely won’t be more maintainable. The key problematic code
> is
> > > > > still in.
> > > > >
> > > > > Other than Spark 1.6 and Ignite, I don’t see any reason at all for
> a
> > > > 0.5.6
> > > > > release. (Konstantin was right — it is good for Apache releases to
> > > > > maintain version compatibility with new versions of other Apache
> > > > software.
> > > > > That is Apache projects helping each other.)
> > > > >
> > > > > What feature do you feel justifies a 0.5.6 release? What feature
> > other
> > > > > than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
> > > > >
> > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > Date: December 30, 2015 at 12:32:01 AM
> > > > >
> > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > CC: dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org
> > > > >
> > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > >
> > > > > Amos,
> > > > >
> > > > > I don't think we have a strict plan for making a minor release and
> we
> > > > have
> > > > > a roadmap for major release. And ignite and Spark 1.6 is not a key
> > > > feature
> > > > > of 0.5.6. Konstantin just wanted to be merged that contribution if
> > that
> > > > > voting is finished until we make a release. And Spark 1.6 is on
> > going.
> > > As
> > > > > you told, we are an Apache project. 0.5.6 will be stable and
> > > > maintainable.
> > > > > If 0.5.6 has an experimental features, I don't agree to make a
> > release.
> > > > > 0.5.6 will be more stable version of 0.5.5. And of course, the most
> > > > people
> > > > > like more stable version. Isn't it enough?
> > > > >
> > > > > Regards,
> > > > > Jongyoul
> > > > >
> > > > > On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <
> > amos.elberg@gmail.com
> > > >
> > > > > wrote:
> > > > > My suggestion is that we do a 0.5.6 that just has the bare minimal
> > > > changes
> > > > > necessary for Spark 1.6 and Ignite and nothing else.
> > > > >
> > > > > That way we provide “must have” features while minimizing risk.
> > > > >
> > > > > Other than that, yes: I think we should keep our current release
> plan
> > > and
> > > > > not make a release for “nice to have” changes until CI is fixed.
> > > > >
> > > > > The main purpose of making a new minor release should be whether
> > > already
> > > > > merged features are meaningful to make a minor release even if any
> > > major
> > > > > issues are on going, isn't it?
> > > > >
> > > > > I’m not sure that I understand what you are asking.
> > > > >
> > > > > We have a planned 0.6 release. We just did an unplanned “minor”
> 0.5.5
> > > > > release. It feels like only a few weeks ago. I voted for it because
> > it
> > > > > seemed that it would stabilize the codebase and provide a
> > maintainable
> > > > > interim foundation.
> > > > >
> > > > > I do not think any of the features since 0.5.5 are “meaningful”
> > enough
> > > to
> > > > > justify changing the release plan. Not even close. I think it is
> rare
> > > > > that any off-roadmap “nice to have” feature would ever be a good
> > reason
> > > > to
> > > > > change a release plan. Especially when our CI “house” is not in
> > order.
> > > > >
> > > > > We’re an Apache project — we need to be stable, maintainable,
> > reliable,
> > > > > predictable.
> > > > >
> > > > > Is there any merged PR that is so important it can’t wait for 0.6?
> > > > >
> > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > Date: December 29, 2015 at 11:54:35 PM
> > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > > CC: dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org
> > > > >
> > > > >
> > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > >
> > > > > Okay, Amos,
> > > > >
> > > > > Do you propose Zeppelin should not have another release before fix
> CI
> > > > > issue? I think even though CI has some problems, another minors
> fixes
> > > is
> > > > > meaningful to make a new minor release. Do you agree with that? Or
> > > don't
> > > > > you agree that it's enough? The main purpose of making a new minor
> > > > release
> > > > > should be whether already merged features are meaningful to make a
> > > minor
> > > > > release even if any major issues are on going, isn't it?
> > > > >
> > > > > Regards,
> > > > > Jongyoul
> > > > >
> > > > > On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <
> > amos.elberg@gmail.com
> > > >
> > > > > wrote:
> > > > > Hah!
> > > > >
> > > > > I promise you, an hour after a 0.5.6 comes out, I will have emails
> > > asking
> > > > > me when I will support 0.5.6, even if no-one actually needs any
> 0.5.6
> > > > > changes or even knows what they are!
> > > > >
> > > > > I want to be clear though: My primary issue for 0.5.6 is not
> whether
> > to
> > > > > merge the R interpreter.
> > > > >
> > > > > My issues are I think we need to fix CI in general, and I’m loathe
> to
> > > > have
> > > > > more releases with that dammed spark-under-zeppelin code, which is
> > the
> > > > root
> > > > > of many other issues.
> > > > >
> > > > >
> > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > Date: December 29, 2015 at 11:21:00 PM
> > > > > To: Amos B. Elberg <am...@gmail.com>,
> > > > > dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org
> > >
> > > > >
> > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > >
> > > > > Okay, I understand your situation. If you rebased your PR from
> > master,
> > > > you
> > > > > can rebased your PR only once but I also know why you had to do
> > that. I
> > > > > think R is a roadmap for 0.6.0 and you'd better skip rebasing
> 0.5.6.
> > > How
> > > > > about you?
> > > > >
> > > > > On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <
> > amos.elberg@gmail.com
> > > >
> > > > > wrote:
> > > > > Jongyoul - the reason we have to rebase twice is that the changes
> in
> > > > > zeppelin-master will break the R interpreter.
> > > > >
> > > > > So I’ll have to rebase once so that I’m based off of 0.5.6 and
> people
> > > can
> > > > > use the code. Then rebase again for 0.6.0.
> > > > >
> > > > > Remember, I have a user base I need to support — there are a lot of
> > > > people
> > > > > using the R interpreter now. So its not just a PR where I can
> ignore
> > it
> > > > > until its ready to merge.
> > > > >
> > > > > The changes have already broken the shiro PR apparently quite
> often.
> > > > >
> > > > > I made a “release” of the R Interpreter just so I could stop
> rebasing
> > > > > against Zeppelin master. I spent > 60 hours dealing with this for
> the
> > > > > changes leading up to 0.5 and 0.5.5.
> > > > >
> > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > > Date: December 29, 2015 at 11:08:36 PM
> > > > > To: Amos B. Elberg <am...@gmail.com>
> > > > >
> > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > >
> > > > > I don't know why you should rebased twice. If you can make a PR
> from
> > > > > current master, almost changes merged without rebasing and if a
> > > committer
> > > > > asks to rebase your PR, this is because you and another
> contributors
> > > > > changes the same codes and another contributions is merged before
> > your
> > > > PR.
> > > > > In specific R case, Moon want you to rebase because he tries to fix
> > the
> > > > > testing codes so rebasing your PR will accepts their changes. In
> most
> > > > case,
> > > > > contributors don't need to rebase their PR before merge because
> > > committer
> > > > > commit someone's PR by doing cherry-pick. We also felt sorry that
> you
> > > > were
> > > > > bothered by testing issue and Moon is fighting to fix the testing
> > > infra.
> > > > > However all of PRs shouldn't be rebased.
> > > > >
> > > > > On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <
> > > amos.elberg@gmail.com>
> > > > > wrote:
> > > > > I think there is no big pain because whole changes to be merged
> > > > > into 0.5.6 will be also merged into 0.6.0.
> > > > >
> > > > > If we make another release now, the PRs will have to be rebased
> > > *twice*,
> > > > > once for 0.5.6, and once again for 0.6.
> > > > >
> > > > > Also - since this is now the second e-mail from a committer to do
> the
> > > > same
> > > > > thing — is there a reason you guys are leaving R out of the agenda
> > for
> > > > the
> > > > > next release? I understood the PR had been accepted and was pending
> > > only
> > > > > Moon fixing the testing infrastructure.
> > > > >
> > > > >
> > > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > > dev@zeppelin.incubator.apache.org>
> > > > > Date: December 29, 2015 at 10:56:33 PM
> > > > >
> > > > > To: dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org
> > > > >
> > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > >
> > > > > Good idea!
> > > > >
> > > > > 0.5.6 is a minor release thus fixing minor bugs and typos is
> enough.
> > > But
> > > > I
> > > > > also think 0.6.0 should have major changes like supporting spark
> 1.6
> > > and
> > > > > Shiro security and improving testing infra. And concerning rebasing
> > and
> > > > > committing, I think there is no big pain because whole changes to
> be
> > > > merged
> > > > > into 0.5.6 will be also merged into 0.6.0.
> > > > >
> > > > > JL
> > > > >
> > > > > On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <
> > > amos.elberg@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I don’t want to come off as the naysayer here, but I think the
> > effort
> > > > > that
> > > > > > would go into a release would be better spent on the testing
> > > > > infrastructure
> > > > > > and outstanding PRs.
> > > > > >
> > > > > > If we feel we need a release for 1.6 and Ignite, I suggest we
> make
> > a
> > > > > > release that *only* includes the absolute minimal changes
> required
> > to
> > > > do
> > > > > > that.
> > > > > >
> > > > > > There was one PR for 1.6 support that didn’t really work and is
> > going
> > > > to
> > > > > > break anything built against the current codebase. Except for a
> > > change
> > > > in
> > > > > > the name of one method called by one class, all of the changes
> seem
> > > to
> > > > > > involve support for spark-under-zeppelin, which is something we
> > want
> > > to
> > > > > > take out.
> > > > > >
> > > > > > We also don’t currently have a working testing framework. A lot
> of
> > > PRs
> > > > > > have been committed under the “ignore travis its broken” theory.
> > I’m
> > > > > > loathe to make a release that hasn’t really been tested, and it
> > > doesn’t
> > > > > > seem we’re in a position to do that.
> > > > > >
> > > > > > While there have been a lot of merged PRs, I don’t think any of
> > them
> > > > are
> > > > > > on-roadmap. They mostly seem to be very minor, like fixing typos
> > and
> > > > > > changing which text box gets highlighted. Those are important
> > things,
> > > > of
> > > > > > course, but not major enough to justify the effort involved in a
> > > > release.
> > > > > >
> > > > > > Another release will not make it easier to integrate the larger
> > PRs.
> > > It
> > > > > > will have the opposite effect. Developers will have to rebase
> > against
> > > > > > whatever gets broken by 1.6 and other changes.
> > > > > >
> > > > > > I suggest we wait to do a significant release until we can take
> out
> > > the
> > > > > > legacy spark-under-zeppelin code that has caused so many issues,
> > > have a
> > > > > > working testing framework, and integrate the major outstanding
> PRs.
> > > > > >
> > > > > > So, again, if we want a release, I suggest we include the
> absolute
> > > > > minimum
> > > > > > changes necessary for 1.6 and Ignite, and perhaps call it an
> > interim
> > > or
> > > > > > maintenance release.
> > > > > >
> > > > > >
> > > > > > From: Konstantin Boudnik <co...@apache.org>
> > > > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > > > dev@zeppelin.incubator.apache.org>,
> > > dev@zeppelin.incubator.apache.org
> > > > <
> > > > > > dev@zeppelin.incubator.apache.org>
> > > > > > Date: December 29, 2015 at 10:05:36 PM
> > > > > > To: dev@zeppelin.incubator.apache.org <
> > > > dev@zeppelin.incubator.apache.org
> > > > > >
> > > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > > >
> > > > > > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final
> -
> > > > would
> > > > > > make
> > > > > > sense to add this to the latest release of Zeppelin. I will open
> a
> > > JIRA
> > > > > and
> > > > > > supply a patch for it, if there's no objections.
> > > > > >
> > > > > > Cos
> > > > > >
> > > > > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > > > > > Hi folks,
> > > > > > >
> > > > > > > How about we make release 0.5.6-incubating?
> > > > > > >
> > > > > > > Since last release, more than 100 pull requests are merged and
> > more
> > > > > than
> > > > > > 80
> > > > > > > issues are resolved.
> > > > > > >
> > > > > > > It's including new interpreters, a lot of new features and
> > > > improvement
> > > > > on
> > > > > > > GUI with much improved stability thanks to lots of bug fixes.
> > > > > > >
> > > > > > > Also it's great time to have a Zeppelin release that support
> > Spark
> > > > 1.6
> > > > > (
> > > > > > > ZEPPELIN-395), which about to be released.
> > > > > > >
> > > > > > > Once we branch for 0.5.6-incubating release, it's more safe to
> > make
> > > > > large
> > > > > > > code base change such as "Added Shiro security" (
> > > > > > > https://github.com/apache/incubator-zeppelin/pull/53) and many
> > > other
> > > > > > > planned feature in 0.6.0 roadmap, that will require lots of
> > > internal
> > > > > API
> > > > > > > updates.
> > > > > > >
> > > > > > > What do you think?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > moon
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > http://madeng.net
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > http://madeng.net
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > http://madeng.net
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > http://madeng.net
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > http://madeng.net
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 이종열, Jongyoul Lee, 李宗烈
> > > > > http://madeng.net
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Alexander Bezzubov <bz...@apache.org>.
+1 for 0.5.6 release from maser

On Wed, Dec 30, 2015 at 9:51 PM, Khalid Huseynov <kh...@nflabs.com>
wrote:

> +1 for 0.5.6 release with current improvements/fixes.
>
>
> On Wed, Dec 30, 2015 at 4:10 PM, moon soo Lee <mo...@apache.org> wrote:
>
> > Amos,
> >
> > Who started the word "meaningful" is not important.
> > Release discussion will not be judgement of how meaningful/major/big the
> > contributions are.
> >
> > CI problem i have describe about R interpreter PR [1] is not related with
> > any other contribution that we're trying to release.
> >
> > CI test does not have any known false negative, and we force contributor
> > rerun the test until false positive disappear. So logically, we can
> > guarantee that every contribution has passed the CI test correctly.
> >
> > Also Testis being done not only by CI but also all Zeppelin users.
> > If users see serious problem in the release candidate, they'll block the
> > release vote during release candidate verification.
> >
> > Hope this make you feel more confident about the code we're trying to
> > release.
> >
> > Thanks,
> > moon
> >
> > [1]
> >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/GitHub-incubator-zeppelin-pull-request-R-Interpreter-for-Zeppelin-tp956p4623.html
> >
> >
> > On Tue, Dec 29, 2015 at 10:53 PM Amos B. Elberg <am...@gmail.com>
> > wrote:
> >
> > > You did reply to both.  Let me try to clarify the problem with CI:
> > >
> > > The problem is *not* that particular PRs cause instability at runtime.
> > >
> > > The problem with CI is that if CI is not working properly, then *we
> can’t
> > > know* whether PRs will cause instability.  Or what that connects to
> > > Zeppelin will break.
> > >
> > > CI is our own standard of testability.
> > >
> > > It is very common in organizations that they establish a standard of
> > > reliability.  But, when things become difficult, or there is a problem
> > with
> > > the standard, the organization comes under pressure to bend or flex the
> > > standard.
> > >
> > > In my experience, when organizations violate their own standards for
> the
> > > sake of expedience, it is a recipe for trouble 100% of the time.
> > >
> > > —
> > >
> > > I just reviewed the changes Jongyoul posted.  One of them relates to a
> > bug
> > > that was reported in September that has become an issue at Twitter.
> That
> > > seems to me to be a justification for a “hot fix” to the bug.
> > >
> > > I still don’t see any justification for a release though.
> > >
> > >
> > > From: moon soo Lee <mo...@apache.org>
> > > Reply: dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org>
> > > Date: December 30, 2015 at 1:36:58 AM
> > > To: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org
> > >
> > > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> > >
> > > Amos,
> > >
> > > If i summarize why you against 0.5.6-incubating release,
> > >
> > > * CI is not working
> > > * Does not have meaningful or major features to be released
> > >
> > > these two, right? I replied answer for both of them
> > >
> > > Here
> > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4763.html
> > > and here
> > >
> > >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4765.html
> > >
> > > I'm listening and respect your opinion. Please check my reply and tell
> me
> > > if you have different opinion, but please include REASON WHY you think
> in
> > > that way otherwise it's hard to understand what you're thinking.
> > >
> > > Thanks,
> > > moon
> > >
> > >
> > > On Tue, Dec 29, 2015 at 10:18 PM Amos B. Elberg <amos.elberg@gmail.com
> >
> > > wrote:
> > >
> > > > Do you want me to explain the commits after 0.5.5 in details?
> > > > I want you to provide an example of any feature that justifies the
> > effort
> > > > that will be put into making a release, delaying 0.6 and CI and
> > > everything
> > > > else, and rebasing the outstanding major PRs.
> > > >
> > > > I will settle for *one* example. Just one!
> > > >
> > > > And what is your answer that why minor release has a important
> feature
> > > and
> > > > what the difference between major and minor is?
> > > > My view is that a “minor” release is one that doesn’t require changes
> > in
> > > > code built against the release other than recompiling. “Major” means
> > > > people have to work to update their code because of the release.
> > > >
> > > > I don't know why you oppose a new minor release including minor bug
> > > fixes.
> > > > I’m not even sure these count as “bug fixes” :p A change to the
> shading
> > > > of a window so it matches other windows is nice, but its hardly a
> “bug
> > > > fix.”
> > > >
> > > > Anyway I don’t think this release will really be limited to UI and
> > > “minor”
> > > > changes. I think there will be changes to the core code — like the
> 1.6
> > PR
> > > > — that will actually be problems disguised as minor changes. And i
> > don’t
> > > > think we can test for that without CI.
> > > >
> > > > And What kind of aspects are less maintainable between 0.5.5 and
> 0.5.6?
> > > > The fact of the change is what makes it less maintainable!
> > > >
> > > > And what kind of fixes makes Zeppelin less stable?
> > > > The *codebase* is definitely less stable.
> > > >
> > > > Do you believe that some PR is unstable because of failing CI?
> > > >
> > > > Since CI is failing, how do I know if any PRs are stable or not?
> > > >
> > > >
> > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > Date: December 30, 2015 at 1:05:55 AM
> > > > To: Amos B. Elberg <am...@gmail.com>
> > > > CC: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org
> > > >
> > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > >
> > > > Do you want me to explain the commits after 0.5.5 in details? And
> what
> > is
> > > > your answer that why minor release has a important feature and what
> the
> > > > difference between major and minor is? I also think it's good to fix
> > > > version up for ignite but this is not a major feature. I don't know
> why
> > > > you oppose a new minor release including minor bug fixes. And What
> kind
> > > of
> > > > aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6 is
> less
> > > > maintainable, we should revert that commit because it's harmful to
> > > > Zeppelin. And what kind of fixes makes Zeppelin less stable? I would
> > like
> > > > to show me that commit number or issue number. And finally, Moon
> > admitted
> > > > CI had some flakey tests and have tried to remove or fix that tests.
> Do
> > > you
> > > > believe that some PR is unstable because of failing CI?
> > > >
> > > > On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <
> amos.elberg@gmail.com
> > >
> > > > wrote:
> > > > A codebase that often changes in ways that break other code is an
> > > unstable
> > > > codebase, by definition.
> > > >
> > > > I don’t think it will be more stable at runtime, especially since CI
> > > isn’t
> > > > working.
> > > >
> > > > It definitely won’t be more maintainable. The key problematic code is
> > > > still in.
> > > >
> > > > Other than Spark 1.6 and Ignite, I don’t see any reason at all for a
> > > 0.5.6
> > > > release. (Konstantin was right — it is good for Apache releases to
> > > > maintain version compatibility with new versions of other Apache
> > > software.
> > > > That is Apache projects helping each other.)
> > > >
> > > > What feature do you feel justifies a 0.5.6 release? What feature
> other
> > > > than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
> > > >
> > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > Date: December 30, 2015 at 12:32:01 AM
> > > >
> > > > To: Amos B. Elberg <am...@gmail.com>
> > > > CC: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org
> > > >
> > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > >
> > > > Amos,
> > > >
> > > > I don't think we have a strict plan for making a minor release and we
> > > have
> > > > a roadmap for major release. And ignite and Spark 1.6 is not a key
> > > feature
> > > > of 0.5.6. Konstantin just wanted to be merged that contribution if
> that
> > > > voting is finished until we make a release. And Spark 1.6 is on
> going.
> > As
> > > > you told, we are an Apache project. 0.5.6 will be stable and
> > > maintainable.
> > > > If 0.5.6 has an experimental features, I don't agree to make a
> release.
> > > > 0.5.6 will be more stable version of 0.5.5. And of course, the most
> > > people
> > > > like more stable version. Isn't it enough?
> > > >
> > > > Regards,
> > > > Jongyoul
> > > >
> > > > On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <
> amos.elberg@gmail.com
> > >
> > > > wrote:
> > > > My suggestion is that we do a 0.5.6 that just has the bare minimal
> > > changes
> > > > necessary for Spark 1.6 and Ignite and nothing else.
> > > >
> > > > That way we provide “must have” features while minimizing risk.
> > > >
> > > > Other than that, yes: I think we should keep our current release plan
> > and
> > > > not make a release for “nice to have” changes until CI is fixed.
> > > >
> > > > The main purpose of making a new minor release should be whether
> > already
> > > > merged features are meaningful to make a minor release even if any
> > major
> > > > issues are on going, isn't it?
> > > >
> > > > I’m not sure that I understand what you are asking.
> > > >
> > > > We have a planned 0.6 release. We just did an unplanned “minor” 0.5.5
> > > > release. It feels like only a few weeks ago. I voted for it because
> it
> > > > seemed that it would stabilize the codebase and provide a
> maintainable
> > > > interim foundation.
> > > >
> > > > I do not think any of the features since 0.5.5 are “meaningful”
> enough
> > to
> > > > justify changing the release plan. Not even close. I think it is rare
> > > > that any off-roadmap “nice to have” feature would ever be a good
> reason
> > > to
> > > > change a release plan. Especially when our CI “house” is not in
> order.
> > > >
> > > > We’re an Apache project — we need to be stable, maintainable,
> reliable,
> > > > predictable.
> > > >
> > > > Is there any merged PR that is so important it can’t wait for 0.6?
> > > >
> > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > Date: December 29, 2015 at 11:54:35 PM
> > > > To: Amos B. Elberg <am...@gmail.com>
> > > > CC: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org
> > > >
> > > >
> > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > >
> > > > Okay, Amos,
> > > >
> > > > Do you propose Zeppelin should not have another release before fix CI
> > > > issue? I think even though CI has some problems, another minors fixes
> > is
> > > > meaningful to make a new minor release. Do you agree with that? Or
> > don't
> > > > you agree that it's enough? The main purpose of making a new minor
> > > release
> > > > should be whether already merged features are meaningful to make a
> > minor
> > > > release even if any major issues are on going, isn't it?
> > > >
> > > > Regards,
> > > > Jongyoul
> > > >
> > > > On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <
> amos.elberg@gmail.com
> > >
> > > > wrote:
> > > > Hah!
> > > >
> > > > I promise you, an hour after a 0.5.6 comes out, I will have emails
> > asking
> > > > me when I will support 0.5.6, even if no-one actually needs any 0.5.6
> > > > changes or even knows what they are!
> > > >
> > > > I want to be clear though: My primary issue for 0.5.6 is not whether
> to
> > > > merge the R interpreter.
> > > >
> > > > My issues are I think we need to fix CI in general, and I’m loathe to
> > > have
> > > > more releases with that dammed spark-under-zeppelin code, which is
> the
> > > root
> > > > of many other issues.
> > > >
> > > >
> > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > Date: December 29, 2015 at 11:21:00 PM
> > > > To: Amos B. Elberg <am...@gmail.com>,
> > > > dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > > >
> > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > >
> > > > Okay, I understand your situation. If you rebased your PR from
> master,
> > > you
> > > > can rebased your PR only once but I also know why you had to do
> that. I
> > > > think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6.
> > How
> > > > about you?
> > > >
> > > > On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <
> amos.elberg@gmail.com
> > >
> > > > wrote:
> > > > Jongyoul - the reason we have to rebase twice is that the changes in
> > > > zeppelin-master will break the R interpreter.
> > > >
> > > > So I’ll have to rebase once so that I’m based off of 0.5.6 and people
> > can
> > > > use the code. Then rebase again for 0.6.0.
> > > >
> > > > Remember, I have a user base I need to support — there are a lot of
> > > people
> > > > using the R interpreter now. So its not just a PR where I can ignore
> it
> > > > until its ready to merge.
> > > >
> > > > The changes have already broken the shiro PR apparently quite often.
> > > >
> > > > I made a “release” of the R Interpreter just so I could stop rebasing
> > > > against Zeppelin master. I spent > 60 hours dealing with this for the
> > > > changes leading up to 0.5 and 0.5.5.
> > > >
> > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > > Date: December 29, 2015 at 11:08:36 PM
> > > > To: Amos B. Elberg <am...@gmail.com>
> > > >
> > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > >
> > > > I don't know why you should rebased twice. If you can make a PR from
> > > > current master, almost changes merged without rebasing and if a
> > committer
> > > > asks to rebase your PR, this is because you and another contributors
> > > > changes the same codes and another contributions is merged before
> your
> > > PR.
> > > > In specific R case, Moon want you to rebase because he tries to fix
> the
> > > > testing codes so rebasing your PR will accepts their changes. In most
> > > case,
> > > > contributors don't need to rebase their PR before merge because
> > committer
> > > > commit someone's PR by doing cherry-pick. We also felt sorry that you
> > > were
> > > > bothered by testing issue and Moon is fighting to fix the testing
> > infra.
> > > > However all of PRs shouldn't be rebased.
> > > >
> > > > On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <
> > amos.elberg@gmail.com>
> > > > wrote:
> > > > I think there is no big pain because whole changes to be merged
> > > > into 0.5.6 will be also merged into 0.6.0.
> > > >
> > > > If we make another release now, the PRs will have to be rebased
> > *twice*,
> > > > once for 0.5.6, and once again for 0.6.
> > > >
> > > > Also - since this is now the second e-mail from a committer to do the
> > > same
> > > > thing — is there a reason you guys are leaving R out of the agenda
> for
> > > the
> > > > next release? I understood the PR had been accepted and was pending
> > only
> > > > Moon fixing the testing infrastructure.
> > > >
> > > >
> > > > From: Jongyoul Lee <jo...@gmail.com>
> > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > dev@zeppelin.incubator.apache.org>
> > > > Date: December 29, 2015 at 10:56:33 PM
> > > >
> > > > To: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org
> > > >
> > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > >
> > > > Good idea!
> > > >
> > > > 0.5.6 is a minor release thus fixing minor bugs and typos is enough.
> > But
> > > I
> > > > also think 0.6.0 should have major changes like supporting spark 1.6
> > and
> > > > Shiro security and improving testing infra. And concerning rebasing
> and
> > > > committing, I think there is no big pain because whole changes to be
> > > merged
> > > > into 0.5.6 will be also merged into 0.6.0.
> > > >
> > > > JL
> > > >
> > > > On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <
> > amos.elberg@gmail.com>
> > > > wrote:
> > > >
> > > > > I don’t want to come off as the naysayer here, but I think the
> effort
> > > > that
> > > > > would go into a release would be better spent on the testing
> > > > infrastructure
> > > > > and outstanding PRs.
> > > > >
> > > > > If we feel we need a release for 1.6 and Ignite, I suggest we make
> a
> > > > > release that *only* includes the absolute minimal changes required
> to
> > > do
> > > > > that.
> > > > >
> > > > > There was one PR for 1.6 support that didn’t really work and is
> going
> > > to
> > > > > break anything built against the current codebase. Except for a
> > change
> > > in
> > > > > the name of one method called by one class, all of the changes seem
> > to
> > > > > involve support for spark-under-zeppelin, which is something we
> want
> > to
> > > > > take out.
> > > > >
> > > > > We also don’t currently have a working testing framework. A lot of
> > PRs
> > > > > have been committed under the “ignore travis its broken” theory.
> I’m
> > > > > loathe to make a release that hasn’t really been tested, and it
> > doesn’t
> > > > > seem we’re in a position to do that.
> > > > >
> > > > > While there have been a lot of merged PRs, I don’t think any of
> them
> > > are
> > > > > on-roadmap. They mostly seem to be very minor, like fixing typos
> and
> > > > > changing which text box gets highlighted. Those are important
> things,
> > > of
> > > > > course, but not major enough to justify the effort involved in a
> > > release.
> > > > >
> > > > > Another release will not make it easier to integrate the larger
> PRs.
> > It
> > > > > will have the opposite effect. Developers will have to rebase
> against
> > > > > whatever gets broken by 1.6 and other changes.
> > > > >
> > > > > I suggest we wait to do a significant release until we can take out
> > the
> > > > > legacy spark-under-zeppelin code that has caused so many issues,
> > have a
> > > > > working testing framework, and integrate the major outstanding PRs.
> > > > >
> > > > > So, again, if we want a release, I suggest we include the absolute
> > > > minimum
> > > > > changes necessary for 1.6 and Ignite, and perhaps call it an
> interim
> > or
> > > > > maintenance release.
> > > > >
> > > > >
> > > > > From: Konstantin Boudnik <co...@apache.org>
> > > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > > dev@zeppelin.incubator.apache.org>,
> > dev@zeppelin.incubator.apache.org
> > > <
> > > > > dev@zeppelin.incubator.apache.org>
> > > > > Date: December 29, 2015 at 10:05:36 PM
> > > > > To: dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org
> > > > >
> > > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > > >
> > > > > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -
> > > would
> > > > > make
> > > > > sense to add this to the latest release of Zeppelin. I will open a
> > JIRA
> > > > and
> > > > > supply a patch for it, if there's no objections.
> > > > >
> > > > > Cos
> > > > >
> > > > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > > > > Hi folks,
> > > > > >
> > > > > > How about we make release 0.5.6-incubating?
> > > > > >
> > > > > > Since last release, more than 100 pull requests are merged and
> more
> > > > than
> > > > > 80
> > > > > > issues are resolved.
> > > > > >
> > > > > > It's including new interpreters, a lot of new features and
> > > improvement
> > > > on
> > > > > > GUI with much improved stability thanks to lots of bug fixes.
> > > > > >
> > > > > > Also it's great time to have a Zeppelin release that support
> Spark
> > > 1.6
> > > > (
> > > > > > ZEPPELIN-395), which about to be released.
> > > > > >
> > > > > > Once we branch for 0.5.6-incubating release, it's more safe to
> make
> > > > large
> > > > > > code base change such as "Added Shiro security" (
> > > > > > https://github.com/apache/incubator-zeppelin/pull/53) and many
> > other
> > > > > > planned feature in 0.6.0 roadmap, that will require lots of
> > internal
> > > > API
> > > > > > updates.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > Thanks,
> > > > > > moon
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 이종열, Jongyoul Lee, 李宗烈
> > > > http://madeng.net
> > > >
> > > >
> > > >
> > > > --
> > > > 이종열, Jongyoul Lee, 李宗烈
> > > > http://madeng.net
> > > >
> > > >
> > > >
> > > > --
> > > > 이종열, Jongyoul Lee, 李宗烈
> > > > http://madeng.net
> > > >
> > > >
> > > >
> > > > --
> > > > 이종열, Jongyoul Lee, 李宗烈
> > > > http://madeng.net
> > > >
> > > >
> > > >
> > > > --
> > > > 이종열, Jongyoul Lee, 李宗烈
> > > > http://madeng.net
> > > >
> > > >
> > > >
> > > > --
> > > > 이종열, Jongyoul Lee, 李宗烈
> > > > http://madeng.net
> > > >
> > >
> >
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Khalid Huseynov <kh...@nflabs.com>.
+1 for 0.5.6 release with current improvements/fixes.


On Wed, Dec 30, 2015 at 4:10 PM, moon soo Lee <mo...@apache.org> wrote:

> Amos,
>
> Who started the word "meaningful" is not important.
> Release discussion will not be judgement of how meaningful/major/big the
> contributions are.
>
> CI problem i have describe about R interpreter PR [1] is not related with
> any other contribution that we're trying to release.
>
> CI test does not have any known false negative, and we force contributor
> rerun the test until false positive disappear. So logically, we can
> guarantee that every contribution has passed the CI test correctly.
>
> Also Testis being done not only by CI but also all Zeppelin users.
> If users see serious problem in the release candidate, they'll block the
> release vote during release candidate verification.
>
> Hope this make you feel more confident about the code we're trying to
> release.
>
> Thanks,
> moon
>
> [1]
>
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/GitHub-incubator-zeppelin-pull-request-R-Interpreter-for-Zeppelin-tp956p4623.html
>
>
> On Tue, Dec 29, 2015 at 10:53 PM Amos B. Elberg <am...@gmail.com>
> wrote:
>
> > You did reply to both.  Let me try to clarify the problem with CI:
> >
> > The problem is *not* that particular PRs cause instability at runtime.
> >
> > The problem with CI is that if CI is not working properly, then *we can’t
> > know* whether PRs will cause instability.  Or what that connects to
> > Zeppelin will break.
> >
> > CI is our own standard of testability.
> >
> > It is very common in organizations that they establish a standard of
> > reliability.  But, when things become difficult, or there is a problem
> with
> > the standard, the organization comes under pressure to bend or flex the
> > standard.
> >
> > In my experience, when organizations violate their own standards for the
> > sake of expedience, it is a recipe for trouble 100% of the time.
> >
> > —
> >
> > I just reviewed the changes Jongyoul posted.  One of them relates to a
> bug
> > that was reported in September that has become an issue at Twitter.  That
> > seems to me to be a justification for a “hot fix” to the bug.
> >
> > I still don’t see any justification for a release though.
> >
> >
> > From: moon soo Lee <mo...@apache.org>
> > Reply: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>
> > Date: December 30, 2015 at 1:36:58 AM
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Amos,
> >
> > If i summarize why you against 0.5.6-incubating release,
> >
> > * CI is not working
> > * Does not have meaningful or major features to be released
> >
> > these two, right? I replied answer for both of them
> >
> > Here
> >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4763.html
> > and here
> >
> >
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4765.html
> >
> > I'm listening and respect your opinion. Please check my reply and tell me
> > if you have different opinion, but please include REASON WHY you think in
> > that way otherwise it's hard to understand what you're thinking.
> >
> > Thanks,
> > moon
> >
> >
> > On Tue, Dec 29, 2015 at 10:18 PM Amos B. Elberg <am...@gmail.com>
> > wrote:
> >
> > > Do you want me to explain the commits after 0.5.5 in details?
> > > I want you to provide an example of any feature that justifies the
> effort
> > > that will be put into making a release, delaying 0.6 and CI and
> > everything
> > > else, and rebasing the outstanding major PRs.
> > >
> > > I will settle for *one* example. Just one!
> > >
> > > And what is your answer that why minor release has a important feature
> > and
> > > what the difference between major and minor is?
> > > My view is that a “minor” release is one that doesn’t require changes
> in
> > > code built against the release other than recompiling. “Major” means
> > > people have to work to update their code because of the release.
> > >
> > > I don't know why you oppose a new minor release including minor bug
> > fixes.
> > > I’m not even sure these count as “bug fixes” :p A change to the shading
> > > of a window so it matches other windows is nice, but its hardly a “bug
> > > fix.”
> > >
> > > Anyway I don’t think this release will really be limited to UI and
> > “minor”
> > > changes. I think there will be changes to the core code — like the 1.6
> PR
> > > — that will actually be problems disguised as minor changes. And i
> don’t
> > > think we can test for that without CI.
> > >
> > > And What kind of aspects are less maintainable between 0.5.5 and 0.5.6?
> > > The fact of the change is what makes it less maintainable!
> > >
> > > And what kind of fixes makes Zeppelin less stable?
> > > The *codebase* is definitely less stable.
> > >
> > > Do you believe that some PR is unstable because of failing CI?
> > >
> > > Since CI is failing, how do I know if any PRs are stable or not?
> > >
> > >
> > > From: Jongyoul Lee <jo...@gmail.com>
> > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > Date: December 30, 2015 at 1:05:55 AM
> > > To: Amos B. Elberg <am...@gmail.com>
> > > CC: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org
> > >
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > >
> > > Do you want me to explain the commits after 0.5.5 in details? And what
> is
> > > your answer that why minor release has a important feature and what the
> > > difference between major and minor is? I also think it's good to fix
> > > version up for ignite but this is not a major feature. I don't know why
> > > you oppose a new minor release including minor bug fixes. And What kind
> > of
> > > aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6 is less
> > > maintainable, we should revert that commit because it's harmful to
> > > Zeppelin. And what kind of fixes makes Zeppelin less stable? I would
> like
> > > to show me that commit number or issue number. And finally, Moon
> admitted
> > > CI had some flakey tests and have tried to remove or fix that tests. Do
> > you
> > > believe that some PR is unstable because of failing CI?
> > >
> > > On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <amos.elberg@gmail.com
> >
> > > wrote:
> > > A codebase that often changes in ways that break other code is an
> > unstable
> > > codebase, by definition.
> > >
> > > I don’t think it will be more stable at runtime, especially since CI
> > isn’t
> > > working.
> > >
> > > It definitely won’t be more maintainable. The key problematic code is
> > > still in.
> > >
> > > Other than Spark 1.6 and Ignite, I don’t see any reason at all for a
> > 0.5.6
> > > release. (Konstantin was right — it is good for Apache releases to
> > > maintain version compatibility with new versions of other Apache
> > software.
> > > That is Apache projects helping each other.)
> > >
> > > What feature do you feel justifies a 0.5.6 release? What feature other
> > > than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
> > >
> > > From: Jongyoul Lee <jo...@gmail.com>
> > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > Date: December 30, 2015 at 12:32:01 AM
> > >
> > > To: Amos B. Elberg <am...@gmail.com>
> > > CC: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org
> > >
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > >
> > > Amos,
> > >
> > > I don't think we have a strict plan for making a minor release and we
> > have
> > > a roadmap for major release. And ignite and Spark 1.6 is not a key
> > feature
> > > of 0.5.6. Konstantin just wanted to be merged that contribution if that
> > > voting is finished until we make a release. And Spark 1.6 is on going.
> As
> > > you told, we are an Apache project. 0.5.6 will be stable and
> > maintainable.
> > > If 0.5.6 has an experimental features, I don't agree to make a release.
> > > 0.5.6 will be more stable version of 0.5.5. And of course, the most
> > people
> > > like more stable version. Isn't it enough?
> > >
> > > Regards,
> > > Jongyoul
> > >
> > > On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <amos.elberg@gmail.com
> >
> > > wrote:
> > > My suggestion is that we do a 0.5.6 that just has the bare minimal
> > changes
> > > necessary for Spark 1.6 and Ignite and nothing else.
> > >
> > > That way we provide “must have” features while minimizing risk.
> > >
> > > Other than that, yes: I think we should keep our current release plan
> and
> > > not make a release for “nice to have” changes until CI is fixed.
> > >
> > > The main purpose of making a new minor release should be whether
> already
> > > merged features are meaningful to make a minor release even if any
> major
> > > issues are on going, isn't it?
> > >
> > > I’m not sure that I understand what you are asking.
> > >
> > > We have a planned 0.6 release. We just did an unplanned “minor” 0.5.5
> > > release. It feels like only a few weeks ago. I voted for it because it
> > > seemed that it would stabilize the codebase and provide a maintainable
> > > interim foundation.
> > >
> > > I do not think any of the features since 0.5.5 are “meaningful” enough
> to
> > > justify changing the release plan. Not even close. I think it is rare
> > > that any off-roadmap “nice to have” feature would ever be a good reason
> > to
> > > change a release plan. Especially when our CI “house” is not in order.
> > >
> > > We’re an Apache project — we need to be stable, maintainable, reliable,
> > > predictable.
> > >
> > > Is there any merged PR that is so important it can’t wait for 0.6?
> > >
> > > From: Jongyoul Lee <jo...@gmail.com>
> > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > Date: December 29, 2015 at 11:54:35 PM
> > > To: Amos B. Elberg <am...@gmail.com>
> > > CC: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org
> > >
> > >
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > >
> > > Okay, Amos,
> > >
> > > Do you propose Zeppelin should not have another release before fix CI
> > > issue? I think even though CI has some problems, another minors fixes
> is
> > > meaningful to make a new minor release. Do you agree with that? Or
> don't
> > > you agree that it's enough? The main purpose of making a new minor
> > release
> > > should be whether already merged features are meaningful to make a
> minor
> > > release even if any major issues are on going, isn't it?
> > >
> > > Regards,
> > > Jongyoul
> > >
> > > On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <amos.elberg@gmail.com
> >
> > > wrote:
> > > Hah!
> > >
> > > I promise you, an hour after a 0.5.6 comes out, I will have emails
> asking
> > > me when I will support 0.5.6, even if no-one actually needs any 0.5.6
> > > changes or even knows what they are!
> > >
> > > I want to be clear though: My primary issue for 0.5.6 is not whether to
> > > merge the R interpreter.
> > >
> > > My issues are I think we need to fix CI in general, and I’m loathe to
> > have
> > > more releases with that dammed spark-under-zeppelin code, which is the
> > root
> > > of many other issues.
> > >
> > >
> > > From: Jongyoul Lee <jo...@gmail.com>
> > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > Date: December 29, 2015 at 11:21:00 PM
> > > To: Amos B. Elberg <am...@gmail.com>,
> > > dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> > >
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > >
> > > Okay, I understand your situation. If you rebased your PR from master,
> > you
> > > can rebased your PR only once but I also know why you had to do that. I
> > > think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6.
> How
> > > about you?
> > >
> > > On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <amos.elberg@gmail.com
> >
> > > wrote:
> > > Jongyoul - the reason we have to rebase twice is that the changes in
> > > zeppelin-master will break the R interpreter.
> > >
> > > So I’ll have to rebase once so that I’m based off of 0.5.6 and people
> can
> > > use the code. Then rebase again for 0.6.0.
> > >
> > > Remember, I have a user base I need to support — there are a lot of
> > people
> > > using the R interpreter now. So its not just a PR where I can ignore it
> > > until its ready to merge.
> > >
> > > The changes have already broken the shiro PR apparently quite often.
> > >
> > > I made a “release” of the R Interpreter just so I could stop rebasing
> > > against Zeppelin master. I spent > 60 hours dealing with this for the
> > > changes leading up to 0.5 and 0.5.5.
> > >
> > > From: Jongyoul Lee <jo...@gmail.com>
> > > Reply: Jongyoul Lee <jo...@gmail.com>
> > > Date: December 29, 2015 at 11:08:36 PM
> > > To: Amos B. Elberg <am...@gmail.com>
> > >
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > >
> > > I don't know why you should rebased twice. If you can make a PR from
> > > current master, almost changes merged without rebasing and if a
> committer
> > > asks to rebase your PR, this is because you and another contributors
> > > changes the same codes and another contributions is merged before your
> > PR.
> > > In specific R case, Moon want you to rebase because he tries to fix the
> > > testing codes so rebasing your PR will accepts their changes. In most
> > case,
> > > contributors don't need to rebase their PR before merge because
> committer
> > > commit someone's PR by doing cherry-pick. We also felt sorry that you
> > were
> > > bothered by testing issue and Moon is fighting to fix the testing
> infra.
> > > However all of PRs shouldn't be rebased.
> > >
> > > On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <
> amos.elberg@gmail.com>
> > > wrote:
> > > I think there is no big pain because whole changes to be merged
> > > into 0.5.6 will be also merged into 0.6.0.
> > >
> > > If we make another release now, the PRs will have to be rebased
> *twice*,
> > > once for 0.5.6, and once again for 0.6.
> > >
> > > Also - since this is now the second e-mail from a committer to do the
> > same
> > > thing — is there a reason you guys are leaving R out of the agenda for
> > the
> > > next release? I understood the PR had been accepted and was pending
> only
> > > Moon fixing the testing infrastructure.
> > >
> > >
> > > From: Jongyoul Lee <jo...@gmail.com>
> > > Reply: dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org>
> > > Date: December 29, 2015 at 10:56:33 PM
> > >
> > > To: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org
> > >
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > >
> > > Good idea!
> > >
> > > 0.5.6 is a minor release thus fixing minor bugs and typos is enough.
> But
> > I
> > > also think 0.6.0 should have major changes like supporting spark 1.6
> and
> > > Shiro security and improving testing infra. And concerning rebasing and
> > > committing, I think there is no big pain because whole changes to be
> > merged
> > > into 0.5.6 will be also merged into 0.6.0.
> > >
> > > JL
> > >
> > > On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <
> amos.elberg@gmail.com>
> > > wrote:
> > >
> > > > I don’t want to come off as the naysayer here, but I think the effort
> > > that
> > > > would go into a release would be better spent on the testing
> > > infrastructure
> > > > and outstanding PRs.
> > > >
> > > > If we feel we need a release for 1.6 and Ignite, I suggest we make a
> > > > release that *only* includes the absolute minimal changes required to
> > do
> > > > that.
> > > >
> > > > There was one PR for 1.6 support that didn’t really work and is going
> > to
> > > > break anything built against the current codebase. Except for a
> change
> > in
> > > > the name of one method called by one class, all of the changes seem
> to
> > > > involve support for spark-under-zeppelin, which is something we want
> to
> > > > take out.
> > > >
> > > > We also don’t currently have a working testing framework. A lot of
> PRs
> > > > have been committed under the “ignore travis its broken” theory. I’m
> > > > loathe to make a release that hasn’t really been tested, and it
> doesn’t
> > > > seem we’re in a position to do that.
> > > >
> > > > While there have been a lot of merged PRs, I don’t think any of them
> > are
> > > > on-roadmap. They mostly seem to be very minor, like fixing typos and
> > > > changing which text box gets highlighted. Those are important things,
> > of
> > > > course, but not major enough to justify the effort involved in a
> > release.
> > > >
> > > > Another release will not make it easier to integrate the larger PRs.
> It
> > > > will have the opposite effect. Developers will have to rebase against
> > > > whatever gets broken by 1.6 and other changes.
> > > >
> > > > I suggest we wait to do a significant release until we can take out
> the
> > > > legacy spark-under-zeppelin code that has caused so many issues,
> have a
> > > > working testing framework, and integrate the major outstanding PRs.
> > > >
> > > > So, again, if we want a release, I suggest we include the absolute
> > > minimum
> > > > changes necessary for 1.6 and Ignite, and perhaps call it an interim
> or
> > > > maintenance release.
> > > >
> > > >
> > > > From: Konstantin Boudnik <co...@apache.org>
> > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > dev@zeppelin.incubator.apache.org>,
> dev@zeppelin.incubator.apache.org
> > <
> > > > dev@zeppelin.incubator.apache.org>
> > > > Date: December 29, 2015 at 10:05:36 PM
> > > > To: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org
> > > >
> > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > >
> > > > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -
> > would
> > > > make
> > > > sense to add this to the latest release of Zeppelin. I will open a
> JIRA
> > > and
> > > > supply a patch for it, if there's no objections.
> > > >
> > > > Cos
> > > >
> > > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > > > Hi folks,
> > > > >
> > > > > How about we make release 0.5.6-incubating?
> > > > >
> > > > > Since last release, more than 100 pull requests are merged and more
> > > than
> > > > 80
> > > > > issues are resolved.
> > > > >
> > > > > It's including new interpreters, a lot of new features and
> > improvement
> > > on
> > > > > GUI with much improved stability thanks to lots of bug fixes.
> > > > >
> > > > > Also it's great time to have a Zeppelin release that support Spark
> > 1.6
> > > (
> > > > > ZEPPELIN-395), which about to be released.
> > > > >
> > > > > Once we branch for 0.5.6-incubating release, it's more safe to make
> > > large
> > > > > code base change such as "Added Shiro security" (
> > > > > https://github.com/apache/incubator-zeppelin/pull/53) and many
> other
> > > > > planned feature in 0.6.0 roadmap, that will require lots of
> internal
> > > API
> > > > > updates.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Thanks,
> > > > > moon
> > > >
> > >
> > >
> > >
> > > --
> > > 이종열, Jongyoul Lee, 李宗烈
> > > http://madeng.net
> > >
> > >
> > >
> > > --
> > > 이종열, Jongyoul Lee, 李宗烈
> > > http://madeng.net
> > >
> > >
> > >
> > > --
> > > 이종열, Jongyoul Lee, 李宗烈
> > > http://madeng.net
> > >
> > >
> > >
> > > --
> > > 이종열, Jongyoul Lee, 李宗烈
> > > http://madeng.net
> > >
> > >
> > >
> > > --
> > > 이종열, Jongyoul Lee, 李宗烈
> > > http://madeng.net
> > >
> > >
> > >
> > > --
> > > 이종열, Jongyoul Lee, 李宗烈
> > > http://madeng.net
> > >
> >
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by moon soo Lee <mo...@apache.org>.
Amos,

Who started the word "meaningful" is not important.
Release discussion will not be judgement of how meaningful/major/big the
contributions are.

CI problem i have describe about R interpreter PR [1] is not related with
any other contribution that we're trying to release.

CI test does not have any known false negative, and we force contributor
rerun the test until false positive disappear. So logically, we can
guarantee that every contribution has passed the CI test correctly.

Also Testis being done not only by CI but also all Zeppelin users.
If users see serious problem in the release candidate, they'll block the
release vote during release candidate verification.

Hope this make you feel more confident about the code we're trying to
release.

Thanks,
moon

[1]
http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/GitHub-incubator-zeppelin-pull-request-R-Interpreter-for-Zeppelin-tp956p4623.html


On Tue, Dec 29, 2015 at 10:53 PM Amos B. Elberg <am...@gmail.com>
wrote:

> You did reply to both.  Let me try to clarify the problem with CI:
>
> The problem is *not* that particular PRs cause instability at runtime.
>
> The problem with CI is that if CI is not working properly, then *we can’t
> know* whether PRs will cause instability.  Or what that connects to
> Zeppelin will break.
>
> CI is our own standard of testability.
>
> It is very common in organizations that they establish a standard of
> reliability.  But, when things become difficult, or there is a problem with
> the standard, the organization comes under pressure to bend or flex the
> standard.
>
> In my experience, when organizations violate their own standards for the
> sake of expedience, it is a recipe for trouble 100% of the time.
>
> —
>
> I just reviewed the changes Jongyoul posted.  One of them relates to a bug
> that was reported in September that has become an issue at Twitter.  That
> seems to me to be a justification for a “hot fix” to the bug.
>
> I still don’t see any justification for a release though.
>
>
> From: moon soo Lee <mo...@apache.org>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 30, 2015 at 1:36:58 AM
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Amos,
>
> If i summarize why you against 0.5.6-incubating release,
>
> * CI is not working
> * Does not have meaningful or major features to be released
>
> these two, right? I replied answer for both of them
>
> Here
>
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4763.html
> and here
>
> http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4765.html
>
> I'm listening and respect your opinion. Please check my reply and tell me
> if you have different opinion, but please include REASON WHY you think in
> that way otherwise it's hard to understand what you're thinking.
>
> Thanks,
> moon
>
>
> On Tue, Dec 29, 2015 at 10:18 PM Amos B. Elberg <am...@gmail.com>
> wrote:
>
> > Do you want me to explain the commits after 0.5.5 in details?
> > I want you to provide an example of any feature that justifies the effort
> > that will be put into making a release, delaying 0.6 and CI and
> everything
> > else, and rebasing the outstanding major PRs.
> >
> > I will settle for *one* example. Just one!
> >
> > And what is your answer that why minor release has a important feature
> and
> > what the difference between major and minor is?
> > My view is that a “minor” release is one that doesn’t require changes in
> > code built against the release other than recompiling. “Major” means
> > people have to work to update their code because of the release.
> >
> > I don't know why you oppose a new minor release including minor bug
> fixes.
> > I’m not even sure these count as “bug fixes” :p A change to the shading
> > of a window so it matches other windows is nice, but its hardly a “bug
> > fix.”
> >
> > Anyway I don’t think this release will really be limited to UI and
> “minor”
> > changes. I think there will be changes to the core code — like the 1.6 PR
> > — that will actually be problems disguised as minor changes. And i don’t
> > think we can test for that without CI.
> >
> > And What kind of aspects are less maintainable between 0.5.5 and 0.5.6?
> > The fact of the change is what makes it less maintainable!
> >
> > And what kind of fixes makes Zeppelin less stable?
> > The *codebase* is definitely less stable.
> >
> > Do you believe that some PR is unstable because of failing CI?
> >
> > Since CI is failing, how do I know if any PRs are stable or not?
> >
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 30, 2015 at 1:05:55 AM
> > To: Amos B. Elberg <am...@gmail.com>
> > CC: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Do you want me to explain the commits after 0.5.5 in details? And what is
> > your answer that why minor release has a important feature and what the
> > difference between major and minor is? I also think it's good to fix
> > version up for ignite but this is not a major feature. I don't know why
> > you oppose a new minor release including minor bug fixes. And What kind
> of
> > aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6 is less
> > maintainable, we should revert that commit because it's harmful to
> > Zeppelin. And what kind of fixes makes Zeppelin less stable? I would like
> > to show me that commit number or issue number. And finally, Moon admitted
> > CI had some flakey tests and have tried to remove or fix that tests. Do
> you
> > believe that some PR is unstable because of failing CI?
> >
> > On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > A codebase that often changes in ways that break other code is an
> unstable
> > codebase, by definition.
> >
> > I don’t think it will be more stable at runtime, especially since CI
> isn’t
> > working.
> >
> > It definitely won’t be more maintainable. The key problematic code is
> > still in.
> >
> > Other than Spark 1.6 and Ignite, I don’t see any reason at all for a
> 0.5.6
> > release. (Konstantin was right — it is good for Apache releases to
> > maintain version compatibility with new versions of other Apache
> software.
> > That is Apache projects helping each other.)
> >
> > What feature do you feel justifies a 0.5.6 release? What feature other
> > than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 30, 2015 at 12:32:01 AM
> >
> > To: Amos B. Elberg <am...@gmail.com>
> > CC: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Amos,
> >
> > I don't think we have a strict plan for making a minor release and we
> have
> > a roadmap for major release. And ignite and Spark 1.6 is not a key
> feature
> > of 0.5.6. Konstantin just wanted to be merged that contribution if that
> > voting is finished until we make a release. And Spark 1.6 is on going. As
> > you told, we are an Apache project. 0.5.6 will be stable and
> maintainable.
> > If 0.5.6 has an experimental features, I don't agree to make a release.
> > 0.5.6 will be more stable version of 0.5.5. And of course, the most
> people
> > like more stable version. Isn't it enough?
> >
> > Regards,
> > Jongyoul
> >
> > On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > My suggestion is that we do a 0.5.6 that just has the bare minimal
> changes
> > necessary for Spark 1.6 and Ignite and nothing else.
> >
> > That way we provide “must have” features while minimizing risk.
> >
> > Other than that, yes: I think we should keep our current release plan and
> > not make a release for “nice to have” changes until CI is fixed.
> >
> > The main purpose of making a new minor release should be whether already
> > merged features are meaningful to make a minor release even if any major
> > issues are on going, isn't it?
> >
> > I’m not sure that I understand what you are asking.
> >
> > We have a planned 0.6 release. We just did an unplanned “minor” 0.5.5
> > release. It feels like only a few weeks ago. I voted for it because it
> > seemed that it would stabilize the codebase and provide a maintainable
> > interim foundation.
> >
> > I do not think any of the features since 0.5.5 are “meaningful” enough to
> > justify changing the release plan. Not even close. I think it is rare
> > that any off-roadmap “nice to have” feature would ever be a good reason
> to
> > change a release plan. Especially when our CI “house” is not in order.
> >
> > We’re an Apache project — we need to be stable, maintainable, reliable,
> > predictable.
> >
> > Is there any merged PR that is so important it can’t wait for 0.6?
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 29, 2015 at 11:54:35 PM
> > To: Amos B. Elberg <am...@gmail.com>
> > CC: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Okay, Amos,
> >
> > Do you propose Zeppelin should not have another release before fix CI
> > issue? I think even though CI has some problems, another minors fixes is
> > meaningful to make a new minor release. Do you agree with that? Or don't
> > you agree that it's enough? The main purpose of making a new minor
> release
> > should be whether already merged features are meaningful to make a minor
> > release even if any major issues are on going, isn't it?
> >
> > Regards,
> > Jongyoul
> >
> > On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > Hah!
> >
> > I promise you, an hour after a 0.5.6 comes out, I will have emails asking
> > me when I will support 0.5.6, even if no-one actually needs any 0.5.6
> > changes or even knows what they are!
> >
> > I want to be clear though: My primary issue for 0.5.6 is not whether to
> > merge the R interpreter.
> >
> > My issues are I think we need to fix CI in general, and I’m loathe to
> have
> > more releases with that dammed spark-under-zeppelin code, which is the
> root
> > of many other issues.
> >
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 29, 2015 at 11:21:00 PM
> > To: Amos B. Elberg <am...@gmail.com>,
> > dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Okay, I understand your situation. If you rebased your PR from master,
> you
> > can rebased your PR only once but I also know why you had to do that. I
> > think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
> > about you?
> >
> > On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > Jongyoul - the reason we have to rebase twice is that the changes in
> > zeppelin-master will break the R interpreter.
> >
> > So I’ll have to rebase once so that I’m based off of 0.5.6 and people can
> > use the code. Then rebase again for 0.6.0.
> >
> > Remember, I have a user base I need to support — there are a lot of
> people
> > using the R interpreter now. So its not just a PR where I can ignore it
> > until its ready to merge.
> >
> > The changes have already broken the shiro PR apparently quite often.
> >
> > I made a “release” of the R Interpreter just so I could stop rebasing
> > against Zeppelin master. I spent > 60 hours dealing with this for the
> > changes leading up to 0.5 and 0.5.5.
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 29, 2015 at 11:08:36 PM
> > To: Amos B. Elberg <am...@gmail.com>
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > I don't know why you should rebased twice. If you can make a PR from
> > current master, almost changes merged without rebasing and if a committer
> > asks to rebase your PR, this is because you and another contributors
> > changes the same codes and another contributions is merged before your
> PR.
> > In specific R case, Moon want you to rebase because he tries to fix the
> > testing codes so rebasing your PR will accepts their changes. In most
> case,
> > contributors don't need to rebase their PR before merge because committer
> > commit someone's PR by doing cherry-pick. We also felt sorry that you
> were
> > bothered by testing issue and Moon is fighting to fix the testing infra.
> > However all of PRs shouldn't be rebased.
> >
> > On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > I think there is no big pain because whole changes to be merged
> > into 0.5.6 will be also merged into 0.6.0.
> >
> > If we make another release now, the PRs will have to be rebased *twice*,
> > once for 0.5.6, and once again for 0.6.
> >
> > Also - since this is now the second e-mail from a committer to do the
> same
> > thing — is there a reason you guys are leaving R out of the agenda for
> the
> > next release? I understood the PR had been accepted and was pending only
> > Moon fixing the testing infrastructure.
> >
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>
> > Date: December 29, 2015 at 10:56:33 PM
> >
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Good idea!
> >
> > 0.5.6 is a minor release thus fixing minor bugs and typos is enough. But
> I
> > also think 0.6.0 should have major changes like supporting spark 1.6 and
> > Shiro security and improving testing infra. And concerning rebasing and
> > committing, I think there is no big pain because whole changes to be
> merged
> > into 0.5.6 will be also merged into 0.6.0.
> >
> > JL
> >
> > On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> >
> > > I don’t want to come off as the naysayer here, but I think the effort
> > that
> > > would go into a release would be better spent on the testing
> > infrastructure
> > > and outstanding PRs.
> > >
> > > If we feel we need a release for 1.6 and Ignite, I suggest we make a
> > > release that *only* includes the absolute minimal changes required to
> do
> > > that.
> > >
> > > There was one PR for 1.6 support that didn’t really work and is going
> to
> > > break anything built against the current codebase. Except for a change
> in
> > > the name of one method called by one class, all of the changes seem to
> > > involve support for spark-under-zeppelin, which is something we want to
> > > take out.
> > >
> > > We also don’t currently have a working testing framework. A lot of PRs
> > > have been committed under the “ignore travis its broken” theory. I’m
> > > loathe to make a release that hasn’t really been tested, and it doesn’t
> > > seem we’re in a position to do that.
> > >
> > > While there have been a lot of merged PRs, I don’t think any of them
> are
> > > on-roadmap. They mostly seem to be very minor, like fixing typos and
> > > changing which text box gets highlighted. Those are important things,
> of
> > > course, but not major enough to justify the effort involved in a
> release.
> > >
> > > Another release will not make it easier to integrate the larger PRs. It
> > > will have the opposite effect. Developers will have to rebase against
> > > whatever gets broken by 1.6 and other changes.
> > >
> > > I suggest we wait to do a significant release until we can take out the
> > > legacy spark-under-zeppelin code that has caused so many issues, have a
> > > working testing framework, and integrate the major outstanding PRs.
> > >
> > > So, again, if we want a release, I suggest we include the absolute
> > minimum
> > > changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> > > maintenance release.
> > >
> > >
> > > From: Konstantin Boudnik <co...@apache.org>
> > > Reply: dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org
> <
> > > dev@zeppelin.incubator.apache.org>
> > > Date: December 29, 2015 at 10:05:36 PM
> > > To: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org
> > >
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > >
> > > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -
> would
> > > make
> > > sense to add this to the latest release of Zeppelin. I will open a JIRA
> > and
> > > supply a patch for it, if there's no objections.
> > >
> > > Cos
> > >
> > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > > Hi folks,
> > > >
> > > > How about we make release 0.5.6-incubating?
> > > >
> > > > Since last release, more than 100 pull requests are merged and more
> > than
> > > 80
> > > > issues are resolved.
> > > >
> > > > It's including new interpreters, a lot of new features and
> improvement
> > on
> > > > GUI with much improved stability thanks to lots of bug fixes.
> > > >
> > > > Also it's great time to have a Zeppelin release that support Spark
> 1.6
> > (
> > > > ZEPPELIN-395), which about to be released.
> > > >
> > > > Once we branch for 0.5.6-incubating release, it's more safe to make
> > large
> > > > code base change such as "Added Shiro security" (
> > > > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > > > planned feature in 0.6.0 roadmap, that will require lots of internal
> > API
> > > > updates.
> > > >
> > > > What do you think?
> > > >
> > > > Thanks,
> > > > moon
> > >
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by "Amos B. Elberg" <am...@gmail.com>.
You did reply to both.  Let me try to clarify the problem with CI:

The problem is *not* that particular PRs cause instability at runtime. 

The problem with CI is that if CI is not working properly, then *we can’t know* whether PRs will cause instability.  Or what that connects to Zeppelin will break.  

CI is our own standard of testability.  

It is very common in organizations that they establish a standard of reliability.  But, when things become difficult, or there is a problem with the standard, the organization comes under pressure to bend or flex the standard.  

In my experience, when organizations violate their own standards for the sake of expedience, it is a recipe for trouble 100% of the time. 

— 

I just reviewed the changes Jongyoul posted.  One of them relates to a bug that was reported in September that has become an issue at Twitter.  That seems to me to be a justification for a “hot fix” to the bug. 

I still don’t see any justification for a release though. 


From: moon soo Lee <mo...@apache.org>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: December 30, 2015 at 1:36:58 AM
To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating  

Amos,  

If i summarize why you against 0.5.6-incubating release,  

* CI is not working  
* Does not have meaningful or major features to be released  

these two, right? I replied answer for both of them  

Here  
http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4763.html  
and here  
http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4765.html  

I'm listening and respect your opinion. Please check my reply and tell me  
if you have different opinion, but please include REASON WHY you think in  
that way otherwise it's hard to understand what you're thinking.  

Thanks,  
moon  


On Tue, Dec 29, 2015 at 10:18 PM Amos B. Elberg <am...@gmail.com>  
wrote:  

> Do you want me to explain the commits after 0.5.5 in details?  
> I want you to provide an example of any feature that justifies the effort  
> that will be put into making a release, delaying 0.6 and CI and everything  
> else, and rebasing the outstanding major PRs.  
>  
> I will settle for *one* example. Just one!  
>  
> And what is your answer that why minor release has a important feature and  
> what the difference between major and minor is?  
> My view is that a “minor” release is one that doesn’t require changes in  
> code built against the release other than recompiling. “Major” means  
> people have to work to update their code because of the release.  
>  
> I don't know why you oppose a new minor release including minor bug fixes.  
> I’m not even sure these count as “bug fixes” :p A change to the shading  
> of a window so it matches other windows is nice, but its hardly a “bug  
> fix.”  
>  
> Anyway I don’t think this release will really be limited to UI and “minor”  
> changes. I think there will be changes to the core code — like the 1.6 PR  
> — that will actually be problems disguised as minor changes. And i don’t  
> think we can test for that without CI.  
>  
> And What kind of aspects are less maintainable between 0.5.5 and 0.5.6?  
> The fact of the change is what makes it less maintainable!  
>  
> And what kind of fixes makes Zeppelin less stable?  
> The *codebase* is definitely less stable.  
>  
> Do you believe that some PR is unstable because of failing CI?  
>  
> Since CI is failing, how do I know if any PRs are stable or not?  
>  
>  
> From: Jongyoul Lee <jo...@gmail.com>  
> Reply: Jongyoul Lee <jo...@gmail.com>  
> Date: December 30, 2015 at 1:05:55 AM  
> To: Amos B. Elberg <am...@gmail.com>  
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> Do you want me to explain the commits after 0.5.5 in details? And what is  
> your answer that why minor release has a important feature and what the  
> difference between major and minor is? I also think it's good to fix  
> version up for ignite but this is not a major feature. I don't know why  
> you oppose a new minor release including minor bug fixes. And What kind of  
> aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6 is less  
> maintainable, we should revert that commit because it's harmful to  
> Zeppelin. And what kind of fixes makes Zeppelin less stable? I would like  
> to show me that commit number or issue number. And finally, Moon admitted  
> CI had some flakey tests and have tried to remove or fix that tests. Do you  
> believe that some PR is unstable because of failing CI?  
>  
> On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com>  
> wrote:  
> A codebase that often changes in ways that break other code is an unstable  
> codebase, by definition.  
>  
> I don’t think it will be more stable at runtime, especially since CI isn’t  
> working.  
>  
> It definitely won’t be more maintainable. The key problematic code is  
> still in.  
>  
> Other than Spark 1.6 and Ignite, I don’t see any reason at all for a 0.5.6  
> release. (Konstantin was right — it is good for Apache releases to  
> maintain version compatibility with new versions of other Apache software.  
> That is Apache projects helping each other.)  
>  
> What feature do you feel justifies a 0.5.6 release? What feature other  
> than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?  
>  
> From: Jongyoul Lee <jo...@gmail.com>  
> Reply: Jongyoul Lee <jo...@gmail.com>  
> Date: December 30, 2015 at 12:32:01 AM  
>  
> To: Amos B. Elberg <am...@gmail.com>  
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> Amos,  
>  
> I don't think we have a strict plan for making a minor release and we have  
> a roadmap for major release. And ignite and Spark 1.6 is not a key feature  
> of 0.5.6. Konstantin just wanted to be merged that contribution if that  
> voting is finished until we make a release. And Spark 1.6 is on going. As  
> you told, we are an Apache project. 0.5.6 will be stable and maintainable.  
> If 0.5.6 has an experimental features, I don't agree to make a release.  
> 0.5.6 will be more stable version of 0.5.5. And of course, the most people  
> like more stable version. Isn't it enough?  
>  
> Regards,  
> Jongyoul  
>  
> On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>  
> wrote:  
> My suggestion is that we do a 0.5.6 that just has the bare minimal changes  
> necessary for Spark 1.6 and Ignite and nothing else.  
>  
> That way we provide “must have” features while minimizing risk.  
>  
> Other than that, yes: I think we should keep our current release plan and  
> not make a release for “nice to have” changes until CI is fixed.  
>  
> The main purpose of making a new minor release should be whether already  
> merged features are meaningful to make a minor release even if any major  
> issues are on going, isn't it?  
>  
> I’m not sure that I understand what you are asking.  
>  
> We have a planned 0.6 release. We just did an unplanned “minor” 0.5.5  
> release. It feels like only a few weeks ago. I voted for it because it  
> seemed that it would stabilize the codebase and provide a maintainable  
> interim foundation.  
>  
> I do not think any of the features since 0.5.5 are “meaningful” enough to  
> justify changing the release plan. Not even close. I think it is rare  
> that any off-roadmap “nice to have” feature would ever be a good reason to  
> change a release plan. Especially when our CI “house” is not in order.  
>  
> We’re an Apache project — we need to be stable, maintainable, reliable,  
> predictable.  
>  
> Is there any merged PR that is so important it can’t wait for 0.6?  
>  
> From: Jongyoul Lee <jo...@gmail.com>  
> Reply: Jongyoul Lee <jo...@gmail.com>  
> Date: December 29, 2015 at 11:54:35 PM  
> To: Amos B. Elberg <am...@gmail.com>  
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> Okay, Amos,  
>  
> Do you propose Zeppelin should not have another release before fix CI  
> issue? I think even though CI has some problems, another minors fixes is  
> meaningful to make a new minor release. Do you agree with that? Or don't  
> you agree that it's enough? The main purpose of making a new minor release  
> should be whether already merged features are meaningful to make a minor  
> release even if any major issues are on going, isn't it?  
>  
> Regards,  
> Jongyoul  
>  
> On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>  
> wrote:  
> Hah!  
>  
> I promise you, an hour after a 0.5.6 comes out, I will have emails asking  
> me when I will support 0.5.6, even if no-one actually needs any 0.5.6  
> changes or even knows what they are!  
>  
> I want to be clear though: My primary issue for 0.5.6 is not whether to  
> merge the R interpreter.  
>  
> My issues are I think we need to fix CI in general, and I’m loathe to have  
> more releases with that dammed spark-under-zeppelin code, which is the root  
> of many other issues.  
>  
>  
> From: Jongyoul Lee <jo...@gmail.com>  
> Reply: Jongyoul Lee <jo...@gmail.com>  
> Date: December 29, 2015 at 11:21:00 PM  
> To: Amos B. Elberg <am...@gmail.com>,  
> dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> Okay, I understand your situation. If you rebased your PR from master, you  
> can rebased your PR only once but I also know why you had to do that. I  
> think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How  
> about you?  
>  
> On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>  
> wrote:  
> Jongyoul - the reason we have to rebase twice is that the changes in  
> zeppelin-master will break the R interpreter.  
>  
> So I’ll have to rebase once so that I’m based off of 0.5.6 and people can  
> use the code. Then rebase again for 0.6.0.  
>  
> Remember, I have a user base I need to support — there are a lot of people  
> using the R interpreter now. So its not just a PR where I can ignore it  
> until its ready to merge.  
>  
> The changes have already broken the shiro PR apparently quite often.  
>  
> I made a “release” of the R Interpreter just so I could stop rebasing  
> against Zeppelin master. I spent > 60 hours dealing with this for the  
> changes leading up to 0.5 and 0.5.5.  
>  
> From: Jongyoul Lee <jo...@gmail.com>  
> Reply: Jongyoul Lee <jo...@gmail.com>  
> Date: December 29, 2015 at 11:08:36 PM  
> To: Amos B. Elberg <am...@gmail.com>  
>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> I don't know why you should rebased twice. If you can make a PR from  
> current master, almost changes merged without rebasing and if a committer  
> asks to rebase your PR, this is because you and another contributors  
> changes the same codes and another contributions is merged before your PR.  
> In specific R case, Moon want you to rebase because he tries to fix the  
> testing codes so rebasing your PR will accepts their changes. In most case,  
> contributors don't need to rebase their PR before merge because committer  
> commit someone's PR by doing cherry-pick. We also felt sorry that you were  
> bothered by testing issue and Moon is fighting to fix the testing infra.  
> However all of PRs shouldn't be rebased.  
>  
> On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com>  
> wrote:  
> I think there is no big pain because whole changes to be merged  
> into 0.5.6 will be also merged into 0.6.0.  
>  
> If we make another release now, the PRs will have to be rebased *twice*,  
> once for 0.5.6, and once again for 0.6.  
>  
> Also - since this is now the second e-mail from a committer to do the same  
> thing — is there a reason you guys are leaving R out of the agenda for the  
> next release? I understood the PR had been accepted and was pending only  
> Moon fixing the testing infrastructure.  
>  
>  
> From: Jongyoul Lee <jo...@gmail.com>  
> Reply: dev@zeppelin.incubator.apache.org <  
> dev@zeppelin.incubator.apache.org>  
> Date: December 29, 2015 at 10:56:33 PM  
>  
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> Good idea!  
>  
> 0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I  
> also think 0.6.0 should have major changes like supporting spark 1.6 and  
> Shiro security and improving testing infra. And concerning rebasing and  
> committing, I think there is no big pain because whole changes to be merged  
> into 0.5.6 will be also merged into 0.6.0.  
>  
> JL  
>  
> On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>  
> wrote:  
>  
> > I don’t want to come off as the naysayer here, but I think the effort  
> that  
> > would go into a release would be better spent on the testing  
> infrastructure  
> > and outstanding PRs.  
> >  
> > If we feel we need a release for 1.6 and Ignite, I suggest we make a  
> > release that *only* includes the absolute minimal changes required to do  
> > that.  
> >  
> > There was one PR for 1.6 support that didn’t really work and is going to  
> > break anything built against the current codebase. Except for a change in  
> > the name of one method called by one class, all of the changes seem to  
> > involve support for spark-under-zeppelin, which is something we want to  
> > take out.  
> >  
> > We also don’t currently have a working testing framework. A lot of PRs  
> > have been committed under the “ignore travis its broken” theory. I’m  
> > loathe to make a release that hasn’t really been tested, and it doesn’t  
> > seem we’re in a position to do that.  
> >  
> > While there have been a lot of merged PRs, I don’t think any of them are  
> > on-roadmap. They mostly seem to be very minor, like fixing typos and  
> > changing which text box gets highlighted. Those are important things, of  
> > course, but not major enough to justify the effort involved in a release.  
> >  
> > Another release will not make it easier to integrate the larger PRs. It  
> > will have the opposite effect. Developers will have to rebase against  
> > whatever gets broken by 1.6 and other changes.  
> >  
> > I suggest we wait to do a significant release until we can take out the  
> > legacy spark-under-zeppelin code that has caused so many issues, have a  
> > working testing framework, and integrate the major outstanding PRs.  
> >  
> > So, again, if we want a release, I suggest we include the absolute  
> minimum  
> > changes necessary for 1.6 and Ignite, and perhaps call it an interim or  
> > maintenance release.  
> >  
> >  
> > From: Konstantin Boudnik <co...@apache.org>  
> > Reply: dev@zeppelin.incubator.apache.org <  
> > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <  
> > dev@zeppelin.incubator.apache.org>  
> > Date: December 29, 2015 at 10:05:36 PM  
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org  
> >  
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating  
> >  
> > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would  
> > make  
> > sense to add this to the latest release of Zeppelin. I will open a JIRA  
> and  
> > supply a patch for it, if there's no objections.  
> >  
> > Cos  
> >  
> > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:  
> > > Hi folks,  
> > >  
> > > How about we make release 0.5.6-incubating?  
> > >  
> > > Since last release, more than 100 pull requests are merged and more  
> than  
> > 80  
> > > issues are resolved.  
> > >  
> > > It's including new interpreters, a lot of new features and improvement  
> on  
> > > GUI with much improved stability thanks to lots of bug fixes.  
> > >  
> > > Also it's great time to have a Zeppelin release that support Spark 1.6  
> (  
> > > ZEPPELIN-395), which about to be released.  
> > >  
> > > Once we branch for 0.5.6-incubating release, it's more safe to make  
> large  
> > > code base change such as "Added Shiro security" (  
> > > https://github.com/apache/incubator-zeppelin/pull/53) and many other  
> > > planned feature in 0.6.0 roadmap, that will require lots of internal  
> API  
> > > updates.  
> > >  
> > > What do you think?  
> > >  
> > > Thanks,  
> > > moon  
> >  
>  
>  
>  
> --  
> 이종열, Jongyoul Lee, 李宗烈  
> http://madeng.net  
>  
>  
>  
> --  
> 이종열, Jongyoul Lee, 李宗烈  
> http://madeng.net  
>  
>  
>  
> --  
> 이종열, Jongyoul Lee, 李宗烈  
> http://madeng.net  
>  
>  
>  
> --  
> 이종열, Jongyoul Lee, 李宗烈  
> http://madeng.net  
>  
>  
>  
> --  
> 이종열, Jongyoul Lee, 李宗烈  
> http://madeng.net  
>  
>  
>  
> --  
> 이종열, Jongyoul Lee, 李宗烈  
> http://madeng.net  
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by moon soo Lee <mo...@apache.org>.
Amos,

If i summarize why you against 0.5.6-incubating release,

* CI is not working
* Does not have meaningful or major features to be released

these two, right? I replied answer for both of them

Here
http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4763.html
and here
http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/DISCUSS-Release-0-5-6-incubating-tp4728p4765.html

I'm listening and respect your opinion. Please check my reply and tell me
if you have different opinion, but please include REASON WHY you think in
that way otherwise it's hard to understand what you're thinking.

Thanks,
moon


On Tue, Dec 29, 2015 at 10:18 PM Amos B. Elberg <am...@gmail.com>
wrote:

> Do you want me to explain the commits after 0.5.5 in details?
> I want you to provide an example of any feature that justifies the effort
> that will be put into making a release, delaying 0.6 and CI and everything
> else, and rebasing the outstanding major PRs.
>
> I will settle for *one* example.  Just one!
>
> And what is your answer that why minor release has a important feature and
> what the difference between major and minor is?
> My view is that a “minor” release is one that doesn’t require changes in
> code built against the release other than recompiling.  “Major” means
> people have to work to update their code because of the release.
>
> I don't know why you oppose a new minor release including minor bug fixes.
> I’m not even sure these count as “bug fixes” :p  A change to the shading
> of a window so it matches other windows is nice, but its hardly a “bug
> fix.”
>
> Anyway I don’t think this release will really be limited to UI and “minor”
> changes.  I think there will be changes to the core code — like the 1.6 PR
> — that will actually be problems disguised as minor changes.  And i don’t
> think we can test for that without CI.
>
> And What kind of aspects are less maintainable between 0.5.5 and 0.5.6?
> The fact of the change is what makes it less maintainable!
>
> And what kind of fixes makes Zeppelin less stable?
> The *codebase* is definitely less stable.
>
> Do you believe that some PR is unstable because of failing CI?
>
> Since CI is failing, how do I know if any PRs are stable or not?
>
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 30, 2015 at 1:05:55 AM
> To: Amos B. Elberg <am...@gmail.com>
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Do you want me to explain the commits after 0.5.5 in details? And what is
> your answer that why minor release has a important feature and what the
> difference between major and minor is? I also think it's good to fix
> version up for ignite but this is not a major feature.  I don't know why
> you oppose a new minor release including minor bug fixes. And What kind of
> aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6 is less
> maintainable, we should revert that commit because it's harmful to
> Zeppelin. And what kind of fixes makes Zeppelin less stable? I would like
> to show me that commit number or issue number. And finally, Moon admitted
> CI had some flakey tests and have tried to remove or fix that tests. Do you
> believe that some PR is unstable because of failing CI?
>
> On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> A codebase that often changes in ways that break other code is an unstable
> codebase, by definition.
>
> I don’t think it will be more stable at runtime, especially since CI isn’t
> working.
>
> It definitely won’t be more maintainable.  The key problematic code is
> still in.
>
> Other than Spark 1.6 and Ignite, I don’t see any reason at all for a 0.5.6
> release.  (Konstantin was right — it is good for Apache releases to
> maintain version compatibility with new versions of other Apache software.
> That is Apache projects helping each other.)
>
> What feature do you feel justifies a 0.5.6 release?  What feature other
> than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 30, 2015 at 12:32:01 AM
>
> To: Amos B. Elberg <am...@gmail.com>
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Amos,
>
> I don't think we have a strict plan for making a minor release and we have
> a roadmap for major release. And ignite and Spark 1.6 is not a key feature
> of 0.5.6. Konstantin just wanted to be merged that contribution if that
> voting is finished until we make a release. And Spark 1.6 is on going. As
> you told, we are an Apache project. 0.5.6 will be stable and maintainable.
> If 0.5.6 has an experimental features, I don't agree to make a release.
> 0.5.6 will be more stable version of 0.5.5. And of course, the most people
> like more stable version. Isn't it enough?
>
> Regards,
> Jongyoul
>
> On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> My suggestion is that we do a 0.5.6 that just has the bare minimal changes
> necessary for Spark 1.6 and Ignite and nothing else.
>
> That way we provide “must have” features while minimizing risk.
>
> Other than that, yes:  I think we should keep our current release plan and
> not make a release for “nice to have” changes until CI is fixed.
>
> The main purpose of making a new minor release should be whether already
> merged features are meaningful to make a minor release even if any major
> issues are on going, isn't it?
>
> I’m not sure that I understand what you are asking.
>
> We have a planned 0.6 release.  We just did an unplanned “minor” 0.5.5
> release.  It feels like only a few weeks ago.  I voted for it because it
> seemed that it would stabilize the codebase and provide a maintainable
> interim foundation.
>
> I do not think any of the features since 0.5.5 are “meaningful” enough to
> justify changing the release plan.  Not even close.  I think it is rare
> that any off-roadmap “nice to have” feature would ever be a good reason to
> change a release plan.  Especially when our CI “house” is not in order.
>
> We’re an Apache project — we need to be stable, maintainable, reliable,
> predictable.
>
> Is there any merged PR that is so important it can’t wait for 0.6?
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 29, 2015 at 11:54:35 PM
> To: Amos B. Elberg <am...@gmail.com>
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Okay, Amos,
>
> Do you propose Zeppelin should not have another release before fix CI
> issue? I think even though CI has some problems, another minors fixes is
> meaningful to make a new minor release. Do you agree with that? Or don't
> you agree that it's enough? The main purpose of making a new minor release
> should be whether already merged features are meaningful to make a minor
> release even if any major issues are on going, isn't it?
>
> Regards,
> Jongyoul
>
> On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> Hah!
>
> I promise you, an hour after a 0.5.6 comes out, I will have emails asking
> me when I will support 0.5.6, even if no-one actually needs any 0.5.6
> changes or even knows what they are!
>
> I want to be clear though:   My primary issue for 0.5.6 is not whether to
> merge the R interpreter.
>
> My issues are I think we need to fix CI in general, and I’m loathe to have
> more releases with that dammed spark-under-zeppelin code, which is the root
> of many other issues.
>
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 29, 2015 at 11:21:00 PM
> To: Amos B. Elberg <am...@gmail.com>,
> dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Okay, I understand your situation. If you rebased your PR from master, you
> can rebased your PR only once but I also know why you had to do that. I
> think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
> about you?
>
> On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> Jongyoul - the reason we have to rebase twice is that the changes in
> zeppelin-master will break the R interpreter.
>
> So I’ll have to rebase once so that I’m based off of 0.5.6 and people can
> use the code.  Then rebase again for 0.6.0.
>
> Remember, I have a user base I need to support — there are a lot of people
> using the R interpreter now.  So its not just a PR where I can ignore it
> until its ready to merge.
>
> The changes have already broken the shiro PR apparently quite often.
>
> I made a “release” of the R Interpreter just so I could stop rebasing
> against Zeppelin master.   I spent > 60 hours dealing with this for the
> changes leading up to 0.5 and 0.5.5.
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 29, 2015 at 11:08:36 PM
> To: Amos B. Elberg <am...@gmail.com>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> I don't know why you should rebased twice. If you can make a PR from
> current master, almost changes merged without rebasing and if a committer
> asks to rebase your PR, this is because you and another contributors
> changes the same codes and another contributions is merged before your PR.
> In specific R case, Moon want you to rebase because he tries to fix the
> testing codes so rebasing your PR will accepts their changes. In most case,
> contributors don't need to rebase their PR before merge because committer
> commit someone's PR by doing cherry-pick. We also felt sorry that you were
> bothered by testing issue and Moon is fighting to fix the testing infra.
> However all of PRs shouldn't be rebased.
>
> On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> I think there is no big pain because whole changes to be merged
> into 0.5.6 will be also merged into 0.6.0.
>
> If we make another release now, the PRs will have to be rebased *twice*,
> once for 0.5.6, and once again for 0.6.
>
> Also - since this is now the second e-mail from a committer to do the same
> thing — is there a reason you guys are leaving R out of the agenda for the
> next release?  I understood the PR had been accepted and was pending only
> Moon fixing the testing infrastructure.
>
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 29, 2015 at 10:56:33 PM
>
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Good idea!
>
> 0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I
> also think 0.6.0 should have major changes like supporting spark 1.6 and
> Shiro security and improving testing infra. And concerning rebasing and
> committing, I think there is no big pain because whole changes to be merged
> into 0.5.6 will be also merged into 0.6.0.
>
> JL
>
> On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
>
> > I don’t want to come off as the naysayer here, but I think the effort
> that
> > would go into a release would be better spent on the testing
> infrastructure
> > and outstanding PRs.
> >
> > If we feel we need a release for 1.6 and Ignite, I suggest we make a
> > release that *only* includes the absolute minimal changes required to do
> > that.
> >
> > There was one PR for 1.6 support that didn’t really work and is going to
> > break anything built against the current codebase. Except for a change in
> > the name of one method called by one class, all of the changes seem to
> > involve support for spark-under-zeppelin, which is something we want to
> > take out.
> >
> > We also don’t currently have a working testing framework. A lot of PRs
> > have been committed under the “ignore travis its broken” theory. I’m
> > loathe to make a release that hasn’t really been tested, and it doesn’t
> > seem we’re in a position to do that.
> >
> > While there have been a lot of merged PRs, I don’t think any of them are
> > on-roadmap. They mostly seem to be very minor, like fixing typos and
> > changing which text box gets highlighted. Those are important things, of
> > course, but not major enough to justify the effort involved in a release.
> >
> > Another release will not make it easier to integrate the larger PRs. It
> > will have the opposite effect. Developers will have to rebase against
> > whatever gets broken by 1.6 and other changes.
> >
> > I suggest we wait to do a significant release until we can take out the
> > legacy spark-under-zeppelin code that has caused so many issues, have a
> > working testing framework, and integrate the major outstanding PRs.
> >
> > So, again, if we want a release, I suggest we include the absolute
> minimum
> > changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> > maintenance release.
> >
> >
> > From: Konstantin Boudnik <co...@apache.org>
> > Reply: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>
> > Date: December 29, 2015 at 10:05:36 PM
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
> > make
> > sense to add this to the latest release of Zeppelin. I will open a JIRA
> and
> > supply a patch for it, if there's no objections.
> >
> > Cos
> >
> > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > Hi folks,
> > >
> > > How about we make release 0.5.6-incubating?
> > >
> > > Since last release, more than 100 pull requests are merged and more
> than
> > 80
> > > issues are resolved.
> > >
> > > It's including new interpreters, a lot of new features and improvement
> on
> > > GUI with much improved stability thanks to lots of bug fixes.
> > >
> > > Also it's great time to have a Zeppelin release that support Spark 1.6
> (
> > > ZEPPELIN-395), which about to be released.
> > >
> > > Once we branch for 0.5.6-incubating release, it's more safe to make
> large
> > > code base change such as "Added Shiro security" (
> > > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > > planned feature in 0.6.0 roadmap, that will require lots of internal
> API
> > > updates.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > moon
> >
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Jungtaek Lim <ka...@gmail.com>.
+1 to release, since our team heavily rely on patches to REST API I've
addressed.

This thread is just for discussion, and we can do actual integration test /
acceptance test before/while voting.
If it raises any issues which is critical, we can cancel the vote and
address issues at that time.

Regarding versioning, what strategy Zeppelin respects now? It would be very
important to maintain such a big project.
For example, if Zeppelin respects semver, new release version should be
0.6.0, since it also has patches other than bugfixes. And we may want to
maintain version branches, too.

Regarding CI failures, many Apache TLPs also have flaky CI tests failure.
(DISCLAIMER: I'm a collaborator of Jedis, and committer / PMC member of
Apache Storm.)

You can easily find "retest this, please" from Apache Spark project, and
Apache Kafka project collects random test failure issues to an umbrella
issue - https://issues.apache.org/jira/browse/KAFKA-2054.
So does the Apache Storm project -
https://issues.apache.org/jira/browse/STORM-915.

Every contributors are happy to try to fix if possible, but we can't 100%
sure that project doesn't have any flaky tests at any time.
If flaky tests failure can block releasing, we can't publish any new
release version.

Amos, I agree that we try not to ignore flaky tests. I just want to say
that it would be better to treat these to be not blocker.

Thanks,
Jungtaek Lim (HeartSaVioR)




On Wed, Dec 30, 2015 at 3:34 PM, Anthony Corbacho <
anthonycorbacho@apache.org> wrote:

> +1, releasing often is better especially bug fix, or minor improvement.
>
> @Moon when do thing you can start the vote?
>
>
> On Wed, Dec 30, 2015 at 3:17 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
>
> > Do you want me to explain the commits after 0.5.5 in details?
> > I want you to provide an example of any feature that justifies the effort
> > that will be put into making a release, delaying 0.6 and CI and
> everything
> > else, and rebasing the outstanding major PRs.
> >
> > I will settle for *one* example.  Just one!
> >
> > And what is your answer that why minor release has a important feature
> and
> > what the difference between major and minor is?
> > My view is that a “minor” release is one that doesn’t require changes in
> > code built against the release other than recompiling.  “Major” means
> > people have to work to update their code because of the release.
> >
> > I don't know why you oppose a new minor release including minor bug
> fixes.
> > I’m not even sure these count as “bug fixes” :p  A change to the shading
> > of a window so it matches other windows is nice, but its hardly a “bug
> > fix.”
> >
> > Anyway I don’t think this release will really be limited to UI and
> “minor”
> > changes.  I think there will be changes to the core code — like the 1.6
> PR
> > — that will actually be problems disguised as minor changes.  And i don’t
> > think we can test for that without CI.
> >
> > And What kind of aspects are less maintainable between 0.5.5 and 0.5.6?
> > The fact of the change is what makes it less maintainable!
> >
> > And what kind of fixes makes Zeppelin less stable?
> > The *codebase* is definitely less stable.
> >
> > Do you believe that some PR is unstable because of failing CI?
> >
> > Since CI is failing, how do I know if any PRs are stable or not?
> >
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 30, 2015 at 1:05:55 AM
> > To: Amos B. Elberg <am...@gmail.com>
> > CC: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Do you want me to explain the commits after 0.5.5 in details? And what is
> > your answer that why minor release has a important feature and what the
> > difference between major and minor is? I also think it's good to fix
> > version up for ignite but this is not a major feature.  I don't know why
> > you oppose a new minor release including minor bug fixes. And What kind
> of
> > aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6 is less
> > maintainable, we should revert that commit because it's harmful to
> > Zeppelin. And what kind of fixes makes Zeppelin less stable? I would like
> > to show me that commit number or issue number. And finally, Moon admitted
> > CI had some flakey tests and have tried to remove or fix that tests. Do
> you
> > believe that some PR is unstable because of failing CI?
> >
> > On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > A codebase that often changes in ways that break other code is an
> unstable
> > codebase, by definition.
> >
> > I don’t think it will be more stable at runtime, especially since CI
> isn’t
> > working.
> >
> > It definitely won’t be more maintainable.  The key problematic code is
> > still in.
> >
> > Other than Spark 1.6 and Ignite, I don’t see any reason at all for a
> 0.5.6
> > release.  (Konstantin was right — it is good for Apache releases to
> > maintain version compatibility with new versions of other Apache
> software.
> > That is Apache projects helping each other.)
> >
> > What feature do you feel justifies a 0.5.6 release?  What feature other
> > than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 30, 2015 at 12:32:01 AM
> >
> > To: Amos B. Elberg <am...@gmail.com>
> > CC: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Amos,
> >
> > I don't think we have a strict plan for making a minor release and we
> have
> > a roadmap for major release. And ignite and Spark 1.6 is not a key
> feature
> > of 0.5.6. Konstantin just wanted to be merged that contribution if that
> > voting is finished until we make a release. And Spark 1.6 is on going. As
> > you told, we are an Apache project. 0.5.6 will be stable and
> maintainable.
> > If 0.5.6 has an experimental features, I don't agree to make a release.
> > 0.5.6 will be more stable version of 0.5.5. And of course, the most
> people
> > like more stable version. Isn't it enough?
> >
> > Regards,
> > Jongyoul
> >
> > On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > My suggestion is that we do a 0.5.6 that just has the bare minimal
> changes
> > necessary for Spark 1.6 and Ignite and nothing else.
> >
> > That way we provide “must have” features while minimizing risk.
> >
> > Other than that, yes:  I think we should keep our current release plan
> and
> > not make a release for “nice to have” changes until CI is fixed.
> >
> > The main purpose of making a new minor release should be whether already
> > merged features are meaningful to make a minor release even if any major
> > issues are on going, isn't it?
> >
> > I’m not sure that I understand what you are asking.
> >
> > We have a planned 0.6 release.  We just did an unplanned “minor” 0.5.5
> > release.  It feels like only a few weeks ago.  I voted for it because it
> > seemed that it would stabilize the codebase and provide a maintainable
> > interim foundation.
> >
> > I do not think any of the features since 0.5.5 are “meaningful” enough to
> > justify changing the release plan.  Not even close.  I think it is rare
> > that any off-roadmap “nice to have” feature would ever be a good reason
> to
> > change a release plan.  Especially when our CI “house” is not in order.
> >
> > We’re an Apache project — we need to be stable, maintainable, reliable,
> > predictable.
> >
> > Is there any merged PR that is so important it can’t wait for 0.6?
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 29, 2015 at 11:54:35 PM
> > To: Amos B. Elberg <am...@gmail.com>
> > CC: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> >
> > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Okay, Amos,
> >
> > Do you propose Zeppelin should not have another release before fix CI
> > issue? I think even though CI has some problems, another minors fixes is
> > meaningful to make a new minor release. Do you agree with that? Or don't
> > you agree that it's enough? The main purpose of making a new minor
> release
> > should be whether already merged features are meaningful to make a minor
> > release even if any major issues are on going, isn't it?
> >
> > Regards,
> > Jongyoul
> >
> > On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > Hah!
> >
> > I promise you, an hour after a 0.5.6 comes out, I will have emails asking
> > me when I will support 0.5.6, even if no-one actually needs any 0.5.6
> > changes or even knows what they are!
> >
> > I want to be clear though:   My primary issue for 0.5.6 is not whether to
> > merge the R interpreter.
> >
> > My issues are I think we need to fix CI in general, and I’m loathe to
> have
> > more releases with that dammed spark-under-zeppelin code, which is the
> root
> > of many other issues.
> >
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 29, 2015 at 11:21:00 PM
> > To: Amos B. Elberg <am...@gmail.com>,
> > dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> >
> > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Okay, I understand your situation. If you rebased your PR from master,
> you
> > can rebased your PR only once but I also know why you had to do that. I
> > think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
> > about you?
> >
> > On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > Jongyoul - the reason we have to rebase twice is that the changes in
> > zeppelin-master will break the R interpreter.
> >
> > So I’ll have to rebase once so that I’m based off of 0.5.6 and people can
> > use the code.  Then rebase again for 0.6.0.
> >
> > Remember, I have a user base I need to support — there are a lot of
> people
> > using the R interpreter now.  So its not just a PR where I can ignore it
> > until its ready to merge.
> >
> > The changes have already broken the shiro PR apparently quite often.
> >
> > I made a “release” of the R Interpreter just so I could stop rebasing
> > against Zeppelin master.   I spent > 60 hours dealing with this for the
> > changes leading up to 0.5 and 0.5.5.
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 29, 2015 at 11:08:36 PM
> > To: Amos B. Elberg <am...@gmail.com>
> >
> > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> >
> > I don't know why you should rebased twice. If you can make a PR from
> > current master, almost changes merged without rebasing and if a committer
> > asks to rebase your PR, this is because you and another contributors
> > changes the same codes and another contributions is merged before your
> PR.
> > In specific R case, Moon want you to rebase because he tries to fix the
> > testing codes so rebasing your PR will accepts their changes. In most
> case,
> > contributors don't need to rebase their PR before merge because committer
> > commit someone's PR by doing cherry-pick. We also felt sorry that you
> were
> > bothered by testing issue and Moon is fighting to fix the testing infra.
> > However all of PRs shouldn't be rebased.
> >
> > On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > I think there is no big pain because whole changes to be merged
> > into 0.5.6 will be also merged into 0.6.0.
> >
> > If we make another release now, the PRs will have to be rebased *twice*,
> > once for 0.5.6, and once again for 0.6.
> >
> > Also - since this is now the second e-mail from a committer to do the
> same
> > thing — is there a reason you guys are leaving R out of the agenda for
> the
> > next release?  I understood the PR had been accepted and was pending only
> > Moon fixing the testing infrastructure.
> >
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>
> > Date: December 29, 2015 at 10:56:33 PM
> >
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Good idea!
> >
> > 0.5.6 is a minor release thus fixing minor bugs and typos is enough. But
> I
> > also think 0.6.0 should have major changes like supporting spark 1.6 and
> > Shiro security and improving testing infra. And concerning rebasing and
> > committing, I think there is no big pain because whole changes to be
> merged
> > into 0.5.6 will be also merged into 0.6.0.
> >
> > JL
> >
> > On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> >
> > > I don’t want to come off as the naysayer here, but I think the effort
> > that
> > > would go into a release would be better spent on the testing
> > infrastructure
> > > and outstanding PRs.
> > >
> > > If we feel we need a release for 1.6 and Ignite, I suggest we make a
> > > release that *only* includes the absolute minimal changes required to
> do
> > > that.
> > >
> > > There was one PR for 1.6 support that didn’t really work and is going
> to
> > > break anything built against the current codebase. Except for a change
> in
> > > the name of one method called by one class, all of the changes seem to
> > > involve support for spark-under-zeppelin, which is something we want to
> > > take out.
> > >
> > > We also don’t currently have a working testing framework. A lot of PRs
> > > have been committed under the “ignore travis its broken” theory. I’m
> > > loathe to make a release that hasn’t really been tested, and it doesn’t
> > > seem we’re in a position to do that.
> > >
> > > While there have been a lot of merged PRs, I don’t think any of them
> are
> > > on-roadmap. They mostly seem to be very minor, like fixing typos and
> > > changing which text box gets highlighted. Those are important things,
> of
> > > course, but not major enough to justify the effort involved in a
> release.
> > >
> > > Another release will not make it easier to integrate the larger PRs. It
> > > will have the opposite effect. Developers will have to rebase against
> > > whatever gets broken by 1.6 and other changes.
> > >
> > > I suggest we wait to do a significant release until we can take out the
> > > legacy spark-under-zeppelin code that has caused so many issues, have a
> > > working testing framework, and integrate the major outstanding PRs.
> > >
> > > So, again, if we want a release, I suggest we include the absolute
> > minimum
> > > changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> > > maintenance release.
> > >
> > >
> > > From: Konstantin Boudnik <co...@apache.org>
> > > Reply: dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org
> <
> > > dev@zeppelin.incubator.apache.org>
> > > Date: December 29, 2015 at 10:05:36 PM
> > > To: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org
> > >
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > >
> > > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -
> would
> > > make
> > > sense to add this to the latest release of Zeppelin. I will open a JIRA
> > and
> > > supply a patch for it, if there's no objections.
> > >
> > > Cos
> > >
> > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > > Hi folks,
> > > >
> > > > How about we make release 0.5.6-incubating?
> > > >
> > > > Since last release, more than 100 pull requests are merged and more
> > than
> > > 80
> > > > issues are resolved.
> > > >
> > > > It's including new interpreters, a lot of new features and
> improvement
> > on
> > > > GUI with much improved stability thanks to lots of bug fixes.
> > > >
> > > > Also it's great time to have a Zeppelin release that support Spark
> 1.6
> > (
> > > > ZEPPELIN-395), which about to be released.
> > > >
> > > > Once we branch for 0.5.6-incubating release, it's more safe to make
> > large
> > > > code base change such as "Added Shiro security" (
> > > > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > > > planned feature in 0.6.0 roadmap, that will require lots of internal
> > API
> > > > updates.
> > > >
> > > > What do you think?
> > > >
> > > > Thanks,
> > > > moon
> > >
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
>



-- 
Name : Jungtaek Lim
Blog : http://medium.com/@heartsavior
Twitter : http://twitter.com/heartsavior
LinkedIn : http://www.linkedin.com/in/heartsavior

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Anthony Corbacho <an...@apache.org>.
+1, releasing often is better especially bug fix, or minor improvement.

@Moon when do thing you can start the vote?


On Wed, Dec 30, 2015 at 3:17 PM, Amos B. Elberg <am...@gmail.com>
wrote:

> Do you want me to explain the commits after 0.5.5 in details?
> I want you to provide an example of any feature that justifies the effort
> that will be put into making a release, delaying 0.6 and CI and everything
> else, and rebasing the outstanding major PRs.
>
> I will settle for *one* example.  Just one!
>
> And what is your answer that why minor release has a important feature and
> what the difference between major and minor is?
> My view is that a “minor” release is one that doesn’t require changes in
> code built against the release other than recompiling.  “Major” means
> people have to work to update their code because of the release.
>
> I don't know why you oppose a new minor release including minor bug fixes.
> I’m not even sure these count as “bug fixes” :p  A change to the shading
> of a window so it matches other windows is nice, but its hardly a “bug
> fix.”
>
> Anyway I don’t think this release will really be limited to UI and “minor”
> changes.  I think there will be changes to the core code — like the 1.6 PR
> — that will actually be problems disguised as minor changes.  And i don’t
> think we can test for that without CI.
>
> And What kind of aspects are less maintainable between 0.5.5 and 0.5.6?
> The fact of the change is what makes it less maintainable!
>
> And what kind of fixes makes Zeppelin less stable?
> The *codebase* is definitely less stable.
>
> Do you believe that some PR is unstable because of failing CI?
>
> Since CI is failing, how do I know if any PRs are stable or not?
>
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 30, 2015 at 1:05:55 AM
> To: Amos B. Elberg <am...@gmail.com>
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Do you want me to explain the commits after 0.5.5 in details? And what is
> your answer that why minor release has a important feature and what the
> difference between major and minor is? I also think it's good to fix
> version up for ignite but this is not a major feature.  I don't know why
> you oppose a new minor release including minor bug fixes. And What kind of
> aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6 is less
> maintainable, we should revert that commit because it's harmful to
> Zeppelin. And what kind of fixes makes Zeppelin less stable? I would like
> to show me that commit number or issue number. And finally, Moon admitted
> CI had some flakey tests and have tried to remove or fix that tests. Do you
> believe that some PR is unstable because of failing CI?
>
> On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> A codebase that often changes in ways that break other code is an unstable
> codebase, by definition.
>
> I don’t think it will be more stable at runtime, especially since CI isn’t
> working.
>
> It definitely won’t be more maintainable.  The key problematic code is
> still in.
>
> Other than Spark 1.6 and Ignite, I don’t see any reason at all for a 0.5.6
> release.  (Konstantin was right — it is good for Apache releases to
> maintain version compatibility with new versions of other Apache software.
> That is Apache projects helping each other.)
>
> What feature do you feel justifies a 0.5.6 release?  What feature other
> than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 30, 2015 at 12:32:01 AM
>
> To: Amos B. Elberg <am...@gmail.com>
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Amos,
>
> I don't think we have a strict plan for making a minor release and we have
> a roadmap for major release. And ignite and Spark 1.6 is not a key feature
> of 0.5.6. Konstantin just wanted to be merged that contribution if that
> voting is finished until we make a release. And Spark 1.6 is on going. As
> you told, we are an Apache project. 0.5.6 will be stable and maintainable.
> If 0.5.6 has an experimental features, I don't agree to make a release.
> 0.5.6 will be more stable version of 0.5.5. And of course, the most people
> like more stable version. Isn't it enough?
>
> Regards,
> Jongyoul
>
> On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> My suggestion is that we do a 0.5.6 that just has the bare minimal changes
> necessary for Spark 1.6 and Ignite and nothing else.
>
> That way we provide “must have” features while minimizing risk.
>
> Other than that, yes:  I think we should keep our current release plan and
> not make a release for “nice to have” changes until CI is fixed.
>
> The main purpose of making a new minor release should be whether already
> merged features are meaningful to make a minor release even if any major
> issues are on going, isn't it?
>
> I’m not sure that I understand what you are asking.
>
> We have a planned 0.6 release.  We just did an unplanned “minor” 0.5.5
> release.  It feels like only a few weeks ago.  I voted for it because it
> seemed that it would stabilize the codebase and provide a maintainable
> interim foundation.
>
> I do not think any of the features since 0.5.5 are “meaningful” enough to
> justify changing the release plan.  Not even close.  I think it is rare
> that any off-roadmap “nice to have” feature would ever be a good reason to
> change a release plan.  Especially when our CI “house” is not in order.
>
> We’re an Apache project — we need to be stable, maintainable, reliable,
> predictable.
>
> Is there any merged PR that is so important it can’t wait for 0.6?
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 29, 2015 at 11:54:35 PM
> To: Amos B. Elberg <am...@gmail.com>
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Okay, Amos,
>
> Do you propose Zeppelin should not have another release before fix CI
> issue? I think even though CI has some problems, another minors fixes is
> meaningful to make a new minor release. Do you agree with that? Or don't
> you agree that it's enough? The main purpose of making a new minor release
> should be whether already merged features are meaningful to make a minor
> release even if any major issues are on going, isn't it?
>
> Regards,
> Jongyoul
>
> On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> Hah!
>
> I promise you, an hour after a 0.5.6 comes out, I will have emails asking
> me when I will support 0.5.6, even if no-one actually needs any 0.5.6
> changes or even knows what they are!
>
> I want to be clear though:   My primary issue for 0.5.6 is not whether to
> merge the R interpreter.
>
> My issues are I think we need to fix CI in general, and I’m loathe to have
> more releases with that dammed spark-under-zeppelin code, which is the root
> of many other issues.
>
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 29, 2015 at 11:21:00 PM
> To: Amos B. Elberg <am...@gmail.com>,
> dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Okay, I understand your situation. If you rebased your PR from master, you
> can rebased your PR only once but I also know why you had to do that. I
> think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
> about you?
>
> On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> Jongyoul - the reason we have to rebase twice is that the changes in
> zeppelin-master will break the R interpreter.
>
> So I’ll have to rebase once so that I’m based off of 0.5.6 and people can
> use the code.  Then rebase again for 0.6.0.
>
> Remember, I have a user base I need to support — there are a lot of people
> using the R interpreter now.  So its not just a PR where I can ignore it
> until its ready to merge.
>
> The changes have already broken the shiro PR apparently quite often.
>
> I made a “release” of the R Interpreter just so I could stop rebasing
> against Zeppelin master.   I spent > 60 hours dealing with this for the
> changes leading up to 0.5 and 0.5.5.
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 29, 2015 at 11:08:36 PM
> To: Amos B. Elberg <am...@gmail.com>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> I don't know why you should rebased twice. If you can make a PR from
> current master, almost changes merged without rebasing and if a committer
> asks to rebase your PR, this is because you and another contributors
> changes the same codes and another contributions is merged before your PR.
> In specific R case, Moon want you to rebase because he tries to fix the
> testing codes so rebasing your PR will accepts their changes. In most case,
> contributors don't need to rebase their PR before merge because committer
> commit someone's PR by doing cherry-pick. We also felt sorry that you were
> bothered by testing issue and Moon is fighting to fix the testing infra.
> However all of PRs shouldn't be rebased.
>
> On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> I think there is no big pain because whole changes to be merged
> into 0.5.6 will be also merged into 0.6.0.
>
> If we make another release now, the PRs will have to be rebased *twice*,
> once for 0.5.6, and once again for 0.6.
>
> Also - since this is now the second e-mail from a committer to do the same
> thing — is there a reason you guys are leaving R out of the agenda for the
> next release?  I understood the PR had been accepted and was pending only
> Moon fixing the testing infrastructure.
>
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 29, 2015 at 10:56:33 PM
>
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Good idea!
>
> 0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I
> also think 0.6.0 should have major changes like supporting spark 1.6 and
> Shiro security and improving testing infra. And concerning rebasing and
> committing, I think there is no big pain because whole changes to be merged
> into 0.5.6 will be also merged into 0.6.0.
>
> JL
>
> On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
>
> > I don’t want to come off as the naysayer here, but I think the effort
> that
> > would go into a release would be better spent on the testing
> infrastructure
> > and outstanding PRs.
> >
> > If we feel we need a release for 1.6 and Ignite, I suggest we make a
> > release that *only* includes the absolute minimal changes required to do
> > that.
> >
> > There was one PR for 1.6 support that didn’t really work and is going to
> > break anything built against the current codebase. Except for a change in
> > the name of one method called by one class, all of the changes seem to
> > involve support for spark-under-zeppelin, which is something we want to
> > take out.
> >
> > We also don’t currently have a working testing framework. A lot of PRs
> > have been committed under the “ignore travis its broken” theory. I’m
> > loathe to make a release that hasn’t really been tested, and it doesn’t
> > seem we’re in a position to do that.
> >
> > While there have been a lot of merged PRs, I don’t think any of them are
> > on-roadmap. They mostly seem to be very minor, like fixing typos and
> > changing which text box gets highlighted. Those are important things, of
> > course, but not major enough to justify the effort involved in a release.
> >
> > Another release will not make it easier to integrate the larger PRs. It
> > will have the opposite effect. Developers will have to rebase against
> > whatever gets broken by 1.6 and other changes.
> >
> > I suggest we wait to do a significant release until we can take out the
> > legacy spark-under-zeppelin code that has caused so many issues, have a
> > working testing framework, and integrate the major outstanding PRs.
> >
> > So, again, if we want a release, I suggest we include the absolute
> minimum
> > changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> > maintenance release.
> >
> >
> > From: Konstantin Boudnik <co...@apache.org>
> > Reply: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>
> > Date: December 29, 2015 at 10:05:36 PM
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
> > make
> > sense to add this to the latest release of Zeppelin. I will open a JIRA
> and
> > supply a patch for it, if there's no objections.
> >
> > Cos
> >
> > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > Hi folks,
> > >
> > > How about we make release 0.5.6-incubating?
> > >
> > > Since last release, more than 100 pull requests are merged and more
> than
> > 80
> > > issues are resolved.
> > >
> > > It's including new interpreters, a lot of new features and improvement
> on
> > > GUI with much improved stability thanks to lots of bug fixes.
> > >
> > > Also it's great time to have a Zeppelin release that support Spark 1.6
> (
> > > ZEPPELIN-395), which about to be released.
> > >
> > > Once we branch for 0.5.6-incubating release, it's more safe to make
> large
> > > code base change such as "Added Shiro security" (
> > > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > > planned feature in 0.6.0 roadmap, that will require lots of internal
> API
> > > updates.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > moon
> >
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by "Amos B. Elberg" <am...@gmail.com>.
Do you want me to explain the commits after 0.5.5 in details? 
I want you to provide an example of any feature that justifies the effort that will be put into making a release, delaying 0.6 and CI and everything else, and rebasing the outstanding major PRs. 

I will settle for *one* example.  Just one!

And what is your answer that why minor release has a important feature and what the difference between major and minor is?
My view is that a “minor” release is one that doesn’t require changes in code built against the release other than recompiling.  “Major” means people have to work to update their code because of the release. 

I don't know why you oppose a new minor release including minor bug fixes. 
I’m not even sure these count as “bug fixes” :p  A change to the shading of a window so it matches other windows is nice, but its hardly a “bug fix.”  

Anyway I don’t think this release will really be limited to UI and “minor” changes.  I think there will be changes to the core code — like the 1.6 PR — that will actually be problems disguised as minor changes.  And i don’t think we can test for that without CI. 

And What kind of aspects are less maintainable between 0.5.5 and 0.5.6?
The fact of the change is what makes it less maintainable! 

And what kind of fixes makes Zeppelin less stable? 
The *codebase* is definitely less stable. 

Do you believe that some PR is unstable because of failing CI?

Since CI is failing, how do I know if any PRs are stable or not?  


From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 30, 2015 at 1:05:55 AM
To: Amos B. Elberg <am...@gmail.com>
CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating  

Do you want me to explain the commits after 0.5.5 in details? And what is your answer that why minor release has a important feature and what the difference between major and minor is? I also think it's good to fix version up for ignite but this is not a major feature.  I don't know why you oppose a new minor release including minor bug fixes. And What kind of aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6 is less maintainable, we should revert that commit because it's harmful to Zeppelin. And what kind of fixes makes Zeppelin less stable? I would like to show me that commit number or issue number. And finally, Moon admitted CI had some flakey tests and have tried to remove or fix that tests. Do you believe that some PR is unstable because of failing CI?

On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com> wrote:
A codebase that often changes in ways that break other code is an unstable codebase, by definition.

I don’t think it will be more stable at runtime, especially since CI isn’t working.  

It definitely won’t be more maintainable.  The key problematic code is still in.  

Other than Spark 1.6 and Ignite, I don’t see any reason at all for a 0.5.6 release.  (Konstantin was right — it is good for Apache releases to maintain version compatibility with new versions of other Apache software.  That is Apache projects helping each other.)

What feature do you feel justifies a 0.5.6 release?  What feature other than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?

From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 30, 2015 at 12:32:01 AM

To: Amos B. Elberg <am...@gmail.com>
CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating

Amos,

I don't think we have a strict plan for making a minor release and we have a roadmap for major release. And ignite and Spark 1.6 is not a key feature of 0.5.6. Konstantin just wanted to be merged that contribution if that voting is finished until we make a release. And Spark 1.6 is on going. As you told, we are an Apache project. 0.5.6 will be stable and maintainable. If 0.5.6 has an experimental features, I don't agree to make a release. 0.5.6 will be more stable version of 0.5.5. And of course, the most people like more stable version. Isn't it enough?

Regards,
Jongyoul

On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com> wrote:
My suggestion is that we do a 0.5.6 that just has the bare minimal changes necessary for Spark 1.6 and Ignite and nothing else.  

That way we provide “must have” features while minimizing risk. 

Other than that, yes:  I think we should keep our current release plan and not make a release for “nice to have” changes until CI is fixed.  

The main purpose of making a new minor release should be whether already merged features are meaningful to make a minor release even if any major issues are on going, isn't it?

I’m not sure that I understand what you are asking. 

We have a planned 0.6 release.  We just did an unplanned “minor” 0.5.5 release.  It feels like only a few weeks ago.  I voted for it because it seemed that it would stabilize the codebase and provide a maintainable interim foundation.  

I do not think any of the features since 0.5.5 are “meaningful” enough to justify changing the release plan.  Not even close.  I think it is rare that any off-roadmap “nice to have” feature would ever be a good reason to change a release plan.  Especially when our CI “house” is not in order. 

We’re an Apache project — we need to be stable, maintainable, reliable, predictable.  

Is there any merged PR that is so important it can’t wait for 0.6? 

From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 29, 2015 at 11:54:35 PM
To: Amos B. Elberg <am...@gmail.com>
CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>

Subject:  Re: [DISCUSS] Release 0.5.6-incubating

Okay, Amos,

Do you propose Zeppelin should not have another release before fix CI issue? I think even though CI has some problems, another minors fixes is meaningful to make a new minor release. Do you agree with that? Or don't you agree that it's enough? The main purpose of making a new minor release should be whether already merged features are meaningful to make a minor release even if any major issues are on going, isn't it?

Regards,
Jongyoul

On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com> wrote:
Hah!  

I promise you, an hour after a 0.5.6 comes out, I will have emails asking me when I will support 0.5.6, even if no-one actually needs any 0.5.6 changes or even knows what they are!  

I want to be clear though:   My primary issue for 0.5.6 is not whether to merge the R interpreter.

My issues are I think we need to fix CI in general, and I’m loathe to have more releases with that dammed spark-under-zeppelin code, which is the root of many other issues.  


From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 29, 2015 at 11:21:00 PM
To: Amos B. Elberg <am...@gmail.com>, dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>

Subject:  Re: [DISCUSS] Release 0.5.6-incubating

Okay, I understand your situation. If you rebased your PR from master, you can rebased your PR only once but I also know why you had to do that. I think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How about you?

On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com> wrote:
Jongyoul - the reason we have to rebase twice is that the changes in zeppelin-master will break the R interpreter.  

So I’ll have to rebase once so that I’m based off of 0.5.6 and people can use the code.  Then rebase again for 0.6.0.  

Remember, I have a user base I need to support — there are a lot of people using the R interpreter now.  So its not just a PR where I can ignore it until its ready to merge.

The changes have already broken the shiro PR apparently quite often. 

I made a “release” of the R Interpreter just so I could stop rebasing against Zeppelin master.   I spent > 60 hours dealing with this for the changes leading up to 0.5 and 0.5.5. 

From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 29, 2015 at 11:08:36 PM
To: Amos B. Elberg <am...@gmail.com>

Subject:  Re: [DISCUSS] Release 0.5.6-incubating

I don't know why you should rebased twice. If you can make a PR from current master, almost changes merged without rebasing and if a committer asks to rebase your PR, this is because you and another contributors changes the same codes and another contributions is merged before your PR. In specific R case, Moon want you to rebase because he tries to fix the testing codes so rebasing your PR will accepts their changes. In most case, contributors don't need to rebase their PR before merge because committer commit someone's PR by doing cherry-pick. We also felt sorry that you were bothered by testing issue and Moon is fighting to fix the testing infra. However all of PRs shouldn't be rebased.

On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com> wrote:
I think there is no big pain because whole changes to be merged 
into 0.5.6 will be also merged into 0.6.0. 

If we make another release now, the PRs will have to be rebased *twice*, once for 0.5.6, and once again for 0.6.  

Also - since this is now the second e-mail from a committer to do the same thing — is there a reason you guys are leaving R out of the agenda for the next release?  I understood the PR had been accepted and was pending only Moon fixing the testing infrastructure. 


From: Jongyoul Lee <jo...@gmail.com>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: December 29, 2015 at 10:56:33 PM

To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating

Good idea!

0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I
also think 0.6.0 should have major changes like supporting spark 1.6 and
Shiro security and improving testing infra. And concerning rebasing and
committing, I think there is no big pain because whole changes to be merged
into 0.5.6 will be also merged into 0.6.0.

JL

On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
wrote:

> I don’t want to come off as the naysayer here, but I think the effort that
> would go into a release would be better spent on the testing infrastructure
> and outstanding PRs.
>
> If we feel we need a release for 1.6 and Ignite, I suggest we make a
> release that *only* includes the absolute minimal changes required to do
> that.
>
> There was one PR for 1.6 support that didn’t really work and is going to
> break anything built against the current codebase. Except for a change in
> the name of one method called by one class, all of the changes seem to
> involve support for spark-under-zeppelin, which is something we want to
> take out.
>
> We also don’t currently have a working testing framework. A lot of PRs
> have been committed under the “ignore travis its broken” theory. I’m
> loathe to make a release that hasn’t really been tested, and it doesn’t
> seem we’re in a position to do that.
>
> While there have been a lot of merged PRs, I don’t think any of them are
> on-roadmap. They mostly seem to be very minor, like fixing typos and
> changing which text box gets highlighted. Those are important things, of
> course, but not major enough to justify the effort involved in a release.
>
> Another release will not make it easier to integrate the larger PRs. It
> will have the opposite effect. Developers will have to rebase against
> whatever gets broken by 1.6 and other changes.
>
> I suggest we wait to do a significant release until we can take out the
> legacy spark-under-zeppelin code that has caused so many issues, have a
> working testing framework, and integrate the major outstanding PRs.
>
> So, again, if we want a release, I suggest we include the absolute minimum
> changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> maintenance release.
>
>
> From: Konstantin Boudnik <co...@apache.org>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 29, 2015 at 10:05:36 PM
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject: Re: [DISCUSS] Release 0.5.6-incubating
>
> Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
> make
> sense to add this to the latest release of Zeppelin. I will open a JIRA and
> supply a patch for it, if there's no objections.
>
> Cos
>
> On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > Hi folks,
> >
> > How about we make release 0.5.6-incubating?
> >
> > Since last release, more than 100 pull requests are merged and more than
> 80
> > issues are resolved.
> >
> > It's including new interpreters, a lot of new features and improvement on
> > GUI with much improved stability thanks to lots of bug fixes.
> >
> > Also it's great time to have a Zeppelin release that support Spark 1.6 (
> > ZEPPELIN-395), which about to be released.
> >
> > Once we branch for 0.5.6-incubating release, it's more safe to make large
> > code base change such as "Added Shiro security" (
> > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > planned feature in 0.6.0 roadmap, that will require lots of internal API
> > updates.
> >
> > What do you think?
> >
> > Thanks,
> > moon
>



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Jongyoul Lee <jo...@gmail.com>.
Do you want me to explain the commits after 0.5.5 in details? And what is
your answer that why minor release has a important feature and what the
difference between major and minor is? I also think it's good to fix
version up for ignite but this is not a major feature.  I don't know why
you oppose a new minor release including minor bug fixes. And What kind of
aspects are less maintainable between 0.5.5 and 0.5.6? If 0.5.6 is less
maintainable, we should revert that commit because it's harmful to
Zeppelin. And what kind of fixes makes Zeppelin less stable? I would like
to show me that commit number or issue number. And finally, Moon admitted
CI had some flakey tests and have tried to remove or fix that tests. Do you
believe that some PR is unstable because of failing CI?

On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com>
wrote:

> A codebase that often changes in ways that break other code is an unstable
> codebase, by definition.
>
> I don’t think it will be more stable at runtime, especially since CI isn’t
> working.
>
> It definitely won’t be more maintainable.  The key problematic code is
> still in.
>
> Other than Spark 1.6 and Ignite, I don’t see any reason at all for a 0.5.6
> release.  (Konstantin was right — it is good for Apache releases to
> maintain version compatibility with new versions of other Apache software.
> That is Apache projects helping each other.)
>
> What feature do you feel justifies a 0.5.6 release?  What feature other
> than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
>
> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
> Date: December 30, 2015 at 12:32:01 AM
>
> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Amos,
>
> I don't think we have a strict plan for making a minor release and we have
> a roadmap for major release. And ignite and Spark 1.6 is not a key feature
> of 0.5.6. Konstantin just wanted to be merged that contribution if that
> voting is finished until we make a release. And Spark 1.6 is on going. As
> you told, we are an Apache project. 0.5.6 will be stable and maintainable.
> If 0.5.6 has an experimental features, I don't agree to make a release.
> 0.5.6 will be more stable version of 0.5.5. And of course, the most people
> like more stable version. Isn't it enough?
>
> Regards,
> Jongyoul
>
> On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
>
>> My suggestion is that we do a 0.5.6 that just has the bare minimal
>> changes necessary for Spark 1.6 and Ignite and nothing else.
>>
>> That way we provide “must have” features while minimizing risk.
>>
>> Other than that, yes:  I think we should keep our current release plan
>> and not make a release for “nice to have” changes until CI is fixed.
>>
>> The main purpose of making a new minor release should be whether already
>> merged features are meaningful to make a minor release even if any major
>> issues are on going, isn't it?
>>
>>
>> I’m not sure that I understand what you are asking.
>>
>> We have a planned 0.6 release.  We just did an unplanned “minor” 0.5.5
>> release.  It feels like only a few weeks ago.  I voted for it because it
>> seemed that it would stabilize the codebase and provide a maintainable
>> interim foundation.
>>
>> I do not think any of the features since 0.5.5 are “meaningful” enough to
>> justify changing the release plan.  Not even close.  I think it is rare
>> that any off-roadmap “nice to have” feature would ever be a good reason to
>> change a release plan.  Especially when our CI “house” is not in order.
>>
>> We’re an Apache project — we need to be stable, maintainable, reliable,
>> predictable.
>>
>> Is there any merged PR that is so important it can’t wait for 0.6?
>>
>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>> Date: December 29, 2015 at 11:54:35 PM
>> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>
>> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>> <de...@zeppelin.incubator.apache.org>
>>
>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>
>> Okay, Amos,
>>
>> Do you propose Zeppelin should not have another release before fix CI
>> issue? I think even though CI has some problems, another minors fixes is
>> meaningful to make a new minor release. Do you agree with that? Or don't
>> you agree that it's enough? The main purpose of making a new minor release
>> should be whether already merged features are meaningful to make a minor
>> release even if any major issues are on going, isn't it?
>>
>> Regards,
>> Jongyoul
>>
>> On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>
>> wrote:
>>
>>> Hah!
>>>
>>> I promise you, an hour after a 0.5.6 comes out, I will have emails
>>> asking me when I will support 0.5.6, even if no-one actually needs any
>>> 0.5.6 changes or even knows what they are!
>>>
>>> I want to be clear though:   My primary issue for 0.5.6 is not whether
>>> to merge the R interpreter.
>>>
>>> My issues are I think we need to fix CI in general, and I’m loathe to
>>> have more releases with that dammed spark-under-zeppelin code, which is the
>>> root of many other issues.
>>>
>>>
>>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>> Date: December 29, 2015 at 11:21:00 PM
>>> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>,
>>> dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>>> <de...@zeppelin.incubator.apache.org>
>>>
>>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>>
>>> Okay, I understand your situation. If you rebased your PR from master,
>>> you can rebased your PR only once but I also know why you had to do that. I
>>> think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
>>> about you?
>>>
>>> On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
>>> wrote:
>>>
>>>> Jongyoul - the reason we have to rebase twice is that the changes in
>>>> zeppelin-master will break the R interpreter.
>>>>
>>>> So I’ll have to rebase once so that I’m based off of 0.5.6 and people
>>>> can use the code.  Then rebase again for 0.6.0.
>>>>
>>>> Remember, I have a user base I need to support — there are a lot of
>>>> people using the R interpreter now.  So its not just a PR where I can
>>>> ignore it until its ready to merge.
>>>>
>>>> The changes have already broken the shiro PR apparently quite often.
>>>>
>>>> I made a “release” of the R Interpreter just so I could stop rebasing
>>>> against Zeppelin master.   I spent > 60 hours dealing with this for the
>>>> changes leading up to 0.5 and 0.5.5.
>>>>
>>>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>>> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>>> Date: December 29, 2015 at 11:08:36 PM
>>>> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>
>>>>
>>>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>>>
>>>> I don't know why you should rebased twice. If you can make a PR from
>>>> current master, almost changes merged without rebasing and if a committer
>>>> asks to rebase your PR, this is because you and another contributors
>>>> changes the same codes and another contributions is merged before your PR.
>>>> In specific R case, Moon want you to rebase because he tries to fix the
>>>> testing codes so rebasing your PR will accepts their changes. In most case,
>>>> contributors don't need to rebase their PR before merge because committer
>>>> commit someone's PR by doing cherry-pick. We also felt sorry that you were
>>>> bothered by testing issue and Moon is fighting to fix the testing infra.
>>>> However all of PRs shouldn't be rebased.
>>>>
>>>> On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <amos.elberg@gmail.com
>>>> > wrote:
>>>>
>>>>> I think there is no big pain because whole changes to be merged
>>>>> into 0.5.6 will be also merged into 0.6.0.
>>>>>
>>>>>
>>>>> If we make another release now, the PRs will have to be rebased
>>>>> *twice*, once for 0.5.6, and once again for 0.6.
>>>>>
>>>>> Also - since this is now the second e-mail from a committer to do the
>>>>> same thing — is there a reason you guys are leaving R out of the agenda for
>>>>> the next release?  I understood the PR had been accepted and was pending
>>>>> only Moon fixing the testing infrastructure.
>>>>>
>>>>>
>>>>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>>>> Reply: dev@zeppelin.incubator.apache.org
>>>>> <de...@zeppelin.incubator.apache.org>
>>>>> <de...@zeppelin.incubator.apache.org>
>>>>> Date: December 29, 2015 at 10:56:33 PM
>>>>>
>>>>> To: dev@zeppelin.incubator.apache.org
>>>>> <de...@zeppelin.incubator.apache.org>
>>>>> <de...@zeppelin.incubator.apache.org>
>>>>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>>>>
>>>>> Good idea!
>>>>>
>>>>> 0.5.6 is a minor release thus fixing minor bugs and typos is enough.
>>>>> But I
>>>>> also think 0.6.0 should have major changes like supporting spark 1.6
>>>>> and
>>>>> Shiro security and improving testing infra. And concerning rebasing and
>>>>> committing, I think there is no big pain because whole changes to be
>>>>> merged
>>>>> into 0.5.6 will be also merged into 0.6.0.
>>>>>
>>>>> JL
>>>>>
>>>>> On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <
>>>>> amos.elberg@gmail.com>
>>>>> wrote:
>>>>>
>>>>> > I don’t want to come off as the naysayer here, but I think the
>>>>> effort that
>>>>> > would go into a release would be better spent on the testing
>>>>> infrastructure
>>>>> > and outstanding PRs.
>>>>> >
>>>>> > If we feel we need a release for 1.6 and Ignite, I suggest we make a
>>>>> > release that *only* includes the absolute minimal changes required
>>>>> to do
>>>>> > that.
>>>>> >
>>>>> > There was one PR for 1.6 support that didn’t really work and is
>>>>> going to
>>>>> > break anything built against the current codebase. Except for a
>>>>> change in
>>>>> > the name of one method called by one class, all of the changes seem
>>>>> to
>>>>> > involve support for spark-under-zeppelin, which is something we want
>>>>> to
>>>>> > take out.
>>>>> >
>>>>> > We also don’t currently have a working testing framework. A lot of
>>>>> PRs
>>>>> > have been committed under the “ignore travis its broken” theory. I’m
>>>>> > loathe to make a release that hasn’t really been tested, and it
>>>>> doesn’t
>>>>> > seem we’re in a position to do that.
>>>>> >
>>>>> > While there have been a lot of merged PRs, I don’t think any of them
>>>>> are
>>>>> > on-roadmap. They mostly seem to be very minor, like fixing typos and
>>>>> > changing which text box gets highlighted. Those are important
>>>>> things, of
>>>>> > course, but not major enough to justify the effort involved in a
>>>>> release.
>>>>> >
>>>>> > Another release will not make it easier to integrate the larger PRs.
>>>>> It
>>>>> > will have the opposite effect. Developers will have to rebase against
>>>>> > whatever gets broken by 1.6 and other changes.
>>>>> >
>>>>> > I suggest we wait to do a significant release until we can take out
>>>>> the
>>>>> > legacy spark-under-zeppelin code that has caused so many issues,
>>>>> have a
>>>>> > working testing framework, and integrate the major outstanding PRs.
>>>>> >
>>>>> > So, again, if we want a release, I suggest we include the absolute
>>>>> minimum
>>>>> > changes necessary for 1.6 and Ignite, and perhaps call it an interim
>>>>> or
>>>>> > maintenance release.
>>>>> >
>>>>> >
>>>>> > From: Konstantin Boudnik <co...@apache.org>
>>>>> > Reply: dev@zeppelin.incubator.apache.org <
>>>>> > dev@zeppelin.incubator.apache.org>,
>>>>> dev@zeppelin.incubator.apache.org <
>>>>> > dev@zeppelin.incubator.apache.org>
>>>>> > Date: December 29, 2015 at 10:05:36 PM
>>>>> > To: dev@zeppelin.incubator.apache.org <
>>>>> dev@zeppelin.incubator.apache.org>
>>>>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
>>>>> >
>>>>> > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -
>>>>> would
>>>>> > make
>>>>> > sense to add this to the latest release of Zeppelin. I will open a
>>>>> JIRA and
>>>>> > supply a patch for it, if there's no objections.
>>>>> >
>>>>> > Cos
>>>>> >
>>>>> > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
>>>>> > > Hi folks,
>>>>> > >
>>>>> > > How about we make release 0.5.6-incubating?
>>>>> > >
>>>>> > > Since last release, more than 100 pull requests are merged and
>>>>> more than
>>>>> > 80
>>>>> > > issues are resolved.
>>>>> > >
>>>>> > > It's including new interpreters, a lot of new features and
>>>>> improvement on
>>>>> > > GUI with much improved stability thanks to lots of bug fixes.
>>>>> > >
>>>>> > > Also it's great time to have a Zeppelin release that support Spark
>>>>> 1.6 (
>>>>> > > ZEPPELIN-395), which about to be released.
>>>>> > >
>>>>> > > Once we branch for 0.5.6-incubating release, it's more safe to
>>>>> make large
>>>>> > > code base change such as "Added Shiro security" (
>>>>> > > https://github.com/apache/incubator-zeppelin/pull/53) and many
>>>>> other
>>>>> > > planned feature in 0.6.0 roadmap, that will require lots of
>>>>> internal API
>>>>> > > updates.
>>>>> > >
>>>>> > > What do you think?
>>>>> > >
>>>>> > > Thanks,
>>>>> > > moon
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 이종열, Jongyoul Lee, 李宗烈
>>>>> http://madeng.net
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 이종열, Jongyoul Lee, 李宗烈
>>>> http://madeng.net
>>>>
>>>>
>>>
>>>
>>> --
>>> 이종열, Jongyoul Lee, 李宗烈
>>> http://madeng.net
>>>
>>>
>>
>>
>> --
>> 이종열, Jongyoul Lee, 李宗烈
>> http://madeng.net
>>
>>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>


-- 
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

Re: [DISCUSS] Release 0.5.6-incubating

Posted by "Amos B. Elberg" <am...@gmail.com>.
I keep trying to get out and I keep getting pulled back in…

Moon - “meaningful" was Jongyoul’s word, which I was repeating back.  The question is whether any changes justify a release, and that is clearly relevant to the discussion.  

> Those false positive tests happens in around 6% of chance according to my 
> experiment [2], i don't think they're making project unmaintainable at all. 
> 
> If you tell me why you think "CI isn’t working.", that would be really 
> helpful to understand why do you think it's blocker for the release. 
When I first reported this to you, in September, you thought I was messing it up and didn’t believe there is an issue.

In fact you got frustrated in November when I pressed that there really is an issue with testing, and it wasn’t a bug in my code. 

Now that you have looked at it (thank you again!), you agree with me that there really are issues.  But you are not convinced they are big issues.

That is fair. 

I believe that as you spend more time trying to fix the CI issue, as I did, you will eventually reach the same conclusions that I have.  

In my experience, it was not just a small number of “false positive” tests.  I did see those.  But there were also timeouts, and sporadic issues downloading needed testing infrastructure.  Beyond that, the bulk of the errors I saw related to spark failing to start. 

(BTW - it is definitely more than 6%, just based on the notes in the PRs.  But the situation I suspect to be broader.  When there are issues with a testing engine, developers react by reducing the number and scope of tests.  I have a suspicion that if CI were fully functional, we’d have layers of additional tests.  I can think of quite a few I’d like to add related to handling proper spark setup and the zeppelin preference system.)

From: moon soo Lee <mo...@apache.org>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: December 30, 2015 at 1:15:56 AM
To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating  

Amos,  

I don't think you or anyone here can define which contributions are more  
meaningful or which contributions are not.  

That's totally irrelevant thing for the release discussion.  

Thanks,  
moon  

On Tue, Dec 29, 2015 at 10:12 PM moon soo Lee <mo...@apache.org> wrote:  

> Amos,  
>  
> CI is definitely working. Although it's got some flickering test, they're  
> all  
> false positive. It doesn't harm any code quality. So even flickering test  
> are testing the code correctly. And we're addressing them [1].  
>  
> Those false positive tests happens in around 6% of chance according to my  
> experiment [2], i don't think they're making project unmaintainable at all.  
>  
> If you tell me why you think "CI isn’t working.", that would be really  
> helpful to understand why do you think it's blocker for the release.  
>  
> Thanks,  
> moon  
>  
> [1]  
> https://issues.apache.org/jira/browse/ZEPPELIN-476?jql=labels%20%3D%20flaky-test%20and%20project%20%3D%20zeppelin  
> [2] https://github.com/apache/incubator-zeppelin/pull/527  
>  
> On Tue, Dec 29, 2015 at 10:08 PM Amos B. Elberg <am...@gmail.com>  
> wrote:  
>  
>> I’m not the only person who gets a vote, so after I reply to Jongyoul, I  
>> will not say anything more on this subject. I think my view is pretty  
>> clear.  
>>  
>> I will add that I just reviewed all of those commits.  
>>  
>> They are all minor improvements to the UI. Things like whether a  
>> background gets greyed out when a pop-up appears. Two of them could be  
>> viewed as fixes for minor UI issues. None of them relates to any stability  
>> issues in Zeppelin.  
>>  
>> For most of them I had trouble spotting whether anything had changed,  
>> even with the helpful screenshots.  
>>  
>> I don’t think any of them, or all of them together, are a reason for a  
>> release.  
>>  
>> From: Corneau Damien <co...@gmail.com>  
>> Reply: dev@zeppelin.incubator.apache.org <  
>> dev@zeppelin.incubator.apache.org>  
>> Date: December 30, 2015 at 12:51:50 AM  
>> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
>> CC: Jongyoul Lee <jo...@gmail.com>  
>> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>>  
>> I don't think minor releases needs be planned (feature wise),  
>> its something we should do when we feel the need that we fixed or improved  
>> something important.  
>> We even talked at some point of doing some more periodic releases.  
>>  
>> I see a lot of good benefits from making a new minor release, especially  
>> bug fix wise.  
>>  
>> https://github.com/apache/incubator-zeppelin/pull/580  
>>  
>> https://github.com/apache/incubator-zeppelin/commit/47eb95aeeefa8925ef5b49487b967f40ad451454  
>>  
>> https://github.com/apache/incubator-zeppelin/commit/f0d3c3f0e3e898b5625a1d3745a701271905c22c  
>>  
>> https://github.com/apache/incubator-zeppelin/commit/4a1edd525b31e5c6de41c3598ce921b82b7abeeb  
>>  
>> https://github.com/apache/incubator-zeppelin/commit/71c1af84a1c4f285842dfd5c85fc99ffc4bfca26  
>>  
>> https://github.com/apache/incubator-zeppelin/commit/d90e3805bb2d2434bc08672a6227c0afc927f6ae  
>>  
>> https://github.com/apache/incubator-zeppelin/commit/986b0adba3a7986a387c0633d15279b6b2f45c95  
>>  
>> On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com>  
>> wrote:  
>>  
>> > A codebase that often changes in ways that break other code is an  
>> unstable  
>> > codebase, by definition.  
>> >  
>> > I don’t think it will be more stable at runtime, especially since CI  
>> isn’t  
>> > working.  
>> >  
>> > It definitely won’t be more maintainable. The key problematic code is  
>> > still in.  
>> >  
>> > Other than Spark 1.6 and Ignite, I don’t see any reason at all for a  
>> 0.5.6  
>> > release. (Konstantin was right — it is good for Apache releases to  
>> > maintain version compatibility with new versions of other Apache  
>> software.  
>> > That is Apache projects helping each other.)  
>> >  
>> > What feature do you feel justifies a 0.5.6 release? What feature other  
>> > than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?  
>> >  
>> > From: Jongyoul Lee <jo...@gmail.com>  
>> > Reply: Jongyoul Lee <jo...@gmail.com>  
>> > Date: December 30, 2015 at 12:32:01 AM  
>> > To: Amos B. Elberg <am...@gmail.com>  
>> > CC: dev@zeppelin.incubator.apache.org <  
>> dev@zeppelin.incubator.apache.org>  
>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>> >  
>> > Amos,  
>> >  
>> > I don't think we have a strict plan for making a minor release and we  
>> have  
>> > a roadmap for major release. And ignite and Spark 1.6 is not a key  
>> feature  
>> > of 0.5.6. Konstantin just wanted to be merged that contribution if that  
>> > voting is finished until we make a release. And Spark 1.6 is on going.  
>> As  
>> > you told, we are an Apache project. 0.5.6 will be stable and  
>> maintainable.  
>> > If 0.5.6 has an experimental features, I don't agree to make a release.  
>> > 0.5.6 will be more stable version of 0.5.5. And of course, the most  
>> people  
>> > like more stable version. Isn't it enough?  
>> >  
>> > Regards,  
>> > Jongyoul  
>> >  
>> > On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>  
>> > wrote:  
>> > My suggestion is that we do a 0.5.6 that just has the bare minimal  
>> changes  
>> > necessary for Spark 1.6 and Ignite and nothing else.  
>> >  
>> > That way we provide “must have” features while minimizing risk.  
>> >  
>> > Other than that, yes: I think we should keep our current release plan  
>> and  
>> > not make a release for “nice to have” changes until CI is fixed.  
>> >  
>> > The main purpose of making a new minor release should be whether already  
>> > merged features are meaningful to make a minor release even if any major  
>> > issues are on going, isn't it?  
>> >  
>> > I’m not sure that I understand what you are asking.  
>> >  
>> > We have a planned 0.6 release. We just did an unplanned “minor” 0.5.5  
>> > release. It feels like only a few weeks ago. I voted for it because it  
>> > seemed that it would stabilize the codebase and provide a maintainable  
>> > interim foundation.  
>> >  
>> > I do not think any of the features since 0.5.5 are “meaningful” enough  
>> to  
>> > justify changing the release plan. Not even close. I think it is rare  
>> > that any off-roadmap “nice to have” feature would ever be a good reason  
>> to  
>> > change a release plan. Especially when our CI “house” is not in order.  
>> >  
>> > We’re an Apache project — we need to be stable, maintainable, reliable,  
>> > predictable.  
>> >  
>> > Is there any merged PR that is so important it can’t wait for 0.6?  
>> >  
>> > From: Jongyoul Lee <jo...@gmail.com>  
>> > Reply: Jongyoul Lee <jo...@gmail.com>  
>> > Date: December 29, 2015 at 11:54:35 PM  
>> > To: Amos B. Elberg <am...@gmail.com>  
>> > CC: dev@zeppelin.incubator.apache.org <  
>> dev@zeppelin.incubator.apache.org>  
>> >  
>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>> >  
>> > Okay, Amos,  
>> >  
>> > Do you propose Zeppelin should not have another release before fix CI  
>> > issue? I think even though CI has some problems, another minors fixes is  
>> > meaningful to make a new minor release. Do you agree with that? Or don't  
>> > you agree that it's enough? The main purpose of making a new minor  
>> release  
>> > should be whether already merged features are meaningful to make a minor  
>> > release even if any major issues are on going, isn't it?  
>> >  
>> > Regards,  
>> > Jongyoul  
>> >  
>> > On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>  
>> > wrote:  
>> > Hah!  
>> >  
>> > I promise you, an hour after a 0.5.6 comes out, I will have emails  
>> asking  
>> > me when I will support 0.5.6, even if no-one actually needs any 0.5.6  
>> > changes or even knows what they are!  
>> >  
>> > I want to be clear though: My primary issue for 0.5.6 is not whether to  
>> > merge the R interpreter.  
>> >  
>> > My issues are I think we need to fix CI in general, and I’m loathe to  
>> have  
>> > more releases with that dammed spark-under-zeppelin code, which is the  
>> root  
>> > of many other issues.  
>> >  
>> >  
>> > From: Jongyoul Lee <jo...@gmail.com>  
>> > Reply: Jongyoul Lee <jo...@gmail.com>  
>> > Date: December 29, 2015 at 11:21:00 PM  
>> > To: Amos B. Elberg <am...@gmail.com>,  
>> > dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
>> >  
>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>> >  
>> > Okay, I understand your situation. If you rebased your PR from master,  
>> you  
>> > can rebased your PR only once but I also know why you had to do that. I  
>> > think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How  
>> > about you?  
>> >  
>> > On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>  
>> > wrote:  
>> > Jongyoul - the reason we have to rebase twice is that the changes in  
>> > zeppelin-master will break the R interpreter.  
>> >  
>> > So I’ll have to rebase once so that I’m based off of 0.5.6 and people  
>> can  
>> > use the code. Then rebase again for 0.6.0.  
>> >  
>> > Remember, I have a user base I need to support — there are a lot of  
>> people  
>> > using the R interpreter now. So its not just a PR where I can ignore it  
>> > until its ready to merge.  
>> >  
>> > The changes have already broken the shiro PR apparently quite often.  
>> >  
>> > I made a “release” of the R Interpreter just so I could stop rebasing  
>> > against Zeppelin master. I spent > 60 hours dealing with this for the  
>> > changes leading up to 0.5 and 0.5.5.  
>> >  
>> > From: Jongyoul Lee <jo...@gmail.com>  
>> > Reply: Jongyoul Lee <jo...@gmail.com>  
>> > Date: December 29, 2015 at 11:08:36 PM  
>> > To: Amos B. Elberg <am...@gmail.com>  
>> >  
>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>> >  
>> > I don't know why you should rebased twice. If you can make a PR from  
>> > current master, almost changes merged without rebasing and if a  
>> committer  
>> > asks to rebase your PR, this is because you and another contributors  
>> > changes the same codes and another contributions is merged before your  
>> PR.  
>> > In specific R case, Moon want you to rebase because he tries to fix the  
>> > testing codes so rebasing your PR will accepts their changes. In most  
>> case,  
>> > contributors don't need to rebase their PR before merge because  
>> committer  
>> > commit someone's PR by doing cherry-pick. We also felt sorry that you  
>> were  
>> > bothered by testing issue and Moon is fighting to fix the testing infra.  
>> > However all of PRs shouldn't be rebased.  
>> >  
>> > On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <amos.elberg@gmail.com  
>> >  
>> > wrote:  
>> > I think there is no big pain because whole changes to be merged  
>> > into 0.5.6 will be also merged into 0.6.0.  
>> >  
>> > If we make another release now, the PRs will have to be rebased *twice*,  
>> > once for 0.5.6, and once again for 0.6.  
>> >  
>> > Also - since this is now the second e-mail from a committer to do the  
>> same  
>> > thing — is there a reason you guys are leaving R out of the agenda for  
>> the  
>> > next release? I understood the PR had been accepted and was pending only  
>> > Moon fixing the testing infrastructure.  
>> >  
>> >  
>> > From: Jongyoul Lee <jo...@gmail.com>  
>> > Reply: dev@zeppelin.incubator.apache.org <  
>> > dev@zeppelin.incubator.apache.org>  
>> > Date: December 29, 2015 at 10:56:33 PM  
>> >  
>> > To: dev@zeppelin.incubator.apache.org <  
>> dev@zeppelin.incubator.apache.org>  
>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>> >  
>> > Good idea!  
>> >  
>> > 0.5.6 is a minor release thus fixing minor bugs and typos is enough.  
>> But I  
>> > also think 0.6.0 should have major changes like supporting spark 1.6 and  
>> > Shiro security and improving testing infra. And concerning rebasing and  
>> > committing, I think there is no big pain because whole changes to be  
>> merged  
>> > into 0.5.6 will be also merged into 0.6.0.  
>> >  
>> > JL  
>> >  
>> > On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <amos.elberg@gmail.com  
>> >  
>> > wrote:  
>> >  
>> > > I don’t want to come off as the naysayer here, but I think the effort  
>> > that  
>> > > would go into a release would be better spent on the testing  
>> > infrastructure  
>> > > and outstanding PRs.  
>> > >  
>> > > If we feel we need a release for 1.6 and Ignite, I suggest we make a  
>> > > release that *only* includes the absolute minimal changes required to  
>> do  
>> > > that.  
>> > >  
>> > > There was one PR for 1.6 support that didn’t really work and is going  
>> to  
>> > > break anything built against the current codebase. Except for a  
>> change in  
>> > > the name of one method called by one class, all of the changes seem to  
>> > > involve support for spark-under-zeppelin, which is something we want  
>> to  
>> > > take out.  
>> > >  
>> > > We also don’t currently have a working testing framework. A lot of PRs  
>> > > have been committed under the “ignore travis its broken” theory. I’m  
>> > > loathe to make a release that hasn’t really been tested, and it  
>> doesn’t  
>> > > seem we’re in a position to do that.  
>> > >  
>> > > While there have been a lot of merged PRs, I don’t think any of them  
>> are  
>> > > on-roadmap. They mostly seem to be very minor, like fixing typos and  
>> > > changing which text box gets highlighted. Those are important things,  
>> of  
>> > > course, but not major enough to justify the effort involved in a  
>> release.  
>> > >  
>> > > Another release will not make it easier to integrate the larger PRs.  
>> It  
>> > > will have the opposite effect. Developers will have to rebase against  
>> > > whatever gets broken by 1.6 and other changes.  
>> > >  
>> > > I suggest we wait to do a significant release until we can take out  
>> the  
>> > > legacy spark-under-zeppelin code that has caused so many issues, have  
>> a  
>> > > working testing framework, and integrate the major outstanding PRs.  
>> > >  
>> > > So, again, if we want a release, I suggest we include the absolute  
>> > minimum  
>> > > changes necessary for 1.6 and Ignite, and perhaps call it an interim  
>> or  
>> > > maintenance release.  
>> > >  
>> > >  
>> > > From: Konstantin Boudnik <co...@apache.org>  
>> > > Reply: dev@zeppelin.incubator.apache.org <  
>> > > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org  
>> <  
>> > > dev@zeppelin.incubator.apache.org>  
>> > > Date: December 29, 2015 at 10:05:36 PM  
>> > > To: dev@zeppelin.incubator.apache.org <  
>> dev@zeppelin.incubator.apache.org  
>> > >  
>> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>> > >  
>> > > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -  
>> would  
>> > > make  
>> > > sense to add this to the latest release of Zeppelin. I will open a  
>> JIRA  
>> > and  
>> > > supply a patch for it, if there's no objections.  
>> > >  
>> > > Cos  
>> > >  
>> > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:  
>> > > > Hi folks,  
>> > > >  
>> > > > How about we make release 0.5.6-incubating?  
>> > > >  
>> > > > Since last release, more than 100 pull requests are merged and more  
>> > than  
>> > > 80  
>> > > > issues are resolved.  
>> > > >  
>> > > > It's including new interpreters, a lot of new features and  
>> improvement  
>> > on  
>> > > > GUI with much improved stability thanks to lots of bug fixes.  
>> > > >  
>> > > > Also it's great time to have a Zeppelin release that support Spark  
>> 1.6  
>> > (  
>> > > > ZEPPELIN-395), which about to be released.  
>> > > >  
>> > > > Once we branch for 0.5.6-incubating release, it's more safe to make  
>> > large  
>> > > > code base change such as "Added Shiro security" (  
>> > > > https://github.com/apache/incubator-zeppelin/pull/53) and many  
>> other  
>> > > > planned feature in 0.6.0 roadmap, that will require lots of internal  
>> > API  
>> > > > updates.  
>> > > >  
>> > > > What do you think?  
>> > > >  
>> > > > Thanks,  
>> > > > moon  
>> > >  
>> >  
>> >  
>> >  
>> > --  
>> > 이종열, Jongyoul Lee, 李宗烈  
>> > http://madeng.net  
>> >  
>> >  
>> >  
>> > --  
>> > 이종열, Jongyoul Lee, 李宗烈  
>> > http://madeng.net  
>> >  
>> >  
>> >  
>> > --  
>> > 이종열, Jongyoul Lee, 李宗烈  
>> > http://madeng.net  
>> >  
>> >  
>> >  
>> > --  
>> > 이종열, Jongyoul Lee, 李宗烈  
>> > http://madeng.net  
>> >  
>> >  
>> >  
>> > --  
>> > 이종열, Jongyoul Lee, 李宗烈  
>> > http://madeng.net  
>> >  
>>  
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by moon soo Lee <mo...@apache.org>.
Amos,

I don't think you or anyone here can define which contributions are more
meaningful or which contributions are not.

That's totally irrelevant thing for the release discussion.

Thanks,
moon

On Tue, Dec 29, 2015 at 10:12 PM moon soo Lee <mo...@apache.org> wrote:

> Amos,
>
> CI is definitely working. Although it's got some flickering test, they're
> all
> false positive. It doesn't harm any code quality. So even flickering test
> are testing the code correctly. And we're addressing them [1].
>
> Those false positive tests happens in around 6% of chance according to my
> experiment [2], i don't think they're making project unmaintainable at all.
>
> If you tell me why you think  "CI isn’t working.", that would be really
> helpful to understand why do you think it's blocker for the release.
>
> Thanks,
> moon
>
> [1]
> https://issues.apache.org/jira/browse/ZEPPELIN-476?jql=labels%20%3D%20flaky-test%20and%20project%20%3D%20zeppelin
> [2] https://github.com/apache/incubator-zeppelin/pull/527
>
> On Tue, Dec 29, 2015 at 10:08 PM Amos B. Elberg <am...@gmail.com>
> wrote:
>
>> I’m not the only person who gets a vote, so after I reply to Jongyoul, I
>> will not say anything more on this subject.  I think my view is pretty
>> clear.
>>
>> I will add that I just reviewed all of those commits.
>>
>> They are all minor improvements to the UI.  Things like whether a
>> background gets greyed out when a pop-up appears.  Two of them could be
>> viewed as fixes for minor UI issues.  None of them relates to any stability
>> issues in Zeppelin.
>>
>> For most of them I had trouble spotting whether anything had changed,
>> even with the helpful screenshots.
>>
>> I don’t think any of them, or all of them together, are a reason for a
>> release.
>>
>> From: Corneau Damien <co...@gmail.com>
>> Reply: dev@zeppelin.incubator.apache.org <
>> dev@zeppelin.incubator.apache.org>
>> Date: December 30, 2015 at 12:51:50 AM
>> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>> CC: Jongyoul Lee <jo...@gmail.com>
>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>
>> I don't think minor releases needs be planned (feature wise),
>> its something we should do when we feel the need that we fixed or improved
>> something important.
>> We even talked at some point of doing some more periodic releases.
>>
>> I see a lot of good benefits from making a new minor release, especially
>> bug fix wise.
>>
>> https://github.com/apache/incubator-zeppelin/pull/580
>>
>> https://github.com/apache/incubator-zeppelin/commit/47eb95aeeefa8925ef5b49487b967f40ad451454
>>
>> https://github.com/apache/incubator-zeppelin/commit/f0d3c3f0e3e898b5625a1d3745a701271905c22c
>>
>> https://github.com/apache/incubator-zeppelin/commit/4a1edd525b31e5c6de41c3598ce921b82b7abeeb
>>
>> https://github.com/apache/incubator-zeppelin/commit/71c1af84a1c4f285842dfd5c85fc99ffc4bfca26
>>
>> https://github.com/apache/incubator-zeppelin/commit/d90e3805bb2d2434bc08672a6227c0afc927f6ae
>>
>> https://github.com/apache/incubator-zeppelin/commit/986b0adba3a7986a387c0633d15279b6b2f45c95
>>
>> On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com>
>> wrote:
>>
>> > A codebase that often changes in ways that break other code is an
>> unstable
>> > codebase, by definition.
>> >
>> > I don’t think it will be more stable at runtime, especially since CI
>> isn’t
>> > working.
>> >
>> > It definitely won’t be more maintainable. The key problematic code is
>> > still in.
>> >
>> > Other than Spark 1.6 and Ignite, I don’t see any reason at all for a
>> 0.5.6
>> > release. (Konstantin was right — it is good for Apache releases to
>> > maintain version compatibility with new versions of other Apache
>> software.
>> > That is Apache projects helping each other.)
>> >
>> > What feature do you feel justifies a 0.5.6 release? What feature other
>> > than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
>> >
>> > From: Jongyoul Lee <jo...@gmail.com>
>> > Reply: Jongyoul Lee <jo...@gmail.com>
>> > Date: December 30, 2015 at 12:32:01 AM
>> > To: Amos B. Elberg <am...@gmail.com>
>> > CC: dev@zeppelin.incubator.apache.org <
>> dev@zeppelin.incubator.apache.org>
>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
>> >
>> > Amos,
>> >
>> > I don't think we have a strict plan for making a minor release and we
>> have
>> > a roadmap for major release. And ignite and Spark 1.6 is not a key
>> feature
>> > of 0.5.6. Konstantin just wanted to be merged that contribution if that
>> > voting is finished until we make a release. And Spark 1.6 is on going.
>> As
>> > you told, we are an Apache project. 0.5.6 will be stable and
>> maintainable.
>> > If 0.5.6 has an experimental features, I don't agree to make a release.
>> > 0.5.6 will be more stable version of 0.5.5. And of course, the most
>> people
>> > like more stable version. Isn't it enough?
>> >
>> > Regards,
>> > Jongyoul
>> >
>> > On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>
>> > wrote:
>> > My suggestion is that we do a 0.5.6 that just has the bare minimal
>> changes
>> > necessary for Spark 1.6 and Ignite and nothing else.
>> >
>> > That way we provide “must have” features while minimizing risk.
>> >
>> > Other than that, yes: I think we should keep our current release plan
>> and
>> > not make a release for “nice to have” changes until CI is fixed.
>> >
>> > The main purpose of making a new minor release should be whether already
>> > merged features are meaningful to make a minor release even if any major
>> > issues are on going, isn't it?
>> >
>> > I’m not sure that I understand what you are asking.
>> >
>> > We have a planned 0.6 release. We just did an unplanned “minor” 0.5.5
>> > release. It feels like only a few weeks ago. I voted for it because it
>> > seemed that it would stabilize the codebase and provide a maintainable
>> > interim foundation.
>> >
>> > I do not think any of the features since 0.5.5 are “meaningful” enough
>> to
>> > justify changing the release plan. Not even close. I think it is rare
>> > that any off-roadmap “nice to have” feature would ever be a good reason
>> to
>> > change a release plan. Especially when our CI “house” is not in order.
>> >
>> > We’re an Apache project — we need to be stable, maintainable, reliable,
>> > predictable.
>> >
>> > Is there any merged PR that is so important it can’t wait for 0.6?
>> >
>> > From: Jongyoul Lee <jo...@gmail.com>
>> > Reply: Jongyoul Lee <jo...@gmail.com>
>> > Date: December 29, 2015 at 11:54:35 PM
>> > To: Amos B. Elberg <am...@gmail.com>
>> > CC: dev@zeppelin.incubator.apache.org <
>> dev@zeppelin.incubator.apache.org>
>> >
>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
>> >
>> > Okay, Amos,
>> >
>> > Do you propose Zeppelin should not have another release before fix CI
>> > issue? I think even though CI has some problems, another minors fixes is
>> > meaningful to make a new minor release. Do you agree with that? Or don't
>> > you agree that it's enough? The main purpose of making a new minor
>> release
>> > should be whether already merged features are meaningful to make a minor
>> > release even if any major issues are on going, isn't it?
>> >
>> > Regards,
>> > Jongyoul
>> >
>> > On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>
>> > wrote:
>> > Hah!
>> >
>> > I promise you, an hour after a 0.5.6 comes out, I will have emails
>> asking
>> > me when I will support 0.5.6, even if no-one actually needs any 0.5.6
>> > changes or even knows what they are!
>> >
>> > I want to be clear though: My primary issue for 0.5.6 is not whether to
>> > merge the R interpreter.
>> >
>> > My issues are I think we need to fix CI in general, and I’m loathe to
>> have
>> > more releases with that dammed spark-under-zeppelin code, which is the
>> root
>> > of many other issues.
>> >
>> >
>> > From: Jongyoul Lee <jo...@gmail.com>
>> > Reply: Jongyoul Lee <jo...@gmail.com>
>> > Date: December 29, 2015 at 11:21:00 PM
>> > To: Amos B. Elberg <am...@gmail.com>,
>> > dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>> >
>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
>> >
>> > Okay, I understand your situation. If you rebased your PR from master,
>> you
>> > can rebased your PR only once but I also know why you had to do that. I
>> > think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
>> > about you?
>> >
>> > On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
>> > wrote:
>> > Jongyoul - the reason we have to rebase twice is that the changes in
>> > zeppelin-master will break the R interpreter.
>> >
>> > So I’ll have to rebase once so that I’m based off of 0.5.6 and people
>> can
>> > use the code. Then rebase again for 0.6.0.
>> >
>> > Remember, I have a user base I need to support — there are a lot of
>> people
>> > using the R interpreter now. So its not just a PR where I can ignore it
>> > until its ready to merge.
>> >
>> > The changes have already broken the shiro PR apparently quite often.
>> >
>> > I made a “release” of the R Interpreter just so I could stop rebasing
>> > against Zeppelin master. I spent > 60 hours dealing with this for the
>> > changes leading up to 0.5 and 0.5.5.
>> >
>> > From: Jongyoul Lee <jo...@gmail.com>
>> > Reply: Jongyoul Lee <jo...@gmail.com>
>> > Date: December 29, 2015 at 11:08:36 PM
>> > To: Amos B. Elberg <am...@gmail.com>
>> >
>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
>> >
>> > I don't know why you should rebased twice. If you can make a PR from
>> > current master, almost changes merged without rebasing and if a
>> committer
>> > asks to rebase your PR, this is because you and another contributors
>> > changes the same codes and another contributions is merged before your
>> PR.
>> > In specific R case, Moon want you to rebase because he tries to fix the
>> > testing codes so rebasing your PR will accepts their changes. In most
>> case,
>> > contributors don't need to rebase their PR before merge because
>> committer
>> > commit someone's PR by doing cherry-pick. We also felt sorry that you
>> were
>> > bothered by testing issue and Moon is fighting to fix the testing infra.
>> > However all of PRs shouldn't be rebased.
>> >
>> > On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <amos.elberg@gmail.com
>> >
>> > wrote:
>> > I think there is no big pain because whole changes to be merged
>> > into 0.5.6 will be also merged into 0.6.0.
>> >
>> > If we make another release now, the PRs will have to be rebased *twice*,
>> > once for 0.5.6, and once again for 0.6.
>> >
>> > Also - since this is now the second e-mail from a committer to do the
>> same
>> > thing — is there a reason you guys are leaving R out of the agenda for
>> the
>> > next release? I understood the PR had been accepted and was pending only
>> > Moon fixing the testing infrastructure.
>> >
>> >
>> > From: Jongyoul Lee <jo...@gmail.com>
>> > Reply: dev@zeppelin.incubator.apache.org <
>> > dev@zeppelin.incubator.apache.org>
>> > Date: December 29, 2015 at 10:56:33 PM
>> >
>> > To: dev@zeppelin.incubator.apache.org <
>> dev@zeppelin.incubator.apache.org>
>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
>> >
>> > Good idea!
>> >
>> > 0.5.6 is a minor release thus fixing minor bugs and typos is enough.
>> But I
>> > also think 0.6.0 should have major changes like supporting spark 1.6 and
>> > Shiro security and improving testing infra. And concerning rebasing and
>> > committing, I think there is no big pain because whole changes to be
>> merged
>> > into 0.5.6 will be also merged into 0.6.0.
>> >
>> > JL
>> >
>> > On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <amos.elberg@gmail.com
>> >
>> > wrote:
>> >
>> > > I don’t want to come off as the naysayer here, but I think the effort
>> > that
>> > > would go into a release would be better spent on the testing
>> > infrastructure
>> > > and outstanding PRs.
>> > >
>> > > If we feel we need a release for 1.6 and Ignite, I suggest we make a
>> > > release that *only* includes the absolute minimal changes required to
>> do
>> > > that.
>> > >
>> > > There was one PR for 1.6 support that didn’t really work and is going
>> to
>> > > break anything built against the current codebase. Except for a
>> change in
>> > > the name of one method called by one class, all of the changes seem to
>> > > involve support for spark-under-zeppelin, which is something we want
>> to
>> > > take out.
>> > >
>> > > We also don’t currently have a working testing framework. A lot of PRs
>> > > have been committed under the “ignore travis its broken” theory. I’m
>> > > loathe to make a release that hasn’t really been tested, and it
>> doesn’t
>> > > seem we’re in a position to do that.
>> > >
>> > > While there have been a lot of merged PRs, I don’t think any of them
>> are
>> > > on-roadmap. They mostly seem to be very minor, like fixing typos and
>> > > changing which text box gets highlighted. Those are important things,
>> of
>> > > course, but not major enough to justify the effort involved in a
>> release.
>> > >
>> > > Another release will not make it easier to integrate the larger PRs.
>> It
>> > > will have the opposite effect. Developers will have to rebase against
>> > > whatever gets broken by 1.6 and other changes.
>> > >
>> > > I suggest we wait to do a significant release until we can take out
>> the
>> > > legacy spark-under-zeppelin code that has caused so many issues, have
>> a
>> > > working testing framework, and integrate the major outstanding PRs.
>> > >
>> > > So, again, if we want a release, I suggest we include the absolute
>> > minimum
>> > > changes necessary for 1.6 and Ignite, and perhaps call it an interim
>> or
>> > > maintenance release.
>> > >
>> > >
>> > > From: Konstantin Boudnik <co...@apache.org>
>> > > Reply: dev@zeppelin.incubator.apache.org <
>> > > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org
>> <
>> > > dev@zeppelin.incubator.apache.org>
>> > > Date: December 29, 2015 at 10:05:36 PM
>> > > To: dev@zeppelin.incubator.apache.org <
>> dev@zeppelin.incubator.apache.org
>> > >
>> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
>> > >
>> > > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -
>> would
>> > > make
>> > > sense to add this to the latest release of Zeppelin. I will open a
>> JIRA
>> > and
>> > > supply a patch for it, if there's no objections.
>> > >
>> > > Cos
>> > >
>> > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
>> > > > Hi folks,
>> > > >
>> > > > How about we make release 0.5.6-incubating?
>> > > >
>> > > > Since last release, more than 100 pull requests are merged and more
>> > than
>> > > 80
>> > > > issues are resolved.
>> > > >
>> > > > It's including new interpreters, a lot of new features and
>> improvement
>> > on
>> > > > GUI with much improved stability thanks to lots of bug fixes.
>> > > >
>> > > > Also it's great time to have a Zeppelin release that support Spark
>> 1.6
>> > (
>> > > > ZEPPELIN-395), which about to be released.
>> > > >
>> > > > Once we branch for 0.5.6-incubating release, it's more safe to make
>> > large
>> > > > code base change such as "Added Shiro security" (
>> > > > https://github.com/apache/incubator-zeppelin/pull/53) and many
>> other
>> > > > planned feature in 0.6.0 roadmap, that will require lots of internal
>> > API
>> > > > updates.
>> > > >
>> > > > What do you think?
>> > > >
>> > > > Thanks,
>> > > > moon
>> > >
>> >
>> >
>> >
>> > --
>> > 이종열, Jongyoul Lee, 李宗烈
>> > http://madeng.net
>> >
>> >
>> >
>> > --
>> > 이종열, Jongyoul Lee, 李宗烈
>> > http://madeng.net
>> >
>> >
>> >
>> > --
>> > 이종열, Jongyoul Lee, 李宗烈
>> > http://madeng.net
>> >
>> >
>> >
>> > --
>> > 이종열, Jongyoul Lee, 李宗烈
>> > http://madeng.net
>> >
>> >
>> >
>> > --
>> > 이종열, Jongyoul Lee, 李宗烈
>> > http://madeng.net
>> >
>>
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by moon soo Lee <mo...@apache.org>.
Amos,

CI is definitely working. Although it's got some flickering test, they're
all
false positive. It doesn't harm any code quality. So even flickering test
are testing the code correctly. And we're addressing them [1].

Those false positive tests happens in around 6% of chance according to my
experiment [2], i don't think they're making project unmaintainable at all.

If you tell me why you think  "CI isn’t working.", that would be really
helpful to understand why do you think it's blocker for the release.

Thanks,
moon

[1]
https://issues.apache.org/jira/browse/ZEPPELIN-476?jql=labels%20%3D%20flaky-test%20and%20project%20%3D%20zeppelin
[2] https://github.com/apache/incubator-zeppelin/pull/527

On Tue, Dec 29, 2015 at 10:08 PM Amos B. Elberg <am...@gmail.com>
wrote:

> I’m not the only person who gets a vote, so after I reply to Jongyoul, I
> will not say anything more on this subject.  I think my view is pretty
> clear.
>
> I will add that I just reviewed all of those commits.
>
> They are all minor improvements to the UI.  Things like whether a
> background gets greyed out when a pop-up appears.  Two of them could be
> viewed as fixes for minor UI issues.  None of them relates to any stability
> issues in Zeppelin.
>
> For most of them I had trouble spotting whether anything had changed, even
> with the helpful screenshots.
>
> I don’t think any of them, or all of them together, are a reason for a
> release.
>
> From: Corneau Damien <co...@gmail.com>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 30, 2015 at 12:51:50 AM
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> CC: Jongyoul Lee <jo...@gmail.com>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> I don't think minor releases needs be planned (feature wise),
> its something we should do when we feel the need that we fixed or improved
> something important.
> We even talked at some point of doing some more periodic releases.
>
> I see a lot of good benefits from making a new minor release, especially
> bug fix wise.
>
> https://github.com/apache/incubator-zeppelin/pull/580
>
> https://github.com/apache/incubator-zeppelin/commit/47eb95aeeefa8925ef5b49487b967f40ad451454
>
> https://github.com/apache/incubator-zeppelin/commit/f0d3c3f0e3e898b5625a1d3745a701271905c22c
>
> https://github.com/apache/incubator-zeppelin/commit/4a1edd525b31e5c6de41c3598ce921b82b7abeeb
>
> https://github.com/apache/incubator-zeppelin/commit/71c1af84a1c4f285842dfd5c85fc99ffc4bfca26
>
> https://github.com/apache/incubator-zeppelin/commit/d90e3805bb2d2434bc08672a6227c0afc927f6ae
>
> https://github.com/apache/incubator-zeppelin/commit/986b0adba3a7986a387c0633d15279b6b2f45c95
>
> On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
>
> > A codebase that often changes in ways that break other code is an
> unstable
> > codebase, by definition.
> >
> > I don’t think it will be more stable at runtime, especially since CI
> isn’t
> > working.
> >
> > It definitely won’t be more maintainable. The key problematic code is
> > still in.
> >
> > Other than Spark 1.6 and Ignite, I don’t see any reason at all for a
> 0.5.6
> > release. (Konstantin was right — it is good for Apache releases to
> > maintain version compatibility with new versions of other Apache
> software.
> > That is Apache projects helping each other.)
> >
> > What feature do you feel justifies a 0.5.6 release? What feature other
> > than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 30, 2015 at 12:32:01 AM
> > To: Amos B. Elberg <am...@gmail.com>
> > CC: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Amos,
> >
> > I don't think we have a strict plan for making a minor release and we
> have
> > a roadmap for major release. And ignite and Spark 1.6 is not a key
> feature
> > of 0.5.6. Konstantin just wanted to be merged that contribution if that
> > voting is finished until we make a release. And Spark 1.6 is on going. As
> > you told, we are an Apache project. 0.5.6 will be stable and
> maintainable.
> > If 0.5.6 has an experimental features, I don't agree to make a release.
> > 0.5.6 will be more stable version of 0.5.5. And of course, the most
> people
> > like more stable version. Isn't it enough?
> >
> > Regards,
> > Jongyoul
> >
> > On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > My suggestion is that we do a 0.5.6 that just has the bare minimal
> changes
> > necessary for Spark 1.6 and Ignite and nothing else.
> >
> > That way we provide “must have” features while minimizing risk.
> >
> > Other than that, yes: I think we should keep our current release plan and
> > not make a release for “nice to have” changes until CI is fixed.
> >
> > The main purpose of making a new minor release should be whether already
> > merged features are meaningful to make a minor release even if any major
> > issues are on going, isn't it?
> >
> > I’m not sure that I understand what you are asking.
> >
> > We have a planned 0.6 release. We just did an unplanned “minor” 0.5.5
> > release. It feels like only a few weeks ago. I voted for it because it
> > seemed that it would stabilize the codebase and provide a maintainable
> > interim foundation.
> >
> > I do not think any of the features since 0.5.5 are “meaningful” enough to
> > justify changing the release plan. Not even close. I think it is rare
> > that any off-roadmap “nice to have” feature would ever be a good reason
> to
> > change a release plan. Especially when our CI “house” is not in order.
> >
> > We’re an Apache project — we need to be stable, maintainable, reliable,
> > predictable.
> >
> > Is there any merged PR that is so important it can’t wait for 0.6?
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 29, 2015 at 11:54:35 PM
> > To: Amos B. Elberg <am...@gmail.com>
> > CC: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Okay, Amos,
> >
> > Do you propose Zeppelin should not have another release before fix CI
> > issue? I think even though CI has some problems, another minors fixes is
> > meaningful to make a new minor release. Do you agree with that? Or don't
> > you agree that it's enough? The main purpose of making a new minor
> release
> > should be whether already merged features are meaningful to make a minor
> > release even if any major issues are on going, isn't it?
> >
> > Regards,
> > Jongyoul
> >
> > On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > Hah!
> >
> > I promise you, an hour after a 0.5.6 comes out, I will have emails asking
> > me when I will support 0.5.6, even if no-one actually needs any 0.5.6
> > changes or even knows what they are!
> >
> > I want to be clear though: My primary issue for 0.5.6 is not whether to
> > merge the R interpreter.
> >
> > My issues are I think we need to fix CI in general, and I’m loathe to
> have
> > more releases with that dammed spark-under-zeppelin code, which is the
> root
> > of many other issues.
> >
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 29, 2015 at 11:21:00 PM
> > To: Amos B. Elberg <am...@gmail.com>,
> > dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Okay, I understand your situation. If you rebased your PR from master,
> you
> > can rebased your PR only once but I also know why you had to do that. I
> > think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
> > about you?
> >
> > On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > Jongyoul - the reason we have to rebase twice is that the changes in
> > zeppelin-master will break the R interpreter.
> >
> > So I’ll have to rebase once so that I’m based off of 0.5.6 and people can
> > use the code. Then rebase again for 0.6.0.
> >
> > Remember, I have a user base I need to support — there are a lot of
> people
> > using the R interpreter now. So its not just a PR where I can ignore it
> > until its ready to merge.
> >
> > The changes have already broken the shiro PR apparently quite often.
> >
> > I made a “release” of the R Interpreter just so I could stop rebasing
> > against Zeppelin master. I spent > 60 hours dealing with this for the
> > changes leading up to 0.5 and 0.5.5.
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: Jongyoul Lee <jo...@gmail.com>
> > Date: December 29, 2015 at 11:08:36 PM
> > To: Amos B. Elberg <am...@gmail.com>
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > I don't know why you should rebased twice. If you can make a PR from
> > current master, almost changes merged without rebasing and if a committer
> > asks to rebase your PR, this is because you and another contributors
> > changes the same codes and another contributions is merged before your
> PR.
> > In specific R case, Moon want you to rebase because he tries to fix the
> > testing codes so rebasing your PR will accepts their changes. In most
> case,
> > contributors don't need to rebase their PR before merge because committer
> > commit someone's PR by doing cherry-pick. We also felt sorry that you
> were
> > bothered by testing issue and Moon is fighting to fix the testing infra.
> > However all of PRs shouldn't be rebased.
> >
> > On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> > I think there is no big pain because whole changes to be merged
> > into 0.5.6 will be also merged into 0.6.0.
> >
> > If we make another release now, the PRs will have to be rebased *twice*,
> > once for 0.5.6, and once again for 0.6.
> >
> > Also - since this is now the second e-mail from a committer to do the
> same
> > thing — is there a reason you guys are leaving R out of the agenda for
> the
> > next release? I understood the PR had been accepted and was pending only
> > Moon fixing the testing infrastructure.
> >
> >
> > From: Jongyoul Lee <jo...@gmail.com>
> > Reply: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>
> > Date: December 29, 2015 at 10:56:33 PM
> >
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Good idea!
> >
> > 0.5.6 is a minor release thus fixing minor bugs and typos is enough. But
> I
> > also think 0.6.0 should have major changes like supporting spark 1.6 and
> > Shiro security and improving testing infra. And concerning rebasing and
> > committing, I think there is no big pain because whole changes to be
> merged
> > into 0.5.6 will be also merged into 0.6.0.
> >
> > JL
> >
> > On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
> > wrote:
> >
> > > I don’t want to come off as the naysayer here, but I think the effort
> > that
> > > would go into a release would be better spent on the testing
> > infrastructure
> > > and outstanding PRs.
> > >
> > > If we feel we need a release for 1.6 and Ignite, I suggest we make a
> > > release that *only* includes the absolute minimal changes required to
> do
> > > that.
> > >
> > > There was one PR for 1.6 support that didn’t really work and is going
> to
> > > break anything built against the current codebase. Except for a change
> in
> > > the name of one method called by one class, all of the changes seem to
> > > involve support for spark-under-zeppelin, which is something we want to
> > > take out.
> > >
> > > We also don’t currently have a working testing framework. A lot of PRs
> > > have been committed under the “ignore travis its broken” theory. I’m
> > > loathe to make a release that hasn’t really been tested, and it doesn’t
> > > seem we’re in a position to do that.
> > >
> > > While there have been a lot of merged PRs, I don’t think any of them
> are
> > > on-roadmap. They mostly seem to be very minor, like fixing typos and
> > > changing which text box gets highlighted. Those are important things,
> of
> > > course, but not major enough to justify the effort involved in a
> release.
> > >
> > > Another release will not make it easier to integrate the larger PRs. It
> > > will have the opposite effect. Developers will have to rebase against
> > > whatever gets broken by 1.6 and other changes.
> > >
> > > I suggest we wait to do a significant release until we can take out the
> > > legacy spark-under-zeppelin code that has caused so many issues, have a
> > > working testing framework, and integrate the major outstanding PRs.
> > >
> > > So, again, if we want a release, I suggest we include the absolute
> > minimum
> > > changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> > > maintenance release.
> > >
> > >
> > > From: Konstantin Boudnik <co...@apache.org>
> > > Reply: dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org
> <
> > > dev@zeppelin.incubator.apache.org>
> > > Date: December 29, 2015 at 10:05:36 PM
> > > To: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org
> > >
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > >
> > > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -
> would
> > > make
> > > sense to add this to the latest release of Zeppelin. I will open a JIRA
> > and
> > > supply a patch for it, if there's no objections.
> > >
> > > Cos
> > >
> > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > > Hi folks,
> > > >
> > > > How about we make release 0.5.6-incubating?
> > > >
> > > > Since last release, more than 100 pull requests are merged and more
> > than
> > > 80
> > > > issues are resolved.
> > > >
> > > > It's including new interpreters, a lot of new features and
> improvement
> > on
> > > > GUI with much improved stability thanks to lots of bug fixes.
> > > >
> > > > Also it's great time to have a Zeppelin release that support Spark
> 1.6
> > (
> > > > ZEPPELIN-395), which about to be released.
> > > >
> > > > Once we branch for 0.5.6-incubating release, it's more safe to make
> > large
> > > > code base change such as "Added Shiro security" (
> > > > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > > > planned feature in 0.6.0 roadmap, that will require lots of internal
> > API
> > > > updates.
> > > >
> > > > What do you think?
> > > >
> > > > Thanks,
> > > > moon
> > >
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
> >
> >
> > --
> > 이종열, Jongyoul Lee, 李宗烈
> > http://madeng.net
> >
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by "Amos B. Elberg" <am...@gmail.com>.
I’m not the only person who gets a vote, so after I reply to Jongyoul, I will not say anything more on this subject.  I think my view is pretty clear. 

I will add that I just reviewed all of those commits.  

They are all minor improvements to the UI.  Things like whether a background gets greyed out when a pop-up appears.  Two of them could be viewed as fixes for minor UI issues.  None of them relates to any stability issues in Zeppelin.  

For most of them I had trouble spotting whether anything had changed, even with the helpful screenshots.  

I don’t think any of them, or all of them together, are a reason for a release.  

From: Corneau Damien <co...@gmail.com>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: December 30, 2015 at 12:51:50 AM
To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
CC: Jongyoul Lee <jo...@gmail.com>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating  

I don't think minor releases needs be planned (feature wise),  
its something we should do when we feel the need that we fixed or improved  
something important.  
We even talked at some point of doing some more periodic releases.  

I see a lot of good benefits from making a new minor release, especially  
bug fix wise.  

https://github.com/apache/incubator-zeppelin/pull/580  
https://github.com/apache/incubator-zeppelin/commit/47eb95aeeefa8925ef5b49487b967f40ad451454  
https://github.com/apache/incubator-zeppelin/commit/f0d3c3f0e3e898b5625a1d3745a701271905c22c  
https://github.com/apache/incubator-zeppelin/commit/4a1edd525b31e5c6de41c3598ce921b82b7abeeb  
https://github.com/apache/incubator-zeppelin/commit/71c1af84a1c4f285842dfd5c85fc99ffc4bfca26  
https://github.com/apache/incubator-zeppelin/commit/d90e3805bb2d2434bc08672a6227c0afc927f6ae  
https://github.com/apache/incubator-zeppelin/commit/986b0adba3a7986a387c0633d15279b6b2f45c95  

On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com>  
wrote:  

> A codebase that often changes in ways that break other code is an unstable  
> codebase, by definition.  
>  
> I don’t think it will be more stable at runtime, especially since CI isn’t  
> working.  
>  
> It definitely won’t be more maintainable. The key problematic code is  
> still in.  
>  
> Other than Spark 1.6 and Ignite, I don’t see any reason at all for a 0.5.6  
> release. (Konstantin was right — it is good for Apache releases to  
> maintain version compatibility with new versions of other Apache software.  
> That is Apache projects helping each other.)  
>  
> What feature do you feel justifies a 0.5.6 release? What feature other  
> than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?  
>  
> From: Jongyoul Lee <jo...@gmail.com>  
> Reply: Jongyoul Lee <jo...@gmail.com>  
> Date: December 30, 2015 at 12:32:01 AM  
> To: Amos B. Elberg <am...@gmail.com>  
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> Amos,  
>  
> I don't think we have a strict plan for making a minor release and we have  
> a roadmap for major release. And ignite and Spark 1.6 is not a key feature  
> of 0.5.6. Konstantin just wanted to be merged that contribution if that  
> voting is finished until we make a release. And Spark 1.6 is on going. As  
> you told, we are an Apache project. 0.5.6 will be stable and maintainable.  
> If 0.5.6 has an experimental features, I don't agree to make a release.  
> 0.5.6 will be more stable version of 0.5.5. And of course, the most people  
> like more stable version. Isn't it enough?  
>  
> Regards,  
> Jongyoul  
>  
> On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>  
> wrote:  
> My suggestion is that we do a 0.5.6 that just has the bare minimal changes  
> necessary for Spark 1.6 and Ignite and nothing else.  
>  
> That way we provide “must have” features while minimizing risk.  
>  
> Other than that, yes: I think we should keep our current release plan and  
> not make a release for “nice to have” changes until CI is fixed.  
>  
> The main purpose of making a new minor release should be whether already  
> merged features are meaningful to make a minor release even if any major  
> issues are on going, isn't it?  
>  
> I’m not sure that I understand what you are asking.  
>  
> We have a planned 0.6 release. We just did an unplanned “minor” 0.5.5  
> release. It feels like only a few weeks ago. I voted for it because it  
> seemed that it would stabilize the codebase and provide a maintainable  
> interim foundation.  
>  
> I do not think any of the features since 0.5.5 are “meaningful” enough to  
> justify changing the release plan. Not even close. I think it is rare  
> that any off-roadmap “nice to have” feature would ever be a good reason to  
> change a release plan. Especially when our CI “house” is not in order.  
>  
> We’re an Apache project — we need to be stable, maintainable, reliable,  
> predictable.  
>  
> Is there any merged PR that is so important it can’t wait for 0.6?  
>  
> From: Jongyoul Lee <jo...@gmail.com>  
> Reply: Jongyoul Lee <jo...@gmail.com>  
> Date: December 29, 2015 at 11:54:35 PM  
> To: Amos B. Elberg <am...@gmail.com>  
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> Okay, Amos,  
>  
> Do you propose Zeppelin should not have another release before fix CI  
> issue? I think even though CI has some problems, another minors fixes is  
> meaningful to make a new minor release. Do you agree with that? Or don't  
> you agree that it's enough? The main purpose of making a new minor release  
> should be whether already merged features are meaningful to make a minor  
> release even if any major issues are on going, isn't it?  
>  
> Regards,  
> Jongyoul  
>  
> On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>  
> wrote:  
> Hah!  
>  
> I promise you, an hour after a 0.5.6 comes out, I will have emails asking  
> me when I will support 0.5.6, even if no-one actually needs any 0.5.6  
> changes or even knows what they are!  
>  
> I want to be clear though: My primary issue for 0.5.6 is not whether to  
> merge the R interpreter.  
>  
> My issues are I think we need to fix CI in general, and I’m loathe to have  
> more releases with that dammed spark-under-zeppelin code, which is the root  
> of many other issues.  
>  
>  
> From: Jongyoul Lee <jo...@gmail.com>  
> Reply: Jongyoul Lee <jo...@gmail.com>  
> Date: December 29, 2015 at 11:21:00 PM  
> To: Amos B. Elberg <am...@gmail.com>,  
> dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> Okay, I understand your situation. If you rebased your PR from master, you  
> can rebased your PR only once but I also know why you had to do that. I  
> think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How  
> about you?  
>  
> On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>  
> wrote:  
> Jongyoul - the reason we have to rebase twice is that the changes in  
> zeppelin-master will break the R interpreter.  
>  
> So I’ll have to rebase once so that I’m based off of 0.5.6 and people can  
> use the code. Then rebase again for 0.6.0.  
>  
> Remember, I have a user base I need to support — there are a lot of people  
> using the R interpreter now. So its not just a PR where I can ignore it  
> until its ready to merge.  
>  
> The changes have already broken the shiro PR apparently quite often.  
>  
> I made a “release” of the R Interpreter just so I could stop rebasing  
> against Zeppelin master. I spent > 60 hours dealing with this for the  
> changes leading up to 0.5 and 0.5.5.  
>  
> From: Jongyoul Lee <jo...@gmail.com>  
> Reply: Jongyoul Lee <jo...@gmail.com>  
> Date: December 29, 2015 at 11:08:36 PM  
> To: Amos B. Elberg <am...@gmail.com>  
>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> I don't know why you should rebased twice. If you can make a PR from  
> current master, almost changes merged without rebasing and if a committer  
> asks to rebase your PR, this is because you and another contributors  
> changes the same codes and another contributions is merged before your PR.  
> In specific R case, Moon want you to rebase because he tries to fix the  
> testing codes so rebasing your PR will accepts their changes. In most case,  
> contributors don't need to rebase their PR before merge because committer  
> commit someone's PR by doing cherry-pick. We also felt sorry that you were  
> bothered by testing issue and Moon is fighting to fix the testing infra.  
> However all of PRs shouldn't be rebased.  
>  
> On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com>  
> wrote:  
> I think there is no big pain because whole changes to be merged  
> into 0.5.6 will be also merged into 0.6.0.  
>  
> If we make another release now, the PRs will have to be rebased *twice*,  
> once for 0.5.6, and once again for 0.6.  
>  
> Also - since this is now the second e-mail from a committer to do the same  
> thing — is there a reason you guys are leaving R out of the agenda for the  
> next release? I understood the PR had been accepted and was pending only  
> Moon fixing the testing infrastructure.  
>  
>  
> From: Jongyoul Lee <jo...@gmail.com>  
> Reply: dev@zeppelin.incubator.apache.org <  
> dev@zeppelin.incubator.apache.org>  
> Date: December 29, 2015 at 10:56:33 PM  
>  
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> Good idea!  
>  
> 0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I  
> also think 0.6.0 should have major changes like supporting spark 1.6 and  
> Shiro security and improving testing infra. And concerning rebasing and  
> committing, I think there is no big pain because whole changes to be merged  
> into 0.5.6 will be also merged into 0.6.0.  
>  
> JL  
>  
> On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>  
> wrote:  
>  
> > I don’t want to come off as the naysayer here, but I think the effort  
> that  
> > would go into a release would be better spent on the testing  
> infrastructure  
> > and outstanding PRs.  
> >  
> > If we feel we need a release for 1.6 and Ignite, I suggest we make a  
> > release that *only* includes the absolute minimal changes required to do  
> > that.  
> >  
> > There was one PR for 1.6 support that didn’t really work and is going to  
> > break anything built against the current codebase. Except for a change in  
> > the name of one method called by one class, all of the changes seem to  
> > involve support for spark-under-zeppelin, which is something we want to  
> > take out.  
> >  
> > We also don’t currently have a working testing framework. A lot of PRs  
> > have been committed under the “ignore travis its broken” theory. I’m  
> > loathe to make a release that hasn’t really been tested, and it doesn’t  
> > seem we’re in a position to do that.  
> >  
> > While there have been a lot of merged PRs, I don’t think any of them are  
> > on-roadmap. They mostly seem to be very minor, like fixing typos and  
> > changing which text box gets highlighted. Those are important things, of  
> > course, but not major enough to justify the effort involved in a release.  
> >  
> > Another release will not make it easier to integrate the larger PRs. It  
> > will have the opposite effect. Developers will have to rebase against  
> > whatever gets broken by 1.6 and other changes.  
> >  
> > I suggest we wait to do a significant release until we can take out the  
> > legacy spark-under-zeppelin code that has caused so many issues, have a  
> > working testing framework, and integrate the major outstanding PRs.  
> >  
> > So, again, if we want a release, I suggest we include the absolute  
> minimum  
> > changes necessary for 1.6 and Ignite, and perhaps call it an interim or  
> > maintenance release.  
> >  
> >  
> > From: Konstantin Boudnik <co...@apache.org>  
> > Reply: dev@zeppelin.incubator.apache.org <  
> > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <  
> > dev@zeppelin.incubator.apache.org>  
> > Date: December 29, 2015 at 10:05:36 PM  
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org  
> >  
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating  
> >  
> > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would  
> > make  
> > sense to add this to the latest release of Zeppelin. I will open a JIRA  
> and  
> > supply a patch for it, if there's no objections.  
> >  
> > Cos  
> >  
> > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:  
> > > Hi folks,  
> > >  
> > > How about we make release 0.5.6-incubating?  
> > >  
> > > Since last release, more than 100 pull requests are merged and more  
> than  
> > 80  
> > > issues are resolved.  
> > >  
> > > It's including new interpreters, a lot of new features and improvement  
> on  
> > > GUI with much improved stability thanks to lots of bug fixes.  
> > >  
> > > Also it's great time to have a Zeppelin release that support Spark 1.6  
> (  
> > > ZEPPELIN-395), which about to be released.  
> > >  
> > > Once we branch for 0.5.6-incubating release, it's more safe to make  
> large  
> > > code base change such as "Added Shiro security" (  
> > > https://github.com/apache/incubator-zeppelin/pull/53) and many other  
> > > planned feature in 0.6.0 roadmap, that will require lots of internal  
> API  
> > > updates.  
> > >  
> > > What do you think?  
> > >  
> > > Thanks,  
> > > moon  
> >  
>  
>  
>  
> --  
> 이종열, Jongyoul Lee, 李宗烈  
> http://madeng.net  
>  
>  
>  
> --  
> 이종열, Jongyoul Lee, 李宗烈  
> http://madeng.net  
>  
>  
>  
> --  
> 이종열, Jongyoul Lee, 李宗烈  
> http://madeng.net  
>  
>  
>  
> --  
> 이종열, Jongyoul Lee, 李宗烈  
> http://madeng.net  
>  
>  
>  
> --  
> 이종열, Jongyoul Lee, 李宗烈  
> http://madeng.net  
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Corneau Damien <co...@gmail.com>.
I don't think minor releases needs be planned (feature wise),
its something we should do when we feel the need that we fixed or improved
something important.
We even talked at some point of doing some more periodic releases.

I see a lot of good benefits from making a new minor release, especially
bug fix wise.

https://github.com/apache/incubator-zeppelin/pull/580
https://github.com/apache/incubator-zeppelin/commit/47eb95aeeefa8925ef5b49487b967f40ad451454
https://github.com/apache/incubator-zeppelin/commit/f0d3c3f0e3e898b5625a1d3745a701271905c22c
https://github.com/apache/incubator-zeppelin/commit/4a1edd525b31e5c6de41c3598ce921b82b7abeeb
https://github.com/apache/incubator-zeppelin/commit/71c1af84a1c4f285842dfd5c85fc99ffc4bfca26
https://github.com/apache/incubator-zeppelin/commit/d90e3805bb2d2434bc08672a6227c0afc927f6ae
https://github.com/apache/incubator-zeppelin/commit/986b0adba3a7986a387c0633d15279b6b2f45c95

On Wed, Dec 30, 2015 at 2:42 PM, Amos B. Elberg <am...@gmail.com>
wrote:

> A codebase that often changes in ways that break other code is an unstable
> codebase, by definition.
>
> I don’t think it will be more stable at runtime, especially since CI isn’t
> working.
>
> It definitely won’t be more maintainable.  The key problematic code is
> still in.
>
> Other than Spark 1.6 and Ignite, I don’t see any reason at all for a 0.5.6
> release.  (Konstantin was right — it is good for Apache releases to
> maintain version compatibility with new versions of other Apache software.
> That is Apache projects helping each other.)
>
> What feature do you feel justifies a 0.5.6 release?  What feature other
> than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 30, 2015 at 12:32:01 AM
> To: Amos B. Elberg <am...@gmail.com>
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Amos,
>
> I don't think we have a strict plan for making a minor release and we have
> a roadmap for major release. And ignite and Spark 1.6 is not a key feature
> of 0.5.6. Konstantin just wanted to be merged that contribution if that
> voting is finished until we make a release. And Spark 1.6 is on going. As
> you told, we are an Apache project. 0.5.6 will be stable and maintainable.
> If 0.5.6 has an experimental features, I don't agree to make a release.
> 0.5.6 will be more stable version of 0.5.5. And of course, the most people
> like more stable version. Isn't it enough?
>
> Regards,
> Jongyoul
>
> On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> My suggestion is that we do a 0.5.6 that just has the bare minimal changes
> necessary for Spark 1.6 and Ignite and nothing else.
>
> That way we provide “must have” features while minimizing risk.
>
> Other than that, yes:  I think we should keep our current release plan and
> not make a release for “nice to have” changes until CI is fixed.
>
> The main purpose of making a new minor release should be whether already
> merged features are meaningful to make a minor release even if any major
> issues are on going, isn't it?
>
> I’m not sure that I understand what you are asking.
>
> We have a planned 0.6 release.  We just did an unplanned “minor” 0.5.5
> release.  It feels like only a few weeks ago.  I voted for it because it
> seemed that it would stabilize the codebase and provide a maintainable
> interim foundation.
>
> I do not think any of the features since 0.5.5 are “meaningful” enough to
> justify changing the release plan.  Not even close.  I think it is rare
> that any off-roadmap “nice to have” feature would ever be a good reason to
> change a release plan.  Especially when our CI “house” is not in order.
>
> We’re an Apache project — we need to be stable, maintainable, reliable,
> predictable.
>
> Is there any merged PR that is so important it can’t wait for 0.6?
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 29, 2015 at 11:54:35 PM
> To: Amos B. Elberg <am...@gmail.com>
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Okay, Amos,
>
> Do you propose Zeppelin should not have another release before fix CI
> issue? I think even though CI has some problems, another minors fixes is
> meaningful to make a new minor release. Do you agree with that? Or don't
> you agree that it's enough? The main purpose of making a new minor release
> should be whether already merged features are meaningful to make a minor
> release even if any major issues are on going, isn't it?
>
> Regards,
> Jongyoul
>
> On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> Hah!
>
> I promise you, an hour after a 0.5.6 comes out, I will have emails asking
> me when I will support 0.5.6, even if no-one actually needs any 0.5.6
> changes or even knows what they are!
>
> I want to be clear though:   My primary issue for 0.5.6 is not whether to
> merge the R interpreter.
>
> My issues are I think we need to fix CI in general, and I’m loathe to have
> more releases with that dammed spark-under-zeppelin code, which is the root
> of many other issues.
>
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 29, 2015 at 11:21:00 PM
> To: Amos B. Elberg <am...@gmail.com>,
> dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Okay, I understand your situation. If you rebased your PR from master, you
> can rebased your PR only once but I also know why you had to do that. I
> think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
> about you?
>
> On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> Jongyoul - the reason we have to rebase twice is that the changes in
> zeppelin-master will break the R interpreter.
>
> So I’ll have to rebase once so that I’m based off of 0.5.6 and people can
> use the code.  Then rebase again for 0.6.0.
>
> Remember, I have a user base I need to support — there are a lot of people
> using the R interpreter now.  So its not just a PR where I can ignore it
> until its ready to merge.
>
> The changes have already broken the shiro PR apparently quite often.
>
> I made a “release” of the R Interpreter just so I could stop rebasing
> against Zeppelin master.   I spent > 60 hours dealing with this for the
> changes leading up to 0.5 and 0.5.5.
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com>
> Date: December 29, 2015 at 11:08:36 PM
> To: Amos B. Elberg <am...@gmail.com>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> I don't know why you should rebased twice. If you can make a PR from
> current master, almost changes merged without rebasing and if a committer
> asks to rebase your PR, this is because you and another contributors
> changes the same codes and another contributions is merged before your PR.
> In specific R case, Moon want you to rebase because he tries to fix the
> testing codes so rebasing your PR will accepts their changes. In most case,
> contributors don't need to rebase their PR before merge because committer
> commit someone's PR by doing cherry-pick. We also felt sorry that you were
> bothered by testing issue and Moon is fighting to fix the testing infra.
> However all of PRs shouldn't be rebased.
>
> On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
> I think there is no big pain because whole changes to be merged
> into 0.5.6 will be also merged into 0.6.0.
>
> If we make another release now, the PRs will have to be rebased *twice*,
> once for 0.5.6, and once again for 0.6.
>
> Also - since this is now the second e-mail from a committer to do the same
> thing — is there a reason you guys are leaving R out of the agenda for the
> next release?  I understood the PR had been accepted and was pending only
> Moon fixing the testing infrastructure.
>
>
> From: Jongyoul Lee <jo...@gmail.com>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 29, 2015 at 10:56:33 PM
>
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Good idea!
>
> 0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I
> also think 0.6.0 should have major changes like supporting spark 1.6 and
> Shiro security and improving testing infra. And concerning rebasing and
> committing, I think there is no big pain because whole changes to be merged
> into 0.5.6 will be also merged into 0.6.0.
>
> JL
>
> On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
>
> > I don’t want to come off as the naysayer here, but I think the effort
> that
> > would go into a release would be better spent on the testing
> infrastructure
> > and outstanding PRs.
> >
> > If we feel we need a release for 1.6 and Ignite, I suggest we make a
> > release that *only* includes the absolute minimal changes required to do
> > that.
> >
> > There was one PR for 1.6 support that didn’t really work and is going to
> > break anything built against the current codebase. Except for a change in
> > the name of one method called by one class, all of the changes seem to
> > involve support for spark-under-zeppelin, which is something we want to
> > take out.
> >
> > We also don’t currently have a working testing framework. A lot of PRs
> > have been committed under the “ignore travis its broken” theory. I’m
> > loathe to make a release that hasn’t really been tested, and it doesn’t
> > seem we’re in a position to do that.
> >
> > While there have been a lot of merged PRs, I don’t think any of them are
> > on-roadmap. They mostly seem to be very minor, like fixing typos and
> > changing which text box gets highlighted. Those are important things, of
> > course, but not major enough to justify the effort involved in a release.
> >
> > Another release will not make it easier to integrate the larger PRs. It
> > will have the opposite effect. Developers will have to rebase against
> > whatever gets broken by 1.6 and other changes.
> >
> > I suggest we wait to do a significant release until we can take out the
> > legacy spark-under-zeppelin code that has caused so many issues, have a
> > working testing framework, and integrate the major outstanding PRs.
> >
> > So, again, if we want a release, I suggest we include the absolute
> minimum
> > changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> > maintenance release.
> >
> >
> > From: Konstantin Boudnik <co...@apache.org>
> > Reply: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>
> > Date: December 29, 2015 at 10:05:36 PM
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
> > make
> > sense to add this to the latest release of Zeppelin. I will open a JIRA
> and
> > supply a patch for it, if there's no objections.
> >
> > Cos
> >
> > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > Hi folks,
> > >
> > > How about we make release 0.5.6-incubating?
> > >
> > > Since last release, more than 100 pull requests are merged and more
> than
> > 80
> > > issues are resolved.
> > >
> > > It's including new interpreters, a lot of new features and improvement
> on
> > > GUI with much improved stability thanks to lots of bug fixes.
> > >
> > > Also it's great time to have a Zeppelin release that support Spark 1.6
> (
> > > ZEPPELIN-395), which about to be released.
> > >
> > > Once we branch for 0.5.6-incubating release, it's more safe to make
> large
> > > code base change such as "Added Shiro security" (
> > > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > > planned feature in 0.6.0 roadmap, that will require lots of internal
> API
> > > updates.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > moon
> >
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by "Amos B. Elberg" <am...@gmail.com>.
A codebase that often changes in ways that break other code is an unstable codebase, by definition.

I don’t think it will be more stable at runtime, especially since CI isn’t working.  

It definitely won’t be more maintainable.  The key problematic code is still in.  

Other than Spark 1.6 and Ignite, I don’t see any reason at all for a 0.5.6 release.  (Konstantin was right — it is good for Apache releases to maintain version compatibility with new versions of other Apache software.  That is Apache projects helping each other.)

What feature do you feel justifies a 0.5.6 release?  What feature other than 1.6 and Ignite does anyone feel justifies a 0.5.6 release?

From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 30, 2015 at 12:32:01 AM
To: Amos B. Elberg <am...@gmail.com>
CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating  

Amos,

I don't think we have a strict plan for making a minor release and we have a roadmap for major release. And ignite and Spark 1.6 is not a key feature of 0.5.6. Konstantin just wanted to be merged that contribution if that voting is finished until we make a release. And Spark 1.6 is on going. As you told, we are an Apache project. 0.5.6 will be stable and maintainable. If 0.5.6 has an experimental features, I don't agree to make a release. 0.5.6 will be more stable version of 0.5.5. And of course, the most people like more stable version. Isn't it enough?

Regards,
Jongyoul

On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com> wrote:
My suggestion is that we do a 0.5.6 that just has the bare minimal changes necessary for Spark 1.6 and Ignite and nothing else.  

That way we provide “must have” features while minimizing risk. 

Other than that, yes:  I think we should keep our current release plan and not make a release for “nice to have” changes until CI is fixed.  

The main purpose of making a new minor release should be whether already merged features are meaningful to make a minor release even if any major issues are on going, isn't it?

I’m not sure that I understand what you are asking. 

We have a planned 0.6 release.  We just did an unplanned “minor” 0.5.5 release.  It feels like only a few weeks ago.  I voted for it because it seemed that it would stabilize the codebase and provide a maintainable interim foundation.  

I do not think any of the features since 0.5.5 are “meaningful” enough to justify changing the release plan.  Not even close.  I think it is rare that any off-roadmap “nice to have” feature would ever be a good reason to change a release plan.  Especially when our CI “house” is not in order. 

We’re an Apache project — we need to be stable, maintainable, reliable, predictable.  

Is there any merged PR that is so important it can’t wait for 0.6? 

From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 29, 2015 at 11:54:35 PM
To: Amos B. Elberg <am...@gmail.com>
CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>

Subject:  Re: [DISCUSS] Release 0.5.6-incubating

Okay, Amos,

Do you propose Zeppelin should not have another release before fix CI issue? I think even though CI has some problems, another minors fixes is meaningful to make a new minor release. Do you agree with that? Or don't you agree that it's enough? The main purpose of making a new minor release should be whether already merged features are meaningful to make a minor release even if any major issues are on going, isn't it?

Regards,
Jongyoul

On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com> wrote:
Hah!  

I promise you, an hour after a 0.5.6 comes out, I will have emails asking me when I will support 0.5.6, even if no-one actually needs any 0.5.6 changes or even knows what they are!  

I want to be clear though:   My primary issue for 0.5.6 is not whether to merge the R interpreter.

My issues are I think we need to fix CI in general, and I’m loathe to have more releases with that dammed spark-under-zeppelin code, which is the root of many other issues.  


From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 29, 2015 at 11:21:00 PM
To: Amos B. Elberg <am...@gmail.com>, dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  

Subject:  Re: [DISCUSS] Release 0.5.6-incubating

Okay, I understand your situation. If you rebased your PR from master, you can rebased your PR only once but I also know why you had to do that. I think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How about you?

On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com> wrote:
Jongyoul - the reason we have to rebase twice is that the changes in zeppelin-master will break the R interpreter.  

So I’ll have to rebase once so that I’m based off of 0.5.6 and people can use the code.  Then rebase again for 0.6.0.  

Remember, I have a user base I need to support — there are a lot of people using the R interpreter now.  So its not just a PR where I can ignore it until its ready to merge.

The changes have already broken the shiro PR apparently quite often. 

I made a “release” of the R Interpreter just so I could stop rebasing against Zeppelin master.   I spent > 60 hours dealing with this for the changes leading up to 0.5 and 0.5.5. 

From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 29, 2015 at 11:08:36 PM
To: Amos B. Elberg <am...@gmail.com>

Subject:  Re: [DISCUSS] Release 0.5.6-incubating

I don't know why you should rebased twice. If you can make a PR from current master, almost changes merged without rebasing and if a committer asks to rebase your PR, this is because you and another contributors changes the same codes and another contributions is merged before your PR. In specific R case, Moon want you to rebase because he tries to fix the testing codes so rebasing your PR will accepts their changes. In most case, contributors don't need to rebase their PR before merge because committer commit someone's PR by doing cherry-pick. We also felt sorry that you were bothered by testing issue and Moon is fighting to fix the testing infra. However all of PRs shouldn't be rebased.

On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com> wrote:
I think there is no big pain because whole changes to be merged 
into 0.5.6 will be also merged into 0.6.0. 

If we make another release now, the PRs will have to be rebased *twice*, once for 0.5.6, and once again for 0.6.  

Also - since this is now the second e-mail from a committer to do the same thing — is there a reason you guys are leaving R out of the agenda for the next release?  I understood the PR had been accepted and was pending only Moon fixing the testing infrastructure. 


From: Jongyoul Lee <jo...@gmail.com>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: December 29, 2015 at 10:56:33 PM

To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating

Good idea!

0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I
also think 0.6.0 should have major changes like supporting spark 1.6 and
Shiro security and improving testing infra. And concerning rebasing and
committing, I think there is no big pain because whole changes to be merged
into 0.5.6 will be also merged into 0.6.0.

JL

On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
wrote:

> I don’t want to come off as the naysayer here, but I think the effort that
> would go into a release would be better spent on the testing infrastructure
> and outstanding PRs.
>
> If we feel we need a release for 1.6 and Ignite, I suggest we make a
> release that *only* includes the absolute minimal changes required to do
> that.
>
> There was one PR for 1.6 support that didn’t really work and is going to
> break anything built against the current codebase. Except for a change in
> the name of one method called by one class, all of the changes seem to
> involve support for spark-under-zeppelin, which is something we want to
> take out.
>
> We also don’t currently have a working testing framework. A lot of PRs
> have been committed under the “ignore travis its broken” theory. I’m
> loathe to make a release that hasn’t really been tested, and it doesn’t
> seem we’re in a position to do that.
>
> While there have been a lot of merged PRs, I don’t think any of them are
> on-roadmap. They mostly seem to be very minor, like fixing typos and
> changing which text box gets highlighted. Those are important things, of
> course, but not major enough to justify the effort involved in a release.
>
> Another release will not make it easier to integrate the larger PRs. It
> will have the opposite effect. Developers will have to rebase against
> whatever gets broken by 1.6 and other changes.
>
> I suggest we wait to do a significant release until we can take out the
> legacy spark-under-zeppelin code that has caused so many issues, have a
> working testing framework, and integrate the major outstanding PRs.
>
> So, again, if we want a release, I suggest we include the absolute minimum
> changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> maintenance release.
>
>
> From: Konstantin Boudnik <co...@apache.org>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 29, 2015 at 10:05:36 PM
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject: Re: [DISCUSS] Release 0.5.6-incubating
>
> Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
> make
> sense to add this to the latest release of Zeppelin. I will open a JIRA and
> supply a patch for it, if there's no objections.
>
> Cos
>
> On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > Hi folks,
> >
> > How about we make release 0.5.6-incubating?
> >
> > Since last release, more than 100 pull requests are merged and more than
> 80
> > issues are resolved.
> >
> > It's including new interpreters, a lot of new features and improvement on
> > GUI with much improved stability thanks to lots of bug fixes.
> >
> > Also it's great time to have a Zeppelin release that support Spark 1.6 (
> > ZEPPELIN-395), which about to be released.
> >
> > Once we branch for 0.5.6-incubating release, it's more safe to make large
> > code base change such as "Added Shiro security" (
> > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > planned feature in 0.6.0 roadmap, that will require lots of internal API
> > updates.
> >
> > What do you think?
> >
> > Thanks,
> > moon
>



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Jongyoul Lee <jo...@gmail.com>.
Amos,

I don't think we have a strict plan for making a minor release and we have
a roadmap for major release. And ignite and Spark 1.6 is not a key feature
of 0.5.6. Konstantin just wanted to be merged that contribution if that
voting is finished until we make a release. And Spark 1.6 is on going. As
you told, we are an Apache project. 0.5.6 will be stable and maintainable.
If 0.5.6 has an experimental features, I don't agree to make a release.
0.5.6 will be more stable version of 0.5.5. And of course, the most people
like more stable version. Isn't it enough?

Regards,
Jongyoul

On Wed, Dec 30, 2015 at 2:17 PM, Amos B. Elberg <am...@gmail.com>
wrote:

> My suggestion is that we do a 0.5.6 that just has the bare minimal changes
> necessary for Spark 1.6 and Ignite and nothing else.
>
> That way we provide “must have” features while minimizing risk.
>
> Other than that, yes:  I think we should keep our current release plan and
> not make a release for “nice to have” changes until CI is fixed.
>
> The main purpose of making a new minor release should be whether already
> merged features are meaningful to make a minor release even if any major
> issues are on going, isn't it?
>
>
> I’m not sure that I understand what you are asking.
>
> We have a planned 0.6 release.  We just did an unplanned “minor” 0.5.5
> release.  It feels like only a few weeks ago.  I voted for it because it
> seemed that it would stabilize the codebase and provide a maintainable
> interim foundation.
>
> I do not think any of the features since 0.5.5 are “meaningful” enough to
> justify changing the release plan.  Not even close.  I think it is rare
> that any off-roadmap “nice to have” feature would ever be a good reason to
> change a release plan.  Especially when our CI “house” is not in order.
>
> We’re an Apache project — we need to be stable, maintainable, reliable,
> predictable.
>
> Is there any merged PR that is so important it can’t wait for 0.6?
>
> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
> Date: December 29, 2015 at 11:54:35 PM
> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>
> CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> <de...@zeppelin.incubator.apache.org>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Okay, Amos,
>
> Do you propose Zeppelin should not have another release before fix CI
> issue? I think even though CI has some problems, another minors fixes is
> meaningful to make a new minor release. Do you agree with that? Or don't
> you agree that it's enough? The main purpose of making a new minor release
> should be whether already merged features are meaningful to make a minor
> release even if any major issues are on going, isn't it?
>
> Regards,
> Jongyoul
>
> On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
>
>> Hah!
>>
>> I promise you, an hour after a 0.5.6 comes out, I will have emails asking
>> me when I will support 0.5.6, even if no-one actually needs any 0.5.6
>> changes or even knows what they are!
>>
>> I want to be clear though:   My primary issue for 0.5.6 is not whether to
>> merge the R interpreter.
>>
>> My issues are I think we need to fix CI in general, and I’m loathe to
>> have more releases with that dammed spark-under-zeppelin code, which is the
>> root of many other issues.
>>
>>
>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>> Date: December 29, 2015 at 11:21:00 PM
>> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>,
>> dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>> <de...@zeppelin.incubator.apache.org>
>>
>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>
>> Okay, I understand your situation. If you rebased your PR from master,
>> you can rebased your PR only once but I also know why you had to do that. I
>> think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
>> about you?
>>
>> On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
>> wrote:
>>
>>> Jongyoul - the reason we have to rebase twice is that the changes in
>>> zeppelin-master will break the R interpreter.
>>>
>>> So I’ll have to rebase once so that I’m based off of 0.5.6 and people
>>> can use the code.  Then rebase again for 0.6.0.
>>>
>>> Remember, I have a user base I need to support — there are a lot of
>>> people using the R interpreter now.  So its not just a PR where I can
>>> ignore it until its ready to merge.
>>>
>>> The changes have already broken the shiro PR apparently quite often.
>>>
>>> I made a “release” of the R Interpreter just so I could stop rebasing
>>> against Zeppelin master.   I spent > 60 hours dealing with this for the
>>> changes leading up to 0.5 and 0.5.5.
>>>
>>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>> Date: December 29, 2015 at 11:08:36 PM
>>> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>
>>>
>>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>>
>>> I don't know why you should rebased twice. If you can make a PR from
>>> current master, almost changes merged without rebasing and if a committer
>>> asks to rebase your PR, this is because you and another contributors
>>> changes the same codes and another contributions is merged before your PR.
>>> In specific R case, Moon want you to rebase because he tries to fix the
>>> testing codes so rebasing your PR will accepts their changes. In most case,
>>> contributors don't need to rebase their PR before merge because committer
>>> commit someone's PR by doing cherry-pick. We also felt sorry that you were
>>> bothered by testing issue and Moon is fighting to fix the testing infra.
>>> However all of PRs shouldn't be rebased.
>>>
>>> On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com>
>>> wrote:
>>>
>>>> I think there is no big pain because whole changes to be merged
>>>> into 0.5.6 will be also merged into 0.6.0.
>>>>
>>>>
>>>> If we make another release now, the PRs will have to be rebased
>>>> *twice*, once for 0.5.6, and once again for 0.6.
>>>>
>>>> Also - since this is now the second e-mail from a committer to do the
>>>> same thing — is there a reason you guys are leaving R out of the agenda for
>>>> the next release?  I understood the PR had been accepted and was pending
>>>> only Moon fixing the testing infrastructure.
>>>>
>>>>
>>>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>>> Reply: dev@zeppelin.incubator.apache.org
>>>> <de...@zeppelin.incubator.apache.org> <de...@zeppelin.incubator.apache.org>
>>>> Date: December 29, 2015 at 10:56:33 PM
>>>>
>>>> To: dev@zeppelin.incubator.apache.org
>>>> <de...@zeppelin.incubator.apache.org> <de...@zeppelin.incubator.apache.org>
>>>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>>>
>>>> Good idea!
>>>>
>>>> 0.5.6 is a minor release thus fixing minor bugs and typos is enough.
>>>> But I
>>>> also think 0.6.0 should have major changes like supporting spark 1.6 and
>>>> Shiro security and improving testing infra. And concerning rebasing and
>>>> committing, I think there is no big pain because whole changes to be
>>>> merged
>>>> into 0.5.6 will be also merged into 0.6.0.
>>>>
>>>> JL
>>>>
>>>> On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <amos.elberg@gmail.com
>>>> >
>>>> wrote:
>>>>
>>>> > I don’t want to come off as the naysayer here, but I think the effort
>>>> that
>>>> > would go into a release would be better spent on the testing
>>>> infrastructure
>>>> > and outstanding PRs.
>>>> >
>>>> > If we feel we need a release for 1.6 and Ignite, I suggest we make a
>>>> > release that *only* includes the absolute minimal changes required to
>>>> do
>>>> > that.
>>>> >
>>>> > There was one PR for 1.6 support that didn’t really work and is going
>>>> to
>>>> > break anything built against the current codebase. Except for a
>>>> change in
>>>> > the name of one method called by one class, all of the changes seem to
>>>> > involve support for spark-under-zeppelin, which is something we want
>>>> to
>>>> > take out.
>>>> >
>>>> > We also don’t currently have a working testing framework. A lot of PRs
>>>> > have been committed under the “ignore travis its broken” theory. I’m
>>>> > loathe to make a release that hasn’t really been tested, and it
>>>> doesn’t
>>>> > seem we’re in a position to do that.
>>>> >
>>>> > While there have been a lot of merged PRs, I don’t think any of them
>>>> are
>>>> > on-roadmap. They mostly seem to be very minor, like fixing typos and
>>>> > changing which text box gets highlighted. Those are important things,
>>>> of
>>>> > course, but not major enough to justify the effort involved in a
>>>> release.
>>>> >
>>>> > Another release will not make it easier to integrate the larger PRs.
>>>> It
>>>> > will have the opposite effect. Developers will have to rebase against
>>>> > whatever gets broken by 1.6 and other changes.
>>>> >
>>>> > I suggest we wait to do a significant release until we can take out
>>>> the
>>>> > legacy spark-under-zeppelin code that has caused so many issues, have
>>>> a
>>>> > working testing framework, and integrate the major outstanding PRs.
>>>> >
>>>> > So, again, if we want a release, I suggest we include the absolute
>>>> minimum
>>>> > changes necessary for 1.6 and Ignite, and perhaps call it an interim
>>>> or
>>>> > maintenance release.
>>>> >
>>>> >
>>>> > From: Konstantin Boudnik <co...@apache.org>
>>>> > Reply: dev@zeppelin.incubator.apache.org <
>>>> > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org
>>>> <
>>>> > dev@zeppelin.incubator.apache.org>
>>>> > Date: December 29, 2015 at 10:05:36 PM
>>>> > To: dev@zeppelin.incubator.apache.org <
>>>> dev@zeppelin.incubator.apache.org>
>>>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
>>>> >
>>>> > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -
>>>> would
>>>> > make
>>>> > sense to add this to the latest release of Zeppelin. I will open a
>>>> JIRA and
>>>> > supply a patch for it, if there's no objections.
>>>> >
>>>> > Cos
>>>> >
>>>> > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
>>>> > > Hi folks,
>>>> > >
>>>> > > How about we make release 0.5.6-incubating?
>>>> > >
>>>> > > Since last release, more than 100 pull requests are merged and more
>>>> than
>>>> > 80
>>>> > > issues are resolved.
>>>> > >
>>>> > > It's including new interpreters, a lot of new features and
>>>> improvement on
>>>> > > GUI with much improved stability thanks to lots of bug fixes.
>>>> > >
>>>> > > Also it's great time to have a Zeppelin release that support Spark
>>>> 1.6 (
>>>> > > ZEPPELIN-395), which about to be released.
>>>> > >
>>>> > > Once we branch for 0.5.6-incubating release, it's more safe to make
>>>> large
>>>> > > code base change such as "Added Shiro security" (
>>>> > > https://github.com/apache/incubator-zeppelin/pull/53) and many
>>>> other
>>>> > > planned feature in 0.6.0 roadmap, that will require lots of
>>>> internal API
>>>> > > updates.
>>>> > >
>>>> > > What do you think?
>>>> > >
>>>> > > Thanks,
>>>> > > moon
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> 이종열, Jongyoul Lee, 李宗烈
>>>> http://madeng.net
>>>>
>>>>
>>>
>>>
>>> --
>>> 이종열, Jongyoul Lee, 李宗烈
>>> http://madeng.net
>>>
>>>
>>
>>
>> --
>> 이종열, Jongyoul Lee, 李宗烈
>> http://madeng.net
>>
>>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>


-- 
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

Re: [DISCUSS] Release 0.5.6-incubating

Posted by "Amos B. Elberg" <am...@gmail.com>.
My suggestion is that we do a 0.5.6 that just has the bare minimal changes necessary for Spark 1.6 and Ignite and nothing else.  

That way we provide “must have” features while minimizing risk. 

Other than that, yes:  I think we should keep our current release plan and not make a release for “nice to have” changes until CI is fixed.  

The main purpose of making a new minor release should be whether already merged features are meaningful to make a minor release even if any major issues are on going, isn't it?

I’m not sure that I understand what you are asking. 

We have a planned 0.6 release.  We just did an unplanned “minor” 0.5.5 release.  It feels like only a few weeks ago.  I voted for it because it seemed that it would stabilize the codebase and provide a maintainable interim foundation.  

I do not think any of the features since 0.5.5 are “meaningful” enough to justify changing the release plan.  Not even close.  I think it is rare that any off-roadmap “nice to have” feature would ever be a good reason to change a release plan.  Especially when our CI “house” is not in order. 

We’re an Apache project — we need to be stable, maintainable, reliable, predictable.  

Is there any merged PR that is so important it can’t wait for 0.6? 

From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 29, 2015 at 11:54:35 PM
To: Amos B. Elberg <am...@gmail.com>
CC: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating  

Okay, Amos,

Do you propose Zeppelin should not have another release before fix CI issue? I think even though CI has some problems, another minors fixes is meaningful to make a new minor release. Do you agree with that? Or don't you agree that it's enough? The main purpose of making a new minor release should be whether already merged features are meaningful to make a minor release even if any major issues are on going, isn't it?

Regards,
Jongyoul

On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com> wrote:
Hah!  

I promise you, an hour after a 0.5.6 comes out, I will have emails asking me when I will support 0.5.6, even if no-one actually needs any 0.5.6 changes or even knows what they are!  

I want to be clear though:   My primary issue for 0.5.6 is not whether to merge the R interpreter.

My issues are I think we need to fix CI in general, and I’m loathe to have more releases with that dammed spark-under-zeppelin code, which is the root of many other issues.  


From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 29, 2015 at 11:21:00 PM
To: Amos B. Elberg <am...@gmail.com>, dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>

Subject:  Re: [DISCUSS] Release 0.5.6-incubating

Okay, I understand your situation. If you rebased your PR from master, you can rebased your PR only once but I also know why you had to do that. I think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How about you?

On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com> wrote:
Jongyoul - the reason we have to rebase twice is that the changes in zeppelin-master will break the R interpreter.  

So I’ll have to rebase once so that I’m based off of 0.5.6 and people can use the code.  Then rebase again for 0.6.0.  

Remember, I have a user base I need to support — there are a lot of people using the R interpreter now.  So its not just a PR where I can ignore it until its ready to merge.

The changes have already broken the shiro PR apparently quite often. 

I made a “release” of the R Interpreter just so I could stop rebasing against Zeppelin master.   I spent > 60 hours dealing with this for the changes leading up to 0.5 and 0.5.5. 

From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 29, 2015 at 11:08:36 PM
To: Amos B. Elberg <am...@gmail.com>

Subject:  Re: [DISCUSS] Release 0.5.6-incubating

I don't know why you should rebased twice. If you can make a PR from current master, almost changes merged without rebasing and if a committer asks to rebase your PR, this is because you and another contributors changes the same codes and another contributions is merged before your PR. In specific R case, Moon want you to rebase because he tries to fix the testing codes so rebasing your PR will accepts their changes. In most case, contributors don't need to rebase their PR before merge because committer commit someone's PR by doing cherry-pick. We also felt sorry that you were bothered by testing issue and Moon is fighting to fix the testing infra. However all of PRs shouldn't be rebased.

On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com> wrote:
I think there is no big pain because whole changes to be merged 
into 0.5.6 will be also merged into 0.6.0. 

If we make another release now, the PRs will have to be rebased *twice*, once for 0.5.6, and once again for 0.6.  

Also - since this is now the second e-mail from a committer to do the same thing — is there a reason you guys are leaving R out of the agenda for the next release?  I understood the PR had been accepted and was pending only Moon fixing the testing infrastructure. 


From: Jongyoul Lee <jo...@gmail.com>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: December 29, 2015 at 10:56:33 PM

To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating

Good idea!

0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I
also think 0.6.0 should have major changes like supporting spark 1.6 and
Shiro security and improving testing infra. And concerning rebasing and
committing, I think there is no big pain because whole changes to be merged
into 0.5.6 will be also merged into 0.6.0.

JL

On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
wrote:

> I don’t want to come off as the naysayer here, but I think the effort that
> would go into a release would be better spent on the testing infrastructure
> and outstanding PRs.
>
> If we feel we need a release for 1.6 and Ignite, I suggest we make a
> release that *only* includes the absolute minimal changes required to do
> that.
>
> There was one PR for 1.6 support that didn’t really work and is going to
> break anything built against the current codebase. Except for a change in
> the name of one method called by one class, all of the changes seem to
> involve support for spark-under-zeppelin, which is something we want to
> take out.
>
> We also don’t currently have a working testing framework. A lot of PRs
> have been committed under the “ignore travis its broken” theory. I’m
> loathe to make a release that hasn’t really been tested, and it doesn’t
> seem we’re in a position to do that.
>
> While there have been a lot of merged PRs, I don’t think any of them are
> on-roadmap. They mostly seem to be very minor, like fixing typos and
> changing which text box gets highlighted. Those are important things, of
> course, but not major enough to justify the effort involved in a release.
>
> Another release will not make it easier to integrate the larger PRs. It
> will have the opposite effect. Developers will have to rebase against
> whatever gets broken by 1.6 and other changes.
>
> I suggest we wait to do a significant release until we can take out the
> legacy spark-under-zeppelin code that has caused so many issues, have a
> working testing framework, and integrate the major outstanding PRs.
>
> So, again, if we want a release, I suggest we include the absolute minimum
> changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> maintenance release.
>
>
> From: Konstantin Boudnik <co...@apache.org>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 29, 2015 at 10:05:36 PM
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject: Re: [DISCUSS] Release 0.5.6-incubating
>
> Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
> make
> sense to add this to the latest release of Zeppelin. I will open a JIRA and
> supply a patch for it, if there's no objections.
>
> Cos
>
> On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > Hi folks,
> >
> > How about we make release 0.5.6-incubating?
> >
> > Since last release, more than 100 pull requests are merged and more than
> 80
> > issues are resolved.
> >
> > It's including new interpreters, a lot of new features and improvement on
> > GUI with much improved stability thanks to lots of bug fixes.
> >
> > Also it's great time to have a Zeppelin release that support Spark 1.6 (
> > ZEPPELIN-395), which about to be released.
> >
> > Once we branch for 0.5.6-incubating release, it's more safe to make large
> > code base change such as "Added Shiro security" (
> > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > planned feature in 0.6.0 roadmap, that will require lots of internal API
> > updates.
> >
> > What do you think?
> >
> > Thanks,
> > moon
>



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Jongyoul Lee <jo...@gmail.com>.
Okay, Amos,

Do you propose Zeppelin should not have another release before fix CI
issue? I think even though CI has some problems, another minors fixes is
meaningful to make a new minor release. Do you agree with that? Or don't
you agree that it's enough? The main purpose of making a new minor release
should be whether already merged features are meaningful to make a minor
release even if any major issues are on going, isn't it?

Regards,
Jongyoul

On Wed, Dec 30, 2015 at 1:35 PM, Amos B. Elberg <am...@gmail.com>
wrote:

> Hah!
>
> I promise you, an hour after a 0.5.6 comes out, I will have emails asking
> me when I will support 0.5.6, even if no-one actually needs any 0.5.6
> changes or even knows what they are!
>
> I want to be clear though:   My primary issue for 0.5.6 is not whether to
> merge the R interpreter.
>
> My issues are I think we need to fix CI in general, and I’m loathe to have
> more releases with that dammed spark-under-zeppelin code, which is the root
> of many other issues.
>
>
> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
> Date: December 29, 2015 at 11:21:00 PM
> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>,
> dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> <de...@zeppelin.incubator.apache.org>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Okay, I understand your situation. If you rebased your PR from master, you
> can rebased your PR only once but I also know why you had to do that. I
> think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
> about you?
>
> On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
>
>> Jongyoul - the reason we have to rebase twice is that the changes in
>> zeppelin-master will break the R interpreter.
>>
>> So I’ll have to rebase once so that I’m based off of 0.5.6 and people can
>> use the code.  Then rebase again for 0.6.0.
>>
>> Remember, I have a user base I need to support — there are a lot of
>> people using the R interpreter now.  So its not just a PR where I can
>> ignore it until its ready to merge.
>>
>> The changes have already broken the shiro PR apparently quite often.
>>
>> I made a “release” of the R Interpreter just so I could stop rebasing
>> against Zeppelin master.   I spent > 60 hours dealing with this for the
>> changes leading up to 0.5 and 0.5.5.
>>
>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>> Date: December 29, 2015 at 11:08:36 PM
>> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>
>>
>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>
>> I don't know why you should rebased twice. If you can make a PR from
>> current master, almost changes merged without rebasing and if a committer
>> asks to rebase your PR, this is because you and another contributors
>> changes the same codes and another contributions is merged before your PR.
>> In specific R case, Moon want you to rebase because he tries to fix the
>> testing codes so rebasing your PR will accepts their changes. In most case,
>> contributors don't need to rebase their PR before merge because committer
>> commit someone's PR by doing cherry-pick. We also felt sorry that you were
>> bothered by testing issue and Moon is fighting to fix the testing infra.
>> However all of PRs shouldn't be rebased.
>>
>> On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com>
>> wrote:
>>
>>> I think there is no big pain because whole changes to be merged
>>> into 0.5.6 will be also merged into 0.6.0.
>>>
>>>
>>> If we make another release now, the PRs will have to be rebased *twice*,
>>> once for 0.5.6, and once again for 0.6.
>>>
>>> Also - since this is now the second e-mail from a committer to do the
>>> same thing — is there a reason you guys are leaving R out of the agenda for
>>> the next release?  I understood the PR had been accepted and was pending
>>> only Moon fixing the testing infrastructure.
>>>
>>>
>>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>>> Reply: dev@zeppelin.incubator.apache.org
>>> <de...@zeppelin.incubator.apache.org> <de...@zeppelin.incubator.apache.org>
>>> Date: December 29, 2015 at 10:56:33 PM
>>>
>>> To: dev@zeppelin.incubator.apache.org
>>> <de...@zeppelin.incubator.apache.org> <de...@zeppelin.incubator.apache.org>
>>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>>
>>> Good idea!
>>>
>>> 0.5.6 is a minor release thus fixing minor bugs and typos is enough. But
>>> I
>>> also think 0.6.0 should have major changes like supporting spark 1.6 and
>>> Shiro security and improving testing infra. And concerning rebasing and
>>> committing, I think there is no big pain because whole changes to be
>>> merged
>>> into 0.5.6 will be also merged into 0.6.0.
>>>
>>> JL
>>>
>>> On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
>>> wrote:
>>>
>>> > I don’t want to come off as the naysayer here, but I think the effort
>>> that
>>> > would go into a release would be better spent on the testing
>>> infrastructure
>>> > and outstanding PRs.
>>> >
>>> > If we feel we need a release for 1.6 and Ignite, I suggest we make a
>>> > release that *only* includes the absolute minimal changes required to
>>> do
>>> > that.
>>> >
>>> > There was one PR for 1.6 support that didn’t really work and is going
>>> to
>>> > break anything built against the current codebase. Except for a change
>>> in
>>> > the name of one method called by one class, all of the changes seem to
>>> > involve support for spark-under-zeppelin, which is something we want to
>>> > take out.
>>> >
>>> > We also don’t currently have a working testing framework. A lot of PRs
>>> > have been committed under the “ignore travis its broken” theory. I’m
>>> > loathe to make a release that hasn’t really been tested, and it doesn’t
>>> > seem we’re in a position to do that.
>>> >
>>> > While there have been a lot of merged PRs, I don’t think any of them
>>> are
>>> > on-roadmap. They mostly seem to be very minor, like fixing typos and
>>> > changing which text box gets highlighted. Those are important things,
>>> of
>>> > course, but not major enough to justify the effort involved in a
>>> release.
>>> >
>>> > Another release will not make it easier to integrate the larger PRs. It
>>> > will have the opposite effect. Developers will have to rebase against
>>> > whatever gets broken by 1.6 and other changes.
>>> >
>>> > I suggest we wait to do a significant release until we can take out the
>>> > legacy spark-under-zeppelin code that has caused so many issues, have a
>>> > working testing framework, and integrate the major outstanding PRs.
>>> >
>>> > So, again, if we want a release, I suggest we include the absolute
>>> minimum
>>> > changes necessary for 1.6 and Ignite, and perhaps call it an interim or
>>> > maintenance release.
>>> >
>>> >
>>> > From: Konstantin Boudnik <co...@apache.org>
>>> > Reply: dev@zeppelin.incubator.apache.org <
>>> > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org
>>> <
>>> > dev@zeppelin.incubator.apache.org>
>>> > Date: December 29, 2015 at 10:05:36 PM
>>> > To: dev@zeppelin.incubator.apache.org <
>>> dev@zeppelin.incubator.apache.org>
>>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
>>> >
>>> > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -
>>> would
>>> > make
>>> > sense to add this to the latest release of Zeppelin. I will open a
>>> JIRA and
>>> > supply a patch for it, if there's no objections.
>>> >
>>> > Cos
>>> >
>>> > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
>>> > > Hi folks,
>>> > >
>>> > > How about we make release 0.5.6-incubating?
>>> > >
>>> > > Since last release, more than 100 pull requests are merged and more
>>> than
>>> > 80
>>> > > issues are resolved.
>>> > >
>>> > > It's including new interpreters, a lot of new features and
>>> improvement on
>>> > > GUI with much improved stability thanks to lots of bug fixes.
>>> > >
>>> > > Also it's great time to have a Zeppelin release that support Spark
>>> 1.6 (
>>> > > ZEPPELIN-395), which about to be released.
>>> > >
>>> > > Once we branch for 0.5.6-incubating release, it's more safe to make
>>> large
>>> > > code base change such as "Added Shiro security" (
>>> > > https://github.com/apache/incubator-zeppelin/pull/53) and many other
>>> > > planned feature in 0.6.0 roadmap, that will require lots of internal
>>> API
>>> > > updates.
>>> > >
>>> > > What do you think?
>>> > >
>>> > > Thanks,
>>> > > moon
>>> >
>>>
>>>
>>>
>>> --
>>> 이종열, Jongyoul Lee, 李宗烈
>>> http://madeng.net
>>>
>>>
>>
>>
>> --
>> 이종열, Jongyoul Lee, 李宗烈
>> http://madeng.net
>>
>>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>


-- 
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

Re: [DISCUSS] Release 0.5.6-incubating

Posted by "Amos B. Elberg" <am...@gmail.com>.
Hah!  

I promise you, an hour after a 0.5.6 comes out, I will have emails asking me when I will support 0.5.6, even if no-one actually needs any 0.5.6 changes or even knows what they are!  

I want to be clear though:   My primary issue for 0.5.6 is not whether to merge the R interpreter.

My issues are I think we need to fix CI in general, and I’m loathe to have more releases with that dammed spark-under-zeppelin code, which is the root of many other issues.  


From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 29, 2015 at 11:21:00 PM
To: Amos B. Elberg <am...@gmail.com>, dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating  

Okay, I understand your situation. If you rebased your PR from master, you can rebased your PR only once but I also know why you had to do that. I think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How about you?

On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com> wrote:
Jongyoul - the reason we have to rebase twice is that the changes in zeppelin-master will break the R interpreter.  

So I’ll have to rebase once so that I’m based off of 0.5.6 and people can use the code.  Then rebase again for 0.6.0.  

Remember, I have a user base I need to support — there are a lot of people using the R interpreter now.  So its not just a PR where I can ignore it until its ready to merge.

The changes have already broken the shiro PR apparently quite often. 

I made a “release” of the R Interpreter just so I could stop rebasing against Zeppelin master.   I spent > 60 hours dealing with this for the changes leading up to 0.5 and 0.5.5. 

From: Jongyoul Lee <jo...@gmail.com>
Reply: Jongyoul Lee <jo...@gmail.com>
Date: December 29, 2015 at 11:08:36 PM
To: Amos B. Elberg <am...@gmail.com>

Subject:  Re: [DISCUSS] Release 0.5.6-incubating

I don't know why you should rebased twice. If you can make a PR from current master, almost changes merged without rebasing and if a committer asks to rebase your PR, this is because you and another contributors changes the same codes and another contributions is merged before your PR. In specific R case, Moon want you to rebase because he tries to fix the testing codes so rebasing your PR will accepts their changes. In most case, contributors don't need to rebase their PR before merge because committer commit someone's PR by doing cherry-pick. We also felt sorry that you were bothered by testing issue and Moon is fighting to fix the testing infra. However all of PRs shouldn't be rebased.

On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com> wrote:
I think there is no big pain because whole changes to be merged 
into 0.5.6 will be also merged into 0.6.0. 

If we make another release now, the PRs will have to be rebased *twice*, once for 0.5.6, and once again for 0.6.  

Also - since this is now the second e-mail from a committer to do the same thing — is there a reason you guys are leaving R out of the agenda for the next release?  I understood the PR had been accepted and was pending only Moon fixing the testing infrastructure. 


From: Jongyoul Lee <jo...@gmail.com>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: December 29, 2015 at 10:56:33 PM

To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating

Good idea!

0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I
also think 0.6.0 should have major changes like supporting spark 1.6 and
Shiro security and improving testing infra. And concerning rebasing and
committing, I think there is no big pain because whole changes to be merged
into 0.5.6 will be also merged into 0.6.0.

JL

On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
wrote:

> I don’t want to come off as the naysayer here, but I think the effort that
> would go into a release would be better spent on the testing infrastructure
> and outstanding PRs.
>
> If we feel we need a release for 1.6 and Ignite, I suggest we make a
> release that *only* includes the absolute minimal changes required to do
> that.
>
> There was one PR for 1.6 support that didn’t really work and is going to
> break anything built against the current codebase. Except for a change in
> the name of one method called by one class, all of the changes seem to
> involve support for spark-under-zeppelin, which is something we want to
> take out.
>
> We also don’t currently have a working testing framework. A lot of PRs
> have been committed under the “ignore travis its broken” theory. I’m
> loathe to make a release that hasn’t really been tested, and it doesn’t
> seem we’re in a position to do that.
>
> While there have been a lot of merged PRs, I don’t think any of them are
> on-roadmap. They mostly seem to be very minor, like fixing typos and
> changing which text box gets highlighted. Those are important things, of
> course, but not major enough to justify the effort involved in a release.
>
> Another release will not make it easier to integrate the larger PRs. It
> will have the opposite effect. Developers will have to rebase against
> whatever gets broken by 1.6 and other changes.
>
> I suggest we wait to do a significant release until we can take out the
> legacy spark-under-zeppelin code that has caused so many issues, have a
> working testing framework, and integrate the major outstanding PRs.
>
> So, again, if we want a release, I suggest we include the absolute minimum
> changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> maintenance release.
>
>
> From: Konstantin Boudnik <co...@apache.org>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 29, 2015 at 10:05:36 PM
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject: Re: [DISCUSS] Release 0.5.6-incubating
>
> Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
> make
> sense to add this to the latest release of Zeppelin. I will open a JIRA and
> supply a patch for it, if there's no objections.
>
> Cos
>
> On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > Hi folks,
> >
> > How about we make release 0.5.6-incubating?
> >
> > Since last release, more than 100 pull requests are merged and more than
> 80
> > issues are resolved.
> >
> > It's including new interpreters, a lot of new features and improvement on
> > GUI with much improved stability thanks to lots of bug fixes.
> >
> > Also it's great time to have a Zeppelin release that support Spark 1.6 (
> > ZEPPELIN-395), which about to be released.
> >
> > Once we branch for 0.5.6-incubating release, it's more safe to make large
> > code base change such as "Added Shiro security" (
> > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > planned feature in 0.6.0 roadmap, that will require lots of internal API
> > updates.
> >
> > What do you think?
> >
> > Thanks,
> > moon
>



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net



--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Jongyoul Lee <jo...@gmail.com>.
Okay, I understand your situation. If you rebased your PR from master, you
can rebased your PR only once but I also know why you had to do that. I
think R is a roadmap for 0.6.0 and you'd better skip rebasing 0.5.6. How
about you?

On Wed, Dec 30, 2015 at 1:12 PM, Amos B. Elberg <am...@gmail.com>
wrote:

> Jongyoul - the reason we have to rebase twice is that the changes in
> zeppelin-master will break the R interpreter.
>
> So I’ll have to rebase once so that I’m based off of 0.5.6 and people can
> use the code.  Then rebase again for 0.6.0.
>
> Remember, I have a user base I need to support — there are a lot of people
> using the R interpreter now.  So its not just a PR where I can ignore it
> until its ready to merge.
>
> The changes have already broken the shiro PR apparently quite often.
>
> I made a “release” of the R Interpreter just so I could stop rebasing
> against Zeppelin master.   I spent > 60 hours dealing with this for the
> changes leading up to 0.5 and 0.5.5.
>
> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
> Reply: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
> Date: December 29, 2015 at 11:08:36 PM
> To: Amos B. Elberg <am...@gmail.com> <am...@gmail.com>
>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> I don't know why you should rebased twice. If you can make a PR from
> current master, almost changes merged without rebasing and if a committer
> asks to rebase your PR, this is because you and another contributors
> changes the same codes and another contributions is merged before your PR.
> In specific R case, Moon want you to rebase because he tries to fix the
> testing codes so rebasing your PR will accepts their changes. In most case,
> contributors don't need to rebase their PR before merge because committer
> commit someone's PR by doing cherry-pick. We also felt sorry that you were
> bothered by testing issue and Moon is fighting to fix the testing infra.
> However all of PRs shouldn't be rebased.
>
> On Wed, Dec 30, 2015 at 12:59 PM, Amos B. Elberg <am...@gmail.com>
> wrote:
>
>> I think there is no big pain because whole changes to be merged
>> into 0.5.6 will be also merged into 0.6.0.
>>
>>
>> If we make another release now, the PRs will have to be rebased *twice*,
>> once for 0.5.6, and once again for 0.6.
>>
>> Also - since this is now the second e-mail from a committer to do the
>> same thing — is there a reason you guys are leaving R out of the agenda for
>> the next release?  I understood the PR had been accepted and was pending
>> only Moon fixing the testing infrastructure.
>>
>>
>> From: Jongyoul Lee <jo...@gmail.com> <jo...@gmail.com>
>> Reply: dev@zeppelin.incubator.apache.org
>> <de...@zeppelin.incubator.apache.org> <de...@zeppelin.incubator.apache.org>
>> Date: December 29, 2015 at 10:56:33 PM
>>
>> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>> <de...@zeppelin.incubator.apache.org>
>> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>>
>> Good idea!
>>
>> 0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I
>> also think 0.6.0 should have major changes like supporting spark 1.6 and
>> Shiro security and improving testing infra. And concerning rebasing and
>> committing, I think there is no big pain because whole changes to be
>> merged
>> into 0.5.6 will be also merged into 0.6.0.
>>
>> JL
>>
>> On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
>> wrote:
>>
>> > I don’t want to come off as the naysayer here, but I think the effort
>> that
>> > would go into a release would be better spent on the testing
>> infrastructure
>> > and outstanding PRs.
>> >
>> > If we feel we need a release for 1.6 and Ignite, I suggest we make a
>> > release that *only* includes the absolute minimal changes required to do
>> > that.
>> >
>> > There was one PR for 1.6 support that didn’t really work and is going to
>> > break anything built against the current codebase. Except for a change
>> in
>> > the name of one method called by one class, all of the changes seem to
>> > involve support for spark-under-zeppelin, which is something we want to
>> > take out.
>> >
>> > We also don’t currently have a working testing framework. A lot of PRs
>> > have been committed under the “ignore travis its broken” theory. I’m
>> > loathe to make a release that hasn’t really been tested, and it doesn’t
>> > seem we’re in a position to do that.
>> >
>> > While there have been a lot of merged PRs, I don’t think any of them are
>> > on-roadmap. They mostly seem to be very minor, like fixing typos and
>> > changing which text box gets highlighted. Those are important things, of
>> > course, but not major enough to justify the effort involved in a
>> release.
>> >
>> > Another release will not make it easier to integrate the larger PRs. It
>> > will have the opposite effect. Developers will have to rebase against
>> > whatever gets broken by 1.6 and other changes.
>> >
>> > I suggest we wait to do a significant release until we can take out the
>> > legacy spark-under-zeppelin code that has caused so many issues, have a
>> > working testing framework, and integrate the major outstanding PRs.
>> >
>> > So, again, if we want a release, I suggest we include the absolute
>> minimum
>> > changes necessary for 1.6 and Ignite, and perhaps call it an interim or
>> > maintenance release.
>> >
>> >
>> > From: Konstantin Boudnik <co...@apache.org>
>> > Reply: dev@zeppelin.incubator.apache.org <
>> > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <
>> > dev@zeppelin.incubator.apache.org>
>> > Date: December 29, 2015 at 10:05:36 PM
>> > To: dev@zeppelin.incubator.apache.org <
>> dev@zeppelin.incubator.apache.org>
>> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
>> >
>> > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
>> > make
>> > sense to add this to the latest release of Zeppelin. I will open a JIRA
>> and
>> > supply a patch for it, if there's no objections.
>> >
>> > Cos
>> >
>> > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
>> > > Hi folks,
>> > >
>> > > How about we make release 0.5.6-incubating?
>> > >
>> > > Since last release, more than 100 pull requests are merged and more
>> than
>> > 80
>> > > issues are resolved.
>> > >
>> > > It's including new interpreters, a lot of new features and
>> improvement on
>> > > GUI with much improved stability thanks to lots of bug fixes.
>> > >
>> > > Also it's great time to have a Zeppelin release that support Spark
>> 1.6 (
>> > > ZEPPELIN-395), which about to be released.
>> > >
>> > > Once we branch for 0.5.6-incubating release, it's more safe to make
>> large
>> > > code base change such as "Added Shiro security" (
>> > > https://github.com/apache/incubator-zeppelin/pull/53) and many other
>> > > planned feature in 0.6.0 roadmap, that will require lots of internal
>> API
>> > > updates.
>> > >
>> > > What do you think?
>> > >
>> > > Thanks,
>> > > moon
>> >
>>
>>
>>
>> --
>> 이종열, Jongyoul Lee, 李宗烈
>> http://madeng.net
>>
>>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
>


-- 
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

Re: [DISCUSS] Release 0.5.6-incubating

Posted by "Amos B. Elberg" <am...@gmail.com>.
I think there is no big pain because whole changes to be merged 
into 0.5.6 will be also merged into 0.6.0. 

If we make another release now, the PRs will have to be rebased *twice*, once for 0.5.6, and once again for 0.6.  

Also - since this is now the second e-mail from a committer to do the same thing — is there a reason you guys are leaving R out of the agenda for the next release?  I understood the PR had been accepted and was pending only Moon fixing the testing infrastructure. 


From: Jongyoul Lee <jo...@gmail.com>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: December 29, 2015 at 10:56:33 PM
To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating  

Good idea!  

0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I  
also think 0.6.0 should have major changes like supporting spark 1.6 and  
Shiro security and improving testing infra. And concerning rebasing and  
committing, I think there is no big pain because whole changes to be merged  
into 0.5.6 will be also merged into 0.6.0.  

JL  

On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>  
wrote:  

> I don’t want to come off as the naysayer here, but I think the effort that  
> would go into a release would be better spent on the testing infrastructure  
> and outstanding PRs.  
>  
> If we feel we need a release for 1.6 and Ignite, I suggest we make a  
> release that *only* includes the absolute minimal changes required to do  
> that.  
>  
> There was one PR for 1.6 support that didn’t really work and is going to  
> break anything built against the current codebase. Except for a change in  
> the name of one method called by one class, all of the changes seem to  
> involve support for spark-under-zeppelin, which is something we want to  
> take out.  
>  
> We also don’t currently have a working testing framework. A lot of PRs  
> have been committed under the “ignore travis its broken” theory. I’m  
> loathe to make a release that hasn’t really been tested, and it doesn’t  
> seem we’re in a position to do that.  
>  
> While there have been a lot of merged PRs, I don’t think any of them are  
> on-roadmap. They mostly seem to be very minor, like fixing typos and  
> changing which text box gets highlighted. Those are important things, of  
> course, but not major enough to justify the effort involved in a release.  
>  
> Another release will not make it easier to integrate the larger PRs. It  
> will have the opposite effect. Developers will have to rebase against  
> whatever gets broken by 1.6 and other changes.  
>  
> I suggest we wait to do a significant release until we can take out the  
> legacy spark-under-zeppelin code that has caused so many issues, have a  
> working testing framework, and integrate the major outstanding PRs.  
>  
> So, again, if we want a release, I suggest we include the absolute minimum  
> changes necessary for 1.6 and Ignite, and perhaps call it an interim or  
> maintenance release.  
>  
>  
> From: Konstantin Boudnik <co...@apache.org>  
> Reply: dev@zeppelin.incubator.apache.org <  
> dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <  
> dev@zeppelin.incubator.apache.org>  
> Date: December 29, 2015 at 10:05:36 PM  
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would  
> make  
> sense to add this to the latest release of Zeppelin. I will open a JIRA and  
> supply a patch for it, if there's no objections.  
>  
> Cos  
>  
> On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:  
> > Hi folks,  
> >  
> > How about we make release 0.5.6-incubating?  
> >  
> > Since last release, more than 100 pull requests are merged and more than  
> 80  
> > issues are resolved.  
> >  
> > It's including new interpreters, a lot of new features and improvement on  
> > GUI with much improved stability thanks to lots of bug fixes.  
> >  
> > Also it's great time to have a Zeppelin release that support Spark 1.6 (  
> > ZEPPELIN-395), which about to be released.  
> >  
> > Once we branch for 0.5.6-incubating release, it's more safe to make large  
> > code base change such as "Added Shiro security" (  
> > https://github.com/apache/incubator-zeppelin/pull/53) and many other  
> > planned feature in 0.6.0 roadmap, that will require lots of internal API  
> > updates.  
> >  
> > What do you think?  
> >  
> > Thanks,  
> > moon  
>  



--  
이종열, Jongyoul Lee, 李宗烈  
http://madeng.net

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Jongyoul Lee <jo...@gmail.com>.
Good idea!

0.5.6 is a minor release thus fixing minor bugs and typos is enough. But I
also think 0.6.0 should have major changes like supporting spark 1.6 and
Shiro security and improving testing infra. And concerning rebasing and
committing, I think there is no big pain because whole changes to be merged
into 0.5.6 will be also merged into 0.6.0.

JL

On Wed, Dec 30, 2015 at 12:32 PM, Amos B. Elberg <am...@gmail.com>
wrote:

> I don’t want to come off as the naysayer here, but I think the effort that
> would go into a release would be better spent on the testing infrastructure
> and outstanding PRs.
>
> If we feel we need a release for 1.6 and Ignite, I suggest we make a
> release that *only* includes the absolute minimal changes required to do
> that.
>
> There was one PR for 1.6 support that didn’t really work and is going to
> break anything built against the current codebase.  Except for a change in
> the name of one method called by one class, all of the changes seem to
> involve support for spark-under-zeppelin, which is something we want to
> take out.
>
> We also don’t currently have a working testing framework.  A lot of PRs
> have been committed under the “ignore travis its broken” theory.  I’m
> loathe to make a release that hasn’t really been tested, and it doesn’t
> seem we’re in a position to do that.
>
> While there have been a lot of merged PRs, I don’t think any of them are
> on-roadmap. They mostly seem to be very minor, like fixing typos and
> changing which text box gets highlighted.  Those are important things, of
> course, but not major enough to justify the effort involved in a release.
>
> Another release will not make it easier to integrate the larger PRs.  It
> will have the opposite effect.  Developers will have to rebase against
> whatever gets broken by 1.6 and other changes.
>
> I suggest we wait to do a significant release until we can take out the
> legacy spark-under-zeppelin code that has caused so many issues, have a
> working testing framework, and integrate the major outstanding PRs.
>
> So, again, if we want a release, I suggest we include the absolute minimum
> changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> maintenance release.
>
>
> From: Konstantin Boudnik <co...@apache.org>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 29, 2015 at 10:05:36 PM
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
> make
> sense to add this to the latest release of Zeppelin. I will open a JIRA and
> supply a patch for it, if there's no objections.
>
> Cos
>
> On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > Hi folks,
> >
> > How about we make release 0.5.6-incubating?
> >
> > Since last release, more than 100 pull requests are merged and more than
> 80
> > issues are resolved.
> >
> > It's including new interpreters, a lot of new features and improvement on
> > GUI with much improved stability thanks to lots of bug fixes.
> >
> > Also it's great time to have a Zeppelin release that support Spark 1.6 (
> > ZEPPELIN-395), which about to be released.
> >
> > Once we branch for 0.5.6-incubating release, it's more safe to make large
> > code base change such as "Added Shiro security" (
> > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > planned feature in 0.6.0 roadmap, that will require lots of internal API
> > updates.
> >
> > What do you think?
> >
> > Thanks,
> > moon
>



-- 
이종열, Jongyoul Lee, 李宗烈
http://madeng.net

Re: [DISCUSS] Release 0.5.6-incubating

Posted by "Amos B. Elberg" <am...@gmail.com>.
The CI issue is not a problem just with the R Interpreter.

I’ve been following the PR discussions closely and many PRs have been failing CI.  

PRs have been merged even though they failed CI.  

In addition, because CI has not been reliable, CI is not testing as much as we would like.  So even a passing CI is not covering the range of configurations that we would want it to for a release.  

And we don’t understand *why* CI is failing in many of these cases.  Which means we don’t really understand what CI is doing.  

This means that a release would not be able to meet *the project’s own standards* for testability.  

To me that is reason enough. 

But also — a release takes a LOT of effort from everyone, especially the PMC.  PMC time is valuable and limited. 

I don’t see anything in the PRs after 0.5.5 that would make another release a priority right now.  We just made a release.  Other things that will take longer to be addressed if we devote time to a release include R, but also include CI, shiro, multi-tenancy, removing the spark-under-zeppelin code…  

All of those things seem more important and a higher priority than the PRs currently merged in master, which are not major. 

Fixing CI and spark-under-zeppelin both seem to be the highest priority.  That will make the whole project more maintainable and the whole PR and release process faster and smoother for everyone.  

So again - if we need to support Spark 1.6 and Ignite, it would be simpler and faster to make a 0.5.6 branch that is 0.5.5 plus *only* the minimal code for Spark 1.6 and Ignite.  

From: moon soo Lee <mo...@apache.org>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: December 29, 2015 at 11:16:09 PM
To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating  

Please describe a reason why do you think CI is potential blocker for 0.5.6.  

On Tue, Dec 29, 2015 at 8:14 PM Amos B. Elberg <am...@gmail.com>  
wrote:  

> I don’t think R interpreter is a blocker for 0.5.6.  
>  
> I think *CI* is a potential blocker for 0.5.6.  
>  
>  
> From: moon soo Lee <mo...@apache.org>  
> Reply: dev@zeppelin.incubator.apache.org <  
> dev@zeppelin.incubator.apache.org>  
> Date: December 29, 2015 at 11:07:49 PM  
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> To make it more clear,  
>  
> I was thinking release 0.5.6-incubating from current master branch, like we  
> did for 0.5.5-incubating release. Also including Spark 1.6 support.  
>  
>  
> Amos,  
> I'm trying to make your R interpreter PR pass CI which is unsuccessful for  
> now. If it can be merged by the time we make a branch for 0.5.6-incubating  
> release, it will be included in the release. Otherwise there is no reason  
> to be R interpreter PR be a blocker for 0.5.6-incubating release while  
> 0.5.6-incubating is not the last release from Zeppelin project.  
>  
> Thanks,  
> moon  
>  
> On Tue, Dec 29, 2015 at 8:00 PM Chae-Sung Lim <es...@gmail.com> wrote:  
>  
> > Oh, I'm sorry.  
> > Thank you. Good point.  
> >  
> > I am in favor for the release of the 0.5.6-incubating.  
> >  
> > 2015-12-29 19:56 GMT-08:00 Amos B. Elberg <am...@gmail.com>:  
> >  
> > > Chae-Sung — What Moon has proposed is a 0.5.6 release *without* Shiro.  
> > >  
> > > From: Chae-Sung Lim <es...@gmail.com> <es...@gmail.com>  
> > > Reply: dev@zeppelin.incubator.apache.org  
> > > <de...@zeppelin.incubator.apache.org> <dev@zeppelin.incubator.apache.org  
> >  
> > > Date: December 29, 2015 at 10:53:43 PM  
> > >  
> > > To: dev@zeppelin.incubator.apache.org <  
> dev@zeppelin.incubator.apache.org  
> > >  
> > > <de...@zeppelin.incubator.apache.org>  
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating  
> > >  
> > > It is a good idea.  
> > > I think that security is an enhanced version of the release is required  
> > by  
> > > the current Zeppelin.  
> > > (Shiro)  
> > >  
> > > 2015-12-29 19:32 GMT-08:00 Amos B. Elberg <am...@gmail.com>:  
> > >  
> > > > I don’t want to come off as the naysayer here, but I think the effort  
> > > that  
> > > > would go into a release would be better spent on the testing  
> > > infrastructure  
> > > > and outstanding PRs.  
> > > >  
> > > > If we feel we need a release for 1.6 and Ignite, I suggest we make a  
> > > > release that *only* includes the absolute minimal changes required to  
> > do  
> > > > that.  
> > > >  
> > > > There was one PR for 1.6 support that didn’t really work and is going  
> > to  
> > > > break anything built against the current codebase. Except for a  
> change  
> > > in  
> > > > the name of one method called by one class, all of the changes seem  
> to  
> > > > involve support for spark-under-zeppelin, which is something we want  
> to  
> > > > take out.  
> > > >  
> > > > We also don’t currently have a working testing framework. A lot of  
> PRs  
> > > > have been committed under the “ignore travis its broken” theory. I’m  
> > > > loathe to make a release that hasn’t really been tested, and it  
> doesn’t  
> > > > seem we’re in a position to do that.  
> > > >  
> > > > While there have been a lot of merged PRs, I don’t think any of them  
> > are  
> > > > on-roadmap. They mostly seem to be very minor, like fixing typos and  
> > > > changing which text box gets highlighted. Those are important things,  
> > of  
> > > > course, but not major enough to justify the effort involved in a  
> > > release.  
> > > >  
> > > > Another release will not make it easier to integrate the larger PRs.  
> It  
> > > > will have the opposite effect. Developers will have to rebase against  
> > > > whatever gets broken by 1.6 and other changes.  
> > > >  
> > > > I suggest we wait to do a significant release until we can take out  
> the  
> > > > legacy spark-under-zeppelin code that has caused so many issues,  
> have a  
> > > > working testing framework, and integrate the major outstanding PRs.  
> > > >  
> > > > So, again, if we want a release, I suggest we include the absolute  
> > > minimum  
> > > > changes necessary for 1.6 and Ignite, and perhaps call it an interim  
> or  
> > > > maintenance release.  
> > > >  
> > > >  
> > > > From: Konstantin Boudnik <co...@apache.org>  
> > > > Reply: dev@zeppelin.incubator.apache.org <  
> > > > dev@zeppelin.incubator.apache.org>,  
> dev@zeppelin.incubator.apache.org  
> > <  
> > > > dev@zeppelin.incubator.apache.org>  
> > > > Date: December 29, 2015 at 10:05:36 PM  
> > > > To: dev@zeppelin.incubator.apache.org <  
> > dev@zeppelin.incubator.apache.org>  
> > >  
> > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating  
> > > >  
> > > > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -  
> > would  
> > > > make  
> > > > sense to add this to the latest release of Zeppelin. I will open a  
> JIRA  
> > > and  
> > > > supply a patch for it, if there's no objections.  
> > > >  
> > > > Cos  
> > > >  
> > > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:  
> > > > > Hi folks,  
> > > > >  
> > > > > How about we make release 0.5.6-incubating?  
> > > > >  
> > > > > Since last release, more than 100 pull requests are merged and more  
> > > than  
> > > > 80  
> > > > > issues are resolved.  
> > > > >  
> > > > > It's including new interpreters, a lot of new features and  
> > improvement  
> > > on  
> > > > > GUI with much improved stability thanks to lots of bug fixes.  
> > > > >  
> > > > > Also it's great time to have a Zeppelin release that support Spark  
> > 1.6  
> > > (  
> > > > > ZEPPELIN-395), which about to be released.  
> > > > >  
> > > > > Once we branch for 0.5.6-incubating release, it's more safe to make  
> > > large  
> > > > > code base change such as "Added Shiro security" (  
> > > > > https://github.com/apache/incubator-zeppelin/pull/53) and many  
> other  
> > > > > planned feature in 0.6.0 roadmap, that will require lots of  
> internal  
> > > API  
> > > > > updates.  
> > > > >  
> > > > > What do you think?  
> > > > >  
> > > > > Thanks,  
> > > > > moon  
> > > >  
> > >  
> > >  
> >  
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by moon soo Lee <mo...@apache.org>.
Please describe a reason why do you think CI is potential blocker for 0.5.6.

On Tue, Dec 29, 2015 at 8:14 PM Amos B. Elberg <am...@gmail.com>
wrote:

> I don’t think R interpreter is a blocker for 0.5.6.
>
> I think *CI* is a potential blocker for 0.5.6.
>
>
> From: moon soo Lee <mo...@apache.org>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 29, 2015 at 11:07:49 PM
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> To make it more clear,
>
> I was thinking release 0.5.6-incubating from current master branch, like we
> did for 0.5.5-incubating release. Also including Spark 1.6 support.
>
>
> Amos,
> I'm trying to make your R interpreter PR pass CI which is unsuccessful for
> now. If it can be merged by the time we make a branch for 0.5.6-incubating
> release, it will be included in the release. Otherwise there is no reason
> to be R interpreter PR be a blocker for 0.5.6-incubating release while
> 0.5.6-incubating is not the last release from Zeppelin project.
>
> Thanks,
> moon
>
> On Tue, Dec 29, 2015 at 8:00 PM Chae-Sung Lim <es...@gmail.com> wrote:
>
> > Oh, I'm sorry.
> > Thank you. Good point.
> >
> > I am in favor for the release of the 0.5.6-incubating.
> >
> > 2015-12-29 19:56 GMT-08:00 Amos B. Elberg <am...@gmail.com>:
> >
> > > Chae-Sung — What Moon has proposed is a 0.5.6 release *without* Shiro.
> > >
> > > From: Chae-Sung Lim <es...@gmail.com> <es...@gmail.com>
> > > Reply: dev@zeppelin.incubator.apache.org
> > > <de...@zeppelin.incubator.apache.org> <dev@zeppelin.incubator.apache.org
> >
> > > Date: December 29, 2015 at 10:53:43 PM
> > >
> > > To: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org
> > >
> > > <de...@zeppelin.incubator.apache.org>
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > >
> > > It is a good idea.
> > > I think that security is an enhanced version of the release is required
> > by
> > > the current Zeppelin.
> > > (Shiro)
> > >
> > > 2015-12-29 19:32 GMT-08:00 Amos B. Elberg <am...@gmail.com>:
> > >
> > > > I don’t want to come off as the naysayer here, but I think the effort
> > > that
> > > > would go into a release would be better spent on the testing
> > > infrastructure
> > > > and outstanding PRs.
> > > >
> > > > If we feel we need a release for 1.6 and Ignite, I suggest we make a
> > > > release that *only* includes the absolute minimal changes required to
> > do
> > > > that.
> > > >
> > > > There was one PR for 1.6 support that didn’t really work and is going
> > to
> > > > break anything built against the current codebase. Except for a
> change
> > > in
> > > > the name of one method called by one class, all of the changes seem
> to
> > > > involve support for spark-under-zeppelin, which is something we want
> to
> > > > take out.
> > > >
> > > > We also don’t currently have a working testing framework. A lot of
> PRs
> > > > have been committed under the “ignore travis its broken” theory. I’m
> > > > loathe to make a release that hasn’t really been tested, and it
> doesn’t
> > > > seem we’re in a position to do that.
> > > >
> > > > While there have been a lot of merged PRs, I don’t think any of them
> > are
> > > > on-roadmap. They mostly seem to be very minor, like fixing typos and
> > > > changing which text box gets highlighted. Those are important things,
> > of
> > > > course, but not major enough to justify the effort involved in a
> > > release.
> > > >
> > > > Another release will not make it easier to integrate the larger PRs.
> It
> > > > will have the opposite effect. Developers will have to rebase against
> > > > whatever gets broken by 1.6 and other changes.
> > > >
> > > > I suggest we wait to do a significant release until we can take out
> the
> > > > legacy spark-under-zeppelin code that has caused so many issues,
> have a
> > > > working testing framework, and integrate the major outstanding PRs.
> > > >
> > > > So, again, if we want a release, I suggest we include the absolute
> > > minimum
> > > > changes necessary for 1.6 and Ignite, and perhaps call it an interim
> or
> > > > maintenance release.
> > > >
> > > >
> > > > From: Konstantin Boudnik <co...@apache.org>
> > > > Reply: dev@zeppelin.incubator.apache.org <
> > > > dev@zeppelin.incubator.apache.org>,
> dev@zeppelin.incubator.apache.org
> > <
> > > > dev@zeppelin.incubator.apache.org>
> > > > Date: December 29, 2015 at 10:05:36 PM
> > > > To: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>
> > >
> > > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > > >
> > > > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -
> > would
> > > > make
> > > > sense to add this to the latest release of Zeppelin. I will open a
> JIRA
> > > and
> > > > supply a patch for it, if there's no objections.
> > > >
> > > > Cos
> > > >
> > > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > > > Hi folks,
> > > > >
> > > > > How about we make release 0.5.6-incubating?
> > > > >
> > > > > Since last release, more than 100 pull requests are merged and more
> > > than
> > > > 80
> > > > > issues are resolved.
> > > > >
> > > > > It's including new interpreters, a lot of new features and
> > improvement
> > > on
> > > > > GUI with much improved stability thanks to lots of bug fixes.
> > > > >
> > > > > Also it's great time to have a Zeppelin release that support Spark
> > 1.6
> > > (
> > > > > ZEPPELIN-395), which about to be released.
> > > > >
> > > > > Once we branch for 0.5.6-incubating release, it's more safe to make
> > > large
> > > > > code base change such as "Added Shiro security" (
> > > > > https://github.com/apache/incubator-zeppelin/pull/53) and many
> other
> > > > > planned feature in 0.6.0 roadmap, that will require lots of
> internal
> > > API
> > > > > updates.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Thanks,
> > > > > moon
> > > >
> > >
> > >
> >
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by "Amos B. Elberg" <am...@gmail.com>.
I don’t think R interpreter is a blocker for 0.5.6.

I think *CI* is a potential blocker for 0.5.6.  


From: moon soo Lee <mo...@apache.org>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: December 29, 2015 at 11:07:49 PM
To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating  

To make it more clear,  

I was thinking release 0.5.6-incubating from current master branch, like we  
did for 0.5.5-incubating release. Also including Spark 1.6 support.  


Amos,  
I'm trying to make your R interpreter PR pass CI which is unsuccessful for  
now. If it can be merged by the time we make a branch for 0.5.6-incubating  
release, it will be included in the release. Otherwise there is no reason  
to be R interpreter PR be a blocker for 0.5.6-incubating release while  
0.5.6-incubating is not the last release from Zeppelin project.  

Thanks,  
moon  

On Tue, Dec 29, 2015 at 8:00 PM Chae-Sung Lim <es...@gmail.com> wrote:  

> Oh, I'm sorry.  
> Thank you. Good point.  
>  
> I am in favor for the release of the 0.5.6-incubating.  
>  
> 2015-12-29 19:56 GMT-08:00 Amos B. Elberg <am...@gmail.com>:  
>  
> > Chae-Sung — What Moon has proposed is a 0.5.6 release *without* Shiro.  
> >  
> > From: Chae-Sung Lim <es...@gmail.com> <es...@gmail.com>  
> > Reply: dev@zeppelin.incubator.apache.org  
> > <de...@zeppelin.incubator.apache.org> <de...@zeppelin.incubator.apache.org>  
> > Date: December 29, 2015 at 10:53:43 PM  
> >  
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org  
> >  
> > <de...@zeppelin.incubator.apache.org>  
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating  
> >  
> > It is a good idea.  
> > I think that security is an enhanced version of the release is required  
> by  
> > the current Zeppelin.  
> > (Shiro)  
> >  
> > 2015-12-29 19:32 GMT-08:00 Amos B. Elberg <am...@gmail.com>:  
> >  
> > > I don’t want to come off as the naysayer here, but I think the effort  
> > that  
> > > would go into a release would be better spent on the testing  
> > infrastructure  
> > > and outstanding PRs.  
> > >  
> > > If we feel we need a release for 1.6 and Ignite, I suggest we make a  
> > > release that *only* includes the absolute minimal changes required to  
> do  
> > > that.  
> > >  
> > > There was one PR for 1.6 support that didn’t really work and is going  
> to  
> > > break anything built against the current codebase. Except for a change  
> > in  
> > > the name of one method called by one class, all of the changes seem to  
> > > involve support for spark-under-zeppelin, which is something we want to  
> > > take out.  
> > >  
> > > We also don’t currently have a working testing framework. A lot of PRs  
> > > have been committed under the “ignore travis its broken” theory. I’m  
> > > loathe to make a release that hasn’t really been tested, and it doesn’t  
> > > seem we’re in a position to do that.  
> > >  
> > > While there have been a lot of merged PRs, I don’t think any of them  
> are  
> > > on-roadmap. They mostly seem to be very minor, like fixing typos and  
> > > changing which text box gets highlighted. Those are important things,  
> of  
> > > course, but not major enough to justify the effort involved in a  
> > release.  
> > >  
> > > Another release will not make it easier to integrate the larger PRs. It  
> > > will have the opposite effect. Developers will have to rebase against  
> > > whatever gets broken by 1.6 and other changes.  
> > >  
> > > I suggest we wait to do a significant release until we can take out the  
> > > legacy spark-under-zeppelin code that has caused so many issues, have a  
> > > working testing framework, and integrate the major outstanding PRs.  
> > >  
> > > So, again, if we want a release, I suggest we include the absolute  
> > minimum  
> > > changes necessary for 1.6 and Ignite, and perhaps call it an interim or  
> > > maintenance release.  
> > >  
> > >  
> > > From: Konstantin Boudnik <co...@apache.org>  
> > > Reply: dev@zeppelin.incubator.apache.org <  
> > > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org  
> <  
> > > dev@zeppelin.incubator.apache.org>  
> > > Date: December 29, 2015 at 10:05:36 PM  
> > > To: dev@zeppelin.incubator.apache.org <  
> dev@zeppelin.incubator.apache.org>  
> >  
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating  
> > >  
> > > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -  
> would  
> > > make  
> > > sense to add this to the latest release of Zeppelin. I will open a JIRA  
> > and  
> > > supply a patch for it, if there's no objections.  
> > >  
> > > Cos  
> > >  
> > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:  
> > > > Hi folks,  
> > > >  
> > > > How about we make release 0.5.6-incubating?  
> > > >  
> > > > Since last release, more than 100 pull requests are merged and more  
> > than  
> > > 80  
> > > > issues are resolved.  
> > > >  
> > > > It's including new interpreters, a lot of new features and  
> improvement  
> > on  
> > > > GUI with much improved stability thanks to lots of bug fixes.  
> > > >  
> > > > Also it's great time to have a Zeppelin release that support Spark  
> 1.6  
> > (  
> > > > ZEPPELIN-395), which about to be released.  
> > > >  
> > > > Once we branch for 0.5.6-incubating release, it's more safe to make  
> > large  
> > > > code base change such as "Added Shiro security" (  
> > > > https://github.com/apache/incubator-zeppelin/pull/53) and many other  
> > > > planned feature in 0.6.0 roadmap, that will require lots of internal  
> > API  
> > > > updates.  
> > > >  
> > > > What do you think?  
> > > >  
> > > > Thanks,  
> > > > moon  
> > >  
> >  
> >  
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by moon soo Lee <mo...@apache.org>.
To make it more clear,

I was thinking release 0.5.6-incubating from current master branch, like we
did for 0.5.5-incubating release. Also including Spark 1.6 support.


Amos,
I'm trying to make your R interpreter PR pass CI which is unsuccessful for
now. If it can be merged by the time we make a branch for 0.5.6-incubating
release, it will be included in the release. Otherwise there is no reason
to be R interpreter PR be a blocker for 0.5.6-incubating release while
0.5.6-incubating is not the last release from Zeppelin project.

Thanks,
moon

On Tue, Dec 29, 2015 at 8:00 PM Chae-Sung Lim <es...@gmail.com> wrote:

> Oh, I'm sorry.
> Thank you. Good point.
>
> I am in favor for the release of the 0.5.6-incubating.
>
> 2015-12-29 19:56 GMT-08:00 Amos B. Elberg <am...@gmail.com>:
>
> > Chae-Sung — What Moon has proposed is a 0.5.6 release *without* Shiro.
> >
> > From: Chae-Sung Lim <es...@gmail.com> <es...@gmail.com>
> > Reply: dev@zeppelin.incubator.apache.org
> > <de...@zeppelin.incubator.apache.org> <de...@zeppelin.incubator.apache.org>
> > Date: December 29, 2015 at 10:53:43 PM
> >
> > To: dev@zeppelin.incubator.apache.org <dev@zeppelin.incubator.apache.org
> >
> > <de...@zeppelin.incubator.apache.org>
> > Subject:  Re: [DISCUSS] Release 0.5.6-incubating
> >
> > It is a good idea.
> > I think that security is an enhanced version of the release is required
> by
> > the current Zeppelin.
> > (Shiro)
> >
> > 2015-12-29 19:32 GMT-08:00 Amos B. Elberg <am...@gmail.com>:
> >
> > > I don’t want to come off as the naysayer here, but I think the effort
> > that
> > > would go into a release would be better spent on the testing
> > infrastructure
> > > and outstanding PRs.
> > >
> > > If we feel we need a release for 1.6 and Ignite, I suggest we make a
> > > release that *only* includes the absolute minimal changes required to
> do
> > > that.
> > >
> > > There was one PR for 1.6 support that didn’t really work and is going
> to
> > > break anything built against the current codebase. Except for a change
> > in
> > > the name of one method called by one class, all of the changes seem to
> > > involve support for spark-under-zeppelin, which is something we want to
> > > take out.
> > >
> > > We also don’t currently have a working testing framework. A lot of PRs
> > > have been committed under the “ignore travis its broken” theory. I’m
> > > loathe to make a release that hasn’t really been tested, and it doesn’t
> > > seem we’re in a position to do that.
> > >
> > > While there have been a lot of merged PRs, I don’t think any of them
> are
> > > on-roadmap. They mostly seem to be very minor, like fixing typos and
> > > changing which text box gets highlighted. Those are important things,
> of
> > > course, but not major enough to justify the effort involved in a
> > release.
> > >
> > > Another release will not make it easier to integrate the larger PRs. It
> > > will have the opposite effect. Developers will have to rebase against
> > > whatever gets broken by 1.6 and other changes.
> > >
> > > I suggest we wait to do a significant release until we can take out the
> > > legacy spark-under-zeppelin code that has caused so many issues, have a
> > > working testing framework, and integrate the major outstanding PRs.
> > >
> > > So, again, if we want a release, I suggest we include the absolute
> > minimum
> > > changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> > > maintenance release.
> > >
> > >
> > > From: Konstantin Boudnik <co...@apache.org>
> > > Reply: dev@zeppelin.incubator.apache.org <
> > > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org
> <
> > > dev@zeppelin.incubator.apache.org>
> > > Date: December 29, 2015 at 10:05:36 PM
> > > To: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> >
> > > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> > >
> > > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final -
> would
> > > make
> > > sense to add this to the latest release of Zeppelin. I will open a JIRA
> > and
> > > supply a patch for it, if there's no objections.
> > >
> > > Cos
> > >
> > > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > > Hi folks,
> > > >
> > > > How about we make release 0.5.6-incubating?
> > > >
> > > > Since last release, more than 100 pull requests are merged and more
> > than
> > > 80
> > > > issues are resolved.
> > > >
> > > > It's including new interpreters, a lot of new features and
> improvement
> > on
> > > > GUI with much improved stability thanks to lots of bug fixes.
> > > >
> > > > Also it's great time to have a Zeppelin release that support Spark
> 1.6
> > (
> > > > ZEPPELIN-395), which about to be released.
> > > >
> > > > Once we branch for 0.5.6-incubating release, it's more safe to make
> > large
> > > > code base change such as "Added Shiro security" (
> > > > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > > > planned feature in 0.6.0 roadmap, that will require lots of internal
> > API
> > > > updates.
> > > >
> > > > What do you think?
> > > >
> > > > Thanks,
> > > > moon
> > >
> >
> >
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Chae-Sung Lim <es...@gmail.com>.
Oh, I'm sorry.
Thank you. Good point.

I am in favor for the release of the 0.5.6-incubating.

2015-12-29 19:56 GMT-08:00 Amos B. Elberg <am...@gmail.com>:

> Chae-Sung — What Moon has proposed is a 0.5.6 release *without* Shiro.
>
> From: Chae-Sung Lim <es...@gmail.com> <es...@gmail.com>
> Reply: dev@zeppelin.incubator.apache.org
> <de...@zeppelin.incubator.apache.org> <de...@zeppelin.incubator.apache.org>
> Date: December 29, 2015 at 10:53:43 PM
>
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> It is a good idea.
> I think that security is an enhanced version of the release is required by
> the current Zeppelin.
> (Shiro)
>
> 2015-12-29 19:32 GMT-08:00 Amos B. Elberg <am...@gmail.com>:
>
> > I don’t want to come off as the naysayer here, but I think the effort
> that
> > would go into a release would be better spent on the testing
> infrastructure
> > and outstanding PRs.
> >
> > If we feel we need a release for 1.6 and Ignite, I suggest we make a
> > release that *only* includes the absolute minimal changes required to do
> > that.
> >
> > There was one PR for 1.6 support that didn’t really work and is going to
> > break anything built against the current codebase. Except for a change
> in
> > the name of one method called by one class, all of the changes seem to
> > involve support for spark-under-zeppelin, which is something we want to
> > take out.
> >
> > We also don’t currently have a working testing framework. A lot of PRs
> > have been committed under the “ignore travis its broken” theory. I’m
> > loathe to make a release that hasn’t really been tested, and it doesn’t
> > seem we’re in a position to do that.
> >
> > While there have been a lot of merged PRs, I don’t think any of them are
> > on-roadmap. They mostly seem to be very minor, like fixing typos and
> > changing which text box gets highlighted. Those are important things, of
> > course, but not major enough to justify the effort involved in a
> release.
> >
> > Another release will not make it easier to integrate the larger PRs. It
> > will have the opposite effect. Developers will have to rebase against
> > whatever gets broken by 1.6 and other changes.
> >
> > I suggest we wait to do a significant release until we can take out the
> > legacy spark-under-zeppelin code that has caused so many issues, have a
> > working testing framework, and integrate the major outstanding PRs.
> >
> > So, again, if we want a release, I suggest we include the absolute
> minimum
> > changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> > maintenance release.
> >
> >
> > From: Konstantin Boudnik <co...@apache.org>
> > Reply: dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <
> > dev@zeppelin.incubator.apache.org>
> > Date: December 29, 2015 at 10:05:36 PM
> > To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
>
> > Subject: Re: [DISCUSS] Release 0.5.6-incubating
> >
> > Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
> > make
> > sense to add this to the latest release of Zeppelin. I will open a JIRA
> and
> > supply a patch for it, if there's no objections.
> >
> > Cos
> >
> > On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > > Hi folks,
> > >
> > > How about we make release 0.5.6-incubating?
> > >
> > > Since last release, more than 100 pull requests are merged and more
> than
> > 80
> > > issues are resolved.
> > >
> > > It's including new interpreters, a lot of new features and improvement
> on
> > > GUI with much improved stability thanks to lots of bug fixes.
> > >
> > > Also it's great time to have a Zeppelin release that support Spark 1.6
> (
> > > ZEPPELIN-395), which about to be released.
> > >
> > > Once we branch for 0.5.6-incubating release, it's more safe to make
> large
> > > code base change such as "Added Shiro security" (
> > > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > > planned feature in 0.6.0 roadmap, that will require lots of internal
> API
> > > updates.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > moon
> >
>
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by "Amos B. Elberg" <am...@gmail.com>.
Chae-Sung — What Moon has proposed is a 0.5.6 release *without* Shiro.  

From: Chae-Sung Lim <es...@gmail.com>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: December 29, 2015 at 10:53:43 PM
To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating  

It is a good idea.  
I think that security is an enhanced version of the release is required by  
the current Zeppelin.  
(Shiro)  

2015-12-29 19:32 GMT-08:00 Amos B. Elberg <am...@gmail.com>:  

> I don’t want to come off as the naysayer here, but I think the effort that  
> would go into a release would be better spent on the testing infrastructure  
> and outstanding PRs.  
>  
> If we feel we need a release for 1.6 and Ignite, I suggest we make a  
> release that *only* includes the absolute minimal changes required to do  
> that.  
>  
> There was one PR for 1.6 support that didn’t really work and is going to  
> break anything built against the current codebase. Except for a change in  
> the name of one method called by one class, all of the changes seem to  
> involve support for spark-under-zeppelin, which is something we want to  
> take out.  
>  
> We also don’t currently have a working testing framework. A lot of PRs  
> have been committed under the “ignore travis its broken” theory. I’m  
> loathe to make a release that hasn’t really been tested, and it doesn’t  
> seem we’re in a position to do that.  
>  
> While there have been a lot of merged PRs, I don’t think any of them are  
> on-roadmap. They mostly seem to be very minor, like fixing typos and  
> changing which text box gets highlighted. Those are important things, of  
> course, but not major enough to justify the effort involved in a release.  
>  
> Another release will not make it easier to integrate the larger PRs. It  
> will have the opposite effect. Developers will have to rebase against  
> whatever gets broken by 1.6 and other changes.  
>  
> I suggest we wait to do a significant release until we can take out the  
> legacy spark-under-zeppelin code that has caused so many issues, have a  
> working testing framework, and integrate the major outstanding PRs.  
>  
> So, again, if we want a release, I suggest we include the absolute minimum  
> changes necessary for 1.6 and Ignite, and perhaps call it an interim or  
> maintenance release.  
>  
>  
> From: Konstantin Boudnik <co...@apache.org>  
> Reply: dev@zeppelin.incubator.apache.org <  
> dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <  
> dev@zeppelin.incubator.apache.org>  
> Date: December 29, 2015 at 10:05:36 PM  
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>  
> Subject: Re: [DISCUSS] Release 0.5.6-incubating  
>  
> Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would  
> make  
> sense to add this to the latest release of Zeppelin. I will open a JIRA and  
> supply a patch for it, if there's no objections.  
>  
> Cos  
>  
> On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:  
> > Hi folks,  
> >  
> > How about we make release 0.5.6-incubating?  
> >  
> > Since last release, more than 100 pull requests are merged and more than  
> 80  
> > issues are resolved.  
> >  
> > It's including new interpreters, a lot of new features and improvement on  
> > GUI with much improved stability thanks to lots of bug fixes.  
> >  
> > Also it's great time to have a Zeppelin release that support Spark 1.6 (  
> > ZEPPELIN-395), which about to be released.  
> >  
> > Once we branch for 0.5.6-incubating release, it's more safe to make large  
> > code base change such as "Added Shiro security" (  
> > https://github.com/apache/incubator-zeppelin/pull/53) and many other  
> > planned feature in 0.6.0 roadmap, that will require lots of internal API  
> > updates.  
> >  
> > What do you think?  
> >  
> > Thanks,  
> > moon  
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Chae-Sung Lim <es...@gmail.com>.
It is a good idea.
I think that security is an enhanced version of the release is required by
the current Zeppelin.
(Shiro)

2015-12-29 19:32 GMT-08:00 Amos B. Elberg <am...@gmail.com>:

> I don’t want to come off as the naysayer here, but I think the effort that
> would go into a release would be better spent on the testing infrastructure
> and outstanding PRs.
>
> If we feel we need a release for 1.6 and Ignite, I suggest we make a
> release that *only* includes the absolute minimal changes required to do
> that.
>
> There was one PR for 1.6 support that didn’t really work and is going to
> break anything built against the current codebase.  Except for a change in
> the name of one method called by one class, all of the changes seem to
> involve support for spark-under-zeppelin, which is something we want to
> take out.
>
> We also don’t currently have a working testing framework.  A lot of PRs
> have been committed under the “ignore travis its broken” theory.  I’m
> loathe to make a release that hasn’t really been tested, and it doesn’t
> seem we’re in a position to do that.
>
> While there have been a lot of merged PRs, I don’t think any of them are
> on-roadmap. They mostly seem to be very minor, like fixing typos and
> changing which text box gets highlighted.  Those are important things, of
> course, but not major enough to justify the effort involved in a release.
>
> Another release will not make it easier to integrate the larger PRs.  It
> will have the opposite effect.  Developers will have to rebase against
> whatever gets broken by 1.6 and other changes.
>
> I suggest we wait to do a significant release until we can take out the
> legacy spark-under-zeppelin code that has caused so many issues, have a
> working testing framework, and integrate the major outstanding PRs.
>
> So, again, if we want a release, I suggest we include the absolute minimum
> changes necessary for 1.6 and Ignite, and perhaps call it an interim or
> maintenance release.
>
>
> From: Konstantin Boudnik <co...@apache.org>
> Reply: dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <
> dev@zeppelin.incubator.apache.org>
> Date: December 29, 2015 at 10:05:36 PM
> To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
> Subject:  Re: [DISCUSS] Release 0.5.6-incubating
>
> Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
> make
> sense to add this to the latest release of Zeppelin. I will open a JIRA and
> supply a patch for it, if there's no objections.
>
> Cos
>
> On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > Hi folks,
> >
> > How about we make release 0.5.6-incubating?
> >
> > Since last release, more than 100 pull requests are merged and more than
> 80
> > issues are resolved.
> >
> > It's including new interpreters, a lot of new features and improvement on
> > GUI with much improved stability thanks to lots of bug fixes.
> >
> > Also it's great time to have a Zeppelin release that support Spark 1.6 (
> > ZEPPELIN-395), which about to be released.
> >
> > Once we branch for 0.5.6-incubating release, it's more safe to make large
> > code base change such as "Added Shiro security" (
> > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > planned feature in 0.6.0 roadmap, that will require lots of internal API
> > updates.
> >
> > What do you think?
> >
> > Thanks,
> > moon
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by "Amos B. Elberg" <am...@gmail.com>.
I don’t want to come off as the naysayer here, but I think the effort that would go into a release would be better spent on the testing infrastructure and outstanding PRs.  

If we feel we need a release for 1.6 and Ignite, I suggest we make a release that *only* includes the absolute minimal changes required to do that. 

There was one PR for 1.6 support that didn’t really work and is going to break anything built against the current codebase.  Except for a change in the name of one method called by one class, all of the changes seem to involve support for spark-under-zeppelin, which is something we want to take out.  

We also don’t currently have a working testing framework.  A lot of PRs have been committed under the “ignore travis its broken” theory.  I’m loathe to make a release that hasn’t really been tested, and it doesn’t seem we’re in a position to do that.  

While there have been a lot of merged PRs, I don’t think any of them are on-roadmap. They mostly seem to be very minor, like fixing typos and changing which text box gets highlighted.  Those are important things, of course, but not major enough to justify the effort involved in a release.  

Another release will not make it easier to integrate the larger PRs.  It will have the opposite effect.  Developers will have to rebase against whatever gets broken by 1.6 and other changes.  

I suggest we wait to do a significant release until we can take out the legacy spark-under-zeppelin code that has caused so many issues, have a working testing framework, and integrate the major outstanding PRs.  

So, again, if we want a release, I suggest we include the absolute minimum changes necessary for 1.6 and Ignite, and perhaps call it an interim or maintenance release.  


From: Konstantin Boudnik <co...@apache.org>
Reply: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>, dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Date: December 29, 2015 at 10:05:36 PM
To: dev@zeppelin.incubator.apache.org <de...@zeppelin.incubator.apache.org>
Subject:  Re: [DISCUSS] Release 0.5.6-incubating  

Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would make  
sense to add this to the latest release of Zeppelin. I will open a JIRA and  
supply a patch for it, if there's no objections.  

Cos  

On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:  
> Hi folks,  
>  
> How about we make release 0.5.6-incubating?  
>  
> Since last release, more than 100 pull requests are merged and more than 80  
> issues are resolved.  
>  
> It's including new interpreters, a lot of new features and improvement on  
> GUI with much improved stability thanks to lots of bug fixes.  
>  
> Also it's great time to have a Zeppelin release that support Spark 1.6 (  
> ZEPPELIN-395), which about to be released.  
>  
> Once we branch for 0.5.6-incubating release, it's more safe to make large  
> code base change such as "Added Shiro security" (  
> https://github.com/apache/incubator-zeppelin/pull/53) and many other  
> planned feature in 0.6.0 roadmap, that will require lots of internal API  
> updates.  
>  
> What do you think?  
>  
> Thanks,  
> moon

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Corneau Damien <co...@gmail.com>.
Good idea!
There is still a few bug fixes that could be included in that release,
but I think they should be solved by the time the release branch is being
created :)

On Wed, Dec 30, 2015 at 12:05 PM, Konstantin Boudnik <co...@apache.org> wrote:

> Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would
> make
> sense to add this to the latest release of Zeppelin. I will open a JIRA and
> supply a patch for it, if there's no objections.
>
> Cos
>
> On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> > Hi folks,
> >
> > How about we make release 0.5.6-incubating?
> >
> > Since last release, more than 100 pull requests are merged and more than
> 80
> > issues are resolved.
> >
> > It's including new interpreters, a lot of new features and improvement on
> > GUI with much improved stability thanks to lots of bug fixes.
> >
> > Also it's great time to have a Zeppelin release that support Spark 1.6 (
> > ZEPPELIN-395), which about to be released.
> >
> > Once we branch for 0.5.6-incubating release, it's more safe to make large
> > code base change such as "Added Shiro security" (
> > https://github.com/apache/incubator-zeppelin/pull/53) and many other
> > planned feature in 0.6.0 roadmap, that will require lots of internal API
> > updates.
> >
> > What do you think?
> >
> > Thanks,
> > moon
>

Re: [DISCUSS] Release 0.5.6-incubating

Posted by Konstantin Boudnik <co...@apache.org>.
Good idea! BTW, Apache Ignite is voting right now on 1.5.0.final - would make
sense to add this to the latest release of Zeppelin. I will open a JIRA and
supply a patch for it, if there's no objections.

Cos

On Wed, Dec 30, 2015 at 03:00AM, moon soo Lee wrote:
> Hi folks,
> 
> How about we make release 0.5.6-incubating?
> 
> Since last release, more than 100 pull requests are merged and more than 80
> issues are resolved.
> 
> It's including new interpreters, a lot of new features and improvement on
> GUI with much improved stability thanks to lots of bug fixes.
> 
> Also it's great time to have a Zeppelin release that support Spark 1.6 (
> ZEPPELIN-395), which about to be released.
> 
> Once we branch for 0.5.6-incubating release, it's more safe to make large
> code base change such as "Added Shiro security" (
> https://github.com/apache/incubator-zeppelin/pull/53) and many other
> planned feature in 0.6.0 roadmap, that will require lots of internal API
> updates.
> 
> What do you think?
> 
> Thanks,
> moon