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 <jongy...@gmail.com>
Reply: Jongyoul Lee <jongy...@gmail.com>
Date: December 29, 2015 at 11:54:35 PM
To: Amos B. Elberg <amos.elb...@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.elb...@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 <jongy...@gmail.com>
Reply: Jongyoul Lee <jongy...@gmail.com>
Date: December 29, 2015 at 11:21:00 PM
To: Amos B. Elberg <amos.elb...@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.elb...@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 <jongy...@gmail.com>
Reply: Jongyoul Lee <jongy...@gmail.com>
Date: December 29, 2015 at 11:08:36 PM
To: Amos B. Elberg <amos.elb...@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.elb...@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 <jongy...@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.elb...@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 <c...@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

Reply via email to