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 <[email protected]> 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 <[email protected]> wrote: > > > +1 for 0.5.6 release from maser > > > > On Wed, Dec 30, 2015 at 9:51 PM, Khalid Huseynov <[email protected]> > > wrote: > > > > > +1 for 0.5.6 release with current improvements/fixes. > > > > > > > > > On Wed, Dec 30, 2015 at 4:10 PM, moon soo Lee <[email protected]> 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 < > [email protected] > > > > > > > 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 <[email protected]> > > > > > Reply: [email protected] < > > > > > [email protected]> > > > > > Date: December 30, 2015 at 1:36:58 AM > > > > > To: [email protected] < > > > [email protected] > > > > > > > > > > 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 < > > [email protected] > > > > > > > > > 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 <[email protected]> > > > > > > Reply: Jongyoul Lee <[email protected]> > > > > > > Date: December 30, 2015 at 1:05:55 AM > > > > > > To: Amos B. Elberg <[email protected]> > > > > > > CC: [email protected] < > > > > [email protected] > > > > > > > > > > > > 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 < > > > [email protected] > > > > > > > > > > > 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 <[email protected]> > > > > > > Reply: Jongyoul Lee <[email protected]> > > > > > > Date: December 30, 2015 at 12:32:01 AM > > > > > > > > > > > > To: Amos B. Elberg <[email protected]> > > > > > > CC: [email protected] < > > > > [email protected] > > > > > > > > > > > > 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 < > > > [email protected] > > > > > > > > > > > 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 <[email protected]> > > > > > > Reply: Jongyoul Lee <[email protected]> > > > > > > Date: December 29, 2015 at 11:54:35 PM > > > > > > To: Amos B. Elberg <[email protected]> > > > > > > CC: [email protected] < > > > > [email protected] > > > > > > > > > > > > > > > > > > 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 < > > > [email protected] > > > > > > > > > > > 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 <[email protected]> > > > > > > Reply: Jongyoul Lee <[email protected]> > > > > > > Date: December 29, 2015 at 11:21:00 PM > > > > > > To: Amos B. Elberg <[email protected]>, > > > > > > [email protected] < > > [email protected] > > > > > > > > > > > > > > > > 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 < > > > [email protected] > > > > > > > > > > > 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 <[email protected]> > > > > > > Reply: Jongyoul Lee <[email protected]> > > > > > > Date: December 29, 2015 at 11:08:36 PM > > > > > > To: Amos B. Elberg <[email protected]> > > > > > > > > > > > > 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 < > > > > [email protected]> > > > > > > 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 <[email protected]> > > > > > > Reply: [email protected] < > > > > > > [email protected]> > > > > > > Date: December 29, 2015 at 10:56:33 PM > > > > > > > > > > > > To: [email protected] < > > > > [email protected] > > > > > > > > > > > > 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 < > > > > [email protected]> > > > > > > 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 <[email protected]> > > > > > > > Reply: [email protected] < > > > > > > > [email protected]>, > > > > [email protected] > > > > > < > > > > > > > [email protected]> > > > > > > > Date: December 29, 2015 at 10:05:36 PM > > > > > > > To: [email protected] < > > > > > [email protected] > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > >
