Re: [VOTE] Move geode to the attic

+1 From: Dan Smith Sent: Monday, October 24, 2022 10:51 AM To: dev@geode.apache.org Subject: [VOTE] Move geode to the attic ⚠ External Email Hi folks, Last week we discussed moving Geode to the attic [1]. I'm sad to find us at this point. But given that we wil

Re: CODEOWNERS? (was Re: Pending PR reviews)

+1 to Anthony's suggestion I strongly supported the idea behind CODEOWNERS when it was originally implemented, but the reality of the process has been a lot more disruptive to smooth workflows than I anticipated, both as someone who's waiting for code review and as someone who gets tagged to re

Re: [VOTE] Apache Geode 1.15.0.RC1

+1 Verified that performance across a variety of workloads is on par with previous releases. From: Owen Nichols Sent: Friday, June 17, 2022 9:22 AM To: dev@geode.apache.org Subject: [VOTE] Apache Geode 1.15.0.RC1 ⚠ External Email Hello Geode Dev Community, Th

Re: [Proposal] Make "Affects Version" field mandatory for new tickets with "Bug" issue type in JIRA

t;Bug" issue type in JIRA ⚠ External Email I think this is a great idea! I looked into this a while ago, but at the time couldn't find a way to make a field required only for a certain ticket type without additional, commercial extensions for JIRA.

[Proposal] Make "Affects Version" field mandatory for new tickets with "Bug" issue type in JIRA

The dialog window that opens in the Geode JIRA when creating a new ticket currently has three mandatory fields; Project, Issue Type and Summary, which are necessary for every ticket. There are also three optional fields for Component, Description and Affects Version, since there are cases when a

Re: [discuss] Future of the geode-redis module

It's been almost a month since this discussion was started, and all the responses have been supportive of the idea. Is this still something that the Geode community intends to do? Should there be a [vote] email sent out to confirm this course of action? From: Ale

Re: [discuss] Future of the geode-redis module

I agree with this proposal. As someone who has contributed a great deal of time and effort to the geode-for-redis module in the past year or so, it's sad to see it go, but realistically, the last thing that Geode needs is more unmaintained code. Our track record for removing dead or deprecated

Re: [PROPOSAL] annul support/1.15

+1 Given the amount of work that it's apparent is still needed for 1.15 to be ready to release, it seems like the sensible thing to do to reset and try again once we're closer to being done. I don't think we would have cut the branch when we did if we'd known what work was still left, and maint

Re: [Suspected Spam] [VOTE] Apache Geode 1.14.4.RC1

+1 Confirmed that performance across a variety of workloads is on par with previous releases. From: Dick Cavender Sent: Tuesday, March 15, 2022 3:41 PM To: dev@geode.apache.org Subject: [Suspected Spam] [VOTE] Apache Geode 1.14.4.RC1 Hello Geode Dev Community,

Re: [Suspected Spam] [VOTE] Apache Geode 1.13.8.RC1

+1 Confirmed that performance across a variety of workloads was on par with previous releases. From: Dick Cavender Sent: Wednesday, March 9, 2022 3:47 PM To: dev@geode.apache.org Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.8.RC1 Hello Geode Dev Community

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.9.RC1

+1 Confirmed that performance is on par with previous releases for a variety of workloads From: Dick Cavender Sent: Friday, March 4, 2022 2:05 PM To: dev@geode.apache.org Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.9.RC1 Hello Geode Dev Community, This

Re: Proposal: Cut 1.15 release branch from SHA 8f7193c827ee3198ae374101221c02039c70a561

To clarify what I think might be a misunderstanding here, there is zero evidence of any kind that the large warning clean-up PR has introduced any issues, performance-related or otherwise. For my two cents on cutting the branch at the commit before the big change, I'm of the same opinion as Rob

Re: [Suspected Spam] [VOTE] Apache Geode 1.14.3.RC1

+1 Confirmed that performance across a variety of workloads is on par with previous releases. From: Dick Cavender Sent: Friday, January 21, 2022 9:25 AM To: dev@geode.apache.org Subject: [Suspected Spam] [VOTE] Apache Geode 1.14.3.RC1 Hello Geode Dev Community,

Re: [Suspected Spam] [VOTE] Apache Geode 1.13.7.RC1

+1 Tested that performance across a variety of workloads is on par with previous released versions and no performance degradations have been introduced. From: Dick Cavender Sent: Monday, January 17, 2022 11:20 AM To: dev@geode.apache.org Subject: [Suspected Spam

Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

+1 on releasing this From: Nabarun Nag Sent: Tuesday, January 11, 2022 4:45 PM To: dev@geode.apache.org Subject: Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2 +1 to move along with this release. Here is the URI of the component archive specification s

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.8.RC1

+1 Verified that performance across a variety of workloads is on par with previous versions. From: Dick Cavender Sent: Monday, January 10, 2022 3:34 PM To: dev@geode.apache.org Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.8.RC1 Hello Geode Dev Community,

LGTM as a gating job on PRs not actually gating?

I just noticed something when reviewing a PR. We recently voted to make the LGTM check a required precheckin job, but even if that job finds newly introduced alerts, it doesn't turn red and block the PR. This seems like it's not working as intended. The comment from LGTM showing that there are

Re: [DISCUSS] batch patch release voting

The thing I wonder about with this decision is what happens if there are no problems with two of the releases, but one of them has some showstopping issue that needs to be addressed. Given that not every fix that's going into 1.14.1 is going into 1.12.6, it's possible that an unrelated issue wi

Re: @TestOnly or @VisibleForTesting

The main time I use the @VisibleForTesting annotation is when I'm unit testing a method that includes static calls that can't be mocked or verified. A random example from the codebase is LatestLastAccessTimeMessage.process() which has a call to sendReply(dm, lastAccessed) as the last line of the

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.5.RC1

+1 Verified that performance across a variety of workloads is on par with previous releases. From: Dick Cavender Sent: Wednesday, October 20, 2021 4:32 PM To: dev@geode.apache.org Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.5.RC1 Hello Geode Dev Communit

Re: [VOTE] Apache Geode 1.14.0.RC2

+1 Validated that performance across a range of workloads is equivalent to previous releases From: nabarun nag Sent: Tuesday, August 31, 2021 5:36 PM To: dev@geode.apache.org Subject: [VOTE] Apache Geode 1.14.0.RC2 Hello Geode Dev Community, This is a release

Re: [VOTE] Apache Geode 1.13.4.RC1

+1 Confirmed that performance across a variety of workloads is on par with previous releases. From: Dick Cavender Sent: Wednesday, July 28, 2021 2:49 PM To: dev@geode.apache.org Subject: [VOTE] Apache Geode 1.13.4.RC1 Hello Geode Dev Community, This is a relea

Re: [VOTE] Apache Geode 1.12.4.RC1

+1 from me. Confirmed that performance across a wide range of workloads is on par with previous releases. From: Dick Cavender Sent: Wednesday, July 21, 2021 4:35 PM To: dev@geode.apache.org Subject: [VOTE] Apache Geode 1.12.4.RC1 Hello Geode Dev Community, This

Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

I definitely approve of this proposal. I accidentally merged (rather than squashed and merged) a PR a while back because my GitHub session had expired and refreshing the page after trying to squash and merge resulted in the default merge option being used, much to my frustration. I've yet to see

Re: [Suspected Spam] [VOTE] Apache Geode 1.13.3.RC1

+1 Performance is comparable to 1.13.2 in a suite of performance tests. From: Owen Nichols Sent: Monday, June 21, 2021 11:02 AM To: dev@geode.apache.org Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.3.RC1 Hello Geode Dev Community, I'd like to propose an e

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

I think that there should be room for developers to bypass the stress-new-test jobs requirement in cases like this, where the test that's failing is an existing flaky test and that failure is blocking other flaky tests/bugs from being fixed. Splitting the class up won't save us, because stress-n

Re: Cleaning up the codebase - use curly braces everywhere

ng through every line. I'd probably just pick a dozen random ones to check and then approve it. On Thu, May 27, 2021 at 6:36 PM Darrel Schneider wrote: > +1 thanks for working on this > ____ > From: Donal Evans > Sent: Thursday, May 27, 2021 10:22 AM

Re: Cleaning up the codebase - use curly braces everywhere

ctions is that we can provide an inspection profile that treats violations as errors. Then developers can use this profile while editing to spot violations immediately as they’re introduced. A disadvantage is that this somewhat couples Geode to a particular IDE. Dale From: Donal E

Cleaning up the codebase - use curly braces everywhere

Hi Geode dev, I've recently been looking at ways to improve code quality in small ways throughout the codebase, and as a starting point, I thought it would be good to make it so that we're consistently using curly braces for control flow statements everywhere, since this is something that's spe

Re: Reminder to use draft mode

+1 to Naba's PR flow described above. Creating PRs in draft mode is almost always the best choice, as it prevents people from being tagged to review a set of changes that may change significantly due to test failures and only requires a single click to convert to the "ready to review" state - h

Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

Congrats Kamilla! From: Mark Hanson Sent: Monday, April 19, 2021 2:37 PM To: dev@geode.apache.org Subject: Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami Congratulations Kamilla! On 4/19/21, 2:33 PM, "Sarah Abbey" wrote: Congratulations, Kamilla!!!

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

+1 Confirmed that performance in multiple scenarios is on par with the previous 1.12 release. From: Owen Nichols Sent: Wednesday, April 14, 2021 3:38 PM To: dev@geode.apache.org Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1 Hello Geode Dev Community,

Re: Deleting old references to ticket numbers and avoiding new ones

+1 In theory, every commit is now associated with a GEODE jira ticket, so leaving a comment in the code when putting in a fix saying that it's for that ticket is redundant. Good commit names and messages would provide the broader context for changes, and regular comments that don't refer to a t

Re: Precheckin job failed to fork JVM during compile

Hi Kirk, This has been happening intermittently with the latest Liberica JDK8u282 since it was released. I worked with the folks at LIberica to reproduce the issue and they have a fix which will be included in their next release, sometime in April. Donal From: K

Re: [ANNOUNCE] New Geode Committer - Matt Reddington

Congrats Matt! From: Ernie Burghardt Sent: Tuesday, March 23, 2021 10:56 AM To: dev@geode.apache.org Subject: [ANNOUNCE] New Geode Committer - Matt Reddington The Apache Geode Project Management Committee has invited Matt Reddington to join the Geode as a Commit

Re: [VOTE] Apache Geode 1.13.2.RC1

I'm okay with waiting until we know what the situation is with this register interest issue before releasing or scrapping this RC. Making a decision before we fully understand the consequences seems unwise. From: Alexander Murmann Sent: Monday, March 22, 2021 1:5

Re: Proposal: Add GEODE-8950 (performance degradation in P2pPartitionedPutLongBenchmark) to 1.14 blockers list

an be susceptible to the smallest alteration in garbage production/collection, hot methods, locks, etc. This test is a very unlikely scenario in production. I am not sure that constitutes a blocking condition but is troubling. I will give a neutral vote on making it a blocker. > On Mar 12, 2

Proposal: Add GEODE-8950 (performance degradation in P2pPartitionedPutLongBenchmark) to 1.14 blockers list

After some investigation, it appears that a degradation has been introduced that causes the P2pPartitionedPutLongBenchmark to fail at an increased rate. Efforts are underway to narrow down the cause to a single commit, but the degradation was definitely introduced in 1.14, so I believe this shou

Re: [Suspected Spam] [VOTE] Apache Geode 1.13.2.RC1

+1 Confirmed that performance across a broad range of workloads is comparable to that seen in the 1.13.1 release. From: Dick Cavender Sent: Thursday, March 11, 2021 1:34 PM To: dev@geode.apache.org Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.2.RC1 Hello

Re: Avoid PowerMockito

Turns out I should have refreshed the ticket comments before submitting my PR, because Michael Oleske beat me to it yesterday: https://github.com/apache/geode/pull/6107 Sorry for the email spam! From: Donal Evans Sent: Wednesday, March 10, 2021 11:55 AM To: dev

Re: Avoid PowerMockito

I've just submitted a PR to remove three uses of PowerMock.when that can be trivially replaced with Mockito.when: https://github.com/apache/geode/pull/6112 and updated the ticket with a comment listing the remaining classes that are using PowerMock. Only 7 files remain, so this feels like a very

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.1.RC4

+1 Verified that no regressions in performance were present compared to previous versions using some private performance tests. Everything looks good! From: Owen Nichols Sent: Sunday, February 21, 2021 12:07 PM To: dev@geode.apache.org Subject: [Suspected Spam]

Re: Proposal to add GEODE-8947 to blocker list

+1 I can confirm that the performance degradations I saw that led to me opening GEODE-8974 are no longer present with the fix that has been merged to the develop branch. Get Outlook for Android From: Owen Nichols Sent: Tuesday, February

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.1.RC3

I've run into some potential performance issues with this build in some proprietary tests, some of which are potentially quite severe. Until I've had a bit more time to investigate and determine the root causes, I don't think that this build should be released. Would it be possible to extend the

Re: [PROPOSAL] Change the default value of conserve-sockets to false

Thank you to everyone who participated in this discussion. After a quick tally of responses, it looks like there are 6 people in favour of the change happening right now and 3 who are in favour but would prefer it to wait for a major version change. While this isn't a strong consensus, I do thi

Re: [PROPOSAL] Change the default value of conserve-sockets to false

t set this property and we changed the default I believe that we would prevent the upgraded member from rejoining the cluster. Of course the user could explicitly set this property as you point out. Anthony > On Nov 20, 2020, at 8:49 AM, Donal Evans wrote: > > While I agree that

Re: [PROPOSAL] Change the default value of conserve-sockets to false

While I agree that the potential impact of having the setting changed out from a user may be high, the cost of addressing that change is very small. All users have to do is explicitly set the conserve-sockets value to true if they were previously using the default and they will be back to where

Re: [PROPOSAL] Change the default value of conserve-sockets to false

ast. I would LOVE to approve >> this change, but this would mean that users that don’t set this property >> might suddenly have this property changed. We are not sure that this would >> mean for these users. BUT >> >> That said, there have been very little (to none)

[PROPOSAL] Change the default value of conserve-sockets to false

Hi Geode dev, First, from the docs[1], a brief explanation of the purpose of the conserve-sockets property: "The conserve-sockets setting indicates whether application threads share sockets with other threads or use their own sockets for member communication. This setting has no effect on comm

[PROPOSAL] Backport GEODE-8536 and GEODE-8686 to 1.13.1

Hi Geode dev, I would like to backport the fixes for the below issues to the 1.13.1 support branch: GEODE-8536[1] is a StackOverflow that can occur when creating a Lucene IndexWriter. The fix has been on develop for several weeks now without any issues. GEODE-8686[2] is a potential Java-level d

Re: PR process and etiquette

As a (relatively) new committer, one of the more difficult aspects of the PR process is knowing who to tag as a reviewer. The last person to touch a class may not actually have the context or depth of knowledge needed for a thorough review if, say, their changes were just refactoring or code cle

Re: [PROPOSAL] backport GEODE-8651 to 1.13, 9.10, 9.9

+1 From: Anthony Baker Sent: Tuesday, October 27, 2020 2:53 PM To: dev@geode.apache.org Subject: Re: [PROPOSAL] backport GEODE-8651 to 1.13, 9.10, 9.9 +1 from me > On Oct 27, 2020, at 2:21 PM, Xiaojian Zhou wrote: > > Hi, all: > > The fix is to resolve a hang w

[PROPOSAL] Backport fix for GEODE-8620 to 1.13.1

Hi Geode dev, I would like to backport the fix for https://issues.apache.org/jira/browse/GEODE-8620 to the 1.13.1 branch. This bug causes incorrect redundancy levels to be reported for regions in which not all buckets have been created when using the Restore/StatusRedundancy features introduce

Reviews requested for LGTM alert fix PR

Hi Geode dev, As part of continued efforts to address alerts generated by LGTM analysis of the Geode codebase, I've opened a PR that addresses 108 of the "Potential input/output resource leak" alerts currently flagged: https://github.com/apache/geode/pull/5582. This encompasses most (but not al

Re: Colocated regions missing some buckets after restart

see which server is stopped first and starts him first (The issue was first reproduced on kubernetes, and that is how pods restarts servers). Also if you are not able to reproduce the issue, try to set 10 or more colocated regions. BR, Mario ____ Šalje: Donal Evans

Re: Colocated regions missing some buckets after restart

Hi Mario, I tried to reproduce the issue using the steps you describe, but I wasn't able to. After restarting the servers, all regions have the expected 113 buckets, and the server startup process is not noticeably slower. I have a few questions that might help understand why I'm unable to repr

Re: [Discussion] - ClassLoaderService RFC proposal

Sounds good to me. One question though: is it likely that the ClassLoaderService configuration will need to be persisted at all? For example, would it be reasonable to provide a user with the ability to specify a new ClassLoaderService implementation to be used upon cluster restart (via GFSH or

Re: [PROPOSAL] port GEODE-8467 to support/1.13

+1 From: Dave Barnes Sent: Tuesday, September 1, 2020 10:25 AM To: dev@geode.apache.org Subject: Re: [PROPOSAL] port GEODE-8467 to support/1.13 > Assuming that it's passed applicable testing AND GETS AT LEAST 3 VOTES, let's do it. On Tue, Sep 1, 2020 at 10:24 AM

Re: Proposal to bring GEODE-8456 (shiro upgrade) to support branches

+1 We still have outstanding release blockers for 1.13, so getting this fix in now just prevents extra work in the future without slowing us down now. From: Owen Nichols Sent: Monday, August 31, 2020 4:19 PM To: dev@geode.apache.org Subject: Proposal to bring GE

Re: [PROPOSAL] Remove "Fix Version/s" and "Sprint" from Jira "Create Issue" dialogue and include "Affects Version/s"

] Remove "Fix Version/s" and "Sprint" from Jira "Create Issue" dialogue and include "Affects Version/s" +1 --Mark On Tue, Aug 18, 2020 at 9:39 AM Raymond Ingles wrote: > +1 > > On 8/17/20, 3:04 PM, "Donal Evans" wrote: > > Lo

[PROPOSAL] Remove "Fix Version/s" and "Sprint" from Jira "Create Issue" dialogue and include "Affects Version/s"

Looking at the dialogue that opens when you attempt to create a new ticket in the GEODE Jira[1], there are two fields included that aren't really necessary and may cause confusion. The "Fix Version/s" field should presumably not be filled out until the issue has actually been fixed, rather than

Re: [Proposal] Backport GEODE-8422 to support/1.13

+1 From: Mark Hanson Sent: Wednesday, August 12, 2020 4:40 PM To: dev@geode.apache.org Subject: [Proposal] Backport GEODE-8422 to support/1.13 Hi All, We have found a case where tombstones were being cleared when the region was not initialized. This was causing

Re: [PROPOSAL] backport GEODE-8394 to support/1.13

+1 From: Anilkumar Gingade Sent: Friday, August 7, 2020 10:34 AM To: dev@geode.apache.org Subject: [PROPOSAL] backport GEODE-8394 to support/1.13 This causes a large object to be partially (corrupt data) stored in cache instead of throwing an exception.

Re: [PROPOSAL] backport GEODE-6564 to support/1.13

+1 From: Darrel Schneider Sent: Monday, August 3, 2020 4:05 PM To: dev@geode.apache.org Subject: [PROPOSAL] backport GEODE-6564 to support/1.13 GEODE-6564 is a memory leak that has impacted users so it would be good to have it in 1.13. It has a simple, low risk,

Re: Proposal to backport GEODE-8395 (gfsh help banner) to support branches

+1 Nice catch! Get Outlook for Android From: Jinmei Liao Sent: Saturday, August 1, 2020 11:09:45 PM To: dev@geode.apache.org Subject: Re: Proposal to backport GEODE-8395 (gfsh help banner) to support branches +1 On Aug 1, 2020 10:30 PM

Re: [PROPOSAL] back-port GEODE-8388 native client doc fixes to support/1.13

+1 From: Owen Nichols Sent: Friday, July 31, 2020 10:21 AM To: dev@geode.apache.org Subject: Re: [PROPOSAL] back-port GEODE-8388 native client doc fixes to support/1.13 +1 On 7/31/20, 10:20 AM, "Dave Barnes" wrote: GEODE-8388: Geode Native Client user gu

Re: [PROPOSAL] one-time cleanup of stray and obsolete tags in geode repo

I may be mistaken, but I think the develop/highwater tag was used by the geode-benchmarks project. Can we get confirmation that it's no longer in use? +1 conditional on that Get Outlook for Android From: Ju@N Sent: Thursday, July 30, 2020

Re: [PROPOSAL] port GEODE-8385 changes to support/1.13

+1 From: Bruce Schuchardt Sent: Wednesday, July 29, 2020 8:04 AM To: dev@geode.apache.org Subject: [PROPOSAL] port GEODE-8385 changes to support/1.13 This concerns a hang during recovery from disk. The problem was introduced in 1.13. https://nam04.safelinks.pr

Re: [PROPOSAL] port GEODE-8323 changes to support/1.13 branch.

+1 From: Dick Cavender Sent: Tuesday, July 28, 2020 4:53 PM To: dev@geode.apache.org Subject: RE: [PROPOSAL] port GEODE-8323 changes to support/1.13 branch. +1 -Original Message- From: Eric Shu Sent: Tuesday, July 28, 2020 4:22 PM To: dev@geode.apache.o

Re: [PROPOSAL] Postpone Geode 1.14

+1 From: Owen Nichols Sent: Tuesday, July 28, 2020 4:38 PM To: Alexander Murmann ; dev@geode.apache.org Subject: Re: [PROPOSAL] Postpone Geode 1.14 +1 --- Sent from Workspace ONE Boxer

Re: [Discuss] Cutting Geode 1.14

+1 to postponing 1.14. Given the limited resources we have in terms of people who shepherd the release process and ensure the quality of what we end up releasing, it would put an unsustainable amount of strain on those who have already been working extremely hard on getting 1.13 finished if we

Re: [Proposal] - RFC etiquette

system. I believe this approach will help with an overall better understanding of the systems behavior. —Udo On Jul 9, 2020, 1:46 PM -0700, Donal Evans , wrote: While I definitely approve of these proposals in principle (especially the "Use Cases" section, which could really help fa

Re: [Proposal] - RFC etiquette

While I definitely approve of these proposals in principle (especially the "Use Cases" section, which could really help facilitate discussions around other potential solutions/approaches to a problem), the fact that the RFC process is still entirely voluntary on the part of the contributor(s) wh

Re: [PROPOSAL] backport fix for GEODE-8020 to support/1.13

+1 From: Bruce Schuchardt Sent: Thursday, July 9, 2020 8:00 AM To: dev@geode.apache.org Subject: [PROPOSAL] backport fix for GEODE-8020 to support/1.13 There are reports that SSL performance is off on the support/1.13 branch with respect to the support/1.12 bran

Re: [PROPOSAL]: Backport GEODE-8029 to support/1.12 and support/1.13

+1 Get Outlook for Android From: Ju@N Sent: Friday, July 3, 2020 6:06:27 AM To: dev@geode.apache.org Subject: [PROPOSAL]: Backport GEODE-8029 to support/1.12 and support/1.13 Hello devs, I'd like to propose bringing GEODE-8029 [1] to the

Re: Us vs Docker vs Gradle vs JUnit

+1 for fixing the tests. It'll be a lot of work, but it'll only be a lot of work once, as opposed to taking on maintenance of our own custom Docker plugin, which will be an ongoing effort and not at all immune from getting broken again at some point in the future. ___

Re: [Proposal] Back-port doc fixes to support/1.13

+1 From: Owen Nichols Sent: Monday, June 29, 2020 10:35 AM To: dev@geode.apache.org Subject: Re: [Proposal] Back-port doc fixes to support/1.13 +1 On 6/29/20, 10:32 AM, "Jinmei Liao" wrote: +1, yay to doc changes.

Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

he merits. What level of testing has this been through? Does it touch core code? You may be able to get the votes just by demonstrating that the risk is very low. I'm a +0 for this based on the information presented so far. On 6/26/20, 11:50 AM, "Donal Evans" wrote: +1

Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

+1 Although normally features wouldn't really count as "critical fixes" that would warrant inclusion after the release branch has been cut, in this case, the internal API and gfsh commands for restore redundancy are already in the release, and it makes much more sense to include the entire feat

Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12

+1 From: Owen Nichols Sent: Friday, June 26, 2020 9:59 AM To: dev@geode.apache.org Subject: Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12 +1 On 6/26/20, 7:58 AM, "Ju@N" wrote: +1 On Fri, 26 Jun 2020 at 15:51, Bruce Schuchardt wrot

Re: [PROPOSAL] Add windows jobs to PR checks

+1 I recently ran into some Windows failures related to test ordering and Integration tests not properly cleaning up after themselves (totally unrelated to my changes) after merging a PR. If the PR checks had shown these failures, the underlying issue could have been addressed before merging my

Re: [VOTE] Backporting of GEODE-8261 to 1.13 release branch.

+1 From: Nabarun Nag Sent: Friday, June 19, 2020 12:15 PM To: dev@geode.apache.org Subject: [VOTE] Backporting of GEODE-8261 to 1.13 release branch. Hi Geode devs, Requesting vote to backport of GEODE-8261 to 1.13 Why? This commit fixes an issue with servers th

Re: Refactor to Restore Redundancy Command for 1.13?

+1 for getting the feature fully implemented in one release rather than spreading it out over 2. From: Mark Hanson Sent: Monday, June 15, 2020 1:23 PM To: dev@geode.apache.org Subject: Refactor to Restore Redundancy Command for 1.13? Hi All, So we are working o

Re: No more hardcoded region separators!

kind of LGTM or spotless rule? On 5/28/20, 12:46 PM, "Donal Evans" wrote: I'm happy to say that as of about 5 minutes ago, there are no uses of hardcoded "/" in region paths/names in the geode codebase, as all of them have been replaced by the Region.SEPARATOR

Re: No more hardcoded region separators!

s%40vmware.com%7Cff0d3580ae404c540c9a08d8032d27ad%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637262839764198680&sdata=CattsXf3p8X%2BiFalU2uu9be6nxdzLkJ4dXCfL7tE0ec%3D&reserved=0? On Thu, May 28, 2020 at 9:46 AM Donal Evans wrote: > I'm happy to say that as of about 5 min

No more hardcoded region separators!

I'm happy to say that as of about 5 minutes ago, there are no uses of hardcoded "/" in region paths/names in the geode codebase, as all of them have been replaced by the Region.SEPARATOR constant (with the exception of a few occurrences in the geode-management module, which while not having an e

Re: [PROPOSAL] Move definition of Region separator character to geode-common

PM > To: dev@geode.apache.org > Subject: Re: [PROPOSAL] Move definition of Region separator character to > geode-common > > Probably. Unfortunately we haven’t been very good and cleaning these up > and moving forward with a Java modules plan. It’s gunna bite us. &

PR to replace every use of hard-coded / character with a constant

Following on from my first pass refactor a couple of weeks ago, there is now a PR up for review which replaces every instance of a hard-coded "/" character in region names/paths (outside of xml files used by tests and the oql.g file used to parse queries) with a reference to a constant: https://git

Re: [PROPOSAL] Move definition of Region separator character to geode-common

hat is going to > be Java 9 modules safe. Two modules cannot export the same package. So if > geode-commons is going to export org.apache.geode.util I think we will have > collisions. I suggest org.apache.geode.common. > > -Jake > > > > On May 16, 2020, at 1:23 PM, Do

[PROPOSAL] Move definition of Region separator character to geode-common

I've recently been working on a little side project to replace every use of a hardcoded "/" character in region names/paths with a reference to the Region.SEPARATOR constant. I ran into some problems though, since the geode-management module needs to know about the separator character (in the Regio

Re: 1.13 potential change

I'm also bad at using my eyes, apparently. The PR was right there in the list of open ones. I don't know how I missed it. On Fri, May 15, 2020 at 4:59 PM Anthony Baker wrote: > https://github.com/apache/geode/pull/5110 > > Sorry, I’m bad at emailing today. > > On May 15

Re: 1.13 potential change

Is there a link to the PR in question? I don't see anything on GitHub. On Fri, May 15, 2020 at 4:23 PM Anthony Baker wrote: > Whoops, this got stuck on the wrong thread. Resending. > > We’re continuing to investigate some compatibility issues; there may be > further changes needed. > > > Anthon

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

Thanks for the explanation, Robert. Also, I realised I never explicitly said it in my earlier post, but this is a +1 from me On Thu, May 14, 2020 at 8:05 AM Joris Melchior wrote: > This seems like a good thing to have. > > +1 > > From: Robert Houghton > Sent: Ma

Re: [DISCUSS] enable GitHub PR blocking on API breaking changes

Given that this job takes less than 10 minutes to run, pass or fail, I don't see it adding any additional friction to the PR process in terms of having to wait for things to finish. I am curious if there are any circumstances we could envisage where skipping or bypassing this check would be warrant

Re: [PROPOSAL] Merge PR 5103 (GEODE-8083) to support/1.13

+1 Having parity between develop and support branches in terms of checks/tests seems like a sensible idea. On Tue, May 12, 2020 at 4:05 PM Owen Nichols wrote: > I see that ApiChecker PR Check < > https://concourse.apachegeode-ci.info/builds/156385> is passing for 1.13 > so it’s a +1 from me! > >

Re: [PROPOSAL] bring GEODE-8091 to support branches

+1 On Mon, May 11, 2020 at 4:11 PM Anilkumar Gingade wrote: > +1 > > On Mon, May 11, 2020 at 4:10 PM Jinmei Liao wrote: > > > https://issues.apache.org/jira/browse/GEODE-8091 > > > > We've had users that were trying to use the > > "--load-cluster-configuration-from-dir=true" when starting up a

Re: Over usage of @SuppressWarnings

> > You can disable inspection for a warning that is otherwise benign... > Is there a consensus on what constitutes a benign warning? I think the only times I use @SuppressWarnings is in parameterized tests to suppress the unused method warning for the parameters method, or for unchecked casts, as

Re: [DISCUSS] Geode Redis API Improvements

Looks good to me. Fixing broken implementation and providing reliable HA can only be a good thing. My only concern is the backwards compatibility issue, but I don't know if we make any guarantees regarding that for experimental features, so it may be a non-issue. On Thu, May 7, 2020 at 8:35 AM Ray

Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

+1 From: Dick Cavender Sent: Thursday, May 7, 2020 8:52 AM To: dev@geode.apache.org Subject: Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13 +1 On Thu, May 7, 2020 at 7:47 AM Ju@N wrote: > Hello devs, > > I'd like to propose bringing GEODE-8071 [1]

PR Review

I recently spent some of my spare time attempting some code clean-up and improved consistency as regards using Region.SEPARATOR instead of hardcoded "/" in region names/paths, and have the changes up for review here: https://github.com/apache/geode/pull/5049 It'll be a very tedious process, but if

  1   2   >