Request adding to the Geode project in JIRA

[Raymond Ingles]

While I can log in (as 'ringles') to the Geode JIRA, I don't seem to be
able to assign/be assigned JIRA tickets. Can I be added to whatever group
allows that? Thanks!

Wiki edit permissions

[Raymond Ingles]

My colleague and I are hoping to add a new RFC to the Geode wiki, but we need 
edit permissions to do it. I created an account on the wiki in the name of 
ring...@vmware.com, and Sarah did so with the 
address sabbe...@gmail.com. Who should we contact 
about getting edit permissions to add a new RFC for discussion? Thanks!

Re: Wiki edit permissions

[Raymond Ingles]

Thanks! Got the RFC up.

On Wed, Apr 29, 2020 at 5:32 PM Kirk Lund  wrote:

> You should both have permissions for creating and editing now. Thanks!
>
> On Wed, Apr 29, 2020 at 2:29 PM Kirk Lund  wrote:
>
> > Granting you permissions now... hang on a minute or two.
> >
> > On Wed, Apr 29, 2020 at 11:20 AM Raymond Ingles 
> > wrote:
> >
> >> My colleague and I are hoping to add a new RFC to the Geode wiki, but we
> >> need edit permissions to do it. I created an account on the wiki in the
> >> name of ring...@vmware.com<mailto:ring...@vmware.com>, and Sarah did so
> >> with the address sabbe...@gmail.com<mailto:sabbe...@gmail.com>. Who
> >> should we contact about getting edit permissions to add a new RFC for
> >> discussion? Thanks!
> >>
> >
>

[DISCUSS] Geode Redis API Improvements

[Raymond Ingles]

Hi all,

The current Redis API support in Geode has been marked experimental for a
couple years and has several bugs and inconsistencies compared to native
Redis. We created a RFC for updating the Geode Redis API support, to
address issues in the implementation, improve performance and add High
Availability support.

Please review and comment by 5/8/2020.

https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+API+Improvements

Thanks!

Re: [DISCUSS] Geode Redis API Improvements

[Raymond Ingles]

Just a quick nudge - we set a deadline for comments for tomorrow. Anyone
had a chance to look this over yet? Thanks!

On Thu, Apr 30, 2020 at 2:09 PM Raymond Ingles  wrote:

> Hi all,
>
> The current Redis API support in Geode has been marked experimental for a
> couple years and has several bugs and inconsistencies compared to native
> Redis. We created a RFC for updating the Geode Redis API support, to
> address issues in the implementation, improve performance and add High
> Availability support.
>
> Please review and comment by 5/8/2020.
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+API+Improvements
>
> Thanks!
>

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

[Raymond Ingles]

+1

On 7/30/20, 3:21 AM, "Owen Nichols"  wrote:

Tags in the rel/ namespace should be created by the Geode release manager 
as part of an official Geode release only, yet we seem to have some extra ones 
somehow.
Further, I don't see any value in keeping RC tags forever long after the 
release is final.

Please vote +1 in favor of trimming the current list of 110 tags down to 20 
to make it nice and easy for newcomers (as well as the rest of us) to find and 
checkout a specific version of Geode; otherwise vote -1.  If the majority vote 
is +1 at 3PM PDT Fri Aug 7, I will proceed to archive and delete the 90 
unnecessary tags as detailed below.

I propose to KEEP only the following tags, corresponding to official Geode 
releases:

rel/v1.12.0
rel/v1.11.0
rel/v1.10.0
rel/v1.9.2
rel/v1.9.1
rel/v1.9.0
rel/v1.8.0
rel/v1.7.0
rel/v1.6.0
rel/v1.5.0
rel/v1.4.0
rel/v1.3.0
rel/v1.2.1
rel/v1.2.0
rel/v1.1.1
rel/v1.1.0
rel/v1.0.0-incubating
rel/v1.0.0-incubating.M3
rel/v1.0.0-incubating.M2
rel/v1.0.0-incubating.M1

I propose a one-time cleanup to DELETE all other tags, specifically:

develop/highwater
modules-pre-merge
rel/v1.0.0-incubating.M1.RC1
rel/v1.0.0-incubating.M1.RC2
rel/v1.0.0-incubating.M2.RC1
rel/v1.0.0-incubating.M2.RC2
rel/v1.0.0-incubating.M3.RC1
rel/v1.0.0-incubating.M3.RC2
rel/v1.0.0-incubating.M3.RC3
rel/v1.0.0-incubating.M3.RC4
rel/v1.0.0-incubating.M3.RC5
rel/v1.0.0-incubating.M3.RC6
rel/v1.0.0-incubating.M3.RC7
rel/v1.0.0-incubating.RC1
rel/v1.0.0-incubating.RC2
rel/v1.1.0.RC1
rel/v1.1.0.RC2
rel/v1.1.0manualrev-2017-02-16
rel/v1.1.0manualrev-2017-10-19
rel/v1.1.1.RC1
rel/v1.1.1.RC2
rel/v1.10.0.1
rel/v1.10.0.1.RC1
rel/v1.10.0.2
rel/v1.10.0.RC1
rel/v1.10.0.RC2
rel/v1.11.0.1
rel/v1.11.0.2
rel/v1.11.0.23755
rel/v1.11.0.23755_2
rel/v1.11.0.23755_3
rel/v1.11.0.3
rel/v1.11.0.4
rel/v1.11.0.5
rel/v1.11.0.6
rel/v1.11.0.7
rel/v1.11.0.7565
rel/v1.11.0.8
rel/v1.11.0.RC1
rel/v1.11.0.RC2
rel/v1.11.0.RC3
rel/v1.11.0.RC4
rel/v1.12.0.1
rel/v1.12.0.1234
rel/v1.12.0.2
rel/v1.12.0.23755
rel/v1.12.0.3
rel/v1.12.0.4
rel/v1.12.0.5
rel/v1.12.0.6
rel/v1.12.0.RC1
rel/v1.12.0.RC2
rel/v1.12.0.RC3
rel/v1.12.0.RC4
rel/v1.14.0.23755
rel/v1.2.0.RC1
rel/v1.2.0.RC2
rel/v1.2.1.RC1
rel/v1.2.1.RC2
rel/v1.2.1.RC3
rel/v1.2.1.RC4
rel/v1.2.1manualrev-2017-10-19
rel/v1.3.0.RC1
rel/v1.3.0.RC2
rel/v1.3.0.RC3
rel/v1.3.0.RC4
rel/v1.4.0.RC1
rel/v1.4.0.RC2
rel/v1.5.0.RC1
rel/v1.5.0.RC2
rel/v1.6.0.RC1
rel/v1.7.0.RC1
rel/v1.7.0.RC2
rel/v1.8.0.RC1
rel/v1.8.0.RC2
rel/v1.9.0.1
rel/v1.9.0.1.RC1
rel/v1.9.0.2
rel/v1.9.0.RC1
rel/v1.9.0.RC2
rel/v1.9.0.RC3
rel/v1.9.0.RC4
rel/v1.9.1-nordix
rel/v1.9.1.RC1
rel/v1.9.1.RC2
rel/v1.9.1.RC3
rel/v1.9.2.RC1
sga2-core
v1.1.0manualrev-2017-10-19
v9.0.0-beta.1

Re: TimeIntegrationTest is flaky

[Raymond Ingles]

Yes, we're on it. Thanks!

On 8/12/20, 7:25 PM, "Kirk Lund"  wrote:

Since this is a new test, can we please prioritize fixing it?


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8379&data=02%7C01%7Cringles%40vmware.com%7C9c67a42631c6498cba3f08d83f16f959%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637328715199279184&sdata=B2F0qmBfVZ8Yfzo3U3J5inQW9b7eRu0EO44gSVFtKfU%3D&reserved=0

java.lang.AssertionError:
Expecting:
 <0L>
to be greater than:
 <0L>
at

org.apache.geode.redis.internal.executor.server.TimeIntegrationTest.timeCommandRespondsWIthTwoValues(TimeIntegrationTest.java:57)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at

jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at

org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at

org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at

org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at

org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at

org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at

org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at

org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at

org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at

org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at

org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at

org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at

org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at

org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at

jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at

org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at

org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at

org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at

org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at

org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at

jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at

org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at

org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at

org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
at

org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:157)
at

org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
at

org.gradle.internal.conc

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

[Raymond Ingles]

+1

On 8/17/20, 3:04 PM, "Donal Evans"  wrote:

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 at the 
time of ticket creation. The "Sprint" field seems to no longer serve any 
purpose at all that I can discern, having only been filled in 13 tickets, the 
most recent of which was created in December 2018[2]. With the expansion of the 
community contributing to the Geode project, it's important to provide a 
straightforward experience for people who are new to the project and wish to 
file tickets, so the presence of these fields may cause issues.

I propose that these two fields be removed from the "Create Issue" dialogue 
and that the "Affects Version/s" field be added, since that field is far more 
important at time of ticket creation. There are currently 3851 bug tickets in 
the Jira with no "Affects Version/s" value entered at all[3], which I suspect 
is in part due to that field not being an option in the "Create Issue" 
dialogue, meaning you have to remember to go back after creating the ticket and 
enter it. With Geode moving to a model of having support branches and patch 
releases, properly capturing the versions affected by a given issue becomes 
even more important.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.imgur.com%2FoQ8CW87.png&data=02%7C01%7Cringles%40vmware.com%7C5918d3df46ab428a9eb208d842e06aab%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637332878916804491&sdata=c6RjzAIws55sOgzk%2BGJmEGmNzAwBQYjKQrO75eQ7Jho%3D&reserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fprojects%2FGEODE%2Fissues%2FGEODE-8433%3Ffilter%3Dallissues%26orderby%3Dcf%255B12310921%255D%2BASC%252C%2Bcreated%2BDESC&data=02%7C01%7Cringles%40vmware.com%7C5918d3df46ab428a9eb208d842e06aab%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637332878916814487&sdata=ye5J7qVbdhCGlmpbgOe8D64NWkFviky%2F4e3732NzTFI%3D&reserved=0
[3] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8433%3Fjql%3Dproject%2520%253D%2520GEODE%2520AND%2520issuetype%2520%253D%2520Bug%2520AND%2520affectedVersion%2520%253D%2520EMPTY%2520ORDER%2520BY%2520created%2520DESC%252C%2520affectedVersion%2520ASC%252C%2520cf%255B12310921%255D%2520ASC&data=02%7C01%7Cringles%40vmware.com%7C5918d3df46ab428a9eb208d842e06aab%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637332878916814487&sdata=%2FX3co0tPaXWmyJdqy4B3gf3OVxUqz5udUFDOe2kXBxg%3D&reserved=0

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

[Raymond Ingles]

+1

On 8/31/20, 7:19 PM, "Owen Nichols"  wrote:

Recently shiro-1.5.3.jar is getting flagged for ‘high’ security 
vulnerability CVE-2020-13933.

Analysis shows that Geode does not use Shiro in a manner that would expose 
this vulnerability.

The risk of bringing GEODE-8456 is low (difference between Shiro 1.5.3 and 
1.6.0 is bugfix and dependency bump only).  GEODE-8456 has been on develop for 
6 days and passed all tests.

This fix is critical to avoid false positives in automated vulnerability 
scans.  It would be nice to bring to support branches before 1.13.0 is released.

Please vote “+1” to approve including this in 1.13.0.  If there are any -1 
votes, I’ll wait until after 1.13.0 is done to propose this again.

Re: [DISCUSS] One more 1.13 change

[Raymond Ingles]

+1

On 9/28/20, 3:21 PM, "Dan Smith"  wrote:

Hi,

I'd like to backport this change to support/1.13 as well

GEODE-8522: Switching exception log back to debug - 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5566&data=02%7C01%7Cringles%40vmware.com%7C7333b0ccfcef446143e308d863e3b629%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637369176949268879&sdata=yG0RpDG9d9LCdgQauByTV%2Bfh7nHBWL8rvyX6ZZRKXSE%3D&reserved=0

This cleans up some noise in our logs that customers might see.

[https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Favatars3.githubusercontent.com%2Fu%2F47359%3Fs%3D400%26v%3D4&data=02%7C01%7Cringles%40vmware.com%7C7333b0ccfcef446143e308d863e3b629%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637369176949268879&sdata=z%2Fa23PMHASn3GEALwPqI7AXr4o3om1bpz0OkRpyn3rw%3D&reserved=0]
GEODE-8522: Switching exception log back to debug (merge to 1.13) by 
upthewaterspout · Pull Request #5566 · 
apache/geode
This log message happens during the course of normal startup of multiple 
locators. We should not be logging a full stack trace during normal startup. 
(cherry picked from commit 3df057c) Thank you f...
github.com

Re: [DISCUSS] Cutting a Geode 1.14.0 release branch

[Raymond Ingles]

The Redis Compatibility effort has a few things we're hoping to backport to 
1.14. I am putting together a list of tickets now and will report them later 
today. (Many of the tickets are done, and one or two are still in flight but 
close to completion.)

On 2/26/21, 12:09 PM, "Owen Nichols"  wrote:

It's been two weeks since support/1.14 was cut, and the 1.14.0 blocker 
board[1] still lists 5 issues (1 still Unassigned).  

Given the lack of activity on GEODE-8943, GEODE-8860, and GEODE-8809, 
should we defer them to 1.14.1 if we still "aim to ship on March 12th."?

On 2/18/21, 10:00 AM, "Owen Nichols"  wrote:

It's been about a week since support/1.14 was cut, and the 1.14.0 
blocker board [1] still lists 5 issues (two of which appear to be Unassigned).  
If a fix is taking longer than expected, please consider posting a status 
update in the ticket about once a week, and ask for help on the dev list if you 
need.

On 2/12/21, 1:20 AM, "Owen Nichols"  wrote:

support/1.14 has been cut.  Any fixes on develop from today onward 
should be marked as Fixed In 1.15.0.

The 1.14.0 blocker board [1] currently lists 5 issues.  RC1 won't 
be created before this list gets to zero.  To add to the blocker board, please 
propose on the dev list.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2FDashboard.jspa%3FselectPageId%3D12336052&data=04%7C01%7Cringles%40vmware.com%7Ce6bd67eff49f4028e2f208d8da7948ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637499561734786243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2yc4nHIhtQ%2FNz0X1qEHIoDKzncwPmc2O9mDJyaz%2BOr0%3D&reserved=0

On 2/10/21, 8:49 AM, "Owen Nichols"  wrote:

Sounds good.

Once cut, only fixes from the blocker board may be brought to 
support/1.14.

After Feb 12, if you wish to add a critical issue to the 
blocker board, please propose it on the dev list.  If the community agrees it 
is critical, you may tag it as "blocks-1.14.0"

Thanks,
Owen Nichols
1.14.0 Release Manager

On 2/9/21, 11:54 AM, "Alexander Murmann"  
wrote:

Hi everyone,

We aren't seeing many issues that would prevent a 1.14.0 
release on our blocker board < 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2FDashboard.jspa%3FselectPageId%3D12336052&data=04%7C01%7Cringles%40vmware.com%7Ce6bd67eff49f4028e2f208d8da7948ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637499561734786243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2yc4nHIhtQ%2FNz0X1qEHIoDKzncwPmc2O9mDJyaz%2BOr0%3D&reserved=0>
 and all issues have an owner. No new issues seem to be coming in either. This 
seems like a good time to finally cut a 1.14 release branch and get us on track 
to ship Apache Geode 1.14.0 in early March.

I propose we cut the branch at the end of this week and aim 
to ship 4 weeks later, on March 12th.

Proposal: new Geode property CRITICAL_HEAP_PERCENTAGE

[Raymond Ingles]

The Geode Redis Compatibility code is working to emulate the Redis eviction 
policy “noevict”; when memory fills up, the server refuses new write commands 
until deletion or expiration has cleared space.

Right now, part of the implementation is calling 
InternalResourceManager.setCritialHeapPercentage() to ensure that 
LowMemoryExceptions are thrown before heap memory actually runs out. It makes 
sense to make this configurable rather than hardcoding the specific percentage, 
obviously.

Since this is a cache-wide setting (and probably useful to other components) we 
didn’t think it would necessarily be appropriate to add a redis-specific option 
(redis-critical-heap-percentage). What would the implications be to adding a 
general critical-heap-percentage parameter? Are there existing reasons that 
this hasn’t already been done? gfsh already supports these options when 
starting a member.

Does anyone have a strong preference (or aversion) to one or the other?

Re: [DISCUSS] Cutting a Geode 1.14.0 release branch

[Raymond Ingles]

We're actually hoping to get a few things into 1.14 to help make the 
compatibility with Redis to be useful:

Merged to develop:
GEODE-8933: Report max memory setting in Geode Redis statistics
GEODE-8894: Allow individual deltas to trigger bucket size recalculation
GEDOE-8865: Create additional dunit and integration tests for Redis HMGET
GEODE-8624: Improve INCRBYFLOAT accuracy for very large values

Not accepted yet:
GEODE-8864: finish implementation of Redis HSCAN Command
GEODE-8859: Redis data structures may not accurately reflect their size in 
Geode stats
GEODE-8965: Implement Redis “noevict” policy for Geode Redis

On 2/26/21, 1:46 PM, "Raymond Ingles"  wrote:

The Redis Compatibility effort has a few things we're hoping to backport to 
1.14. I am putting together a list of tickets now and will report them later 
today. (Many of the tickets are done, and one or two are still in flight but 
close to completion.)

On 2/26/21, 12:09 PM, "Owen Nichols"  wrote:

It's been two weeks since support/1.14 was cut, and the 1.14.0 blocker 
board[1] still lists 5 issues (1 still Unassigned).  

Given the lack of activity on GEODE-8943, GEODE-8860, and GEODE-8809, 
should we defer them to 1.14.1 if we still "aim to ship on March 12th."?

On 2/18/21, 10:00 AM, "Owen Nichols"  wrote:

It's been about a week since support/1.14 was cut, and the 1.14.0 
blocker board [1] still lists 5 issues (two of which appear to be Unassigned).  
If a fix is taking longer than expected, please consider posting a status 
update in the ticket about once a week, and ask for help on the dev list if you 
need.

On 2/12/21, 1:20 AM, "Owen Nichols"  wrote:

support/1.14 has been cut.  Any fixes on develop from today 
onward should be marked as Fixed In 1.15.0.

The 1.14.0 blocker board [1] currently lists 5 issues.  RC1 
won't be created before this list gets to zero.  To add to the blocker board, 
please propose on the dev list.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2FDashboard.jspa%3FselectPageId%3D12336052&data=04%7C01%7Cringles%40vmware.com%7C4bb0c63928e2424e64ce08d8da86cab3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637499619749705983%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GUnp%2BlwJx63jfJNGUqBJPoHMS70kfTiBrbRKdCUwg5Y%3D&reserved=0

On 2/10/21, 8:49 AM, "Owen Nichols"  wrote:

Sounds good.

Once cut, only fixes from the blocker board may be brought 
to support/1.14.

After Feb 12, if you wish to add a critical issue to the 
blocker board, please propose it on the dev list.  If the community agrees it 
is critical, you may tag it as "blocks-1.14.0"

Thanks,
Owen Nichols
1.14.0 Release Manager

On 2/9/21, 11:54 AM, "Alexander Murmann" 
 wrote:

Hi everyone,

We aren't seeing many issues that would prevent a 
1.14.0 release on our blocker board < 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2FDashboard.jspa%3FselectPageId%3D12336052&data=04%7C01%7Cringles%40vmware.com%7C4bb0c63928e2424e64ce08d8da86cab3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637499619749715974%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WBc%2FT8lqEvmLW0ACjYXcYBHzo0PxQrp3W%2Fzm2IeP%2B1U%3D&reserved=0>
 and all issues have an owner. No new issues seem to be coming in either. This 
seems like a good time to finally cut a 1.14 release branch and get us on track 
to ship Apache Geode 1.14.0 in early March.

I propose we cut the branch at the end of this week and 
aim to ship 4 weeks later, on March 12th.

[Proposal] Backport GEODE-9022 to Apache Geode 1.14

[Raymond Ingles]

Hello –

 Putting forward the proposal to backport GEODE-9022 (Redis INFO command 
support) to support/1.14 branch,

What does GEODE-9022 do?

  *   It adds unit/integration/dunit tests for the Redis INFO command
  *   It moves the INFO command to the ‘Supported’ category

   These changes are low-risk as they are limited entirely to the Geode’s 
Redis-compatibility subsystem and do not impact any other Geode code.

Why do we need to backport these changes?

  *   These changes will allow automated tools that monitor Redis 
health (e.g. DataDog) to also monitor the health of the Geode 
compatibility-with-Redis subsystem.
  *   If we don't backport these changes to 1.14.0 then use of Redis 
compatibility will be impaired or unacceptable for several users

Reference PR: https://github.com/apache/geode/pull/6121

Thanks,
Ray Ingles

[Proposal] Backport GEODE-9009 - Support for Redis DECRBY command

[Raymond Ingles]

Hello –

 Putting forward the proposal to backport GEODE-9009 (Redis DECRBY command 
support) to support/1.14 branch,

What does GEODE-9009 do?

  *   It adds unit/integration/dunit tests for the Redis DECRBY command
  *   It moves the DECRBY command to the ‘Supported’ category

   These changes are low-risk as they are limited entirely to the Geode’s 
Redis-compatibility subsystem and do not impact any other Geode code.

Why do we need to backport these changes?

  *   These changes will allow users of the Geode 
compatibility-with-Redis subsystem to use the DECRBY command
  *   If we don't backport these changes to 1.14.0 then the Redis 
compatibility subsystem will have an awkward gap in support, as the related 
commands (DECR, INCR, INCRBY, INCRBYFLOAT, HINCRBY, HINCRBYFLOAT) are already 
supported.

Reference PR: https://github.com/apache/geode/pull/6119

Thanks,
Ray Ingles

[Proposal] Backport GEODE-9029 - Initial support for Redis SLOWLOG command

[Raymond Ingles]

Hello –

 Putting forward the proposal to backport GEODE-9029 (Redis SLOWLOG command 
support) to support/1.14 branch,

What does GEODE-9029 do?

  *   It adds unit/integration/dunit tests for the Redis SLOWLOG command
  *   It moves the SLOWLOG command to the ‘Supported’ category

These changes are low-risk as they are limited entirely to the Geode’s 
Redis-compatibility subsystem and do not impact any other Geode code.

The version of SLOWLOG is essentially a stub, because (a) Geode does not track 
such data the way Redis does, but (b) if the command is not supported, some 
monitoring tools (like certain versions of the DataDog agent) can experience 
internal errors that prevent monitoring of other, fully-supported statistics.

Why do we need to backport these changes?

  *   These changes will allow automated tools that monitor Redis 
health (e.g. DataDog) to also monitor the health of the Geode 
compatibility-with-Redis subsystem.
  *   If we don't backport these changes to 1.14.0 then use of Redis 
compatibility will be impaired or unacceptable for several users

Reference PR: https://github.com/apache/geode/pull/6131

Thanks,
Ray Ingles

Apache ID for contributor status

[Raymond Ingles]

Apparently there was a disconnect somewhere and I’ll need to contact the chair 
of the Geode PMC to request an Apache ID to establish contributor status. I’ve 
checked and ‘ringles’ is currently unused.

How can I go about requesting the ID? I’ve already signed and sent the ICLA…

Re: Cleaning up the codebase - use curly braces everywhere

[Raymond Ingles]

+1 Sounds like a good idea. Since always using curly braces is part of the 
style guide, fixing this makes sense.

The only possible additional step for 
large-but-automatically-generated-and-specifically-targeted PRs like this is 
running the test suite with code coverage, making sure the updated code paths 
are actually exercised by the tests. I think this particular change is 
low-risk, but that might be a good check as humans aren't all that great at 
checking 3300 instances of anything. And if there *are* gaps, it'll point to 
some good tests to write.

On 5/27/21, 1:22 PM, "Donal Evans"  wrote:

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 specifically called out 
in the Geode Code Style Guide wiki page[1] as one of the "more important 
points" of our code style.

IntelliJ has a "Run inspection by name..." feature that makes it possible 
to identify all places where curly braces aren't used for control flow 
statements, (which showed over 3300 occurrences in the codebase) and also 
allows them to be automatically inserted, making the fix relatively trivial. 
Since this PR will touch 640 files, I wanted to make sure to first check that 
this is something even worth doing, and, if there's agreement that it is, to 
give reviewers context on what the changes are, the motivation for them, and 
how they were made, to help with the review process.

The draft PR I have up[2] currently has no failing tests and can be marked 
as ready to review if there aren't any objections, and once it is, I'll try to 
coordinate with codeowners to get the minimal number of approvals required for 
a merge (it looks like only 6-7 reviewers are needed, though I'm sure that 
almost every code owner will be tagged as reviewers given the number of files 
touched).

If this idea is a success, I think it would be good to have a discussion 
about other low-hanging code improvements we could make using static analysis 
(unnecessary casts, unused variables, duplicate conditions etc.), and, once a 
particular inspection has been "fixed," possibly consider adding a check for it 
as part of the PR pre-checkin to make sure it's not reintroduced. All thoughts 
and feedback are very welcome.

Donal

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FCode%2BStyle%2BGuide&data=04%7C01%7Cringles%40vmware.com%7C3391c856ca6f4715dc0308d921340687%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637577329609790016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6AYrCHhgS0jPJiCcfAZZ2pA2hmS%2B2E2heQDYlUyo0Nw%3D&reserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6523&data=04%7C01%7Cringles%40vmware.com%7C3391c856ca6f4715dc0308d921340687%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637577329609790016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AMD7tgnhnc0HSFFQCNHd2e4hpfoETrPC8sH30SOafaQ%3D&reserved=0

Proposal: Cutting 1.15 Release branch Tuesday, 25 January

[Raymond Ingles]

Hello Geode Dev Community,

We have a proposal to cut the 1.15 release branch this coming Tuesday, the 25th 
of January, 2022. At this point it seems that development is feature-complete, 
and remaining work is on processing release-blocker bugs. Cutting the branch 
will allow new work to proceed without delaying the release.

Absent significant objections, the branch will be cut at some point that day.

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

[Raymond Ingles]

BTW, just to clarify, when I officially proposed cutting the branch, I hadn't 
intended to volunteer as release manager this round. That said, it's important 
to branch at a point we're confident about.

Bisecting a 3K-file change is potentially... complicated. If there's confidence 
we can track down the issue(s) quickly, a later branch point would be nice. If 
not... probably better to branch at a "not known bad" point.



On 1/26/22, 1:03 PM, "Mark Hanson"  wrote:

First, I think I would suggest that we have someone cut a branch as 
suggested and see how long it actually takes.

Second, I would suggest we define a norm if we want to avoid this in the 
future. 

Third, I don't really like the risk of having this in, but I have only 
heard about performance changes in our performance testing. Is there a specific 
defect? I looked at the code changes (not all 3000 files but a chunk) before I 
approved them. The changes were mostly dealing with warnings like unboxing etc. 
Given that these types of changes are lower risk individually, though obviously 
of concern en masse, I would like to see a bug or something before we decide to 
increase the work load by branching before the change. I understand that we are 
nervous about creating a release, but let's get some data (bugs) to justify the 
effort.

Thanks,
Mark

On 1/26/22, 7:21 AM, "Alexander Murmann"  wrote:

Owen, I really appreciate your point about the increased cost of 
backports by the branches diverging like this. I do wonder how high the cost 
will be in practice, given that AFAIK most of these changes limit themselves to 
a single line.

From: Owen Nichols 
Sent: Tuesday, January 25, 2022 20:18
To: dev@geode.apache.org 
Subject: Re: Proposal: Cut 1.15 release branch from SHA 
8f7193c827ee3198ae374101221c02039c70a561

Even a small change can have subtle but important effects only 
discovered after a long time, so leaning on commit-size as a proxy for risk may 
only serve to create a false sense of security.

Also to consider, having a large refactor on develop but not 
support/1.15 will increase backporting pain, as many cherry-picks will have 
merge conflicts that have to be manually "un-refactored".

On 1/25/22, 5:09 PM, "Alexander Murmann"  wrote:

Hi everyone,

Last week we discussed to cut the 1.15 release branch. I would like 
to propose that we cut the branch from last week's SHA 
8f7193c827ee3198ae374101221c02039c70a561. The following commit is a very large 
refactor. Nothing obvious seems wrong with that change, but given that we 
frequently only discover very subtle, but important changes to Geode after a 
long time, I think that this would allow us to reduce some risk for 1.15 and 
its future users and give this large change some time to proof itself on the 
develop branch. I'd love to avoid that work entirely, but am concerned that we 
only might find out about problems a few weeks from now or worse, after we 
shipped.

Another option might be to branch from head and revert the change 
on the release branch. I am uncertain which approach will proof less work.