Re: [DISCUSS] Time to cut Geode 1.10.0?

From that email: To make this work, it's important to be strict about cutting the release branch on the set date and only allow critical fixes after the release has been cut. Once we start compromising on this, we go down a slippery slope that ultimately leads to not getting the predictability ben

Re: [DISCUSS] Time to cut Geode 1.10.0?

Hi Karen, Here is the previous discussion that was very positively received: https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E However, JIRA tells me that GEODE-7013 is already fixed. If we were to go with a SHA from this week

Re: [DISCUSS] Time to cut Geode 1.10.0?

Alexander, can you point me at the policy decision for the "critical issue" rule you mention? I always though it was up to the release manager. I want GEODE-7013 fixes in because it is the right thing to do. Our gfsh help/hint wasn't working the way we say that it did. With the fix, it does. I w

PR Reviews

Would anyone be able to review and/or merge the following 2 PRs? GEODE-6298: Fix flaky test scanMovesRecentlyUsedNodeToTail GEODE-7003: Fix flaky tests in GemFireTransactionDataSourceIntegrationTest Thanks, A

Re: [DISCUSS] Time to cut Geode 1.10.0?

Our "critical issue” rule has the effect that the bar to commit to develop is “low”, but the bar to cherry-pick to support branch is “very high”. Contributors could plan around this disparity more easily if any of the following were true: - releases were more frequent - planned cut date of relea

Re: [DISCUSS] Time to cut Geode 1.10.0?

The selected SHA seems rather arbitrary. Could you enlighten us as to why one from last week rather than say today? GEODE-7006 fixes a bug introduced in 1.9. GEODE-7008 fixes a similar issue introduced in incubation. Both were merged today. > On Jul 30, 2019, at 10:38 AM, Dick Cavender wrote

Re: [DISCUSS] Time to cut Geode 1.10.0?

Dick, thank you for stepping up! I think it's great to cut the branch sooner rather than later. There already is GEODE-7012 which introduces a distributed deadlock during startup. That seems like a critical issue to fix. That should be able to happen after we cut the branch though. Karen, I wonde

Re: [DISCUSS] Time to cut Geode 1.10.0?

I'd like to see the changes from https://issues.apache.org/jira/browse/GEODE-7013 included in the Geode 1.10 release. GEODE-7013's changes restore gfsh help/hint behavior that was lost during a refactor in the earliest releases of Geode. The commit occurred after SHA1 dc6890107a2651d8ba1450e8db8a1

Re: [DISCUSS] Time to cut Geode 1.10.0?

I'll take on the Release Manager role for Geode 1.10 with the 1.9.0 release manager's help (Owen:). I'd like to propose cutting the release/1.10 branch off develop sha: dc6890107a2651d8ba1450e8db8a1c39d712fdc7 aka: 1.10.0-SNAPSHOT.476 Please speak up and discuss. We'll then start taking consider

Re: PR reviews

Is there anyone who knows enough about security and JMX to review PR #3697 (GEODE-6717 NotAuthorizedException during JMX scraping)? Jinmei is out on PTO until mid next week. On Mon, Jul 29, 2019 at 1:51 AM Mario Kevo wrote: > Hi Geode dev, > > We need some PR reviewers on the following PRs. Some

Re: Problem with LGTM on geode-native pull request

Yes, that seems to be the issue. Can you update the lgtm.yml and push to your branch. Thanks, Jake > On Jul 30, 2019, at 5:09 AM, Alberto Gomez wrote: > > Hi, > > I am getting a failure on the C/C++ LGTM analysis over a recently > created pull request on geode-native: > https://github.com/

Problem with LGTM on geode-native pull request

Hi, I am getting a failure on the C/C++ LGTM analysis over a recently created pull request on geode-native: https://github.com/apache/geode-native/pull/504 I have noticed that this it the first PR on geode-native having LGTM analysis. There is a .lgtm.yml on the repo that does not seem up to