Re: [VOTE] Apache Geode 1.15.1.RC1

[Alexander Murmann]

Please ignore the above email. I wrote it a while ago, but my email client only 
decided to send it now

From: Alexander Murmann 
Date: Tuesday, October 11, 2022 at 7:29 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.15.1.RC1
⚠ External Email

The RC is ready to go and the voting deadline is almost a week in the past, but 
we aren’t hearing form Mario. It might make sense for someone else to finalize 
the release.

Any objections and/or volunteers?

From: Anthony Baker 
Date: Thursday, October 6, 2022 at 6:16 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.15.1.RC1
⚠ External Email

Mario, do you plan to close the vote soon?

Anthony


---
Sent from Workspace ONE 
Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=05%7C01%7Camurmann%40vmware.com%7Caa7983283aa547bb6f1808daab94fac4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638010953604897697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=b1HvD10qJvWxN41%2FXuxRH%2Bz9CDM4lvUZNc%2Bpn4YmUDo%3Dreserved=0>

On September 29, 2022 at 5:36:39 AM PDT, Mario Kevo  wrote:
⚠ External Email

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.15.1.RC1.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you performed.

Voting deadline:
3PM PST Tue, Oct 04 2022.

Please note that we are voting upon the source tag:
rel/v1.15.1.RC1

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.15.1data=05%7C01%7Camurmann%40vmware.com%7Caa7983283aa547bb6f1808daab94fac4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638010953604897697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=RKYbKZUflUAyks4MmqKVUu1Xd7IiUvGU06ustzxsqeo%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.15.1.RC1%2Fdata=05%7C01%7Camurmann%40vmware.com%7Caa7983283aa547bb6f1808daab94fac4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638010953604897697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=buXLiYXew79FNG3047J%2BstjBz%2FkAcaRCrpiMZTBCb9E%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1139data=05%7C01%7Camurmann%40vmware.com%7Caa7983283aa547bb6f1808daab94fac4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638010953604897697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=pM05cOrN8uANKKCeQIob2jhhmKPtK0uMGACiHoEds0A%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Camurmann%40vmware.com%7Caa7983283aa547bb6f1808daab94fac4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638010953604897697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2FAWD0BruYjrJN1tAZyH7LGAKeg253QMzTIcmwvMAc4M%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Camurmann%40vmware.com%7Caa7983283aa547bb6f1808daab94fac4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638010953604897697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=3liPBqN608Lm5KGVtTMFlAN2%2BYbyViJYaqKmCQhCnjQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Camurmann%40vmware.com%7Caa7983283aa547bb6f1808daab94fac4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638010953604897697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=g0v%2Fook8ICG%2F8FLMGSlsyd0m7OThBGullxv5qk5ImIk%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Camurmann%40vmware.com%7Caa7983283aa547bb6f1808daab94fac4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638010953604897697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mCPPHHwjhFFEMvyJEAYI7n5zALTIqMpgW2lXv%2Fo6mn4%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-15-maindata=05%7C01%7Camurmann%40vmware.com%7Caa7983283aa547bb6f1808daab94fac4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7

Re: [VOTE] Apache Geode 1.15.1.RC1

[Alexander Murmann]

The RC is ready to go and the voting deadline is almost a week in the past, but 
we aren’t hearing form Mario. It might make sense for someone else to finalize 
the release.

Any objections and/or volunteers?

From: Anthony Baker 
Date: Thursday, October 6, 2022 at 6:16 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.15.1.RC1
⚠ External Email

Mario, do you plan to close the vote soon?

Anthony


---
Sent from Workspace ONE 
Boxer

On September 29, 2022 at 5:36:39 AM PDT, Mario Kevo  wrote:
⚠ External Email

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.15.1.RC1.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you performed.

Voting deadline:
3PM PST Tue, Oct 04 2022.

Please note that we are voting upon the source tag:
rel/v1.15.1.RC1

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.15.1data=05%7C01%7Camurmann%40vmware.com%7C68dc822bc0df48eb029108daa79ceb4c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589655619295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=dcAWDOsBX%2FkYV6ig8O0Idt32UTf4PkaozV%2B4QB2IZfg%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.15.1.RC1%2Fdata=05%7C01%7Camurmann%40vmware.com%7C68dc822bc0df48eb029108daa79ceb4c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589655775534%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Vx6jYb10NBNPwP3Tt5a%2FUyyEIZep61nuWrUM5Kwwenk%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1139data=05%7C01%7Camurmann%40vmware.com%7C68dc822bc0df48eb029108daa79ceb4c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589655775534%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=uv5e8OH8gTyvl5ac5bWkAtUeCNb3BZTtIvFmI8lAZbg%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Camurmann%40vmware.com%7C68dc822bc0df48eb029108daa79ceb4c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589655775534%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=fhRsWE0qLeO3oiseK85PyU%2FxzSmyqqPrn2TBiL7xm94%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Camurmann%40vmware.com%7C68dc822bc0df48eb029108daa79ceb4c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589655775534%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=nXYrUExqKdu0yZDv9bppjZk%2FPVRxWSn%2FLVHA6FoNj6g%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Camurmann%40vmware.com%7C68dc822bc0df48eb029108daa79ceb4c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589655775534%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=1nNUozzIaAF4oYfccwvvLRCPFRiPhHxwknerCvwy%2FFM%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Camurmann%40vmware.com%7C68dc822bc0df48eb029108daa79ceb4c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589655775534%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ZGAAkCBxJEmisLQ%2B9Py3bVR9gLG%2F6hfmXKDWQCgYtIQ%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-15-maindata=05%7C01%7Camurmann%40vmware.com%7C68dc822bc0df48eb029108daa79ceb4c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589655775534%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=bOdtP5RAEdFlEoPP%2Bj%2BPJcK2XFj%2B88m0KWr%2B5pDAisc%3Dreserved=0

Re: Apache Geode 1.15.1 patch version

[Alexander Murmann]

Hi Mario and Weijie,

How are things looking with the release. It seems like 
GEODE-10415 about the CVEs 
in dependencies is still open. Do you folks have any questions or need help 
with anything related to the release or the CVEs?


From: Anthony Baker 
Date: Friday, September 9, 2022 at 11:14 AM
To: dev@geode.apache.org 
Cc: weijie.m...@est.tech 
Subject: Re: Apache Geode 1.15.1 patch version
⚠ External Email

Thanks Mario. I removed some entries from the list that didn’t seem relevant to 
a small patch release. I think previously Xu Weijie volunteered to look at 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10415data=05%7C01%7Camurmann%40vmware.com%7C3cf8274425c74029dfe908da928f23e1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637983440747038207%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=WAwGLB7Fslcl0MvCRaEPHo%2F9%2B%2Bcp1Gg08QSz8emitEs%3Dreserved=0.

Anthony


On Sep 8, 2022, at 11:20 PM, Mario Kevo 
mailto:mario.k...@est.tech>> wrote:

⚠ External Email

Hi all,

I'm going to build a new patch version of the Geode.
There is a list of tasks that are declared to be fixed in 1.15.1. As they are 
already assigned, please can the assignee provide a fix for this so we can move 
on? 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fprojects%2FGEODE%2Fversions%2F12351801data=05%7C01%7Camurmann%40vmware.com%7C3cf8274425c74029dfe908da928f23e1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637983440747038207%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=DTpRef5dV4X1wtWcrB7xWXZCJ%2FBc7rrIu8nt6Dx%2FhtM%3Dreserved=0

Also, there is one blocker that will be good to introduce to this release, if 
it is okay for all of you. 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10415data=05%7C01%7Camurmann%40vmware.com%7C3cf8274425c74029dfe908da928f23e1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637983440747038207%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=WAwGLB7Fslcl0MvCRaEPHo%2F9%2B%2Bcp1Gg08QSz8emitEs%3Dreserved=0

Please suggest if you have some more tickets that are critical and should be 
backported to this release, so we can get an opinion of the community on that 
before releasing the new version.

Thanks and BR,
Mario




⚠ External Email: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender.

Re: Release manager for 1.15.1?

[Alexander Murmann]

Hi Rupert and Anthony,

Thanks for your initiative, Rupert! It’s great to see community members step up 
like this. Unfortunately, there isn’t much you can do to help with the release 
without being a committer or ideally a PMC member, since the vast majority of 
steps require committer credentials. This means that at best you’d be able to 
learn for future releases by watching someone else do the tasks. I encourage 
you to keep contributing and seek becoming a committer or even PMC member at 
which point it’s gonna be fabulous to have you step up as a release manager.

Sorry to deliver the disappointing news. Does that make sense?

Do we have a committer, or better PMC member, who is willing to help out as 
release manager for Geode 1.15.1?



From: rup...@webstersystems.co.uk 
Date: Tuesday, September 6, 2022 at 11:53 AM
To: dev@geode.apache.org 
Cc: u...@geode.apache.org 
Subject: Release manager for 1.15.1?
⚠ External Email

Hi Anthony,



I’m interested to help out on the Geode 1.15.1 Release Manager.

I can make time later this week 



Thanks, kind regards,

Rupert



Webster Systems Ltd

Kingsdon Nursery Garden

Kingsdon, Somerton, Somerset, TA11 7LE, UK

Tel: 07740 289100

 

 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.webstersystems.co.uk%2Fdata=05%7C01%7Camurmann%40vmware.com%7C8ae65379678f400a166008da903911f4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637980872045199430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=2YDdiuwbKep36IHPSE1EQ3oILWx9V%2FV6c8CrFuV86kk%3Dreserved=0

UK Registered No: 6517977



-Original Message-

From: Anthony Baker <  bak...@vmware.com>

Sent: 02 September 2022 17:28

To:   dev@geode.apache.org

Cc:   u...@geode.apache.org

Subject: Release manager for 1.15.1?



This email has reached the company via an external source.



Please be cautious opening any attachments or links.





Hi all,



We need to ship a new Geode 1.15.1 patch to fix a few issues. Part of the Geode 
and ASF release process is identify a Release Manager to collect the changes, 
prepare a release candidate, and publish the release binaries. The good news 
is, we have a well-vetted set of scripts and instructions [1] to automate this 
and make it super easy for first timers to go through the process.



Anyone want to volunteer? We would like to start this process next week (Sept 
6).



Thanks,

Anthony



[1]  

 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FReleasing%2BApache%2BGeodedata=05%7C01%7Camurmann%40vmware.com%7C8ae65379678f400a166008da903911f4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637980872045199430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=nQqUzdIvtLG7WmziSgLq5%2FdvrB5qpR7S3mu2WdI93YI%3Dreserved=0






⚠ External Email: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender.

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

[Alexander Murmann]

+1 to removing CODEOWNERS. It was a good idea, but isn’t working well, in part 
due to the way GitHub doesn’t provide enough information to determine who is 
actually needed for review.

From: Anthony Baker 
Date: Wednesday, June 29, 2022 at 9:34 AM
To: dev@geode.apache.org 
Subject: CODEOWNERS? (was Re: Pending PR reviews)
⚠ External Email

I realize that this is a thread hijack, but hopefully a useful one. I’ve seen 
several requests for timely reviews in recent months. I think that the 
CODEOWNERS goals were important and laudable—directing review requests to those 
most suited to provide oversight—but the implementation has been problematic. 
The size, complexity, and interconnectedness of the code base meant that many 
pull requests tagged not just one expert but just about EVERY expert in the 
community. This is rather inefficient, to say the least.

I propose that we revert CODEOWNERS and return to the review-then-commit model 
requiring at least one +1 vote from a committer. I see Owen has already created 
a PR [1] for this change.

Thoughts?

Anthony

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7820data=05%7C01%7Camurmann%40vmware.com%7Cfb9fa517473e425fa37008da59ed3af8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172681263350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=uZeV4f4aM8YZ2K%2FXvz0xRyRTYXY%2B0uORRuUHE%2FGbu0g%3Dreserved=0


> On Jun 28, 2022, at 5:43 AM, Mario Ivanac  wrote:
>
> ⚠ External Email
>
> Hi,
>
> The following PRs:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7323data=05%7C01%7Camurmann%40vmware.com%7Cfb9fa517473e425fa37008da59ed3af8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172681263350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=WYcPhzswx2x1mn9XUZF0oTsFRC2vAJAqFDuyBKXBT34%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7749data=05%7C01%7Camurmann%40vmware.com%7Cfb9fa517473e425fa37008da59ed3af8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172681263350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=p0UcyQGJdeMIuKYCWYg6eKBxxkrWDR5rlI6D9pVw7rI%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7664data=05%7C01%7Camurmann%40vmware.com%7Cfb9fa517473e425fa37008da59ed3af8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172681263350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=yckAzLMFXHlrRs6sfEvCky61Lp6gW4EFWFQdMZdB9yg%3Dreserved=0
>
> are waiting for review for some time.
>
>
> Could code owners review these PRs?
>
> Thanks,
> Mario
>
> 
>
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

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

[Alexander Murmann]

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.


From: Donal Evans 
Sent: Thursday, May 26, 2022 10:09
To: dev@geode.apache.org 
Subject: [Proposal] Make "Affects Version" field mandatory for new tickets with 
"Bug" issue type in JIRA

⚠ External Email

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 ticket 
can be created without needing these details ("Affects Version" has no clear 
meaning for tickets with the "New Feature" issue type, for example).

However, in the case of tickets with the "Bug" issue type, I feel that an 
"Affects Version" should be a mandatory field, as the version affected by a bug 
is vital information when it comes to triaging and fixing bugs, and I 
frequently see tickets filed with this field not filled in. I'd like to propose 
that we change this field to be mandatory for new Bug tickets. Please let me 
know what you think about this idea, or if there are issues or complications 
that I've missed.

Donal



⚠ External Email: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender.

Re: [PROPOSAL] RFC for migrating from springfox to springdoc

[Alexander Murmann]

Thanks for your proposal, Patrick!

I wonder if this even warrants a proposal over a PR. There seems to be neither 
a downside nor a realistic alternative.

From: Patrick Johnson 
Sent: Thursday, May 5, 2022 13:39
To: dev@geode.apache.org 
Subject: [PROPOSAL] RFC for migrating from springfox to springdoc

Hello devs!

Please review this RFC: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FMigration%2Bfrom%2Bspringfox%2Bto%2Bspringdocdata=05%7C01%7Camurmann%40vmware.com%7C48ff71f755ba42678cd008da2ed75b31%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637873799735336667%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2F99oRiToyYEjPVG8Q8sga1dNwU%2FxlVtx9FxwKg7go4Y%3Dreserved=0
 on migrating from springfox to springdoc for our swagger needs and provide any 
feedback you have.

Review period until Friday, May 13th.

—Patrick Johnson

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

[Alexander Murmann]

Hi Donal,

I think Dan, Ray or Jens were going to issue a PR in the next few days that 
would remove the experimental Redis functionality. Given this is not a complex 
architectural change that might warrant deeper discussion, I would expect that 
the voting inherent to the PR would suffice. Especially, given that the 
discussion here seemed very non-controversial.

From: Donal Evans 
Sent: Wednesday, May 4, 2022 09:28
To: dev@geode.apache.org 
Subject: 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: Alexander Murmann 
Sent: Thursday, April 14, 2022 5:15 PM
To: geode 
Subject: [discuss] Future of the geode-redis module

Hi Geode community!

A while ago engineers from VMware started to improve the geode-redis module 
that has been in Geode for several years, but never had been completed. This 
involved adding more tests for existing functionality, as well as adding 
support for more commands.

VMware will not continue this investment in the geode-redis module. While the 
geode-redis module is in a much better place than two years ago there still is 
a lot of work left to make it a viable option for most of our users and the 
module is still in an experimental state.

For the community this poses the question of what we want to do with the 
existing code. This work now has been started and stopped twice. All code comes 
with a maintenance burden which adds 
up<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben.balter.com%2F2016%2F07%2F21%2Fremoving-a-feature-is-a-feature%2Fdata=05%7C01%7Camurmann%40vmware.com%7Ccc72fa6b54bf478a5ec708da2deb17de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637872784991405843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=fJjO4SpuCBeyTG1hFc%2FXR8vyBMIDbWK8p9jbtOZLnJo%3Dreserved=0>.
 Dependencies might need to be updated; flaky tests fixed and it brings 
cognitive overhead for us and our users. Unless someone else in the community 
steps up to take on the task of maintaining the geode-redis module, I propose 
to remove the code from our develop branch and give everyone more bandwidth to 
use elsewhere.

Thank you all in advance for your thoughts

[discuss] Future of the geode-redis module

[Alexander Murmann]

Hi Geode community!

A while ago engineers from VMware started to improve the geode-redis module 
that has been in Geode for several years, but never had been completed. This 
involved adding more tests for existing functionality, as well as adding 
support for more commands.

VMware will not continue this investment in the geode-redis module. While the 
geode-redis module is in a much better place than two years ago there still is 
a lot of work left to make it a viable option for most of our users and the 
module is still in an experimental state.

For the community this poses the question of what we want to do with the 
existing code. This work now has been started and stopped twice. All code comes 
with a maintenance burden which adds 
up. 
Dependencies might need to be updated; flaky tests fixed and it brings 
cognitive overhead for us and our users. Unless someone else in the community 
steps up to take on the task of maintaining the geode-redis module, I propose 
to remove the code from our develop branch and give everyone more bandwidth to 
use elsewhere.

Thank you all in advance for your thoughts

Re: [DISCUSS] Testing and voting on release candidates

[Alexander Murmann]

This is awesome! Now I am excited to try this on our next vote! 

From: Dan Smith 
Sent: Friday, February 4, 2022 10:56
To: dev@geode.apache.org 
Subject: [DISCUSS] Testing and voting on release candidates

Hi all,

I'd like to suggest something that might make voting on releases a little 
clearer and easier. I feel like we've been a bit vague about what kind of 
testing PMC members are supposed to do on a release candidate, and I see 
different folks (including myself) running different kinds of ad hoc testing.

I'd like to suggest that we should mostly focus on things that are either 
apache requirements for voting on releases or can't reasonably be testing in CI.

The apache release policy [1] says

"Before voting +1 PMC members are required to download the signed source code 
package, compile it as provided, and test the resulting executable on their own 
platform, along with also verifying that the package meets the requirements of 
the ASF policy on releases."

I checked in a script that can do the building and signature verification for 
you [2]. My hope is that we can improve this script do to all of the testing 
that we think is important to do on a developers machine before VOTING +1, and 
free up more time to look at the commits, source files etc. and thinking about 
if this is what we should be releasing.

I'm not trying to discourage any ad hoc testing someone feels like they want to 
do, but I do want to make sure that everyone is in agreement on what we should 
be doing before voting on a release and hopefully make it so that everyone 
feels comfortable voting without wondering what they are supposed to test.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23approving-a-releasedata=04%7C01%7Camurmann%40vmware.com%7Cdea600fb778049baf6ad08d9e8100fc6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637795977950286033%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=sDszGN3xR7feZE4SH3%2B4sBEA8OqV9B8PGKYxdkn5SDQ%3Dreserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Fdevelop%2Fdev-tools%2Frelease-testingdata=04%7C01%7Camurmann%40vmware.com%7Cdea600fb778049baf6ad08d9e8100fc6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637795977950286033%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=oWwALsJY8003Vh7SofZYmVrD2n0%2FcXXWxQr6gjrum7w%3Dreserved=0

Thanks,
-Dan

Re: Geode Jira Access Request

[Alexander Murmann]

What's your username, Steve?


From: Steve Sienkowski 
Sent: Monday, January 31, 2022 14:00
To: dev@geode.apache.org 
Subject: Geode Jira Access Request


Hi team,



Could someone help me get the proper access to the Geode Jira so that I may be 
assigned tickets?



Thanks!

-Steve



Steve Sienkowski
Engineer, VMware Tanzu Caching

ssienkow...@vmware.com

[VMware]

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

[Alexander Murmann]

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.

Proposal: Cut 1.15 release branch from SHA 8f7193c827ee3198ae374101221c02039c70a561

[Alexander Murmann]

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.

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

[Alexander Murmann]

+1

verified signatures
started a small cluster and ran some basic operations, as well as Pulse


--
Please provide anonymous feedback for me 
here.

From: Donal Evans 
Sent: Thursday, January 13, 2022 09:04
To: dev@geode.apache.org 
Subject: 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,

This is a release candidate for Apache Geode version 1.12.8.RC1.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you performed.

Voting deadline:
3PM PST Thu, January 13 2022.

Please note that we are voting upon the source tag:
rel/v1.12.8.RC1

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.8data=04%7C01%7Camurmann%40vmware.com%7Cf56f1c8ff93c4e89cf4d08d9d6b6d4f0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637776903016245057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=GwOI7Z12jvpUDjEmzNbT8K2Tgndsx%2FdAexUXAoRxZSU%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.8.RC1%2Fdata=04%7C01%7Camurmann%40vmware.com%7Cf56f1c8ff93c4e89cf4d08d9d6b6d4f0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637776903016245057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Kcnfyv95E%2FbNZhjc92jP21xIsbRowJgCQLEvGRSEAY0%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1124data=04%7C01%7Camurmann%40vmware.com%7Cf56f1c8ff93c4e89cf4d08d9d6b6d4f0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637776903016245057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2Be76qAAq4yzOlhERL%2FalDJTLYBFeU4S%2FIf8zsssnOmQ%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.8.RC1data=04%7C01%7Camurmann%40vmware.com%7Cf56f1c8ff93c4e89cf4d08d9d6b6d4f0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637776903016245057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=8ZiosrcBTjL5xFWk4snSfOG83qs6DueV9rKzGfq72qQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.8.RC1data=04%7C01%7Camurmann%40vmware.com%7Cf56f1c8ff93c4e89cf4d08d9d6b6d4f0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637776903016245057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=RdQQJ%2FOrMDhXuIcdJDq7kEWjTrjbQ%2BYLy8Zg%2BNz7a%2FI%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.8.RC1data=04%7C01%7Camurmann%40vmware.com%7Cf56f1c8ff93c4e89cf4d08d9d6b6d4f0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637776903016245057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=BSvuwjqYAuy56mMRN3ChjGHL68dPOQnfXhx%2FiS3KeO0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.8.RC1data=04%7C01%7Camurmann%40vmware.com%7Cf56f1c8ff93c4e89cf4d08d9d6b6d4f0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637776903016245057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2BlA9IIS%2B2IuEYPJ2i2wTFQ2VPSwdjNwh2wk2Cx7Pngw%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Camurmann%40vmware.com%7Cf56f1c8ff93c4e89cf4d08d9d6b6d4f0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637776903016245057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=rrCo2YgvkBsxHVZPxPw6sQCfdmjgRM0Ynl%2FmNFO%2BcAE%3Dreserved=0

January Community Meeting

[Alexander Murmann]

Happy new year everyone,

Our community meeting is set to be tomorrow. However, we don't have a topic. 
Unless someone proposes a topic in the next few hours, we should cancel.

Re: [DISCUSS] proposal to pare down old-version testing

[Alexander Murmann]

+1 Great compromise! Let's not forget about this whenever we change the protocol


--
Please provide anonymous feedback for me 
here.

From: Anilkumar Gingade 
Sent: Tuesday, January 4, 2022 07:09
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] proposal to pare down old-version testing

+1
Thanks for bringing this and taking care of this.

-Anil.


On 1/3/22, 10:41 AM, "Dan Smith"  wrote:

Looking at KnownVersion.java - we did make protocol changes in 1.12.1 and 
1.13.2. So, my suggestion would be to keep 1.12.0 and 1.13.1, but dop all the 
other patch versions that aren't the latest.

-Dan

From: Dan Smith 
Sent: Monday, January 3, 2022 10:37 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] proposal to pare down old-version testing

+1 - this seems reasonable to me. If we do make a protocol change in a 
patch, we could potentially keep around an older patch version just in that 
specific case, but otherwise I think this makes sense.

-Dan

From: Anthony Baker 
Sent: Thursday, December 23, 2021 8:53 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] proposal to pare down old-version testing

Interesting data point:  40% of maven central downloads last month were for 
version 1.4.0. Of course those numbers can be easily skewed by CI bots, but 
still!

@Owen, I think your suggestion nicely improves practicality while 
continuing to support strong compatibility. In many cases it’s quite a bit 
easier to upgrade the Geode server cluster compared to potentially many, many 
client applications.  Supporting older client versions gives users time to 
upgrade, quicker access to bug fixes, and helps avoids downtime.

+1

Anthony


> On Dec 22, 2021, at 7:13 PM, Owen Nichols  wrote:
>
> Since adopting our N-2 support policy, the list of released versions in 
/settings.gradle has ballooned to over 30 entries [1].
>
> CI tests use this list to confirm that we don’t break rolling upgrade 
ability or compatibility with older clients, but some of these tests don’t seem 
to scale well: PR#7203 to add the most recent 3 releases (bringing the total to 
33) is unable to pass CI after 8 tries.
>
> Possible solutions fall into two categories: keep the full list and throw 
developers and/or more hardware at the struggling tests, or concede that 
testing every version is not a scalable approach and find ways to shorten the 
list, e.g. randomly select a subset of old versions at runtime, or manually 
pare down the list.
>
> I propose to shorten the list [2] by keeping only the latest patch for 
each minor (unless the client or server protocol version has changed, so also 
keep the patch prior to 1.12.1 and prior to 1.13.2).  As long as a patch 
release doesn’t change the client or server protocol version, I see low value 
in testing upgrades from every patch version to every future version forever.  
The months between patch releases already provide plenty of upgrade coverage on 
that specific patch, then we can move on to the next…even if there could 
somehow be a corner-case where transitive property of upgradability doesn’t 
hold, most users probably take the latest-to-latest upgrade path anyway, which 
will always be tested.
>
> Let’s keep discussion open until 3PM PST Jan 5.  In case of no response, 
I will assume lazy consensus and update settings.gradle as proposed [2].
>
>
>
> [1] Current list from 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fsettings.gradle%23L72-L101data=04%7C01%7Camurmann%40vmware.com%7C579b50b0cacc49ed54df08d9cf9436a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637769057757912491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=8%2F%2BuhyHnyI0ZPbY4Y%2F0vRG6O%2Bi3wuSf3%2BeISAvg0DR8%3Dreserved=0
 :
> 1.0.0-incubating
> 1.1.0
> 1.1.1
> 1.2.0
> 1.3.0
> 1.4.0
> 1.5.0
> 1.6.0
> 1.7.0
> 1.8.0
> 1.9.0
> 1.9.1
> 1.9.2
> 1.10.0
> 1.11.0
> 1.12.0
> 1.12.1
> 1.12.2
> 1.12.3
> 1.12.4
> 1.12.5
> 1.12.6
> 1.12.7*
> 1.13.0
> 1.13.1
> 1.13.2
> 1.13.3
> 1.13.4
> 1.13.5
> 1.13.6*
> 1.14.0
> 1.14.1
> 1.14.2*
> *=released, but not yet added to settings.gradle due to PR#7203 not able 
to pass CI due to size of version list
>
> [2] Proposed shortlist:
> 1.1.1
> 1.2.0
> 1.3.0
> 1.4.0
> 1.5.0
> 1.6.0
> 1.7.0
> 1.8.0
> 1.9.2
> 1.10.0
> 1.11.0
> 1.12.0
> 1.12.7
> 1.13.1
> 1.13.6
> 1.14.2
>

Re: [DISCUSS] Adding LTGM as gating PR checks

[Alexander Murmann]

+1 to adding this. Given it has a low false-positive rate, only checks on code 
actually changed in the PR and runs quickly compared to some of our other steps 
that already happen for every PR, this seems like an easy decision.


From: Robert Houghton 
Sent: Thursday, December 16, 2021 14:20
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding LTGM as gating PR checks

Short answer would be to work with the rest of the community to get the check 
to pass, fix the LGTM configuration, something like that. Otherwise, the 
Concourse CI has the ability to set PR context messages.

-Robert

From: Owen Nichols 
Date: Thursday, December 16, 2021 at 10:40 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding LTGM as gating PR checks
Requiring LGTM looks good to me.  It does not seem to have a high rate of 
false-positives like some other linters, but if we are making it gating, what 
would the process look like to override a false-positive?

On 12/16/21, 10:37 AM, "Anthony Baker"  wrote:

Thanks Robert, I think this is important. I think this is a good first step.

In future I think we should consider adding a CI job to ensure that 
pre-existing security errors are addressed. Perhaps GitHub code scanning is 
worth investigating since they have acquired the LGTM product.

Anthony


> On Dec 16, 2021, at 10:08 AM, Robert Houghton  
wrote:
>
> We have had LGTM tests enabled on Apache Geode PRs for quite some time, 
and have done a great job of trending those warnings and errors to in the right 
direction. I would like to make the change to our GitHub to make those changes 
blocking for all new PRs, given their reliability and lack-of-flakiness.
>
> Does anyone have strong feelings against that?
>
> -Robert Houghton

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

[Alexander Murmann]

+1

verified signatures
verified passing pipeline
started a small cluster and ran some operations and Pulse



From: Owen Nichols 
Sent: Tuesday, December 14, 2021 18:19
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.6.RC1

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.13.6.RC1.
This release contains only a log4j bump to 2.16.0.

Please do a review and give your feedback, including the checks you performed.

Expedited Voting deadline:
3PM PST Wed, December 15 2021.

Please note that we are voting upon the source tag:
rel/v1.13.6.RC1

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.6data=04%7C01%7Camurmann%40vmware.com%7Cdc24ba062afc423c4b5608d9bf715ca0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315874091930%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=1NoVnE4HbgcoI8Soi11JefLMSy3tdH8Dif3utepKWBs%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.6.RC1%2Fdata=04%7C01%7Camurmann%40vmware.com%7Cdc24ba062afc423c4b5608d9bf715ca0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315874091930%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=l%2FVejDjLRQTiXsVcKfD6Xn%2BlL8KIaBSRaqs5v6xhlJE%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1121data=04%7C01%7Camurmann%40vmware.com%7Cdc24ba062afc423c4b5608d9bf715ca0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315874091930%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0YHFEKh%2FZbCE9Ss66RKaO85mkyIBMijg5q0ZZt3Niu0%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.6.RC1data=04%7C01%7Camurmann%40vmware.com%7Cdc24ba062afc423c4b5608d9bf715ca0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315874091930%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=oaDzJfdDdaHifi8%2BywvjoAIIDUnaSx%2Fccre2WYhldco%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.6.RC1data=04%7C01%7Camurmann%40vmware.com%7Cdc24ba062afc423c4b5608d9bf715ca0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315874091930%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ntyOzD3bGGaIX1cbM3AYxR9l7q7PJ6jokz9T8kyFEV0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.6.RC1data=04%7C01%7Camurmann%40vmware.com%7Cdc24ba062afc423c4b5608d9bf715ca0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315874091930%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=xmFRoQZDRmKr5A%2ByiTxXYOo9P3v1JOY9p55hVE9z8nU%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.6.RC1data=04%7C01%7Camurmann%40vmware.com%7Cdc24ba062afc423c4b5608d9bf715ca0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315874091930%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=K1sIhUfk%2Fvhf41JVgwPxW3becu2ruuTX%2BNcX2TAe1uM%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-maindata=04%7C01%7Camurmann%40vmware.com%7Cdc24ba062afc423c4b5608d9bf715ca0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315874091930%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=s4B321i51BDNiSiMrmd3tHA41r%2BNcKXUYRe2nGccIAU%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-rcdata=04%7C01%7Camurmann%40vmware.com%7Cdc24ba062afc423c4b5608d9bf715ca0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315874091930%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=niw2kg60nSbnEPBZhD02UGQfRyo%2B%2FqM5NeClpNoKSA8%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:

Re: Creating index failed

[Alexander Murmann]

Hi Mario!
I agree with you that the user wanted to index all the data in the region when 
using a partitioned region. But when the command is not successful, the cluster 
config is not updated.
After the server restart, it will not have indexes as it is not stored in the 
cluster configuration.
Interesting! If I understand you correctly, the initial request to each server 
succeeds, but later ones will fail because the index is already there. However, 
the first, successful request should also have updated the cluster config, 
right?. Am I misunderstanding something?

From: Mario Kevo 
Sent: Tuesday, December 7, 2021 06:36
To: dev@geode.apache.org 
Subject: Odg: Creating index failed

Hi Jason,

I agree with you that the user wanted to index all the data in the region when 
using a partitioned region. But when the command is not successful, the cluster 
config is not updated.
After the server restart, it will not have indexes as it is not stored in the 
cluster configuration.
So there should be some changes, as the index is created on all members but the 
command is not successful.
I'm working on a fix. As soon as possible I will create PR on the already 
mentioned ticket.

BR,
Mario

Šalje: Jason Huynh 
Poslano: 6. prosinca 2021. 18:45
Prima: dev@geode.apache.org 
Predmet: Re: Creating index failed

Hi Mario,

A lot of the indexing code pre-dates GFSH. The behavior you are seeing is when 
an index is created on a partition region.  When creating an index on a 
partition region, the idea is that the user wanted to index all the data in the 
region.  So the server will let all other servers know to create an index on 
the partition region.

This is slightly different for an index on a replicated region.  That is when 
the index can be created on a per member basis, which is what I think the 
-member flag is for.

GFSH however defaults to sending the create index message to all members for 
any index type from what I remember and from what is being described. That is 
why you’ll see the race condition with indexes created on partitioned regions 
but the end result being that the index that someone wanted to create is either 
created or already there.

-Jason

On 12/6/21, 6:37 AM, "Mario Kevo"  wrote:

Hi devs,

While doing some testing, I found the issue which is already reported 
there. 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-7875data=04%7C01%7Camurmann%40vmware.com%7C48b13b5a3485492868dd08d9b98efd67%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637744846071934875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=82bEcKRqw8yIP4MCx7hsVKgNprgdWu9Vh%2FNatImH2Vo%3Dreserved=0

If we run the create index command it will create an index locally and send 
a request to create an index on other members of that region.
The problem happened if the remote request comes before the request from 
the locator, in that case, a request from the locator failed with the following 
message: Index "index1" already exists.  Create failed due to duplicate name.

This can be reproduced by running 6 servers with DEBUG log level(due to 
this system will be slower), creating a partitioned region, and then creating 
an index.

Why does the server send remote requests to other members as they will get 
a request from the locator to create an index?
Also when running the gfsh command to create an index on one member, it 
will send create index requests to all other members. In that case, what is the 
purpose of this --member flag?

BR,
Mario

Apache Geode Community Meeting

[Alexander Murmann]

Hi everyone,

Sorry, I didn't organize the December community meeting that should have taken 
place today. Given, it's the holiday season coming up, I wonder if it makes 
sense to not bother rescheduling and instead start looking at our January 
meeting.

Does anyone have a topic they'd like to present or discuss on January 6th?

Re: @TestOnly or @VisibleForTesting

[Alexander Murmann]

Another +1 to Eric's point. What are others seeing as valid use cases for those 
annotations?

From: Patrick Johnson 
Sent: Thursday, November 4, 2021 15:55
To: dev@geode.apache.org 
Subject: Re: @TestOnly or @VisibleForTesting

I agree with Eric. Maybe rather than standardizing on one, we should stop 
adding anymore @VisibleForTesting or @TestOnly to the codebase. Possibly 
deprecate @VisibleForTesting.

> On Nov 4, 2021, at 3:30 PM, Eric Zoerner  wrote:
>
> My opinion is that @VisibleForTesting is a code smell and either indicates 
> that there is refactoring needed or there are tests that are unnecessary. If 
> there is functionality in a private method that needs to be tested 
> independently, then that code should be extracted and placed in a separate 
> class that has a wider visibility that can be tested on its own.
>
> The same could probably be said for @TestOnly unless there are actually 
> static analysis tools that need it for some reason.
>
> From: Kirk Lund 
> Date: Thursday, November 4, 2021 at 15:13
> To: dev@geode.apache.org 
> Subject: Re: @TestOnly or @VisibleForTesting
> As everyone thinks about how we want to use these annotations, please keep
> this in mind that both *@VisibleForTesting* and *@TestOnly* can be used on
> Types (Class/Interface/Enum), Constructors, Methods and Fields. (not just
> Methods)
>
> On Thu, Nov 4, 2021 at 3:09 PM Kirk Lund  wrote:
>
>> Hey all,
>>
>> We're introducing a mess to the codebase. It's a small problem, but
>> several small problems become a big problem and one of my missions is to
>> clean up and improve the codebase.
>>
>> I recently started seeing lots of pull requests with usage of @TestOnly.
>> Sometimes it's used instead of @VisibleForTesting, while sometimes I see
>> both annotations added to the same method.
>>
>> Before we start using @TestOnly, I think we need some guidelines for when
>> to use @TestOnly versus @VisibleForTesting. Or if we're going to replace
>> @VisibleForTesting with @TestOnly, then we either need a PR for the
>> replacement or, at a minimum, deprecation annotation and javadocs added to
>> VisibleForTesting.java.
>>
>> The annotations appear similar but the javadocs describe slightly
>> different meanings for them...
>>
>> *@VisibleForTesting* was created in Geode several years ago to mean that
>> the method is either only for testing or the visibility of it was widened
>> (example: a private method might be widened to be package-private,
>> protected or public). The method might be used by product code, but it also
>> has widened scope specifically to allow tests to call it. The javadocs say:
>>
>> "Annotates a program element that exists, or is more widely visible than
>> otherwise necessary, only for use in test code.
>>
>> Introduced while mobbing with Michael Feathers. Name and javadoc borrowed
>> from Guava and AssertJ (both are Apache License 2.0)."
>>
>> *@TestOnly* started appearing when we added org.jetbrains.annotations
>> dependency earlier this year. It seems to indicate a method that is ONLY
>> used for tests (never called by product). The javadocs say:
>>
>> "A member or type annotated with TestOnly claims that it should be used
>> from testing code only.
>>
>> Apart from documentation purposes this annotation is intended to be used
>> by static analysis tools to validate against element contract violations.
>>
>> This annotation means that the annotated element exposes internal data and
>> breaks encapsulation of the containing class; the annotation won't prevent
>> its use from production code, developers even won't see warnings if their
>> IDE doesn't support the annotation. It's better to provide proper API which
>> can be used in production as well as in tests."
>>
>> So... when do we use one over the other? I don't think both annotations
>> should be on the same method. Also, some sort of guidelines are needed if
>> we're going to start using @TestOnly.
>>

Re: November Community Meeting

[Alexander Murmann]

Big thank you to Evaristo for presenting on query resource management today! It 
was very intersting to learn about the problems you and your team had run into 
around query resource consumption, how you worked around them and how we might 
improve that area of Apache Geode further in the future.

I highly recommend for everyone who missed the meeting to watch the recording. 
It's linked on our 
wiki<https://cwiki.apache.org/confluence/display/GEODE/Apache+Geode+Community+Meeting+Notes>
 or you can find it directly on our Geode YouTube 
channel<https://www.youtube.com/playlist?list=PLIpLPje0EtLim5GB8s-qdwmmrhu4eOlh0>.

Also thank you to everyone who joined and maybe even took part in the 
discussion!

We are still looking for a topic for our next meeting which should be on 
December 2nd. If you have something to present or discuss, don't be shy to 
bring the topic.
____
From: Alexander Murmann 
Sent: Thursday, October 28, 2021 08:01
To: geode 
Subject: November Community Meeting

Hi everyone,

A week from now on Thursday November 4th at  15:00 UTC/8:00 Pacific  is our 
next Geode Community Meeting.

Currently the agenda is a talk on Query Resource Management.

Please find all details on the corresponging wiki 
page<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FApache%2BGeode%2BCommunity%2BMeeting%2BNotesdata=04%7C01%7Camurmann%40vmware.com%7Ca45e14be0b0844dfe57308d99a23d3fa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637710300944230944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kPlaZru7rhdEdfejX7z3KUpR6I0bNhqbvnOxto73mKM%3Dreserved=0>


Looking forward to see you all there!

November Community Meeting

[Alexander Murmann]

Hi everyone,

A week from now on Thursday November 4th at  15:00 UTC/8:00 Pacific  is our 
next Geode Community Meeting.

Currently the agenda is a talk on Query Resource Management.

Please find all details on the corresponging wiki 
page


Looking forward to see you all there!

Re: Apache Geode Community Meeting 10/7/2021

[Alexander Murmann]

Hi Jake,

Sorry to hear about your family emergency. It's probably too short notice to 
prepare another topic and to allow everyone interested to get ready for 
discussion as well.

Pushing back to next Thursday, October 14th is probably our best bet.

All the best to you and your family!

From: Jacob Barrett 
Sent: Wednesday, October 6, 2021 13:55
To: dev@geode.apache.org 
Subject: Apache Geode Community Meeting 10/7/2021

Devs,

Sorry for the late notice but due to a family emergency I need to skip 
presenting the pitch for modularizing our feature work at the meeting tomorrow. 
It looks like I am the only item on the agenda then perhaps we should postpone 
this meeting until next week.

-Jake

Re: October Community Meeting

[Alexander Murmann]

Both are such great topics! I think either of them will easily fill up the hour.

Is it OK to keep the query topic for November? We could always set up a 
separate call for anyone who is interested.


--
Please provide anonymous feedback for me 
here<https://forms.gle/kpUiaty3jt8X9y4H9>.

From: Alberto Gomez 
Sent: Friday, October 1, 2021 00:09
To: dev@geode.apache.org ; u...@geode.apache.org 

Subject: Re: October Community Meeting

Hi,

We would like to touch on the topic Anthony mentioned. We could present the 
problem and the different approaches we have explored so far and then continue 
with the discussion started in the RFC.

It could be on next week's meeting or in a later meeting.

Alberto

From: Anthony Baker 
Sent: Wednesday, September 29, 2021 11:39 PM
To: dev@geode.apache.org 
Cc: u...@geode.apache.org 
Subject: Re: October Community Meeting

Looking forward to it!  There has been some good discussion on query resource 
management [1] as well, perhaps we can pick up that topic another time if there 
sufficient interest.

Anthony

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FThrottling%2Bof%2BOQL%2Bqueries%3FfocusedCommentId%3D18874%23comment-18874data=04%7C01%7Camurmann%40vmware.com%7C706f093fac6d4ede240c08d984aa6407%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637686689623689574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FKToH0m75SbWG%2BWHFVXPEknTMBGuO%2BT7jISatzhBgjQ%3Dreserved=0


On Sep 29, 2021, at 9:09 AM, Alexander Murmann 
mailto:amurm...@vmware.com>> wrote:

Hi everyone!

Next Thursday October 6th is our next Community Meeting. Jacob Barrett has 
started some discussions on the mailing list about modularization. This is a 
great topic for our upcoming meeting. Jake won't be able to join till one hour 
after our regular time. I hope everyone is fine if we have the October meeting 
an hour later at 9:00 Pacific (16:00 UTC).

Find the meeting 
details<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FApache%2BGeode%2BCommunity%2BMeeting%2BNotesdata=04%7C01%7Camurmann%40vmware.com%7C706f093fac6d4ede240c08d984aa6407%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637686689623689574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0181kjGbTrcu7m4E86RVKdcM%2F8oO%2F0K4MErHrUxj8qk%3Dreserved=0>
 on the wiki.

Looking forward to seeing you all next week!

Re: October Community Meeting

[Alexander Murmann]

Sorry, this is of course Thursday, October 7th.

From: Alexander Murmann 
Sent: Wednesday, September 29, 2021 09:09
To: geode 
Subject: October Community Meeting

Hi everyone!

Next Thursday October 6th is our next Community Meeting. Jacob Barrett has 
started some discussions on the mailing list about modularization. This is a 
great topic for our upcoming meeting. Jake won't be able to join till one hour 
after our regular time. I hope everyone is fine if we have the October meeting 
an hour later at 9:00 Pacific (16:00 UTC).

Find the meeting 
details<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FApache%2BGeode%2BCommunity%2BMeeting%2BNotesdata=04%7C01%7Camurmann%40vmware.com%7Cbdb410b049174b8bcc1d08d9836396ea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637685286049639630%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0WP6JnRrgCC3tdsGgnOJG%2FlHBrfsFLzNq9JTni%2F%2FjiI%3Dreserved=0>
 on the wiki.

Looking forward to seeing you all next week!

October Community Meeting

[Alexander Murmann]

Hi everyone!

Next Thursday October 6th is our next Community Meeting. Jacob Barrett has 
started some discussions on the mailing list about modularization. This is a 
great topic for our upcoming meeting. Jake won't be able to join till one hour 
after our regular time. I hope everyone is fine if we have the October meeting 
an hour later at 9:00 Pacific (16:00 UTC).

Find the meeting 
details
 on the wiki.

Looking forward to seeing you all next week!

Re: August Community Meeting

[Alexander Murmann]

Hi again everyone,

As of right now I am not seeing any proposed topics in our community meeting 
wiki page. So it doesn't makes sense to meet tomorrow.

The good news is that I believe that Patrick Johnson will be able to speak at 
our next meeting on Thursday, September 9th about some work on ClassLoader 
isolation that he and Udo Kohlmeyer have been doing.

Sorry for the short notice!


--
Please provide anonymous feedback for me 
here<https://forms.gle/kpUiaty3jt8X9y4H9>.

From: Alexander Murmann 
Sent: Tuesday, August 3, 2021 10:06
To: geode 
Subject: Re: August Community Meeting

Hi everyone,

I updated the 
wiki<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fx%2FupaNCgdata=04%7C01%7Camurmann%40vmware.com%7C3ac7471b6cbe43d9193708d956a11a66%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637636072204111362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ewZR2CM8%2BHzKmdxv%2FR3dOSLq4ybcZmyGequ%2BdEToUKQ%3Dreserved=0>
 to reflect that the next community meeting now is Thursday August 12th and 
that the default day is now Thursday as well.

We still don't have any topics to discuss or planned presentations. Please 
update the wiki if you have something you'd like to discuss.

See you all next week!
____
From: Alexander Murmann 
Sent: Thursday, July 29, 2021 11:00
To: geode 
Subject: August Community Meeting

Hi Geode community,

Next week's August 4th is the first Wednesday in August. Usually that would be 
the day that we have our community meeting. Many of our community members work 
on Apache Geode as part of their work at VMware. The majority of those folks 
will be unavailable next week.

Does it work for everyone if we push back a week?
I also wonder if anyone would be opposed to moving the meeting from Wednesdays 
to Thursdays.

So if everyone is fine with the proposals above, our next meeting would be on 
Thursday, August 12th.

Please let me know if this will work!

Re: August Community Meeting

[Alexander Murmann]

Hi everyone,

I updated the wiki<https://cwiki.apache.org/confluence/x/upaNCg> to reflect 
that the next community meeting now is Thursday August 12th and that the 
default day is now Thursday as well.

We still don't have any topics to discuss or planned presentations. Please 
update the wiki if you have something you'd like to discuss.

See you all next week!

From: Alexander Murmann 
Sent: Thursday, July 29, 2021 11:00
To: geode 
Subject: August Community Meeting

Hi Geode community,

Next week's August 4th is the first Wednesday in August. Usually that would be 
the day that we have our community meeting. Many of our community members work 
on Apache Geode as part of their work at VMware. The majority of those folks 
will be unavailable next week.

Does it work for everyone if we push back a week?
I also wonder if anyone would be opposed to moving the meeting from Wednesdays 
to Thursdays.

So if everyone is fine with the proposals above, our next meeting would be on 
Thursday, August 12th.

Please let me know if this will work!

August Community Meeting

[Alexander Murmann]

Hi Geode community,

Next week's August 4th is the first Wednesday in August. Usually that would be 
the day that we have our community meeting. Many of our community members work 
on Apache Geode as part of their work at VMware. The majority of those folks 
will be unavailable next week.

Does it work for everyone if we push back a week?
I also wonder if anyone would be opposed to moving the meeting from Wednesdays 
to Thursdays.

So if everyone is fine with the proposals above, our next meeting would be on 
Thursday, August 12th.

Please let me know if this will work!

Re: July Community Meeting

[Alexander Murmann]

We still have not topics for tomorrow. Let's skip this month.

See you all in August!

From: Alexander Murmann 
Sent: Friday, July 2, 2021 16:02
To: geode 
Subject: July Community Meeting

Hi, my favorite caching community!

Just a reminder that next Wednesday, July 7th is our next community meeting.

So far, we have no proposed 
topics<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FApache%2BGeode%2BCommunity%2BMeeting%2BNotesdata=04%7C01%7Camurmann%40vmware.com%7C4c5de42ab5334ab8902308d93dad71fb%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637608637423735802%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=cFsI%2FShDTr9FHJWrzOglos%2BjBLx5K4ICR90t%2FDlq%2B5Q%3Dreserved=0>.

Please try to add your topics ahead of time. I suggest that we skip the month 
if we have no proposed topics 12 hours before the meeting (3:00 UTC July 7th).

Hoping to see you all at the meeting!

July Community Meeting

[Alexander Murmann]

Hi, my favorite caching community!

Just a reminder that next Wednesday, July 7th is our next community meeting.

So far, we have no proposed 
topics.

Please try to add your topics ahead of time. I suggest that we skip the month 
if we have no proposed topics 12 hours before the meeting (3:00 UTC July 7th).

Hoping to see you all at the meeting!

Re: June Community Meeting

[Alexander Murmann]

Hi everyone!

The wiki 
page<https://cwiki.apache.org/confluence/display/GEODE/Apache+Geode+Community+Meeting+Notes>
 now is updated with a very short summary of our meeting today and a link to 
the recording.

Thanks to everyone who attended and especially Petar Tomic for presenting!

From: Alberto Gomez 
Sent: Monday, May 31, 2021 07:07
To: dev@geode.apache.org 
Subject: Re: June Community Meeting

Hi all,

Just a short note to inform you that we have added some more information in the 
Wiki page about the topic we plan to present in the meeting:


  *   Title: "Servers waiting indefinitely for a reply"
  *   Summary: If a packet is lost between servers, multiple threads get stuck 
and servers wait indefinitely for a reply, without any retry mechanism or 
timeout.
  *   Context: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dlist%253Aorg.apache.geode.dev%2Border%253Adate-backward%23query%3Alist%253Aorg.apache.geode.dev%2520order%253Adate-backward%2Bpage%3A1%2Bmid%3Al6uw5vs62vmtcxo4%2Bstate%3Aresultsdata=04%7C01%7Camurmann%40vmware.com%7C31ebe9b9535c4ae0317008d9243d7bb7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637580668760838009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=apgD8MLWngDBxbId0%2FkK9yPijaj%2BamjCc%2BdclLA58DM%3Dreserved=0

Best regards,

Alberto
____
From: Alexander Murmann 
Sent: Wednesday, May 26, 2021 11:55 PM
To: geode 
Subject: June Community Meeting

Hi everyone,

Next Wednesday, June 2nd, it's time for our next Geode Community Meeting.

So far, our only agenda item is "geode retry/acknowledge improvement" presented 
by contributors from the team at Ericsson.

If you have anything you'd like to present or discuss, please add it to our 
agenda on the project 
Confluence<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FApache%2BGeode%2BCommunity%2BMeeting%2BNotesdata=04%7C01%7Camurmann%40vmware.com%7C31ebe9b9535c4ae0317008d9243d7bb7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637580668760838009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6rWsNzgKu2gDm6gMas07q%2BpgL8EPVJiow1J132tODgU%3Dreserved=0>.
 The same page also contains information on how to join.


Looking forward to seeing you all there!

Re: [Discuss] New feature work approval state in Geode project?

[Alexander Murmann]

I've also seen this on other projects where sometimes an issue gets substantial 
support, but ultimately gets rejected because it doesn't match the project's 
direction. Making this clear before work happens makes sense to me in general. 
However, I wonder if the additional process in our case is more expensive than 
the problem we are solving. How often does it happen on Geode that we reject a 
smaller effort, that wouldn't warrant a RFC, after the work has been done?

From: Bill Burcham 
Sent: Friday, May 28, 2021 10:48
To: dev@geode.apache.org 
Subject: Re: [Discuss] New feature work approval state in Geode project?

We have an RFC process "to get to consensus faster and ultimately get to
execution faster". But I think in general folks tend to only do an RFC for
a "big" change. Bug tickets, and particularly feature tickets are left as a
gray area.

A google search for "most successful open source project" lists Apache
Cassandra at the top. When a bug is submitted to the Cassandra Jira it
starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to the
OPEN state which is described as:

| "the issue is open and ready for the assignee to start work on it."

I think introducing a starting state like TRIAGE NEEDED in the Geode Jira
system, and instituting a (gating) triage process would be a good way to
keep the Geode architecture cohesive and also to maximize the impact of our
contributor's efforts.

Perhaps that triage process would be run by code owners in the area(s)
affected by the ticket (bug or feature).

-Bill

On Fri, May 28, 2021 at 10:36 AM Mark Hanson  wrote:

> Hi All,
>
> There has been some discussion about adding a new state of approved to
> Geode Jira for features or something like it, to help prevent work being
> done that doesn’t make it into the project. What to people think?
>
> Thanks,
> Mark
>

June Community Meeting

[Alexander Murmann]

Hi everyone,

Next Wednesday, June 2nd, it's time for our next Geode Community Meeting.

So far, our only agenda item is "geode retry/acknowledge improvement" presented 
by contributors from the team at Ericsson.

If you have anything you'd like to present or discuss, please add it to our 
agenda on the project 
Confluence.
 The same page also contains information on how to join.


Looking forward to seeing you all there!

Re: Today's Community Meeting

[Alexander Murmann]

Sorry, our next meeting won't be April 2nd, but June 2nd. Apparently, I've lost 
all sense of time during the pandemic.

From: Alexander Murmann
Sent: Wednesday, May 5, 2021 09:39
To: geode 
Subject: Today's Community Meeting

Hi everyone!

It was great to see so many folks attend our first community meeting today and 
contribute to the discussion. An especially big thank you goes to Alberto Gomez 
for presenting his 
RFC<https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN>!

Recording and short notes can be found on the Community Meeting Confluence 
page<https://cwiki.apache.org/confluence/display/GEODE/Apache+Geode+Community+Meeting+Notes>.

Our next meeting will be on Wednesday, April 2nd. I'd love to give someone else 
the opportunity to host the next session. Please raise your virtual hand if you 
are interested!


Please also respond to this email thread with any thoughts on how the next 
session could be even better.

Thanks!

Today's Community Meeting

[Alexander Murmann]

Hi everyone!

It was great to see so many folks attend our first community meeting today and 
contribute to the discussion. An especially big thank you goes to Alberto Gomez 
for presenting his 
RFC!

Recording and short notes can be found on the Community Meeting Confluence 
page.

Our next meeting will be on Wednesday, April 2nd. I'd love to give someone else 
the opportunity to host the next session. Please raise your virtual hand if you 
are interested!


Please also respond to this email thread with any thoughts on how the next 
session could be even better.

Thanks!

Re: [DISCUSS] Monthly, synchronous community meetings

[Alexander Murmann]

Hi everyone!

Just a quick reminder that we have our first Apache Community Meeting a week 
from tomorrow, Wednesday May 5th. Please find all details in our 
wiki<https://cwiki.apache.org/confluence/display/GEODE/Apache+Geode+Community+Meeting+Notes>.

As of right now, we don't have any topics on the agenda. Please feel free to 
add anything you'd like to discuss or share with others in the community. 
Hearing other's ideas on your RFCs, questions or concerns about our process, 
short show & tells are all examples of topics to consider. We are doing this 
for the first time and will have to figure out what topics work well for this 
format, and which don't. The best way to do that is to just try and learn 
together in public.

Looking forward to seeing you all!
____
From: Alexander Murmann 
Sent: Monday, April 19, 2021 11:58
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Monthly, synchronous community meetings

Since there are only voices in support of this, I propose that we hold our 
meeting on the first Wednesday of the month. This means our first meeting will 
be May 5th.

I set up a doc for meeting notes, agenda and logistics in our wiki: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fx%2FupaNCgdata=04%7C01%7Camurmann%40vmware.com%7C35343cb3fbb64ae17b1f08d903651a18%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544555045344877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=bbH6oANj3MVIXsmujpW1LZHIWCU%2Fi2YqnxUMgn1sdss%3Dreserved=0

I believe that everyone in the community should be able to use MS Teams. I set 
up a VMware sponsored MS Teams event for this. Always happy to iterate, if 
there are ideas for a different platform that feels more aligned with OSS and 
Apache.

I suggest everyone adds their topics as early as possible, to make sure folks 
can decide if they are going to make to make sure to attend if one of the 
topics seems very relevant to them

See you all on May 5th at 3pm/15:00 UTC (11amEDT/8amPST/17:00 CEST)



From: Dan Smith 
Sent: Monday, April 12, 2021 09:39
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Monthly, synchronous community meetings

Seems like a good idea. I have no preference on video conference platform.

-Dan

From: Alberto Gomez 
Sent: Friday, April 9, 2021 1:25 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Monthly, synchronous community meetings

Hi,

This idea sounds great to me.

Have you thought about the videoconference platform to host these meetings?

Best regards,

Alberto
____
From: Alexander Murmann 
Sent: Friday, April 9, 2021 2:46 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Monthly, synchronous community meetings

Hi everyone,

On occasion we see discussions on PRs, here on the mailing list that might be 
move much quicker if we chatted synchronously about some of these topics and 
then shared the meetings notes back to the mailing list. Of course, our usual 
processes for voting and additional discussions would still need to be just as 
accessible as they are right now on the mailing list to anyone who cannot 
attend a meeting. However, it might allow us to move these discussions along 
faster and also create a stronger sense of community.

I've seen similar things done in Kubernetes Special Interest Groups 
(example<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fcommunity%2Fblob%2Fmaster%2Fsig-node%2FREADME.mddata=04%7C01%7Camurmann%40vmware.com%7C35343cb3fbb64ae17b1f08d903651a18%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544555045344877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=29Jg1Q8IjRQar%2B3O6H3wDWYtMo2c1wb0mWc85UgWANs%3Dreserved=0>)

Meeting Specifics
Frequency: monthly
Time: It seems like most of our community is distributed between Europe and the 
US. 3pm/15:00 UTC (11amEDT/8amPST/17:00 CEST) seems like a good compromise.
How: We'd have a Confluence page to gather topics ahead of time. Topics should 
be added with as much lead time as possible, to allow interested community 
members to plan attendance. We'd use the same page to take meeting notes.
Topic examples: RFC discussions, process proposals (like the recent codeowner 
introduction), show & tells of recent changes, controversial PRs, the sky is 
the limit till we find certain topics are better in a dedicated meeting.

As with everything, I'd expect us to iterate and evolve this

Does this sound valuable to everyone? How could this be better?

Re: [DISCUSS] Monthly, synchronous community meetings

[Alexander Murmann]

Since there are only voices in support of this, I propose that we hold our 
meeting on the first Wednesday of the month. This means our first meeting will 
be May 5th.

I set up a doc for meeting notes, agenda and logistics in our wiki: 
https://cwiki.apache.org/confluence/x/upaNCg

I believe that everyone in the community should be able to use MS Teams. I set 
up a VMware sponsored MS Teams event for this. Always happy to iterate, if 
there are ideas for a different platform that feels more aligned with OSS and 
Apache.

I suggest everyone adds their topics as early as possible, to make sure folks 
can decide if they are going to make to make sure to attend if one of the 
topics seems very relevant to them

See you all on May 5th at 3pm/15:00 UTC (11amEDT/8amPST/17:00 CEST)



From: Dan Smith 
Sent: Monday, April 12, 2021 09:39
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Monthly, synchronous community meetings

Seems like a good idea. I have no preference on video conference platform.

-Dan

From: Alberto Gomez 
Sent: Friday, April 9, 2021 1:25 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Monthly, synchronous community meetings

Hi,

This idea sounds great to me.

Have you thought about the videoconference platform to host these meetings?

Best regards,

Alberto

From: Alexander Murmann 
Sent: Friday, April 9, 2021 2:46 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Monthly, synchronous community meetings

Hi everyone,

On occasion we see discussions on PRs, here on the mailing list that might be 
move much quicker if we chatted synchronously about some of these topics and 
then shared the meetings notes back to the mailing list. Of course, our usual 
processes for voting and additional discussions would still need to be just as 
accessible as they are right now on the mailing list to anyone who cannot 
attend a meeting. However, it might allow us to move these discussions along 
faster and also create a stronger sense of community.

I've seen similar things done in Kubernetes Special Interest Groups 
(example<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fcommunity%2Fblob%2Fmaster%2Fsig-node%2FREADME.mddata=04%7C01%7Camurmann%40vmware.com%7C736cbf2a3fdc4a442e6308d8fdd1a0ee%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637538424080252391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=chFVe13gJds6yuvMnaC9shfz49eh9NPrG2kYD3WRJ20%3Dreserved=0>)

Meeting Specifics
Frequency: monthly
Time: It seems like most of our community is distributed between Europe and the 
US. 3pm/15:00 UTC (11amEDT/8amPST/17:00 CEST) seems like a good compromise.
How: We'd have a Confluence page to gather topics ahead of time. Topics should 
be added with as much lead time as possible, to allow interested community 
members to plan attendance. We'd use the same page to take meeting notes.
Topic examples: RFC discussions, process proposals (like the recent codeowner 
introduction), show & tells of recent changes, controversial PRs, the sky is 
the limit till we find certain topics are better in a dedicated meeting.

As with everything, I'd expect us to iterate and evolve this

Does this sound valuable to everyone? How could this be better?

[DISCUSS] Monthly, synchronous community meetings

[Alexander Murmann]

Hi everyone,

On occasion we see discussions on PRs, here on the mailing list that might be 
move much quicker if we chatted synchronously about some of these topics and 
then shared the meetings notes back to the mailing list. Of course, our usual 
processes for voting and additional discussions would still need to be just as 
accessible as they are right now on the mailing list to anyone who cannot 
attend a meeting. However, it might allow us to move these discussions along 
faster and also create a stronger sense of community.

I've seen similar things done in Kubernetes Special Interest Groups 
(example)

Meeting Specifics
Frequency: monthly
Time: It seems like most of our community is distributed between Europe and the 
US. 3pm/15:00 UTC (11amEDT/8amPST/17:00 CEST) seems like a good compromise.
How: We'd have a Confluence page to gather topics ahead of time. Topics should 
be added with as much lead time as possible, to allow interested community 
members to plan attendance. We'd use the same page to take meeting notes.
Topic examples: RFC discussions, process proposals (like the recent codeowner 
introduction), show & tells of recent changes, controversial PRs, the sky is 
the limit till we find certain topics are better in a dedicated meeting.

As with everything, I'd expect us to iterate and evolve this

Does this sound valuable to everyone? How could this be better?

Re: request for people putting up pull requests

[Alexander Murmann]

Thanks for calling this out, Bruce!

Even ignoring the curtesy to reviewers, it's hugely beneficial to have at least 
descriptive commit messages, that describe the intent behind the change and 
maybe even give a little bit of insight into the design decision. JIRA is 
great, but all our IDEs and CLI tools integrate with git and it's a huge 
productivity boost to be able to see why a code change was made years from now, 
right from within the tool you are already using. In fact, this convenience can 
help prevent potential bugs, since we are more likely to see the reasoning if 
it's easier to get to.

From: Bruce Schuchardt 
Sent: Tuesday, March 30, 2021 08:07
To: dev@geode.apache.org 
Subject: request for people putting up pull requests

If you want people to review your PR it would be kind of you to put in a 
description of its purpose.  If you just reference a JIRA ticket we have to do 
the extra work of pulling up the ticket to see what it’s about.  I’m seeing 
this more and more lately.

Re: [VOTE] Apache Geode 1.13.2.RC1

[Alexander Murmann]

Hi Dick,

Thanks for holding the release!

The investigation did in fact find the root cause of the delayed 
registerInterest. Darrel created 
GEODE-9067<https://issues.apache.org/jira/browse/GEODE-9067> that describes the 
issue and he already and has a fix for it ?. While this issue should be 
addressed, it has been in Geode since day 1 and it's not worthwhile to restart 
the release for it and redo all work. We have great fixes coming in this 
release that should go to our users quickly. We should however address 
GEODE-9067 it in all future releases (including 1.13.3).

From: Dick Cavender 
Sent: Monday, March 22, 2021 15:03
To: dev@geode.apache.org 
Subject: RE: [VOTE] Apache Geode 1.13.2.RC1

Thanks Donal- Holding 1.13.2 release until there is more information.

-Original Message-
From: Donal Evans 
Sent: Monday, March 22, 2021 2:41 PM
To: dev@geode.apache.org
Subject: 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:59 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.13.2.RC1

Sorry, everyone! We still haven't gotten to the bottom of the very slow 
registerInterest. More details should be coming in a ticket as we get closer to 
the root cause. Right now, we are seeing messages about delayed 
FetchBulkEntries and registerInterest taking over 5 minutes. That's resulting 
in the HARegionQueue filling up and eventually falling over.

I am not sure what's formally the best way forward with this vote. The best 
solution to me seems to put the release on hold till this issue is resolved. 
There is still a chance that this will turn out to be a case that has been in 
Geode for a while now. In that case we could ship this RC after all. If we find 
that we need to make changes to address this issue, we of course should have a 
new vote.

Do we need a vote to pause the release or can we just informally agree that 
waiting for this is the best course of action till someone voices concern about 
the downsides of this delay?

From: Dick Cavender 
Sent: Thursday, March 18, 2021 13:52
To: dev@geode.apache.org 
Subject: RE: [VOTE] Apache Geode 1.13.2.RC1

Update: Apache Geode 1.13.2.RC1 voting deadline is now: 3PM PST Monday, March 
22, 2021

-Original Message-
From: Alexander Murmann 
Sent: Thursday, March 18, 2021 1:23 PM
To: dev@geode.apache.org
Subject: Re: [VOTE] Apache Geode 1.13.2.RC1

I am sorry, can we get another 24 hours to analyze the long registerInterest 
calls, please? Thank you!

From: Dick Cavender 
Sent: Tuesday, March 16, 2021 13:56
To: dev@geode.apache.org 
Subject: RE: [VOTE] Apache Geode 1.13.2.RC1

Certainly! The new Apache Geode 1.13.2.RC1 voting deadline is now: 3PM PST 
Thurs, March 18, 2021

-Original Message-
From: Alexander Murmann 
Sent: Tuesday, March 16, 2021 1:46 PM
To: dev@geode.apache.org
Subject: Re: [VOTE] Apache Geode 1.13.2.RC1

 Can we please extend the vote for another 48 hours? We are investigating a 
potential issue in which registerInterest is taking over 5 minutes. It's still 
unclear what exactly is causing that, but some more time to investigate would 
be better than potentially shipping a bug like this.

From: Dick Cavender 
Sent: Thursday, March 11, 2021 13:34
To: dev@geode.apache.org 
Subject: [VOTE] Apache Geode 1.13.2.RC1

Hello Geode Dev Community,

It's been 4 months since the Apache Geode 1.13.1 release and there are a total 
48 important fixes on support/1.13 that the community would benefit from. The 
recently released v1.12.1 has 33 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fissues%2F%3Fjql%3Dproject%2520%253D%2520GEODE%2520AND%2520fixVersion%2520%253D%25201.12.1%2520and%2520fixVersion%2520%253D%25201.13.2data=04%7C01%7Camurmann%40vmware.com%7C132372aa80994407689808d8ed7e4b84%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637520473980717192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=YzquO%2BJY7oJhfk2F6RGNG4%2FybE0YF69lYqyVC87Fr%2Bo%3Dreserved=0>
 fixes that are not released in 1.13. Based on this I propose release of an 
Apache Geode 1.13.2 based on the current support/1.13 branch. I'll volunteer to 
be the release manager for 1.13.2 and what follows is a release candidate for 
Apache Geode version 1.13.2.RC1.

Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you performed.

Voting deadline:
3PM PST Tues, March 16, 2021

Please note that we are voting upon the source tag:
rel/v1.13.2.RC1

Release 

Re: [DISCUSS] removal of experimental Protobuf client/server interface

[Alexander Murmann]

Udo, having worked on Protobuf with you, I share the emotional attachment. I 
also agree that it's a valuable feature to have and that ideally someone would 
pick it up. I don't think it's feature complete enough at this point to be 
viable. Unlike with Redis, I haven't seen anyone in the community contribute to 
it in a long time. If you or someone else were to volunteer to do all the work 
you propose we do on Protobuf, I'd strongly support keeping it.

I think each of the other feature areas you propose as potential removal 
candidates deserve their own dedicated discussion. I understand some of them 
are harder to remove from a technical perspective or neither experimental nor 
deprecated and would thus require a Geode 2.0.

From: Udo Kohlmeyer 
Sent: Tuesday, March 23, 2021 14:54
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface

-1

Given that I was on the team that started this initiative, I will naturally 
have an inclination to say 'No'.

I don't know if I would go as far as removing this project/initiative out of 
Geode.
I understand that the way that was used to hook into Geode was less the 
perfect, and I fully support removing those and possibly replacing them with 
viable alternatives, if that makes the core Geode project better. What I don't 
support is the removal of the code completely on the basis that it isn't used 
by anyone (we have no proof either direction).

I think that the addition of this adapter is beneficial to the Geode. Given 
that lack of documentation relating to the Geode wire protocol, the barrier of 
entry for anyone else to connect to Geode is HUGE. The Protobuf initiative was 
the effort to lower the bar of entry for other
languages to be able to talk to Geode. But by removing it, we make Geode less 
accessible. I think the lack of focus on this effort can also attribute to the 
lack of use. As @Dave pointed out, there is little to no documentation impact 
for the adapter. Which means, we (Geode) have failed at marketing this feature.

I propose that the Protobuf adapter NOT to be removed, but rather reworked so 
that it fits more in line with our other extensions like Redis and Memcache. 
Yes, we would have to maintain the code, but it is not like we haven't been 
doing this with the Memcache or Redis extension for a MUCH longer period than 
what we have for Protobuf. If we keep Protobuf, we need promote it, so we 
should document this adapter. Alternatively, if we remove Protobuf, we put 
effort into documented our wire protocol, so that Geode wire protocol is not a 
closed box and a HUGE barrier for anyone wanting to connect to Geode.

If we vote to permanently remove the Protobuf from Geode, I want to suggest 
that we put to vote the removal of many other projects in Geode on the basis of 
lack of adoption:
* Geode-Rebalancer
* Geode-Memcache
* Geode-Connector
* Geode-Redis
* Geode Offheap

These are projects that we maintain without any (known) users actively using 
these features.

--Udo

On 3/24/21, 2:16 AM, "Bruce Schuchardt"  wrote:

Hi folks,

We’ve had an experimental client/server interface in Geode that no-one to 
my knowledge is using.  We’re testing it with every build and are having to 
make changes to it to keep it up to date with the rest of the project.  The 
last change of substance to the geode-protobuf sub-project, for instance, was 
in 2018 but that’s been followed by many incidental commits.


GEM-8997
 was opened to have the sub-projects for this interface removed.  I’ve prepared 
a pull 
request
 to remove it and would like to get consensus to move forward with that effort.

Re: [DISCUSS] removal of experimental Protobuf client/server interface

[Alexander Murmann]

+1 for removal

From: Mark Hanson 
Sent: Tuesday, March 23, 2021 11:44
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface

+1 for removal.

On 3/23/21, 8:46 AM, "Darrel Schneider"  wrote:

I'm in favor of its removal. I was working on improving the geode thread 
monitor and found doing that on the protobuf code was much more complicated.

From: Bruce Schuchardt 
Sent: Tuesday, March 23, 2021 8:16 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] removal of experimental Protobuf client/server interface

Hi folks,

We’ve had an experimental client/server interface in Geode that no-one to 
my knowledge is using.  We’re testing it with every build and are having to 
make changes to it to keep it up to date with the rest of the project.  The 
last change of substance to the geode-protobuf sub-project, for instance, was 
in 2018 but that’s been followed by many incidental commits.


GEM-8997
 was opened to have the sub-projects for this interface removed.  I’ve prepared 
a pull 
request
 to remove it and would like to get consensus to move forward with that effort.

Re: [VOTE] Apache Geode 1.13.2.RC1

[Alexander Murmann]

Sorry, everyone! We still haven't gotten to the bottom of the very slow 
registerInterest. More details should be coming in a ticket as we get closer to 
the root cause. Right now, we are seeing messages about delayed 
FetchBulkEntries and registerInterest taking over 5 minutes. That's resulting 
in the HARegionQueue filling up and eventually falling over.

I am not sure what's formally the best way forward with this vote. The best 
solution to me seems to put the release on hold till this issue is resolved. 
There is still a chance that this will turn out to be a case that has been in 
Geode for a while now. In that case we could ship this RC after all. If we find 
that we need to make changes to address this issue, we of course should have a 
new vote.

Do we need a vote to pause the release or can we just informally agree that 
waiting for this is the best course of action till someone voices concern about 
the downsides of this delay?

From: Dick Cavender 
Sent: Thursday, March 18, 2021 13:52
To: dev@geode.apache.org 
Subject: RE: [VOTE] Apache Geode 1.13.2.RC1

Update: Apache Geode 1.13.2.RC1 voting deadline is now: 3PM PST Monday, March 
22, 2021

-Original Message-
From: Alexander Murmann 
Sent: Thursday, March 18, 2021 1:23 PM
To: dev@geode.apache.org
Subject: Re: [VOTE] Apache Geode 1.13.2.RC1

I am sorry, can we get another 24 hours to analyze the long registerInterest 
calls, please? Thank you!

From: Dick Cavender 
Sent: Tuesday, March 16, 2021 13:56
To: dev@geode.apache.org 
Subject: RE: [VOTE] Apache Geode 1.13.2.RC1

Certainly! The new Apache Geode 1.13.2.RC1 voting deadline is now: 3PM PST 
Thurs, March 18, 2021

-Original Message-
From: Alexander Murmann 
Sent: Tuesday, March 16, 2021 1:46 PM
To: dev@geode.apache.org
Subject: Re: [VOTE] Apache Geode 1.13.2.RC1

 Can we please extend the vote for another 48 hours? We are investigating a 
potential issue in which registerInterest is taking over 5 minutes. It's still 
unclear what exactly is causing that, but some more time to investigate would 
be better than potentially shipping a bug like this.

From: Dick Cavender 
Sent: Thursday, March 11, 2021 13:34
To: dev@geode.apache.org 
Subject: [VOTE] Apache Geode 1.13.2.RC1

Hello Geode Dev Community,

It's been 4 months since the Apache Geode 1.13.1 release and there are a total 
48 important fixes on support/1.13 that the community would benefit from. The 
recently released v1.12.1 has 33 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fissues%2F%3Fjql%3Dproject%2520%253D%2520GEODE%2520AND%2520fixVersion%2520%253D%25201.12.1%2520and%2520fixVersion%2520%253D%25201.13.2data=04%7C01%7Camurmann%40vmware.com%7Cc1050e0fe3854d4563f308d8ea4fc162%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637516975554974086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=d2z%2BjMcqP02jW1%2FeXjAEm7w38NJJHbGFGns86r6ih0Y%3Dreserved=0>
 fixes that are not released in 1.13. Based on this I propose release of an 
Apache Geode 1.13.2 based on the current support/1.13 branch. I'll volunteer to 
be the release manager for 1.13.2 and what follows is a release candidate for 
Apache Geode version 1.13.2.RC1.

Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you performed.

Voting deadline:
3PM PST Tues, March 16, 2021

Please note that we are voting upon the source tag:
rel/v1.13.2.RC1

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.2data=04%7C01%7Camurmann%40vmware.com%7Cc1050e0fe3854d4563f308d8ea4fc162%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637516975554974086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=dqw8kY1b3a1BRKe4SUQgxfia1cU70Zr3OKkJr2%2B3wBQ%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.2.RC1%2Fdata=04%7C01%7Camurmann%40vmware.com%7Cc1050e0fe3854d4563f308d8ea4fc162%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637516975554974086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2F5XP4W8%2F6p77BtlxOd1%2F7TkYBcGVh%2BcOasVJGKBgQGo%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1079data=04%7C01%7Camurmann%40vmware.com%7Cc1050e0fe3854d4563f308d8ea4fc162%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637516975554984081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=rN1AU

Re: [VOTE] Apache Geode 1.13.2.RC1

[Alexander Murmann]

I am sorry, can we get another 24 hours to analyze the long registerInterest 
calls, please? Thank you!

From: Dick Cavender 
Sent: Tuesday, March 16, 2021 13:56
To: dev@geode.apache.org 
Subject: RE: [VOTE] Apache Geode 1.13.2.RC1

Certainly! The new Apache Geode 1.13.2.RC1 voting deadline is now: 3PM PST 
Thurs, March 18, 2021

-Original Message-
From: Alexander Murmann 
Sent: Tuesday, March 16, 2021 1:46 PM
To: dev@geode.apache.org
Subject: Re: [VOTE] Apache Geode 1.13.2.RC1

 Can we please extend the vote for another 48 hours? We are investigating a 
potential issue in which registerInterest is taking over 5 minutes. It's still 
unclear what exactly is causing that, but some more time to investigate would 
be better than potentially shipping a bug like this.

From: Dick Cavender 
Sent: Thursday, March 11, 2021 13:34
To: dev@geode.apache.org 
Subject: [VOTE] Apache Geode 1.13.2.RC1

Hello Geode Dev Community,

It's been 4 months since the Apache Geode 1.13.1 release and there are a total 
48 important fixes on support/1.13 that the community would benefit from. The 
recently released v1.12.1 has 33 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fissues%2F%3Fjql%3Dproject%2520%253D%2520GEODE%2520AND%2520fixVersion%2520%253D%25201.12.1%2520and%2520fixVersion%2520%253D%25201.13.2data=04%7C01%7Camurmann%40vmware.com%7C98bde9426b0a4f43b17408d8e8bdff4d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515250024055723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2B8mDv8d%2FO82tOzseOs7klQP0ZPukb79iVLFQ2hy2hwo%3Dreserved=0>
 fixes that are not released in 1.13. Based on this I propose release of an 
Apache Geode 1.13.2 based on the current support/1.13 branch. I'll volunteer to 
be the release manager for 1.13.2 and what follows is a release candidate for 
Apache Geode version 1.13.2.RC1.

Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you performed.

Voting deadline:
3PM PST Tues, March 16, 2021

Please note that we are voting upon the source tag:
rel/v1.13.2.RC1

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.2data=04%7C01%7Camurmann%40vmware.com%7C98bde9426b0a4f43b17408d8e8bdff4d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515250024055723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=AnGqarTXH%2BykrN%2BU%2Fi7auA2dIIr3izk9tsqus74NqE4%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.2.RC1%2Fdata=04%7C01%7Camurmann%40vmware.com%7C98bde9426b0a4f43b17408d8e8bdff4d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515250024055723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Y3%2BvV0OSPvqj45DcnBLCkSVwa%2Fe57DNhaNYwzoHj%2FJw%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1079data=04%7C01%7Camurmann%40vmware.com%7C98bde9426b0a4f43b17408d8e8bdff4d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515250024055723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=MBtKl2Xwh%2FmarUxiilgNnDhk1u%2FkvXbF7XgER4h1nfs%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Camurmann%40vmware.com%7C98bde9426b0a4f43b17408d8e8bdff4d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515250024055723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=urV6jEp7s0HfrYX1krC%2FRC2g2Ct%2B8b%2BK7MtthPaWahw%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Camurmann%40vmware.com%7C98bde9426b0a4f43b17408d8e8bdff4d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515250024065718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TCczV1FmAPY6B%2FvN9aCbiE0uVe3asygDAuh3qW4YB8k%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Camurmann%40vmware.com%7C98bde9426b0a4f43b17408d8e8bdff4d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515250024065718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qzxYRBNOv9wEt%2Ff0LUK32K31bMPaEqjFXNl1BYAB0yg%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https

Re: [Proposal] Backport GEODE-9045 to support/1.14

[Alexander Murmann]

Seems like a no-brainer given the very low risk in the change and that it comes 
with legal reasons

From: Hale Bales 
Sent: Wednesday, March 17, 2021 11:42
To: dev@geode.apache.org 
Subject: [Proposal] Backport GEODE-9045 to support/1.14

Hello,

 I am putting forward the proposal to backport GEODE-9045 (Rename Redis 
properties and error messages) to support/1.14 branch,

What does GEODE-9045 do?

  *   It renames the redis-port property to 
compatible-with-redis-port
  *   It renames the redis-bind-address property to 
compatible-with-redis-bind-address
  *   It renames the redis-password property to 
compatible-with-redis-password
  *   It rewords error messages to remove usages of Redis, and 
changing them to something
  along the lines of Compatible with Redis

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. This is 
simply a rename of properties and does not change any behavior.

Why do we need to backport these changes?

  *   These changes will make us compliant with Redis's copyright, 
which does not allow us to claim that we are Redis. This prevents us from 
having any customer-facing places that say Redis, or Geode Redis.

~ hale (they/them)

Re: [VOTE] Apache Geode 1.13.2.RC1

[Alexander Murmann]

 Can we please extend the vote for another 48 hours? We are investigating a 
potential issue in which registerInterest is taking over 5 minutes. It's still 
unclear what exactly is causing that, but some more time to investigate would 
be better than potentially shipping a bug like this.

From: Dick Cavender 
Sent: Thursday, March 11, 2021 13:34
To: dev@geode.apache.org 
Subject: [VOTE] Apache Geode 1.13.2.RC1

Hello Geode Dev Community,

It's been 4 months since the Apache Geode 1.13.1 release and there are a total 
48 important fixes on support/1.13 that the community would benefit from. The 
recently released v1.12.1 has 33 

 fixes that are not released in 1.13. Based on this I propose release of an 
Apache Geode 1.13.2 based on the current support/1.13 branch. I'll volunteer to 
be the release manager for 1.13.2 and what follows is a release candidate for 
Apache Geode version 1.13.2.RC1.

Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you performed.

Voting deadline:
3PM PST Tues, March 16, 2021

Please note that we are voting upon the source tag:
rel/v1.13.2.RC1

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.2data=04%7C01%7Camurmann%40vmware.com%7Ce0dc57aa7fd648b1c57308d8e4d5726b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952686981115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=MLwDXaBywHxdTVxZ%2BsXY8lnPehLWAxgdGKzck4LHsVw%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.2.RC1%2Fdata=04%7C01%7Camurmann%40vmware.com%7Ce0dc57aa7fd648b1c57308d8e4d5726b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952686981115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=DQPtE3AAMAfMYIw1djzn2DNh7LmhT3%2FVE5YykL%2Fd%2Fvc%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1079data=04%7C01%7Camurmann%40vmware.com%7Ce0dc57aa7fd648b1c57308d8e4d5726b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952686981115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FF3t4Pc9XXU8Ep%2FSIeMkhUnetOMcEV4kqBjy0YEl8rM%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Camurmann%40vmware.com%7Ce0dc57aa7fd648b1c57308d8e4d5726b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952686981115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=LIrEYJbCe1O33cfnOGJpIlVdhr0jHoJob2r2S%2FXH%2FeA%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Camurmann%40vmware.com%7Ce0dc57aa7fd648b1c57308d8e4d5726b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952686981115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=YCZtd31M3i4iNm1afEQVdhoItIeW%2BbBOHr77Vqz8s6M%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Camurmann%40vmware.com%7Ce0dc57aa7fd648b1c57308d8e4d5726b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952686981115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZQjewlz%2Fy6mdeF7Ako2GQNXdM8Nj0RGzmcANbpB%2FbzM%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Camurmann%40vmware.com%7Ce0dc57aa7fd648b1c57308d8e4d5726b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952686981115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=irYcE5U%2BNSTcx7dFQGinDEDhrGM%2F0v4jJ04gT1ZXu2Y%3Dreserved=0

Pipelines:

[DISCUSS] Cutting a Geode 1.14.0 release branch

[Alexander Murmann]

Hi everyone,

We aren't seeing many issues that would prevent a 1.14.0 release on our blocker 
board
 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.

Re: [DISCUSS] Geode 1.14

[Alexander Murmann]

Hi team!

If I am reading the silence correctly as silent approval, can everyone please 
start to add the blocks-1.14.0​ label to all tickets we should consider as 
release blockers?

I also would encourage us to not remove the label when we resolve a ticket. 
This allows us to get a better understanding of our progress. We should remove 
the label if we decide that we can ship without a fix.


On a practical note: It seems like the dashboard doesn't always show all ticket 
changes immediately. I'll let you know when I get a better understanding of 
that behavior.

From: Alexander Murmann 
Sent: Tuesday, January 5, 2021 08:34
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Geode 1.14

I agree with Jianxia that a dashboard would be helpful.

Not every bug that affects a release should necessarily be a release blocker. 
Factors like low severity, existence in prior versions and time to fix might 
all play a role in deciding that a bug should be fixed in a later version. So 
we need a way to track what issues are considered a release blocker separately 
from what versions are affected. Ideally we'd use something like a 
blocked-releases fields. We don't have that right now, so I propose we use a 
blocks-1.14.0​ label.

I started on a dashboard that tracks these 
here<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2FDashboard.jspa%3FselectPageId%3D12336052data=04%7C01%7Camurmann%40vmware.com%7Ce3c64a22854b44232a2708d8b197bfa9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637454612604312895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=rAFXAsnkIWtvxPcv%2BcGnoU5m9B8aCIOLv6bn3bFmEN8%3Dreserved=0>.
 Everyone should have access to view it.

The dashboard shows all issues with the label. There are two lists one with 
open issues and one with resolved issues. I propose that we keep the blocker 
label on an issue if we resolve the issue, but remove it if we decide against 
resolving it in this version. In that case we might want to consider already 
tagging it with a future version (e.g. blocks-1.14.1​), so that it stays top of 
mind. We should only do that though if we indeed want to fix it in that 
version.

Once the list of open issues marked as blockers is down to a handful, we should 
revisit the discussion about cutting the release branch.

If we agree that this is the right approach, I'll need all of your help in 
going back to open tickets and labeling them as release blockers where 
appropriate.

How does that sound?

From: Jacob Barrett 
Sent: Monday, January 4, 2021 16:40
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Geode 1.14



> On Jan 4, 2021, at 3:42 PM, Owen Nichols  wrote:
>
> How to tell whether develop is stable?

Same way we tell if a release branch is stable.

Listen, cutting a release branch from the develop branch shouldn’t result in 
weeks worth of stabilization of the release branch. That is a smell that we 
have bad things going into develop. If there are bad things in develop then we 
are introducing new things to develop on top of bad things, which will just end 
up being more bad things.

It isn’t cut or dry. I am not saying release from develop on an arbitrary day. 
I am saying we know develop isn’t stable. We know a release branch will take 
weeks to repair. Lets turn that around, lets make develop stable so a release 
branch takes days to release, not weeks. Yes there will be issues found on a 
release branch that have to be fixed but that should be an exception, not the 
norm.

-Jake

Re: [DISCUSS] Geode 1.14

[Alexander Murmann]

I agree with Jianxia that a dashboard would be helpful.

Not every bug that affects a release should necessarily be a release blocker. 
Factors like low severity, existence in prior versions and time to fix might 
all play a role in deciding that a bug should be fixed in a later version. So 
we need a way to track what issues are considered a release blocker separately 
from what versions are affected. Ideally we'd use something like a 
blocked-releases fields. We don't have that right now, so I propose we use a 
blocks-1.14.0​ label.

I started on a dashboard that tracks these 
here.
 Everyone should have access to view it.

The dashboard shows all issues with the label. There are two lists one with 
open issues and one with resolved issues. I propose that we keep the blocker 
label on an issue if we resolve the issue, but remove it if we decide against 
resolving it in this version. In that case we might want to consider already 
tagging it with a future version (e.g. blocks-1.14.1​), so that it stays top of 
mind. We should only do that though if we indeed want to fix it in that 
version.

Once the list of open issues marked as blockers is down to a handful, we should 
revisit the discussion about cutting the release branch.

If we agree that this is the right approach, I'll need all of your help in 
going back to open tickets and labeling them as release blockers where 
appropriate.

How does that sound?

From: Jacob Barrett 
Sent: Monday, January 4, 2021 16:40
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Geode 1.14



> On Jan 4, 2021, at 3:42 PM, Owen Nichols  wrote:
>
> How to tell whether develop is stable?

Same way we tell if a release branch is stable.

Listen, cutting a release branch from the develop branch shouldn’t result in 
weeks worth of stabilization of the release branch. That is a smell that we 
have bad things going into develop. If there are bad things in develop then we 
are introducing new things to develop on top of bad things, which will just end 
up being more bad things.

It isn’t cut or dry. I am not saying release from develop on an arbitrary day. 
I am saying we know develop isn’t stable. We know a release branch will take 
weeks to repair. Lets turn that around, lets make develop stable so a release 
branch takes days to release, not weeks. Yes there will be issues found on a 
release branch that have to be fixed but that should be an exception, not the 
norm.

-Jake

Re: [DISCUSS] Geode 1.14

[Alexander Murmann]

Hi all,

Thanks, Owen for reminding us all of this topic!

I wonder how we feel about the state of develop right now. If we cut 1.14 right 
now, it will make it easier to stabilize and ship it. However, I see 21 open 
JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort 
to address as much as possible on develop and then cut 1.14. If we shift all 
attention to 1.14, develop will likely never get better. I'd love to get closer 
to an always shippable develop branch. That should vastly reduce future release 
pain and make everyday development better as well.

Thoughts?

From: Jens Deppe 
Sent: Wednesday, November 25, 2020 20:11
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Geode 1.14

Hi Owen,

Thanks for starting this conversation and especially for volunteering as 
Release Manager!

Since we're already a couple of quarters 'behind', in terms of releases, I'd 
prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 
months of changes to stabilize. How long might that take to finally get 
shipped? (rhetorical).

--Jens

On 11/25/20, 6:05 PM, "Owen Nichols"  wrote:

The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met 
(we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch.  I will volunteer 
as Release Manager.

Below are all release dates since Geode adopted a time-based release 
cadence.

Minor releases:
1.13   branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12   branch cut Feb 4 20201.12.0 shipped Mar 31 2020
1.11   branch cut Nov 4 2019   1.11.0 shipped Dec 31 2019
1.10   branch cut Aug 2 2019   1.10.0 shipped Sep 26 2019
1.9  branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8  branch cut Nov 1 2018   1.8.0 shipped Dec 12 2018

Patch releases:
1.13.1shipped Nov 18 2020
1.9.2  shipped Nov 14 2019
1.9.1  shipped Sep 6 2019

I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on 
the next date in the original quarterly cadence: Feb 1 2021.

-Owen

From: Alexander Murmann 
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org 
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,

As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.

Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.

Re: [DISCUSS] Adding CODEOWNERS to Apache Geode

[Alexander Murmann]

+1

I agree with Owen's point that this will improve the experience for new 
contributors. It also helps people new to the community to have confidence that 
they got the type of review they need to feel confident to merge. I might get 
to reviews that are both from great committers who can review for things like 
coding style, test coverage etc. However, I might be unaware that neither of 
them know the area I am modifying particularly well. This solves this problem. 
I can merge with more confidence, once I got the review from the owner.

From: Anthony Baker 
Sent: Thursday, November 19, 2020 17:55
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode

+1

I think we as a project will need to iterator on the code owners as well as the 
process for code owners.  But this is a model that has been adopted by a number 
of OSS projects both within and outside of Apache.  I like that it provides 
visibility to PR authors and associates motivated experts to review and merge 
changes.

Anthony


> On Nov 19, 2020, at 10:46 AM, Ernie Burghardt  wrote:
>
> Perfect, then let's give this a try.
> +1
>
> On 11/19/20, 10:45 AM, "Robert Houghton"  wrote:
>
>Hi Ernie,
>
>DRAFT PRs do not get reviewers by default, but when the draft transitions 
> to ‘ready’, then the owners are requested to review.
>
>
>From: Ernie Burghardt 
>Date: Thursday, November 19, 2020 at 9:56 AM
>To: dev@geode.apache.org 
>Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode
>Does GitHub allow us to limit this automated action to non-DRAFT PRs?
>
>On 11/18/20, 8:28 PM, "Owen Nichols"  wrote:
>
>+1 This will greatly improve the experience for contributors.  Instead 
> of an intimidating empty list of reviewers when you submit a PR (and no 
> ability to add reviewers, if you’re not a committer), it will be great to 
> already have at least two reviewers automagically assigned.
>
>I have a small concern that initially populating this file via a 
> flurry of PRs may result in a lot of merge conflicts with anyone else that 
> volunteers on the same or an adjacent line.  Also, since you _must_ be a 
> committer to be a code owner, is a PR even necessary…would directly 
> committing changes to the feature/introduce-codeowners branch be acceptable?  
> If not, who needs to review and who can merge the PRs against the ‘introduce’ 
> branch?
>
>What happens if you are the only owner for an area, can you approve 
> your own PR?  Even if the goal is two owners per area, does that mean PRs by 
> either owner cannot be merged if the only other owner is on vacation or 
> otherwise unavailable?
>
>Can we submit PRs against the ‘introduce’ branch now and they just 
> won’t be merged before Nov 26, or do we all just need to be patient until 
> this review period has concluded?
>
>From: Robert Houghton 
>Date: Wednesday, November 18, 2020 at 2:07 PM
>To: dev@geode.apache.org 
>Subject: [DISCUSS] Adding CODEOWNERS to Apache Geode
>Hello Devs.
>
>I would like to improve the quality of the pull-request reviews we see 
> for
>critical parts of the Apache Geode project. In discussions with other
>committers, a (not the) big hurdle to that is getting the right eyes to
>look at a given PR. To that end, I propose the adoption of GitHub's
>CODEOWNERS functionality for the Apache Geode code repository.
>
>A discussion-document of this issue has been written up
>by @upthewaterspout. Thanks Dan!
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FIntroduce%2BCodeowners%2Bfiledata=04%7C01%7Camurmann%40vmware.com%7Cd7fd7c5893484f645a4108d88cf76bf1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637414341580772048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wQxhF4USgHN1ed5j3bsRcjSAQ2jaUtkpfyNI3fFlM4k%3Dreserved=0
>
>I have tested the feature with fellow Geode committers @upthewaterspout
>and @onichols-pivotal, and found it to meet our expectations.  Please
>review the document, and comment or reply to this thread, by 25 
> November,
>so we might start the task of nominating and applying for ownership.
>
>-Robert Houghton
>

Re: PR process and etiquette

[Alexander Murmann]

Let's try to move this towards action:

It seems like we have consensus that a CONTRIBUTING.md file is a great idea.

We also have consensus to recommend in there that one should be mindful to 
create PRs as drafts if you don't consider them ready for review.

It seems reasonable that one might want a review of incomplete code. I'd 
recommend calling out in the PR description that the PR is incomplete, what's 
missing and maybe what areas you'd like reviewers to focus on, given the 
incompleteness.

I'd love to see some of the things Donal called out around commit messages and 
PR descriptions included in CONTRIBUTING.md as well.


Is the above an accurate description of this discussion's consensus?


Udo, if we all agree on the above, would you like to take a stab at writing the 
CONTRIBUTING.md, since you kicked this off? If not, I am happy to give it a 
shot as well.

From: Darrel Schneider 
Sent: Thursday, October 29, 2020 14:33
To: dev@geode.apache.org 
Subject: Re: PR process and etiquette

+1 for adding a CONTRIBUTING.MD file

From: Sarah Abbey 
Sent: Thursday, October 29, 2020 2:07 PM
To: dev@geode.apache.org 
Subject: Re: PR process and etiquette

Regarding knowing who to tag in a PR, because I am working on a very specific 
aspect of Geode, it was frustrating before I was a committer to not be able to 
add reviewers since I knew the handful of people that had enough context to 
review most of the PRs I submitted.  But it is also not hard for me to ask 
these people directly since I work with them every day.  I can imagine it would 
be very frustrating to know exactly who to request a review from, but not be 
able to add them and not be able to directly contact them or get their 
attention.  It would also be nice to be able to request reviews from people who 
are not committers, which we may not be able to change due to GitHub 
limitations. Some of my team members are not committers yet, but I still value 
their input/review of the code even if their review would not count as an 
official approving review. Or if we submit a PR that solves an issue raised by 
a non-committer, it would be nice to have them review it (if they want to/it 
makes sense for them to) to be sure the issue is addressed. Robert has 
mentioned that a workaround is to tag those users in a comment.

Since I only feel like I have significant context in one area of Geode, I 
usually scan the list of PRs for that area unless I'm explicitly tagged as a 
reviewer.  Sometimes, I read other PRs to gain knowledge or if I'm curious, but 
I don't usually add a review.

Regarding waiting until all commit checks are green, it depends on the PR for 
me.  I usually glance at a PR once I'm tagged as a reviewer or I see something 
that needs a review in my area of expertise.  If it looks like the PR still 
needs a lot of work and checks like build did not pass, then I typically wait 
to review it.  If most of the checks have passed, and checks that take a long 
time to run, like DUnit or Acceptance, haven't completed, I will often review 
it.  If certain checks that sometimes have flaky tests are not passing, like 
DUnit, and all other checks are green, I'll often look at those failures to see 
if they are related to the PR at all and check Jira to see if there has been an 
issue filed for them or not.  I'll still review the PR and make a comment about 
the flaky test.  If the failure seems related to the PR, I might still review 
it to see what might've caused the failure.

Whatever we do, our guide to 
contributing
 could definitely use an update.  We might even consider putting a 
CONTRIBUTING.MD file directly in our GitHub repo.  I've found these guides 
useful when contributing to other open source projects.  I also like 
contributing to open source projects when my PR is reviewed timely (within a 
week, though I'm sure we all have different definitions of timely) and any 
feedback or discussion is constructive and kind.

Sarah

From: Donal Evans 
Sent: Thursday, October 29, 2020 3:41 PM
To: dev@geode.apache.org 
Subject: 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 cleanup, and if you 
don't have the luxury of working directly with other 

Re: How to add a new REST end point in Cluster Management Service

[Alexander Murmann]

If it's a how-to, I'd move it out of the proposals section and to where you 
want the how-to to live once everything is done and add a disclaimer at the top 
that it's for work that's still incomplete. "Internal Architecture" seems like 
the least bad fit, givne this how-to is for internal development, rather than 
app developers.

I'd also add that the RFCs shouldn't be taken as a replacement for 
architectural documentation. There might be overlap, but the ultimate goal is 
different. I wouldn't hesitate to add some more documentation in the 
architecture section as we flesh out the general direction from the RFC.

From: Jinmei Liao 
Sent: Tuesday, November 10, 2020 18:25
To: dev@geode.apache.org 
Subject: Re: How to add a new REST end point in Cluster Management Service

It's a how-to on further development. I hate to break all the related docs into 
different places though.

Any feedback is welcome.

On 11/10/20, 1:54 PM, "Alexander Murmann"  wrote:

Jinmei, I am still not sure I understand if this is a proposal. It's listed 
under proposals but written more like a how-to.

So given the feature is still in progress. Do you want feedback on the 
writing of the document or the architecture of the underlying code or both?

From: Jinmei Liao 
Sent: Tuesday, November 10, 2020 10:06
To: dev@geode.apache.org 
Subject: Re: How to add a new REST end point in Cluster Management Service

It's a feature still in development. Should we move the entire CMS specs to 
another section?

On 11/6/20, 3:32 PM, "Alexander Murmann"  wrote:

Jinmei, thanks for writing this! Can you help me understand why this is 
listed under Project Proposals and Specifications?

From: John Blum 
Sent: Wednesday, October 28, 2020 08:27
To: dev@geode.apache.org 
Subject: Re: How to add a new REST end point in Cluster Management 
Service

Hi Jinmei-

I put feedback and other comments in the Wiki page.

Regards,
John


From: Jinmei Liao 
Sent: Monday, October 26, 2020 10:53 AM
To: dev@geode.apache.org 
Subject: How to add a new REST end point in Cluster Management Service

Hi, Geode developers,

I just added a twiki page detailing how to add a new REST end point in 
Cluster Management Service to manage new entities or start new long running 
operations in Geode Cluster. Feel free to look it through and provide 
comments/suggestions.


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAdd%2BA%2BREST%2BEnd%2Bpoint%2Bto%2BCluster%2BManagement%2BServicedata=04%7C01%7Camurmann%40vmware.com%7C325504506e42417dd92208d885e92083%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637406583603976716%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=1x0CsIo9d5ZXwKqPKu5Rgx0OxKFmepdac%2BDc7CCD6no%3Dreserved=0

Thanks!

Jinmei

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

[Alexander Murmann]

+1

Thanks for fixing those, Donal!

From: Donal Evans 
Sent: Tuesday, November 10, 2020 15:46
To: dev@geode.apache.org 
Subject: [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 deadlock that can occur rarely when GII 
and Tombstone GC are happening at the same time. While difficult to reproduce 
the issue, the fix removes the possibility of it occurring and verifies that 
other behaviour is unchanged.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8536data=04%7C01%7Camurmann%40vmware.com%7Cd01a7c296f914967bd7308d885d2dccd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637406487981660456%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ec31IuA2k%2Bu0HX7weQG%2BFrWTNPdov1t9UW%2F%2BGBfqd5U%3Dreserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8686data=04%7C01%7Camurmann%40vmware.com%7Cd01a7c296f914967bd7308d885d2dccd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637406487981660456%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wYAJA%2BBsG3AsKWwULTudOurXNB%2BQ9nEfVqyiWe%2BxvlY%3Dreserved=0

Re: How to add a new REST end point in Cluster Management Service

[Alexander Murmann]

Jinmei, I am still not sure I understand if this is a proposal. It's listed 
under proposals but written more like a how-to.

So given the feature is still in progress. Do you want feedback on the writing 
of the document or the architecture of the underlying code or both?

From: Jinmei Liao 
Sent: Tuesday, November 10, 2020 10:06
To: dev@geode.apache.org 
Subject: Re: How to add a new REST end point in Cluster Management Service

It's a feature still in development. Should we move the entire CMS specs to 
another section?

On 11/6/20, 3:32 PM, "Alexander Murmann"  wrote:

Jinmei, thanks for writing this! Can you help me understand why this is 
listed under Project Proposals and Specifications?

From: John Blum 
Sent: Wednesday, October 28, 2020 08:27
To: dev@geode.apache.org 
Subject: Re: How to add a new REST end point in Cluster Management Service

Hi Jinmei-

I put feedback and other comments in the Wiki page.

Regards,
John


From: Jinmei Liao 
Sent: Monday, October 26, 2020 10:53 AM
To: dev@geode.apache.org 
Subject: How to add a new REST end point in Cluster Management Service

Hi, Geode developers,

I just added a twiki page detailing how to add a new REST end point in 
Cluster Management Service to manage new entities or start new long running 
operations in Geode Cluster. Feel free to look it through and provide 
comments/suggestions.


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAdd%2BA%2BREST%2BEnd%2Bpoint%2Bto%2BCluster%2BManagement%2BServicedata=04%7C01%7Camurmann%40vmware.com%7Cbda9dd562695463ab5d208d885a362d4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637406284070097738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=aghCZFY1kgHnsjxjtPTnIu5RZeQ7xyrPR%2FomjH4GMks%3Dreserved=0

Thanks!

Jinmei

Re: How to add a new REST end point in Cluster Management Service

[Alexander Murmann]

Jinmei, thanks for writing this! Can you help me understand why this is listed 
under Project Proposals and Specifications?

From: John Blum 
Sent: Wednesday, October 28, 2020 08:27
To: dev@geode.apache.org 
Subject: Re: How to add a new REST end point in Cluster Management Service

Hi Jinmei-

I put feedback and other comments in the Wiki page.

Regards,
John


From: Jinmei Liao 
Sent: Monday, October 26, 2020 10:53 AM
To: dev@geode.apache.org 
Subject: How to add a new REST end point in Cluster Management Service

Hi, Geode developers,

I just added a twiki page detailing how to add a new REST end point in Cluster 
Management Service to manage new entities or start new long running operations 
in Geode Cluster. Feel free to look it through and provide comments/suggestions.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAdd%2BA%2BREST%2BEnd%2Bpoint%2Bto%2BCluster%2BManagement%2BServicedata=04%7C01%7Camurmann%40vmware.com%7Cd962e8bb0eda43db20b108d87b55fe4e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637394956552000156%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ViF6uE0XR2CESfpba1ysmt31rIUvVAzZx7LDuVwn9kQ%3Dreserved=0

Thanks!

Jinmei

Re: Odg: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

[Alexander Murmann]

Oh, I am so sorry Mario! I mistakenly was under the impression the change was 
related to more failures. I should have looked more carefully! Thank you for 
the fix! ??

From: Mario Ivanac 
Sent: Friday, October 23, 2020 13:39
To: Alexander Murmann ; dev@geode.apache.org 

Subject: Odg: Odg: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

Hi,

I am not aware that tests 
(GEODE-8172<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8172=04%7C01%7Camurmann%40vmware.com%7Cb725e3ba5535457e372e08d87793b4da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637390823620044260%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=3aT5yJlgvgg47aJSJ7SlfekvQ2Sl%2B%2FfWaOQi%2BI6R5YU%3D=0>,
 
GEODE-8216<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8216=04%7C01%7Camurmann%40vmware.com%7Cb725e3ba5535457e372e08d87793b4da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637390823620054258%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=LId8KQoqMGeRG1k3issagxNxepi5arCaofEjMVMGFzU%3D=0>)
 are still failing, after last modification of test (October 7).

BR,
Mario

Šalje: Alexander Murmann 
Poslano: 23. listopada 2020. 22:25
Prima: dev@geode.apache.org 
Kopija: Mario Ivanac 
Predmet: Re: Odg: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

The failing WAN-related tests are still making up the majority of flaky 
tests<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-mass-test-run%2Fjobs%2Fcreate-mass-test-run-report%2Fbuilds%2F40=04%7C01%7Camurmann%40vmware.com%7Cb725e3ba5535457e372e08d87793b4da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637390823620064252%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=2uP8sqNXyghB3vQ3LKYXPEawlioaDxo03Vsh0GgISj4%3D=0>
 we are observing. It's a real issue, since the noise from flaky tests can 
easily hide very real bugs. That's why earlier this year several people spent a 
few months improving the reliability of our tests.

Mario, in July you said you were investigating this. Is that still ongoing? Do 
you need any help?
____
From: Alexander Murmann 
Sent: Tuesday, July 14, 2020 09:00
To: dev@geode.apache.org 
Cc: Alexander Murmann 
Subject: Re: Odg: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

Thanks for looking into this, Mario!

You are probably right, that the underlying issue might have been
pre-existing and that the test is surfacing it. I am glad though that you
are investigating, because a close to 30% fail rate is a problem. Something
like this happens every once in a while and then someone has to do some
work to resolve historical problems that they hadn't planned to addres.

Thanks!

On Tue, Jul 14, 2020 at 1:06 AM Mario Ivanac  wrote:

> Hi,
>
> after adding additional checks in failing test, now I can see that test
> are failing due to fault that some batch are distributed at stopping of GW
> sender.
> Cause of that, I suspect that this problem existed prior to this PR, but
> this PR is first to introduce test to check this.
>
> I will continue to investigate this fault, but I can not locally reproduce
> this fault, so this is slowing troubleshooting.
>
> BR,
> Mario
> 
> Šalje: Alexander Murmann 
> Poslano: 14. srpnja 2020. 1:11
> Prima: Alexander Murmann 
> Kopija: dev@geode.apache.org ; Mario Ivanac
> 
> Predmet: Re: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes
>
> We continue to see these WAN tests adding a fail rate of just below 30% in
> our mass test runs
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-mass-test-run%2Fjobs%2Fcreate-mass-test-run-report%2Fbuilds%2F10data=02%7C01%7Camurmann%40vmware.com%7C3eab11cb15d84879960f08d8280f073b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637303392297231701sdata=STlN5I9iM8gRqsKndH6GKwuY5cVOskAgUjNgkoJvzCw%3Dreserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-mass-test-run%2Fjobs%2Fcreate-mass-test-run-report%2Fbuilds%2F10=04%7C01%7Camurmann%40vmware.com%7Cb725e3ba5535457e372e08d87793b4da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637390823620064252%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=HIAg2oiethvYT4cu8VdDWKRj6R1vHA0UF2%2FDjtnM4so%3D=0>
> >
> .
>
> That's a very significant fail rate that impacts our ability to get our
> code committed w

Re: Odg: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

[Alexander Murmann]

The failing WAN-related tests are still making up the majority of flaky 
tests<https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/create-mass-test-run-report/builds/40>
 we are observing. It's a real issue, since the noise from flaky tests can 
easily hide very real bugs. That's why earlier this year several people spent a 
few months improving the reliability of our tests.

Mario, in July you said you were investigating this. Is that still ongoing? Do 
you need any help?

From: Alexander Murmann 
Sent: Tuesday, July 14, 2020 09:00
To: dev@geode.apache.org 
Cc: Alexander Murmann 
Subject: Re: Odg: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

Thanks for looking into this, Mario!

You are probably right, that the underlying issue might have been
pre-existing and that the test is surfacing it. I am glad though that you
are investigating, because a close to 30% fail rate is a problem. Something
like this happens every once in a while and then someone has to do some
work to resolve historical problems that they hadn't planned to addres.

Thanks!

On Tue, Jul 14, 2020 at 1:06 AM Mario Ivanac  wrote:

> Hi,
>
> after adding additional checks in failing test, now I can see that test
> are failing due to fault that some batch are distributed at stopping of GW
> sender.
> Cause of that, I suspect that this problem existed prior to this PR, but
> this PR is first to introduce test to check this.
>
> I will continue to investigate this fault, but I can not locally reproduce
> this fault, so this is slowing troubleshooting.
>
> BR,
> Mario
> ________
> Šalje: Alexander Murmann 
> Poslano: 14. srpnja 2020. 1:11
> Prima: Alexander Murmann 
> Kopija: dev@geode.apache.org ; Mario Ivanac
> 
> Predmet: Re: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes
>
> We continue to see these WAN tests adding a fail rate of just below 30% in
> our mass test runs
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-mass-test-run%2Fjobs%2Fcreate-mass-test-run-report%2Fbuilds%2F10data=02%7C01%7Camurmann%40vmware.com%7C3eab11cb15d84879960f08d8280f073b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637303392297231701sdata=STlN5I9iM8gRqsKndH6GKwuY5cVOskAgUjNgkoJvzCw%3Dreserved=0
> >
> .
>
> That's a very significant fail rate that impacts our ability to get our
> code committed with confidence.
>
> Can we resolve this issue? Otherwise, I think we need to consider reverting
> GEODE-7458.
>
> On Fri, Jun 19, 2020 at 3:28 PM Alexander Murmann 
> wrote:
>
> > Looking more into this, it looks like this was introduced by the changes
> > for GEODE-7458 - "Adding additional option in gfsh command "start gateway
> > sender" to control clearing of existing queues".
> >
> > That happened about a month ago, but it's inherent to those flaky tests
> > that we discover them only after a while. Nonetheless, they become paper
> > cuts that ultimately slow us down substantially if they persist.
> >
> > @Mario Ivanac If I am correct and GEODE-7458 introduced this you were the
> > one making that change. Might you be able to take a look at making that
> > test more reliable or reverting the change?
> >
> > Thank you!
> >
> > On Fri, Jun 19, 2020 at 7:57 AM Alexander Murmann 
> > wrote:
> >
> >> Thank you so much for sharing this, Mark!
> >>
> >> It looks like there is a big cluster around WAN Gateway. Is anyone
> >> already looking into the WAN issues?
> >>
> >> On Thu, Jun 18, 2020 at 10:06 PM Mark Hanson 
> wrote:
> >>
> >>> FYI, the build success rate was around 90% or so about two months ago.
> >>>
> >>> Here are the DUnit tests that are currently failing in our tests, most
> >>> likely in CI, and PR pipelines.
> >>>
> >>> Please let me know if you have any questions.
> >>>
> >>> Thanks,
> >>> Mark
> >>>
> >>>
> >>>
> >>>
> ***
> >>>
> >>>  Overall build success rate: 78.0% (156 of 200)
> >>>
> >>>
> >>>
> ***
> >>>
> >>>
> >>>
> >>> The following test methods see failures in more than one class.  There
> >>> may be a failing *TestBase class
> &g

Re: [DISCUSS] Shipping patch releases

[Alexander Murmann]

I would feel much more comfortable if the default behavior was to always
port back in reverse order without skipping a support branch. This makes it
much harder to forget poring to a support branch. Few things are more
frustrating to users than upgrading to a new patch release to get a bug fix
and having that bug come back when they upgrade months later to a newer
minor release.

There definitely should be exceptions for example when we are in the final
stages of shipping a patch release on a branch, but those should be
exceptions.

On Fri, Aug 28, 2020 at 5:12 PM Owen Nichols  wrote:

> Sound like there is no need to clarify or amend what is already spelled
> out in RFC[1]:
> * Backports can be made to dormant support branches without requiring a
> proposal or votes, subject to the "exercise good judgement" clause in the
> RFC.
> * Backports to multiple support branches can be made in any order as long
> as eventually all gaps are filled (make sure the Fix Versions list in Jira
> always accurately reflects which branches do have the fix).
>
> On 8/28/20, 1:10 PM, "Owen Nichols"  wrote:
>
> I noticed a recent change on support/1.12 that was not preceded by a
> backport proposal.
>
> I re-read the Shipping Patch Releases RFC[1] which was adopted earlier
> this year, and it doesn’t seem to mention anywhere that a backport proposal
> is required for “dormant” support branches.
>
> However, it does explicitly call out “if a fix is present in release
> N-2 it should also be present in N-1 and N releases.”  Normally the best
> way to satisfy this is to backport to support/1.13 first (which definitely
> does[2] require a backport proposal as we have an active release in
> progress).
>
> Questions for the Geode community:
>
>   1.  Is an out-of-order backport acceptable, and if so, should there
> be any upper limit on how long to tolerate the inconsistency before a
> revert would be required on the older branch?  The risk here is that a
> 1.12.1 could ship before a 1.13.1, causing a user upgrading from 1.12.1 to
> 1.13.0 to experience a regression.
>   2.  Should we clarify that ALL backports to support branches require
> a dev list proposal and three +1’s?  Or should we clarify that only
> backports to an ACTIVE release branch need community approval?
>
> [1] https://www.cwiki.us/display/GEODE/Shipping+patch+releases
> [2]
> https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode#ReleasingApacheGeode-Acceptcriticalfixestothesupportbranch
>
>

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

[Alexander Murmann]

+1

On Tue, Sep 1, 2020 at 6:19 AM Sarah Abbey  wrote:

> +1
> 
> From: Ju@N 
> Sent: Tuesday, September 1, 2020 4:10 AM
> To: dev@geode.apache.org 
> Subject: Re: Proposal to bring GEODE-8456 (shiro upgrade) to support
> branches
>
> +1
>
> On Tue, 1 Sep 2020 at 01:11, Donal Evans  wrote:
>
> > +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 GEODE-8456 (shiro upgrade) to support branches
> >
> > 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.
> >
>
>
> --
> Ju@N
>

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

[Alexander Murmann]

+1

On Mon, Aug 3, 2020 at 4:47 PM Jianxia Chen  wrote:

> +1
>
> On Mon, Aug 3, 2020 at 4:13 PM Darrel Schneider  wrote:
>
> > 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, fix.
> >
>

Re: [PROPOSAL] Postpone Geode 1.14

[Alexander Murmann]

Mark, that's a great point! I'll give everyone till tomorrow to contribute
their opinion on this thread and then inform the user list.

Thanks!

On Wed, Jul 29, 2020 at 1:35 PM Mark Bretl  wrote:

> +1
>
> Should we need to drop a line to user@geode or is communicating on this
> list enough once decided?
>
> --Mark
>
> On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior 
> wrote:
>
> > +1
> >
> > On 2020-07-28, 7:34 PM, "Alexander Murmann" 
> wrote:
> >
> > Hi all,
> >
> > As mentioned on the previous discuss thread, I propose to hold off
> > cutting
> > 1.14 until we have shipped 1.13.
> >
> > Once we have shipped 1.13, we should discuss when we want to cut the
> > 1.14
> > release. The actual ship date for Geode 1.13 is important information
> > for
> > that conversation. Thus we cannot have that conversation before then.
> >
> >
>

[PROPOSAL] Postpone Geode 1.14

[Alexander Murmann]

Hi all,

As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.

Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.

Re: [Discuss] Cutting Geode 1.14

[Alexander Murmann]

Owen, we cannot plan an updated timeline till we have shipped 1.13. If the
goal is to avoid overlap between 1.13 and 1.14 and give folks a break, we
need to know when 1.13 ships.

On Mon, Jul 20, 2020 at 4:57 PM Owen Nichols  wrote:

> Current schedule for cutting support branches is:
> Aug 3, 2020: cut support/1.14
> Nov 2, 2020: cut support/1.15
> Feb 1, 2021: cut support/1.16
> May 3, 2021: cut support/1.17
>
> I have a hard time understanding how anyone can trust that our schedule is
> "time-based" if we can change the dates at the last minute.  But, I am
> reminded that this is only a discussion thread at this point, not a
> proposal yet.  If it does become a proposal, I would just like to see
> concrete dates proposed for the next few branch cuts.  Any change to the
> 1.14 branch cut date almost certainly must affect subsequent branch cut
> dates.
>
> I agree that there needs to be some downtime in between release cycles.
> Given that we came up with the quarterly cadence using an assumption of 1
> month to get a release out, but we've found that it actually takes 2-3
> months, maybe the quarterly cadence is just too aggressive?
>
>
> On 7/20/20, 3:12 PM, "Alexander Murmann"  wrote:
>
> Hi Owen,
>
> I am not proposing to abandon our time-based releases. It's
> unprecedented
> for one of our releases to take this long. Even if we were to cut the
> release now, it would likely not receive any attention till 1.13 is
> out. So
> I don't think there is any benefit in cutting the release now. In
> addition
> there are all the downsides, I discussed above that are unique to this
> situation.
>
>
> An aside:
>
> > [..] developers will hold off on high-risk changes and focus more on
> > hardening as the cut date approaches.
> >
>  To me that wasn't ever part of the reason for timed releases, but
> predictability for users and for developers to know by when features
> need
> to be done to ship. If we feel a change is risky, let's write tests
> till we
> feel it's safe.
>
>
>
> On Mon, Jul 20, 2020 at 12:19 PM Owen Nichols 
> wrote:
>
> > The Geode community adopted a time-based quarterly cadence two years
> ago
> > in the hope it would lead to higher stability and more predictable
> > releases.  The idea was that by knowing exactly when a branch cut is
> > upcoming, developers will hold off on high-risk changes and focus
> more on
> > hardening as the cut date approaches.  The flip side was that the
> next
> > release cut was never more than 3 months away, making it more
> palatable to
> > delay features to the next release for the greater good.
> >
> > I am concerned about reneging on this promise so close to a date that
> > developers have already been planning around.  Develop has seen 259
> commits
> > since support/1.13 was cut, which is a full release worth.  Some
> feature
> > work such as geode-redis is eagerly anticipating a prompt branch cut
> and
> > swift release thereafter.
> >
> > Are you proposing to abandon time-based release cadence entirely?
> If not,
> > can you provide more detail on the new schedule you are envisioning
> (e.g.
> > still 4x/yr, but shifted out by a month? Or move to 3x/yr, starting
> by
> > delaying 1.14 by a month?).
> >
> > I don't know if this is the forum to reflect on *why* it takes so
> long to
> > stabilize from develop and get to something releasable, but if we
> accept
> > that the release process routinely takes 2-3 months (not the 1 month
> our
> > quarterly cadence was predicated on), then taking this opportunity
> to move
> > to a 3x/year cadence might be the smart play.
> >
> > -Owen
> >
> > On 7/20/20, 9:55 AM, "Donal Evans"  wrote:
> >
> > +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 rolled right
> into
> > 1.14 without time to breathe and hopefully ramp up some more people
> to take
> > over parts of the release process.
> >
> > I'm also not in favour of abandoning 1.13 entirely, as there's
> been a
> > huge effort on the part of some community members to get it in

Re: [Discuss] Cutting Geode 1.14

[Alexander Murmann]

Hi Owen,

I am not proposing to abandon our time-based releases. It's unprecedented
for one of our releases to take this long. Even if we were to cut the
release now, it would likely not receive any attention till 1.13 is out. So
I don't think there is any benefit in cutting the release now. In addition
there are all the downsides, I discussed above that are unique to this
situation.


An aside:

> [..] developers will hold off on high-risk changes and focus more on
> hardening as the cut date approaches.
>
 To me that wasn't ever part of the reason for timed releases, but
predictability for users and for developers to know by when features need
to be done to ship. If we feel a change is risky, let's write tests till we
feel it's safe.



On Mon, Jul 20, 2020 at 12:19 PM Owen Nichols  wrote:

> The Geode community adopted a time-based quarterly cadence two years ago
> in the hope it would lead to higher stability and more predictable
> releases.  The idea was that by knowing exactly when a branch cut is
> upcoming, developers will hold off on high-risk changes and focus more on
> hardening as the cut date approaches.  The flip side was that the next
> release cut was never more than 3 months away, making it more palatable to
> delay features to the next release for the greater good.
>
> I am concerned about reneging on this promise so close to a date that
> developers have already been planning around.  Develop has seen 259 commits
> since support/1.13 was cut, which is a full release worth.  Some feature
> work such as geode-redis is eagerly anticipating a prompt branch cut and
> swift release thereafter.
>
> Are you proposing to abandon time-based release cadence entirely?  If not,
> can you provide more detail on the new schedule you are envisioning (e.g.
> still 4x/yr, but shifted out by a month? Or move to 3x/yr, starting by
> delaying 1.14 by a month?).
>
> I don't know if this is the forum to reflect on *why* it takes so long to
> stabilize from develop and get to something releasable, but if we accept
> that the release process routinely takes 2-3 months (not the 1 month our
> quarterly cadence was predicated on), then taking this opportunity to move
> to a 3x/year cadence might be the smart play.
>
> -Owen
>
> On 7/20/20, 9:55 AM, "Donal Evans"  wrote:
>
> +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 rolled right into
> 1.14 without time to breathe and hopefully ramp up some more people to take
> over parts of the release process.
>
> I'm also not in favour of abandoning 1.13 entirely, as there's been a
> huge effort on the part of some community members to get it into a good
> state to release, and dropping 1.13 now would effectively be seeing all
> that work go to waste. It also wouldn't address the core issue that those
> most heavily involved in the release process and in identifying and
> addressing potential release blockers are in danger of being exhausted by
> the non-stop process of finding and fixing bugs in the release, since 1.14
> will have all of the same blockers that 1.13 currently has, plus an
> undetermined number of additional ones that we may not know about yet.
> 
> From: Jacob Barrett 
> Sent: Monday, July 20, 2020 9:38 AM
> To: dev@geode.apache.org 
> Subject: Re: [Discuss] Cutting Geode 1.14
>
> Alternatively, why not abandon 1.13 and try again with 1.14?
>
> > On Jul 20, 2020, at 9:21 AM, Alexander Murmann 
> wrote:
> >
> > Hi everyone,
> >
> > TL;DR: Let's discuss 1.14 once 1.13 is out.
> >
> > If we stick to our cadence of cutting a release every 3 months and
> shipping
> > it 1 month later, 1.14 is due to be cut two weeks from today.
> However, we
> > haven't shipped 1.13 yet and are still struggling with some issues.
> >
> > I suggest that we postpone cutting the 1.14 release till we've
> actually
> > shipped 1.13. Once we've shipped 1.13, we should have another
> conversation
> > about timing of 1.14. I know the 1.13 release has been taxing on many
> > people in our community and we might want to consider giving
> ourselves a
> > little bit of a gap between releases.
>
>
>

Re: [Discuss] Cutting Geode 1.14

[Alexander Murmann]

I think re-cutting 1.13 from current develop is interesting, but I think I
agree with Donal that the amount of additional risk might not be worth it.
Geode 1.13 already has some cool new features like SNI support that I
believe some users have been waiting for and I'd hate to not get that out
for another 2 months.

It also would be nice to get something out and get a little bit of a
breather, rather than running the risk of another 2 months of full-steam.

On Mon, Jul 20, 2020 at 9:55 AM Donal Evans  wrote:

> +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 rolled right into
> 1.14 without time to breathe and hopefully ramp up some more people to take
> over parts of the release process.
>
> I'm also not in favour of abandoning 1.13 entirely, as there's been a huge
> effort on the part of some community members to get it into a good state to
> release, and dropping 1.13 now would effectively be seeing all that work go
> to waste. It also wouldn't address the core issue that those most heavily
> involved in the release process and in identifying and addressing potential
> release blockers are in danger of being exhausted by the non-stop process
> of finding and fixing bugs in the release, since 1.14 will have all of the
> same blockers that 1.13 currently has, plus an undetermined number of
> additional ones that we may not know about yet.
> 
> From: Jacob Barrett 
> Sent: Monday, July 20, 2020 9:38 AM
> To: dev@geode.apache.org 
> Subject: Re: [Discuss] Cutting Geode 1.14
>
> Alternatively, why not abandon 1.13 and try again with 1.14?
>
> > On Jul 20, 2020, at 9:21 AM, Alexander Murmann 
> wrote:
> >
> > Hi everyone,
> >
> > TL;DR: Let's discuss 1.14 once 1.13 is out.
> >
> > If we stick to our cadence of cutting a release every 3 months and
> shipping
> > it 1 month later, 1.14 is due to be cut two weeks from today. However, we
> > haven't shipped 1.13 yet and are still struggling with some issues.
> >
> > I suggest that we postpone cutting the 1.14 release till we've actually
> > shipped 1.13. Once we've shipped 1.13, we should have another
> conversation
> > about timing of 1.14. I know the 1.13 release has been taxing on many
> > people in our community and we might want to consider giving ourselves a
> > little bit of a gap between releases.
>
>

-- 
Alexander J. Murmann
(650) 283-1933

[Discuss] Cutting Geode 1.14

[Alexander Murmann]

Hi everyone,

TL;DR: Let's discuss 1.14 once 1.13 is out.

If we stick to our cadence of cutting a release every 3 months and shipping
it 1 month later, 1.14 is due to be cut two weeks from today. However, we
haven't shipped 1.13 yet and are still struggling with some issues.

I suggest that we postpone cutting the 1.14 release till we've actually
shipped 1.13. Once we've shipped 1.13, we should have another conversation
about timing of 1.14. I know the 1.13 release has been taxing on many
people in our community and we might want to consider giving ourselves a
little bit of a gap between releases.

Re: Odg: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

[Alexander Murmann]

Thanks for looking into this, Mario!

You are probably right, that the underlying issue might have been
pre-existing and that the test is surfacing it. I am glad though that you
are investigating, because a close to 30% fail rate is a problem. Something
like this happens every once in a while and then someone has to do some
work to resolve historical problems that they hadn't planned to addres.

Thanks!

On Tue, Jul 14, 2020 at 1:06 AM Mario Ivanac  wrote:

> Hi,
>
> after adding additional checks in failing test, now I can see that test
> are failing due to fault that some batch are distributed at stopping of GW
> sender.
> Cause of that, I suspect that this problem existed prior to this PR, but
> this PR is first to introduce test to check this.
>
> I will continue to investigate this fault, but I can not locally reproduce
> this fault, so this is slowing troubleshooting.
>
> BR,
> Mario
> ________
> Šalje: Alexander Murmann 
> Poslano: 14. srpnja 2020. 1:11
> Prima: Alexander Murmann 
> Kopija: dev@geode.apache.org ; Mario Ivanac
> 
> Predmet: Re: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes
>
> We continue to see these WAN tests adding a fail rate of just below 30% in
> our mass test runs
> <
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/create-mass-test-run-report/builds/10
> >
> .
>
> That's a very significant fail rate that impacts our ability to get our
> code committed with confidence.
>
> Can we resolve this issue? Otherwise, I think we need to consider reverting
> GEODE-7458.
>
> On Fri, Jun 19, 2020 at 3:28 PM Alexander Murmann 
> wrote:
>
> > Looking more into this, it looks like this was introduced by the changes
> > for GEODE-7458 - "Adding additional option in gfsh command "start gateway
> > sender" to control clearing of existing queues".
> >
> > That happened about a month ago, but it's inherent to those flaky tests
> > that we discover them only after a while. Nonetheless, they become paper
> > cuts that ultimately slow us down substantially if they persist.
> >
> > @Mario Ivanac If I am correct and GEODE-7458 introduced this you were the
> > one making that change. Might you be able to take a look at making that
> > test more reliable or reverting the change?
> >
> > Thank you!
> >
> > On Fri, Jun 19, 2020 at 7:57 AM Alexander Murmann 
> > wrote:
> >
> >> Thank you so much for sharing this, Mark!
> >>
> >> It looks like there is a big cluster around WAN Gateway. Is anyone
> >> already looking into the WAN issues?
> >>
> >> On Thu, Jun 18, 2020 at 10:06 PM Mark Hanson 
> wrote:
> >>
> >>> FYI, the build success rate was around 90% or so about two months ago.
> >>>
> >>> Here are the DUnit tests that are currently failing in our tests, most
> >>> likely in CI, and PR pipelines.
> >>>
> >>> Please let me know if you have any questions.
> >>>
> >>> Thanks,
> >>> Mark
> >>>
> >>>
> >>>
> >>>
> ***
> >>>
> >>>  Overall build success rate: 78.0% (156 of 200)
> >>>
> >>>
> >>>
> ***
> >>>
> >>>
> >>>
> >>> The following test methods see failures in more than one class.  There
> >>> may be a failing *TestBase class
> >>>
> >>>
> >>>
> >>>
> *.testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived:
> >>> 12 failures :
> >>>
> >>>   SerialWANPersistenceEnabledGatewaySenderDUnitTest:  8 failures
> >>> (96.000% success rate)
> >>>
> >>>   SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest:  4 failures
> >>> (98.000% success rate)
> >>>
> >>>
> >>>
> >>>
> *.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived:
> >>> 12 failures :
> >>>
> >>>   ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest:  5
> >>> failures (97.500% success rate)
> >>>
> >>>   ParallelWANPersistenceEnabledGatewaySenderDUnitTest:  7 failures
> >>> (96.500% success rate)
> >>>
> >>>
> >>>
> >>> *.testPingWrongServe

Re: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

[Alexander Murmann]

We continue to see these WAN tests adding a fail rate of just below 30% in
our mass test runs
<https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/create-mass-test-run-report/builds/10>
.

That's a very significant fail rate that impacts our ability to get our
code committed with confidence.

Can we resolve this issue? Otherwise, I think we need to consider reverting
GEODE-7458.

On Fri, Jun 19, 2020 at 3:28 PM Alexander Murmann 
wrote:

> Looking more into this, it looks like this was introduced by the changes
> for GEODE-7458 - "Adding additional option in gfsh command "start gateway
> sender" to control clearing of existing queues".
>
> That happened about a month ago, but it's inherent to those flaky tests
> that we discover them only after a while. Nonetheless, they become paper
> cuts that ultimately slow us down substantially if they persist.
>
> @Mario Ivanac If I am correct and GEODE-7458 introduced this you were the
> one making that change. Might you be able to take a look at making that
> test more reliable or reverting the change?
>
> Thank you!
>
> On Fri, Jun 19, 2020 at 7:57 AM Alexander Murmann 
> wrote:
>
>> Thank you so much for sharing this, Mark!
>>
>> It looks like there is a big cluster around WAN Gateway. Is anyone
>> already looking into the WAN issues?
>>
>> On Thu, Jun 18, 2020 at 10:06 PM Mark Hanson  wrote:
>>
>>> FYI, the build success rate was around 90% or so about two months ago.
>>>
>>> Here are the DUnit tests that are currently failing in our tests, most
>>> likely in CI, and PR pipelines.
>>>
>>> Please let me know if you have any questions.
>>>
>>> Thanks,
>>> Mark
>>>
>>>
>>>
>>> ***
>>>
>>>  Overall build success rate: 78.0% (156 of 200)
>>>
>>>
>>> ***
>>>
>>>
>>>
>>> The following test methods see failures in more than one class.  There
>>> may be a failing *TestBase class
>>>
>>>
>>>
>>> *.testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived:
>>> 12 failures :
>>>
>>>   SerialWANPersistenceEnabledGatewaySenderDUnitTest:  8 failures
>>> (96.000% success rate)
>>>
>>>   SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest:  4 failures
>>> (98.000% success rate)
>>>
>>>
>>>
>>> *.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived:
>>> 12 failures :
>>>
>>>   ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest:  5
>>> failures (97.500% success rate)
>>>
>>>   ParallelWANPersistenceEnabledGatewaySenderDUnitTest:  7 failures
>>> (96.500% success rate)
>>>
>>>
>>>
>>> *.testPingWrongServer:  4 failures :
>>>
>>>   ClientServerMiscSelectorDUnitTest:  3 failures (98.500% success rate)
>>>
>>>   ClientServerMiscDUnitTest:  1 failures (99.500% success rate)
>>>
>>>
>>>
>>>
>>> ***
>>>
>>>
>>>
>>>
>>>
>>> org.apache.geode.internal.cache.wan.serial.SerialWANPersistenceEnabledGatewaySenderDUnitTest:
>>> 8 failures (96.000% success rate)
>>>
>>>
>>>
>>>
>>>  
>>> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>>>
>>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3539
>>>
>>>
>>>  
>>> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>>>
>>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3526
>>>
>>>
>>>  
>>> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>>>
>>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3505
>>>
>>>
>>>  
>>> testReplicatedRegionPersistentWanGateway_

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

[Alexander Murmann]

While it's really late in the branch lifecycle and we should have shipped a
month ago, performance degradations are a no-go

+!

On Thu, Jul 9, 2020 at 8:00 AM Bruce Schuchardt  wrote:

> There are reports that SSL performance is off on the support/1.13 branch
> with respect to the support/1.12 branch,  but performance on develop okay.
> The only communications changes in develop that aren’t in 1.13 are those
> that fixed this long-standing bug, so I’d like to backport it to the 1.13
> branch.
>
> https://github.com/apache/geode/pull/5048
>
> The error was in the cluster communications message-streamer class that
> created some extra objects during message transmission.  The fix is small
> and has been, at this point, through many test iterations.
>

Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary gateway sender when the gateway sender is stopped

[Alexander Murmann]

Hi Alberto,

The timing on this RFC feels really tight. Would you be open to extending
this to next week?

On Wed, Jul 8, 2020 at 1:04 PM Eric Shu  wrote:

> I think the only case the memory issue occurred is when all gateway
> senders are stopped in the wan-site. Otherwise another member would assume
> to be the primary queue. No more events will be enqueued in
> tmpDroppedEvents on the member with original primary queue. (For parallel
> wan queue, I do not think stop one gateway queue is a valid case to
> support.)
>
> For all gateway senders are stopped case, no need to notify any other
> members in the wan site if the limit is reached. The tmpDroppedEvents is
> only used for remove events on the secondary queue. If no events are
> enqueued in the secondary queue, there is no need to add into
> tmpDroppedEvents at all. To me, it should be only used for limited events
> to be queued.
>
> Regards,
> Eric
> 
> From: Alberto Gomez 
> Sent: Wednesday, July 8, 2020 12:02 PM
> To: dev@geode.apache.org 
> Subject: Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the
> primary gateway sender when the gateway sender is stopped
>
> Thanks for your comments, Eric.
>
> Limiting the size of the queue would be a simple solution but I think it
> would pose several problems on the the one configuring and operating Geode:
>
>   *   How big should the queue be? Probably not easy to dimension. Should
> the limit by on the memory occupied by the elements or on the number of
> elements in the queue (in which case, depending on the size of the
> elements, the memory used could vary a lot)?
>   *   What  to do when the limit has been reached? how do we notify that
> it was reached, what to do afterwards, how would we know what dropped
> events did not make it to the queue but should have been removed from the
> secondary's queue...
>
> I think the solution proposed in the RFC is simple enough and also
> addresses a possible confusion with the semantics of the gateway sender
> stop command.
> Stopping a gateway sender currently makes that all events received while
> the sender is stopped are dropped; but at the same time, unlimited memory
> may be consumed by the dropped events. We could put a limit on the amount
> of memory used by the queued dropped events but what would be the point in
> the first place to store them if those events will not be sent to the
> remote site anyway?
> I would expect that after stopping a gateway sender no resources (or at
> least a minimal part) would be consumed by it. Otherwise we may as well not
> stop it or use the pause command depending on what we want to achieve.
>
> From what I have seen, queuing dropped events has its place while the
> gateway sender is starting and while it is stopping but if it is done in a
> sender to be started manually or in a manually stopped server it could
> provoke an unexpected memory exhaustion.
>
> I really think the solution proposed makes the behavior of the gateway
> sender command more logical.
>
> Best regards,
>
> Alberto
> 
> From: Eric Shu 
> Sent: Wednesday, July 8, 2020 7:32 PM
> To: dev@geode.apache.org 
> Subject: Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the
> primary gateway sender when the gateway sender is stopped
>
> It seems that I was not able to comment on the RFC in the wiki yet.
>
> Just try to find out if we have a simple solution for the issue you raised
> -- can we have a up-limit for the tmpDroppedEvents queue in question?
>
> Always check the limit before adding to the queue -- so that the tmp queue
> is not unbound?
>
> Regards,
> Eric
> 
> From: Alberto Gomez 
> Sent: Monday, July 6, 2020 8:24 AM
> To: geode 
> Subject: [DISCUSS] RFC - Avoid the queueing of dropped events by the
> primary gateway sender when the gateway sender is stopped
>
> Hi,
>
> I have published a new RFC in the Apache Geode wiki with the following
> title: "Avoid the queueing of dropped events by the primary gateway sender
> when the gateway sender is stopped".
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAvoid%2Bthe%2Bqueuing%2Bof%2Bdropped%2Bevents%2Bby%2Bthe%2Bprimary%2Bgateway%2Bsender%2Bwhen%2Bthe%2Bgateway%2Bsender%2Bis%2Bstoppeddata=02%7C01%7Ceshu%40vmware.com%7C82aeb2f0bd30435131bd08d8237173c3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298317468898044sdata=ihK%2BeTvnhiA0XXcw22fv5VjjgzjYL2EQwL5%2Fe0KK%2F08%3Dreserved=0
>
> Could you please give comments by Thursday, July 9th, 2020?
>
> Thanks in advance,
>
> Alberto G.
>

Our Slack channel

[Alexander Murmann]

Hi community,

For some of our coordination efforts, like release status updates,
coordination of flaky tests or collective debugging of some issues a more
synchronous medium might be useful. We've had an Apache Geode Slack channel
for a long time, but never used it much. I wonder if it would be worthwhile
to revive it.

I will start an effort to post updates on the current release status and
reliability of our test suite in the channel.

If you do have an Apache email address, you can follow this link
 and sign up with
your Apache email address by following the "create an account" flow below
the form.
If you don't have a Apache email address, you can use this link:
http://s.apache.org/slack-invite

See you all there!

This week's mass-test run results

[Alexander Murmann]

Hi everyone,

Just like Mark did two weeks ago, I'd like to bring some attention to our
mass test runs. These now run in the pipeline

once a week. The results should typically be available on Tuesdays.

*Context*
Some context since we only recently started running these in our pipeline:
In the past we've seen the number of flaky tests, in particular among our
DUnite tests, grow over time. This would eventually lead to death by
thousand paper cuts when trying to merge a PR. The increased noise in our
test suite also gives room for new signals about actual bugs to hide in. In
past efforts to combat the flakiness of our test suite we have found that
running the tests many times against a non-broken SHA gave us great data to
identify which tests contribute most flakiness to the test suite.

*How does this week look?*
This week

doesn't look much different than last week. We got a 78% pass-rate

The test with the single highest fail rate
remains org.apache.geode.management.JMXMBeanReconnectDUnitTest with a fail
rate of 4.5%. I believe Kirk had been working on this for a prolonged time.
Kirk, is this still on your radar?

The other big issue remains a cluster of issues around WAN Gateway that
caused 18 of the total 44 failures we saw in our 200 runs
I believe the WAN test issues got introduced fairly recently by GEODE-7458.

If we got just the JMXMBean issue and the WAN tests addressed, our fail
rate should go back to well above 90% which would be a big win

Re: Fate of master branch

[Alexander Murmann]

+1 to deleting. Given we tag everything properly on the other branches, I
don't see the need for it either.

On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes
 wrote:

> +1 for deleting master branch. An also for updating the wiki page about
> branching that Alberto pointed out.
> 
> De: Bruce Schuchardt 
> Enviado: viernes, 26 de junio de 2020 17:37
> Para: dev@geode.apache.org 
> Asunto: Re: Fate of master branch
>
> Let's just delete it.  I need to do that in my own repos as well.
>
> On 6/26/20, 8:05 AM, "Blake Bender"  wrote:
>
> Apologies if this has been addressed already and I missed it.  In
> keeping with other OSS projects, I believe it’s time we did something about
> removing the insensitive term master from Geode repositories.
>
> One choice a lot of projects appear to be going with is a simple
> rename from master • main.  In our own case, however, master isn’t really
> in use for anything vital.  We track releases with a tag and a branch to
> backport fixes to, and the develop branch is the “source of truth”
> latest-and-greatest version of the code.  We could thus simply delete
> master with no loss I’m aware of.  Any opinions?
>
> Thanks,
>
> Blake
>
>
>

Re: JIRA access

[Alexander Murmann]

Hi Louis,

You should have access now

Please let me know if you need any further help

On Mon, Jun 22, 2020 at 10:33 AM Louis Jacome  wrote:

> Hello,
>
> I am emailing to request access to the Geode project, I have a personal
> account registered under louisjac...@gmail.com that I would like granted
> access. Please let me know if there's anything else you need.
>
> Thanks!
>Louis
>

Re: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

[Alexander Murmann]

Looking more into this, it looks like this was introduced by the changes
for GEODE-7458 - "Adding additional option in gfsh command "start gateway
sender" to control clearing of existing queues".

That happened about a month ago, but it's inherent to those flaky tests
that we discover them only after a while. Nonetheless, they become paper
cuts that ultimately slow us down substantially if they persist.

@Mario Ivanac If I am correct and GEODE-7458 introduced this you were the
one making that change. Might you be able to take a look at making that
test more reliable or reverting the change?

Thank you!

On Fri, Jun 19, 2020 at 7:57 AM Alexander Murmann 
wrote:

> Thank you so much for sharing this, Mark!
>
> It looks like there is a big cluster around WAN Gateway. Is anyone already
> looking into the WAN issues?
>
> On Thu, Jun 18, 2020 at 10:06 PM Mark Hanson  wrote:
>
>> FYI, the build success rate was around 90% or so about two months ago.
>>
>> Here are the DUnit tests that are currently failing in our tests, most
>> likely in CI, and PR pipelines.
>>
>> Please let me know if you have any questions.
>>
>> Thanks,
>> Mark
>>
>>
>>
>> ***
>>
>>  Overall build success rate: 78.0% (156 of 200)
>>
>>
>> ***
>>
>>
>>
>> The following test methods see failures in more than one class.  There
>> may be a failing *TestBase class
>>
>>
>>
>> *.testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived:
>> 12 failures :
>>
>>   SerialWANPersistenceEnabledGatewaySenderDUnitTest:  8 failures (96.000%
>> success rate)
>>
>>   SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest:  4 failures
>> (98.000% success rate)
>>
>>
>>
>> *.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived:
>> 12 failures :
>>
>>   ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest:  5 failures
>> (97.500% success rate)
>>
>>   ParallelWANPersistenceEnabledGatewaySenderDUnitTest:  7 failures
>> (96.500% success rate)
>>
>>
>>
>> *.testPingWrongServer:  4 failures :
>>
>>   ClientServerMiscSelectorDUnitTest:  3 failures (98.500% success rate)
>>
>>   ClientServerMiscDUnitTest:  1 failures (99.500% success rate)
>>
>>
>>
>>
>> ***
>>
>>
>>
>>
>>
>> org.apache.geode.internal.cache.wan.serial.SerialWANPersistenceEnabledGatewaySenderDUnitTest:
>> 8 failures (96.000% success rate)
>>
>>
>>
>>
>>  
>> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3539
>>
>>
>>  
>> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3526
>>
>>
>>  
>> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3505
>>
>>
>>  
>> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3435
>>
>>
>>  
>> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3414
>>
>>
>>  
>> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3391
>>
>>
>>  
>> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedT

Re: [INFO] Latest test run of 200 DistributedTestOpenJDK8 passes

[Alexander Murmann]

Thank you so much for sharing this, Mark!

It looks like there is a big cluster around WAN Gateway. Is anyone already
looking into the WAN issues?

On Thu, Jun 18, 2020 at 10:06 PM Mark Hanson  wrote:

> FYI, the build success rate was around 90% or so about two months ago.
>
> Here are the DUnit tests that are currently failing in our tests, most
> likely in CI, and PR pipelines.
>
> Please let me know if you have any questions.
>
> Thanks,
> Mark
>
>
>
> ***
>
>  Overall build success rate: 78.0% (156 of 200)
>
>
> ***
>
>
>
> The following test methods see failures in more than one class.  There may
> be a failing *TestBase class
>
>
>
> *.testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived:
> 12 failures :
>
>   SerialWANPersistenceEnabledGatewaySenderDUnitTest:  8 failures (96.000%
> success rate)
>
>   SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest:  4 failures
> (98.000% success rate)
>
>
>
> *.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived:
> 12 failures :
>
>   ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest:  5 failures
> (97.500% success rate)
>
>   ParallelWANPersistenceEnabledGatewaySenderDUnitTest:  7 failures
> (96.500% success rate)
>
>
>
> *.testPingWrongServer:  4 failures :
>
>   ClientServerMiscSelectorDUnitTest:  3 failures (98.500% success rate)
>
>   ClientServerMiscDUnitTest:  1 failures (99.500% success rate)
>
>
>
>
> ***
>
>
>
>
>
> org.apache.geode.internal.cache.wan.serial.SerialWANPersistenceEnabledGatewaySenderDUnitTest:
> 8 failures (96.000% success rate)
>
>
>
>
>  
> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3539
>
>
>  
> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3526
>
>
>  
> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3505
>
>
>  
> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3435
>
>
>  
> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3414
>
>
>  
> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3391
>
>
>  
> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3363
>
>
>  
> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3359
>
>
>
> org.apache.geode.management.MemberMXBeanDistributedTest:  2 failures
> (99.000% success rate)
>
>
>
>  testBucketCount
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3463
>
>  testBucketCount
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3411
>
>
>
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart3DUnitTest:
> 1 failures (99.500% success rate)
>
>
>
>  testRegisterInterestAndMakePrimaryWithFullRedundancy
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3381
>
>
>
> org.apache.geode.management.internal.cli.commands.QueryCommandOverHttpDUnitTest:
> 1 failures (99.500% success rate)
>
>
>
>  testSimpleQueryOnLocator
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/3516
>
>
>
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTest:  1
> failures (99.500% success rate)
>
>
>
>  testPingWrongServer
> 

Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

[Alexander Murmann]

+1 to avoiding clutter by not using feature branches on the Geode repo.

Sharing your own repo, as Kirk suggests, also works better when
collaborating with folks who aren't committers.

On Tue, Jun 2, 2020 at 4:16 PM Kirk Lund  wrote:

> I prefer to share a fork among multiple developers instead of using the
> Apache Geode repository.
>
> On Tue, Jun 2, 2020 at 3:42 PM Jacob Barrett  wrote:
>
> > I know this has been brought up multiple times without resolution. I want
> > us resolve to ban the use of Geode repository for work in progress,
> feature
> > branches, or any other branches that are not release or support branches.
> > There is no reason given the nature of GitHub why you can’t fork the
> > repository to contribute.
> >
> > * Work done on these branches results in the ASF bots updating the
> > associated JIRAs and email blasting all of us with your work.
> >
> > * People don’t clean up these branches, which leads to a mess of branches
> > on everyones clones and in the UI.
> >
> > * All your intermediate commits get synced to the repo, which bloats the
> > repo for everyone else. Even your commits you rebase over and force push
> > are left in the repo. When you delete your branch these commits are not
> > removed. There is no way for us to prune unreferenced commits. Nobody
> else
> > needs your commits outside of what was merged to a production branch.
> >
> > If anyone has a use case for working directly from Geode repo that can’t
> > work from a fork please post it here so we can resolve.
> >
> > Thanks,
> > Jake
> >
> >
> >
> >
>

Re: [DISCUSS] Adding Google Analytics to our website

[Alexander Murmann]

Anthony, thank you for looking into this! Did you have any luck recovering
the account?

On Mon, May 4, 2020 at 12:04 PM Anthony Baker  wrote:

>  We may be able to use the account from the ApacheGeode YouTube channel.
> If not, I would suggest creating a google account whose creds are managed
> by the PMC.
>
> Anthony
>
>
> > On May 4, 2020, at 11:57 AM, Alexander Murmann 
> wrote:
> >
> > Seems like nobody has objections to adding this.
> >
> > Google Analytics requires a Google account. Does is work if I create this
> > with my own Google account and add anyone interested or is there a better
> > solution?
> >
> > @Charlie: Yes, that would be great as well!
> >
> > On Wed, Apr 8, 2020 at 6:52 PM Charlie Black  wrote:
> >
> >> If we could add page analytics on docs and other pages that would
> awesome.
> >>  That would allow us to create focused content blogs, videos, investment
> >> on those pages where we find the hottest views.
> >>
> >> Charlie
> >>
> >> On Wed, Apr 8, 2020 at 2:08 PM Bob Glithero
> 
> >> wrote:
> >>
> >>> Hi All,
> >>>
> >>> Hopefully it's ok for me to add my $.02 here.  While understanding
> where
> >>> the traffic is coming from is always helpful, it's possible to take a
> >> more
> >>> active approach to driving traffic.  I also help with community
> marketing
> >>> at RabbitMQ (rabbitmq.com), which uses their platform to host
> tutorials,
> >>> best practices, and other content.  I could find $$$ in my budget to
> help
> >>> modernize the Geode site and make it more generally useful as a content
> >>> platform for developers and others interested in the project.
> >>>
> >>> Bob
> >>>
> >>> On 4/8/20, 1:59 PM, "Alexander Murmann"  wrote:
> >>>
> >>>Hi Michael,
> >>>
> >>>A few things I'd like to know and potential associated actions:
> >>>* Where do our visitors come from (referrer)? -> We might be able to
> >>> lean
> >>>in to those sources.
> >>>* Are we getting any traffic from our Twitter presence? -> If
> certain
> >>>tweets bring more traffic, let's do more of tweets like it!
> >>>* Some people in our community started blogging more. Are we seeing
> >> any
> >>>traffic from that? Are some topics driving more traffic than others
> >> ->
> >>>Might inform what topics or types of articles we should write more
> or
> >>> less
> >>>off.
> >>>
> >>>
> >>>On Wed, Apr 8, 2020 at 9:18 AM Michael Oleske 
> >>> wrote:
> >>>
> >>>> What things are we looking to learn?  Without knowing what we are
> >>>> interested in learning I would be hesitant to add anything.  If we
> >>> know
> >>>> what we want to learn then a conversation about analytics would be
> >>> more
> >>>> fruitful (to me at least)
> >>>>
> >>>> -michael
> >>>>
> >>>>
> >>>> On Tue, Apr 7, 2020 at 3:31 PM Alexander Murmann <
> >>> amurm...@apache.org>
> >>>> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> In promoting our project it might be valuable to get a better
> >> idea
> >>> of
> >>>> where
> >>>>> visitors on our website come from, what they look for and where
> >> we
> >>> lose
> >>>>> them. This should help us improve the website and learn what kind
> >>> of
> >>>> blogs
> >>>>> articles, videos etc. drive user interest to the website.
> >>>>>
> >>>>> To gain those insights I'd like to add Google Analytics (GA).
> >>> While GA
> >>>>> isn't open source, it is commonly used by other Apache projects.
> >>> Apache
> >>>>> Cassandra, Kafka, Samza and Spark all have GA trackers on their
> >>> website.
> >>>>>
> >>>>> I've heard rumors that we at some point had it on our website as
> >>> well. Is
> >>>>> this true? If so, why did we remove it?
> >>>>>
> >>>>> Thank you for your thoughts and concerns!
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >> Charlie Black | cbl...@pivotal.io
> >>
>
>

-- 
Alexander J. Murmann
(650) 283-1933

Re: [DISCUSS] Adding Google Analytics to our website

[Alexander Murmann]

Seems like nobody has objections to adding this.

Google Analytics requires a Google account. Does is work if I create this
with my own Google account and add anyone interested or is there a better
solution?

@Charlie: Yes, that would be great as well!

On Wed, Apr 8, 2020 at 6:52 PM Charlie Black  wrote:

> If we could add page analytics on docs and other pages that would awesome.
>   That would allow us to create focused content blogs, videos, investment
> on those pages where we find the hottest views.
>
> Charlie
>
> On Wed, Apr 8, 2020 at 2:08 PM Bob Glithero 
> wrote:
>
> > Hi All,
> >
> > Hopefully it's ok for me to add my $.02 here.  While understanding where
> > the traffic is coming from is always helpful, it's possible to take a
> more
> > active approach to driving traffic.  I also help with community marketing
> > at RabbitMQ (rabbitmq.com), which uses their platform to host tutorials,
> > best practices, and other content.  I could find $$$ in my budget to help
> > modernize the Geode site and make it more generally useful as a content
> > platform for developers and others interested in the project.
> >
> > Bob
> >
> > On 4/8/20, 1:59 PM, "Alexander Murmann"  wrote:
> >
> > Hi Michael,
> >
> > A few things I'd like to know and potential associated actions:
> > * Where do our visitors come from (referrer)? -> We might be able to
> > lean
> > in to those sources.
> > * Are we getting any traffic from our Twitter presence? -> If certain
> > tweets bring more traffic, let's do more of tweets like it!
> > * Some people in our community started blogging more. Are we seeing
> any
> > traffic from that? Are some topics driving more traffic than others
> ->
> > Might inform what topics or types of articles we should write more or
> > less
> > off.
> >
> >
> > On Wed, Apr 8, 2020 at 9:18 AM Michael Oleske 
> > wrote:
> >
> > > What things are we looking to learn?  Without knowing what we are
> > > interested in learning I would be hesitant to add anything.  If we
> > know
> > > what we want to learn then a conversation about analytics would be
> > more
> > > fruitful (to me at least)
> > >
> > > -michael
> > >
> > >
> > > On Tue, Apr 7, 2020 at 3:31 PM Alexander Murmann <
> > amurm...@apache.org>
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > In promoting our project it might be valuable to get a better
> idea
> > of
> > > where
> > > > visitors on our website come from, what they look for and where
> we
> > lose
> > > > them. This should help us improve the website and learn what kind
> > of
> > > blogs
> > > > articles, videos etc. drive user interest to the website.
> > > >
> > > > To gain those insights I'd like to add Google Analytics (GA).
> > While GA
> > > > isn't open source, it is commonly used by other Apache projects.
> > Apache
> > > > Cassandra, Kafka, Samza and Spark all have GA trackers on their
> > website.
> > > >
> > > > I've heard rumors that we at some point had it on our website as
> > well. Is
> > > > this true? If so, why did we remove it?
> > > >
> > > > Thank you for your thoughts and concerns!
> > > >
> > >
> >
> >
> > --
> Charlie Black | cbl...@pivotal.io
>

Re: [DISCUSS] Adding Google Analytics to our website

[Alexander Murmann]

Hi Michael,

A few things I'd like to know and potential associated actions:
* Where do our visitors come from (referrer)? -> We might be able to lean
in to those sources.
* Are we getting any traffic from our Twitter presence? -> If certain
tweets bring more traffic, let's do more of tweets like it!
* Some people in our community started blogging more. Are we seeing any
traffic from that? Are some topics driving more traffic than others ->
Might inform what topics or types of articles we should write more or less
off.


On Wed, Apr 8, 2020 at 9:18 AM Michael Oleske  wrote:

> What things are we looking to learn?  Without knowing what we are
> interested in learning I would be hesitant to add anything.  If we know
> what we want to learn then a conversation about analytics would be more
> fruitful (to me at least)
>
> -michael
>
>
> On Tue, Apr 7, 2020 at 3:31 PM Alexander Murmann 
> wrote:
>
> > Hi all,
> >
> > In promoting our project it might be valuable to get a better idea of
> where
> > visitors on our website come from, what they look for and where we lose
> > them. This should help us improve the website and learn what kind of
> blogs
> > articles, videos etc. drive user interest to the website.
> >
> > To gain those insights I'd like to add Google Analytics (GA). While GA
> > isn't open source, it is commonly used by other Apache projects. Apache
> > Cassandra, Kafka, Samza and Spark all have GA trackers on their website.
> >
> > I've heard rumors that we at some point had it on our website as well. Is
> > this true? If so, why did we remove it?
> >
> > Thank you for your thoughts and concerns!
> >
>

[DISCUSS] Adding Google Analytics to our website

[Alexander Murmann]

Hi all,

In promoting our project it might be valuable to get a better idea of where
visitors on our website come from, what they look for and where we lose
them. This should help us improve the website and learn what kind of blogs
articles, videos etc. drive user interest to the website.

To gain those insights I'd like to add Google Analytics (GA). While GA
isn't open source, it is commonly used by other Apache projects. Apache
Cassandra, Kafka, Samza and Spark all have GA trackers on their website.

I've heard rumors that we at some point had it on our website as well. Is
this true? If so, why did we remove it?

Thank you for your thoughts and concerns!

Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property

[Alexander Murmann]

I am not sure I am following the argument for removal in a minor version.
Let's expand the argument and make sure we are all basing this on the same
assumptions:

Java has removed insecure encryption algorithms in patch releases. This was
presumably done because it's really fixing a vulnerability, rather than
removing a useful feature.

Are we in agreement that the UDP encryption as it currently exists does not
deliver on providing security for data in transit? Bill's original
description to me indicates that there are problems with the current
implementation, but not that it creates a false sense of security. There
seem to exist some intuitions around this, but in order to make the right
call for our users, we might want to make that more concrete. It would be
unfortunate to break the promises we make via SemVer unintentionally.

On Mon, Mar 2, 2020 at 11:38 AM Udo Kohlmeyer  wrote:

> I'm back tracking on my suggestion... Got stuck on the "removal" part.
>
> +1 -> for deprecation for said feature in 1.12
>
> -1 -> for removal until alternative/equivalent replacement has been
> added (or major version release -- which ever comes first)
>
> @Dan, are you thinking that secured intra-cluster communication needs to
> be deprecated as a whole?
>
> --Udo
>
> On 3/2/20 10:52 AM, Anthony Baker wrote:
> > I don’t think regressed is the right word.  There was an effort to
> harden our udp p2p traffic using encryption based on a DH key exchange.
> I’m not clear on how much that approach actually improved the security of
> data in motion.  And I don’t believe it saw much if any use in practice.
> >
> > Anthony
> >
> >
> >> On Mar 2, 2020, at 10:27 AM, Udo Kohlmeyer 
> wrote:
> >>
> >> I think that if TCP connections are secured and UDP connections are
> not, then we've regressed in our security.
> >>
> >> Is there a way that we could use DTLS?
> >>
> >> --Udo
> >>
> >> On 3/2/20 10:21 AM, Dan Smith wrote:
> >>> Should we deprecate cluster ssl as well? Cluster ssl without udp
> encryption
> >>> means that not all P2P traffic will be encrypted. If we don't want to
> >>> support P2P encryption, it seems like we should deprecate both?
> >>>
> >>> -Dan
> >>>
> >>> On Fri, Feb 28, 2020 at 1:40 PM Udo Kohlmeyer 
> wrote:
> >>>
>  Yes, the proposal was deprecation notice in 1.12 and remove in 1.13..
> 
>  That does not leave users much time to react. So if we remove in 1.14,
>  then users have at least 2 release cycles before we do it.
> 
>  --Udo
> 
>  On 2/28/20 1:11 PM, Owen Nichols wrote:
> > Udo, are you proposing to deprecate in 1.12 and remove in 1.14?
> >
> >> On Feb 28, 2020, at 1:03 PM, Udo Kohlmeyer 
>  wrote:
> >> +1 to adding the deprecation. But I would prefer that we give users
>  more notice than 3 months.
> >> maybe we deprecate it in 1.14
> >>
> >> --Udo
> >>
> >> On 2/28/20 1:00 PM, Ernest Burghardt wrote:
> >>> +1
> >>>
> >>> seems reasonable to do this for 1.12 and be ahead of the game,
> @Owen
>  would
> >>> you please spawn that as a separate release 1.12 thread? thanks, eB
> >>>
> >>> On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols  >
>  wrote:
>  +1
> 
>  We should have done this as soon as SSL/TLS was ready.  Better
> late
>  than
>  never!
> 
>  While we normally wait until a major release to remove deprecated
>  stuff,
>  there is some precedent for removing insecure encryption
> algorithms
>  sooner
>  (Java has done this even in patch releases).  We should consider
>  getting
>  the deprecation notice into 1.12 and removing in 1.13, rather than
>  waiting
>  for 2.0.
> 
> > On Feb 28, 2020, at 11:42 AM, Bill Burcham <
> bill.burc...@gmail.com>
>  wrote:
> > I propose we deprecate Geode’s proprietary UDP message privacy
>  algorithm
> > based on the Diffie-Hellman key exchange protocol. This would
>  deprecate:
> > ConfigurationProperties.SECURITY_UDP_DHALGO
> >
> > String DistributionConfig.getSecurityUDPDHAlgo()
> >
> > void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
> > DistributionConfig.SECURITY_UDP_DHALGO_NAME
> >
> > Additionally we’d have to upate documentation to reflect
> deprecation.
> >
> >   From ConfigurationProperties.java:
> >
> >
> > Application can set this property to valid symmetric key
> algorithm,
>  to
> > encrypt udp messages in Geode. Geode will generate symmetric key
>  using
> > Diffie-Hellman key exchange algorithm between peers. That key
> further
>  used
> > by specified algorithm to encrypt the udp messages.
> >
> > The property (and the feature) was added mid-2016. Unfortunately
> it
>  was
>  not
> > added as an 

Re: PR Titles

[Alexander Murmann]

>
> Don't we have a published checklist or guideline or something for this
> already?  Including stuff like 'always prefix the PR title with a JIRA
> ticket #,' etc?


Yes, we do. However, it only request the addition of the JIRA ticket #. It
does not call out having a descriptive title.

I like the idea of adding a point to the checklist to call this out.


On Mon, Mar 2, 2020 at 9:02 AM Blake Bender  wrote:

> Don't we have a published checklist or guideline or something for this
> already?  Including stuff like 'always prefix the PR title with a JIRA
> ticket #,' etc?
>
> On Mon, Mar 2, 2020 at 8:47 AM Owen Nichols  wrote:
>
> > +1
> >
> > It’s easy to fix too!
> >
> > On Mon, Mar 2, 2020 at 8:34 AM Jacob Barrett 
> wrote:
> >
> > > Please use meaningful PR titles. When browsing the PRs or reading the
> > > notifications, one shouldn’t have to decode your cryptic title.
> Consider
> > > the title as the first line of you commit message.
> > >
> > > -Jake
> > >
> > >
> >
>

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Alexander Murmann]

Hi John,

I think what you are calling out in 1. and 2. matches what was discussed in
the proposal and thread. Please call out if you disagree on a detail.

What's your reasoning behind 3?
I see little reason to ship a patch release (which is significant work) if
there was no important fix.
Likewise I am concerned about waiting to ship a critical fix to our users
or leave them with gaping security vulnerabilities when we have a fix, but
the next patch release train doesn't depart for several weeks.

On Tue, Feb 25, 2020 at 11:41 AM John Blum  wrote:

> Real quick thought... IMO:
>
> 1. There should be patch (maintenance) releases for each major.minor, up to
> N-2 for a set period of time (e.g. 1.5 years), or until N-2 becomes N-3
> where N-3 is no longer supported.
> 2. All important changes should be backported.  I say "important" loosely
> since that should be decided by the community, but in general, that means
> Blocker, Critical, Security fixes or other changes that can impact the
> contract, functionality or proper behavior of Apache Geode in whatever
> context.
> 3. Patch (maintenance) releases should occur at a regular, "predictable"
> intervals (e.g. every 6 weeks), not on an adhoc basis.
>
> $0.02
> -John
>
>
> On Tue, Feb 25, 2020 at 11:23 AM Alexander Murmann 
> wrote:
>
> > >
> > > Or, we could emphasize the shift in process with bigger changes:
> > > i. Instead of cutting "release/1.13.0" on May 4, we could instead cut
> > > "support/1.13"
> > > ii instead of creating "apache-release-1-13-0-main" pipeline, we would
> > > instead create "apache-release-1-13-main"
> > > iii. Instead of cleaning up the pipeline and branch after 1.13.0 was
> > > released, we could keep it around for 9 months and re-use it for
> > collecting
> > > patches and making patch releases during that time.
> > >
> > +1 I cannot see any argument against cutting a release branch for the
> minor
> > version and keeping it around.
> >
> > The community process around deciding how long to gather fixes before
> > > shipping a patch release isn’t any easier either way.
> >
> > How about we wait for someone to call out the need to ship a patch
> > release.  At
> > that point we use the rule of thumb "aim for no more than 1 patch release
> > per minor per month" to guide our community discussion.
> >
> > I would like to see more discussion on the community impact of increasing
> > > the commitment required of a release manager.  In the short term it
> would
> > > be good for Geode to have someone focused on improving the release
> > process
> > > for a longer period of time than a single release.  But in the long
> term,
> > > people may be less likely to volunteer, and release experience will be
> > > concentrated in fewer members of the community...
> >
> > Are there more things that could be automated? When I filled the role ~1
> > year ago there was lots of copying and pasting of scripts and I even
> wrote
> > one to help validate fixVersions. Although release process automation
> > should probably be taken to a different discussion, since it's mostly
> > separate form Anthony's proposal.
> >
> >
> > On Tue, Feb 25, 2020 at 11:06 AM Owen Nichols 
> wrote:
> >
> > > These concerns make sense.  We could satisfy them within our existing
> > > “on-demand” process:
> > >
> > > 1) the first time there is a change to backport to support branches,
> > > propose the patch release.  Now we have a branch.  Decide as a
> community
> > > how urgently it needs to be released vs how long to hold it open for
> > other
> > > potential fixes.
> > >
> > > Or, we could emphasize the shift in process with bigger changes:
> > > i. Instead of cutting "release/1.13.0" on May 4, we could instead cut
> > > "support/1.13"
> > > ii instead of creating "apache-release-1-13-0-main" pipeline, we would
> > > instead create "apache-release-1-13-main"
> > > iii. Instead of cleaning up the pipeline and branch after 1.13.0 was
> > > released, we could keep it around for 9 months and re-use it for
> > collecting
> > > patches and making patch releases during that time.
> > >
> > > The community process around deciding how long to gather fixes before
> > > shipping a patch release isn’t any easier either way.
> > >
> > > One advantage of our current process is that a release doesn’t happen
> > > 

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Alexander Murmann]

ring fixes to a
> dormant branch?  Are release branches separate from support branches?  How
> will committers be able to keep track of what is dormant and what is not?)
> >>
> >
> > Why not just either a) keep the release branch alive? Or b) create a
> support branch from the release tag?
> >
> >> To implement an N-2 support policy, does it make more sense for Geode
> to make small focused patch releases when needed, or to maintain what
> amounts to “3 develop branches at all times”?
> >>
> >
> > To me, “develop branch” implies ongoing work.  I’m proposing “support
> branch” which means only important changes agreed upon by the project
> community.
> >
> >
> >>
> >>> On Feb 24, 2020, at 11:00 AM, Alexander Murmann 
> wrote:
> >>>
> >>> Thanks for proposing this, Anthony!
> >>>
> >>>
> >>>> I don’t think it’s necessary for this proposal to re-define or clarify
> >>>> what constitutes a critical fix; it sounds like the bar would be the
> same
> >>>> as the standard we already apply when back-porting to release branches
> >>>> (proposal /w justification, and 3 votes in favor).  The only
> difference
> >>>> seems to be that now proposals may list up to three target branches,
> not
> >>>> just one.
> >>>>
> >>> re: Owen
> >>> TL;DR: +1 using the same process as we use for merging critical fixes
> >>> during an ongoing release seems appropriate.
> >>>
> >>> Generally merging a fix to a dormant release branch seems less
> problematic
> >>> than merging a fix to an active release branch where a merge will
> reset all
> >>> release work that has already happened. The cost of merging to a
> >>> dormant release branch is much lower than merging to one that's being
> >>> actively released. Ideally we could just do a PR to merge fixes back in
> >>> most cases. Unfortunately, I believe it's unreasonable to expect that
> >>> everyone will be aware at all times what's actively being released and
> >>> what's not => Let's pretend we are always shipping these branches.
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Feb 21, 2020 at 7:35 PM Owen Nichols 
> wrote:
> >>>
> >>>> Thank you Anthony for proposing this “N-2” support policy.  It isn’t
> a big
> >>>> change, but it is helpful to know that the Geode PMC will now be
> standing
> >>>> behind (and ready to vote on) patch releases within a 9-month window.
> >>>>
> >>>> Overall, this sounds much like how 1.9.1 and 1.9.2 started as
> community
> >>>> proposals, found a release manager, and went on to be successfully
> released.
> >>>>
> >>>> I don’t think it’s necessary for this proposal to re-define or clarify
> >>>> what constitutes a critical fix; it sounds like the bar would be the
> same
> >>>> as the standard we already apply when back-porting to release branches
> >>>> (proposal /w justification, and 3 votes in favor).  The only
> difference
> >>>> seems to be that now proposals may list up to three target branches,
> not
> >>>> just one.
> >>>>
> >>>> I also don’t think it’s necessary to alter our current process to
> maintain
> >>>> a standing "support/x.y" branch.  The proposal states that patch
> releases
> >>>> will be “ad-hoc (as needed)”.  Our current process serves this quite
> well:
> >>>> we propose a patch release at the time it is needed, then get a
> release
> >>>> manager and create a release branch specifically for that release
> (e.g.
> >>>> release/1.9.2 was created from the rel/v1.9.1 tag), then clean up
> >>>> afterwards so no unattended pipelines or branches linger.
> >>>>
> >>>> The rotating release manager role has been a hallmark of the Geode
> >>>> community process, so I hope this proposal will not dissuade anyone
> >>>> interested in helping with a release.  However, getting the automation
> >>>> improvements we need will require some continuity over several
> releases.  I
> >>>> would love to volunteer for this!
> >>>>
> >>>> -Owen
> >>>>
> >>>>> On Feb 21, 2020, at 5:30 PM, Anthony Baker 
> wrote:
> >>>>>
> >>>>> Hi everyone,
> >>>>>
> >>>>> I'd like to propose shipping patch releases of Geode as a way to
> >>>>> improve our engagement and support of our user community.  Please
> >>>>> review the details in the linked RFC [1] and kindly offer your
> >>>>> thoughts in this thread.
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Anthony
> >>>>>
> >>>>> [1]
> >>>>
> https://cwiki.apache.org/confluence/display/GEODE/Shipping+patch+releases
> >>>>
> >>>>
> >>
> >

Re: [DISCUSS] RFC: Shipping Geode patch releases

[Alexander Murmann]

Thanks for proposing this, Anthony!


> I don’t think it’s necessary for this proposal to re-define or clarify
> what constitutes a critical fix; it sounds like the bar would be the same
> as the standard we already apply when back-porting to release branches
> (proposal /w justification, and 3 votes in favor).  The only difference
> seems to be that now proposals may list up to three target branches, not
> just one.
>
re: Owen
TL;DR: +1 using the same process as we use for merging critical fixes
during an ongoing release seems appropriate.

Generally merging a fix to a dormant release branch seems less problematic
than merging a fix to an active release branch where a merge will reset all
release work that has already happened. The cost of merging to a
dormant release branch is much lower than merging to one that's being
actively released. Ideally we could just do a PR to merge fixes back in
most cases. Unfortunately, I believe it's unreasonable to expect that
everyone will be aware at all times what's actively being released and
what's not => Let's pretend we are always shipping these branches.




On Fri, Feb 21, 2020 at 7:35 PM Owen Nichols  wrote:

> Thank you Anthony for proposing this “N-2” support policy.  It isn’t a big
> change, but it is helpful to know that the Geode PMC will now be standing
> behind (and ready to vote on) patch releases within a 9-month window.
>
> Overall, this sounds much like how 1.9.1 and 1.9.2 started as community
> proposals, found a release manager, and went on to be successfully released.
>
> I don’t think it’s necessary for this proposal to re-define or clarify
> what constitutes a critical fix; it sounds like the bar would be the same
> as the standard we already apply when back-porting to release branches
> (proposal /w justification, and 3 votes in favor).  The only difference
> seems to be that now proposals may list up to three target branches, not
> just one.
>
> I also don’t think it’s necessary to alter our current process to maintain
> a standing "support/x.y" branch.  The proposal states that patch releases
> will be “ad-hoc (as needed)”.  Our current process serves this quite well:
> we propose a patch release at the time it is needed, then get a release
> manager and create a release branch specifically for that release (e.g.
> release/1.9.2 was created from the rel/v1.9.1 tag), then clean up
> afterwards so no unattended pipelines or branches linger.
>
> The rotating release manager role has been a hallmark of the Geode
> community process, so I hope this proposal will not dissuade anyone
> interested in helping with a release.  However, getting the automation
> improvements we need will require some continuity over several releases.  I
> would love to volunteer for this!
>
> -Owen
>
> > On Feb 21, 2020, at 5:30 PM, Anthony Baker  wrote:
> >
> > Hi everyone,
> >
> > I'd like to propose shipping patch releases of Geode as a way to
> > improve our engagement and support of our user community.  Please
> > review the details in the linked RFC [1] and kindly offer your
> > thoughts in this thread.
> >
> >
> > Thanks,
> > Anthony
> >
> > [1]
> https://cwiki.apache.org/confluence/display/GEODE/Shipping+patch+releases
>
>

Re: [Vote] Include GEODE-7752 into 1.12

[Alexander Murmann]

Thanks for the additional context, Udo! That makes a lot of sense.

I want to make sure we are very deliberate about including anything but a
critical fix in a release branch after it has been cut.

+1 to including Udo's change once we feel confident about the tests

On Wed, Feb 5, 2020 at 4:27 PM Jinmei Liao  wrote:

> Even though the management service is still marketed as "experimental" and
> we don't need to go through deprecations, I would still very much prefer
> this gets pulled into 1.12 so that users don't have to deal with
> experimental public API changes.
>
> On Wed, Feb 5, 2020 at 4:23 PM Udo Kohlmeyer  wrote:
>
> > @Alexander, I can most certainly elaborate more.
> >
> > In short, this refactor does not have to be in 1.12, but it does alter
> > public Builders and classes. Which means, that if we don't release it
> > with 1.12, we would have to go through the cycle of deprecation,etc. to
> > get this change in. Given that the initial GEODE-7715 ticket is not in
> > any released version of Geode, it would just simplify the process of not
> > having to go through unnecessary pain to simplify and make this process
> > more intuitive for users.
> >
> > Does this answer your question as to why?
> >
> > --Udo
> >
> >
> > On 2/5/20 3:01 PM, Alexander Murmann wrote:
> > > Udo, you say "refactor", but this sounds more like a feature or user
> > facing
> > > improvement. Do you mind elaborating a little more why this should be
> in
> > > this release?
> > >
> > > On Wed, Feb 5, 2020 at 1:54 PM Patrick Johnson
> > 
> > > wrote:
> > >
> > >> +1
> > >>
> > >> On 2/5/20, 1:53 PM, "Udo Kohlmeyer"  wrote:
> > >>
> > >>  Hi there Geode dev,
> > >>
> > >>  I would like to request that GEODE-7752
> > >>  (7028f601680fee3f57cbdff63951128d7180ca13) gets included into
> 1.12.
> > >>
> > >>  This piece of code is a refactor of work done in GEODE-7715. This
> > >>  refactor specializes Builders and simplifies Builder behavior for
> > >> better
> > >>  user experience.
> > >>
> > >>  --Udo
> > >>
> > >>
> > >>
> > >>
> >
>
>
> --
> Cheers
>
> Jinmei
>

Re: [Vote] Include GEODE-7752 into 1.12

[Alexander Murmann]

Udo, you say "refactor", but this sounds more like a feature or user facing
improvement. Do you mind elaborating a little more why this should be in
this release?

On Wed, Feb 5, 2020 at 1:54 PM Patrick Johnson 
wrote:

> +1
>
> On 2/5/20, 1:53 PM, "Udo Kohlmeyer"  wrote:
>
> Hi there Geode dev,
>
> I would like to request that GEODE-7752
> (7028f601680fee3f57cbdff63951128d7180ca13) gets included into 1.12.
>
> This piece of code is a refactor of work done in GEODE-7715. This
> refactor specializes Builders and simplifies Builder behavior for
> better
> user experience.
>
> --Udo
>
>
>
>

Re: [PROPOSAL]: Include GEODE-7728 in Release 1.12.0

[Alexander Murmann]

+1

On Wed, Feb 5, 2020 at 9:29 AM Udo Kohlmeyer  wrote:

> +1 - for inclusion
>
> On 2/5/20 4:22 AM, Ju@N wrote:
> > Hello devs,
> >
> > I'd like to include the fix for GEODE-7728 [1] in release 1.12.0.
> > The change is basically to avoid throwing an exception and return the
> > correct result whenever a query has more than one condition and one of
> them
> > compares two indexed fields.
> > This is not a new issue but it can be hit by any user under the
> conditions
> > I've mentioned, it is also considered critical for one of the customers I
> > work for, thus I'm eagerly asking to include the fix in the next release.
> > The SHA is 6e35c201ea605075433203d4e64ca887bafd8fcb [2].
> > Best regards.
> >
> > [1]: https://issues.apache.org/jira/browse/GEODE-7728
> > [2]:
> >
> https://github.com/apache/geode/commit/6e35c201ea605075433203d4e64ca887bafd8fcb
> >
>

Re: Old geode-benchmark PRs

[Alexander Murmann]

Donal, are you still looking at these? If they aren't ready to merge and
not being worked on, should they be closed?

On Wed, Jan 22, 2020 at 3:32 PM Donal Evans  wrote:

> Two of those PRs are mine, so perhaps I can give a bit of context for
> people who might look at them. The oldest of the two, "Feature/Add PdxType
> benchmark and additional framework flexibility" was an attempt to quantify
> and maintain the improvement in performance for PdxType creation when large
> numbers of PdxTypes already exist, and to allow the passing of additional
> system properties to the VMs hosting the servers in order to change the log
> level and prevent the benchmark measuring how long it takes to log PdxType
> creation rather than actual time taken to create new PdxTypes. This PR has
> been open for a very long time, so it's possible that the changes regarding
> passing additional system properties to the VMs are now outdated or
> unnecessary, but the actual benchmarks themselves still have some value.
>
> The second PR, "Added benchmarks for aggregate functions" contains 16 new
> benchmarks related to aggregate OQL queries, (8 each for Partitioned and
> Replicated regions), which were added following work in that area by the
> Commons team. The build is currently marked as failing, but this is due to
> a timeout rather than an actual build failure, as the number of benchmarks
> added increased the total time to build beyond the currently configured
> timeout. Adding such a large number of additional benchmarks will probably
> also noticeably increase the time it takes benchmarks to run, which bears
> consideration.
>
> I hope this helps shed some light for people who may look over those PRs.
>
> On Wed, Jan 22, 2020 at 11:36 AM Dan Smith  wrote:
>
> > Hi,
> >
> > I noticed we have some old outstanding PRs for the geode-benchmarks
> > project. Are any of these things we want to merge or should we close them
> > out?
> >
> > https://github.com/apache/geode-benchmarks/pulls
> >
> > -Dan
> >
>

Re: Requesting permission to upload Apache Geode to Docker Hub

[Alexander Murmann]

You should have access now.

Thanks for stepping up as release manager!

On Fri, Jan 17, 2020 at 11:16 AM Ernest Burghardt 
wrote:

> Hello Geode,
>
> I'll be the Release Manager for 1.12 and need permission to upload Apache
> Geode to Docker Hub.
>
> My DockerHub ID: eburghardt
>
> Thanks in advance,
> EB
>


-- 
Alexander J. Murmann
(650) 283-1933

Re: [DISCUSS] What should we do with @Ignore tests?

[Alexander Murmann]

Here are a few things that are true for me or I believe are true in general:

   - Our test suite is more flaky than we'd like it to be
   - I don't believe that adding more Unit tests that follow existing
   patterns buys us that much. I'd rather see something similar to what some
   folks are doing with Membership right now where we isolate the code and
   test it more systematically
   - We have other testing gaps: We have benchmarks , but we are still
   lacking coverage in that ares; our community is still lacking HA tests. I'd
   rather fill those than bring back old DUnit tests that are chosen somewhat
   at random.
   - I'd rather be deliberate about what tests we introduce than wholesale
   bring back a set of tests, since any of these re-introduced tests has a
   potential to be flaky. Let's make sure our tests carry their weight.
   - If we delete these tests, we can always go back to a SHA from today
   and bring them back at a later date
   - These tests have been ignored since a very long time and we've shipped
   without them and nobody has missed them enough to bring them back.

Given all the above, my vote is for less noise in our code, which means
deleting all ignored tests. If we want to keep them, I'd love to hear a
plan of action on how we bring them back. Having a bunch of dead code helps
nobody.

On Tue, Dec 31, 2019 at 1:50 PM Mark Hanson  wrote:

> Hi All,
>
> As part of what I am doing to fix flaky tests, I periodically come across
> tests that are @Ignore’d. I am curious what we would like to do with them
> generally speaking. We could fix them, which would seem obvious, but we are
> struggling to fix flaky tests as it is.  We could delete them, but those
> tests were written for a reason (I hope).  Or we could leave them. This
> pollutes searches etc as inactive code requiring upkeep at least.
>
> I don’t have an easy answer. Some have suggested deleting them. I tend to
> lean that direction, but I thought I would consult the community for a
> broader perspective.
>
> Thanks,
> Mark

Re: [REQUEST] Squash merge please

[Alexander Murmann]

I wonder if Kirk's and Naba's statements are necessarily at odds.

Make the change easy (warning: this may be hard), then make the easy
> change."

 -Kent Beck

Following Kent Beck's advise might reasonably split into two commits. One
refactor commit and a separate commit that introduces the actual change.
They should be individually revertible and might be easier understood if
split out. I vividly remember a change on our code base where someone did a
huge amount of refactoring that resulted than in one parameter changing in
order to get the desired functionality change. If that was in one commit,
it would be hard to see the actual change. If split out, it's beautiful and
crystal clear.

I am unsure how that would be reflected in terms of JIRA ticket references.
Usually we assume that if there is a commit with the ticket number, the
issue is resolved. Maybe the key here is to create a separate refactoring
ticket.

Would that allow us to have our cake and eat it too?

On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag  wrote:

> It is to help with bisect operations when things start failing ... helps us
> it revert and build faster.
> also with cherry picking features / fixes to previous versions .
> And keeping the git history clean with no unnecessary “merge commits”.
>
> Regards
> Naba
>
>
> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund  wrote:
>
> > -1 I really like to sometimes have more than 1 commit in a PR and keep
> them
> > separate when they merge to develop
> >
> > On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag  wrote:
> >
> > > Hi Geode Committers,
> > >
> > > A kind request for using squash commit instead of using merge.
> > > This will really help us in our bisect operations when a
> > > regression/flakiness in the product is introduced. We can automate and
> go
> > > through fewer commits faster, avoiding commits like "spotless fix" and
> > > "re-trigger precheck-in" or other minor commits in the merged branch.
> > >
> > > Also, please use the commit format : (helps us to know who worked on
> it,
> > > what is the history)
> > >
> > >
> > >
> > > *GEODE-: 
> > > * explanation line 1* explanation line
> 2*
> > >
> > > This is not a rule or anything, but a request to help out your fellow
> > > committers in quickly detecting a problem.
> > >
> > > For inspiration, we can look into Apache Kafka / Spark where they have
> a
> > > complete linear graph for their main branch HEAD [see attachment]
> > >
> > > Regards
> > > Naba.
> > >
> > >
> > >
> >
>

Re: New geode-gfsh module

[Alexander Murmann]

> I imagine once the Management v2 API's are GA (and feature complete), I
don't see a reason why /gfsh/ should not be a stand alone module. It
would definitely have to be updated to use the new v2 API's, which
should not have any direct dependency on geode-core any more.

There also is a big question here of how much of the current GFSH
functionality needs to be there to fully replace the current GFSH. Looking
at the functionality available right now, it seems like we have a very long
way ahead of us.

On Fri, Dec 6, 2019 at 12:32 PM Owen Nichols  wrote:

> Any standalone management API or client thereof would not be able to start
> locator or start server.  For that gfsh still needs a large chunk of
> Geode.
>
>
> > On Dec 6, 2019, at 12:25 PM, Udo Kohlmeyer  wrote:
> >
> > I imagine once the Management v2 API's are GA (and feature complete), I
> don't see a reason why /gfsh/ should not be a stand alone module. It would
> definitely have to be updated to use the new v2 API's, which should not
> have any direct dependency on geode-core any more.
> >
> > On 12/6/19 10:01 AM, Jacob Barrett wrote:
> >>
> >>> On Dec 6, 2019, at 9:44 AM, Jens Deppe  wrote:
> >>>
> >>> Just to be clear, this effort does *not* result in a standalone gfsh
> >>> executable/jar.
> >> Is this a future plan?
> >>
> >>
>
>

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

[Alexander Murmann]

Joris, the "to be reviewed by" field is for a target date by which to wrap
up the discussion. Do you mind updating the field and letting the mailing
list know what timeframe you envision?

Thanks!

On Mon, Dec 2, 2019 at 1:41 PM Joris Melchior  wrote:

> Hi All,
>
> Looking for feedback on the proposal to [un/de]deprecate the IndexType ENUM
> on Geode.
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477
>
> Thanks, Joris.
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> 
>

Re: [DISCUSS/VOTE] Proposal to bring GEODE-7465 to release/1.11.0

[Alexander Murmann]

+1

On Tue, Nov 26, 2019 at 11:32 AM Udo Kohlmeyer  wrote:

> This is no-brainer
>
> *+1*
>
> On 11/26/19 11:27 AM, Owen Nichols wrote:
> > I would like to propose bringing “GEODE-7465: Set eventProcessor to null
> in serial AEQ when it is stopped” into the 1.11 release (necessitating an
> RC4).
> >
> > Without the fix, a sequence of ordinary gfsh commands will leave the WAN
> gateway in an unrecoverable hung state:
> > stop gateway-sender
> > start gateway-sender
> > The only recourse is to restart the server.
> >
> > This fix is critical because the distributed system fails to sync data
> between WAN sites as the user would expect.
> > This issue did exist in previous releases, but recent enhancements to
> WAN/AEQ such as AEQ-pause are increasing user interaction with WAN-related
> gfsh commands.
> >
> > The fix is simple, low risk, tested, and has been on develop for 5 days:
> >
> https://github.com/apache/geode/commit/e148cef9cb63eba283cf86bc490eb280023567ce
>


-- 
Alexander J. Murmann
(650) 283-1933

Re: [DISCUSS] - Move gfsh into its own submodule

[Alexander Murmann]

+1

If we get to 200, the refactor implements itself, right?

On Fri, Nov 22, 2019 at 1:57 PM Jason Huynh  wrote:

> +1
> I think we are now at +114 thanks to jinmei's 100 ;-)
>
>
> On Fri, Nov 22, 2019 at 1:50 PM Mark Bretl  wrote:
>
> > +1
> >
> > On Fri, Nov 22, 2019 at 12:55 PM Nabarun Nag  wrote:
> >
> > > +1
> > >
> > > On Fri, Nov 22, 2019 at 12:51 PM Charlie Black 
> > wrote:
> > >
> > > > this proposal == awesome sauce
> > > >
> > > > +1
> > > >
> > > > On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton <
> rhough...@pivotal.io
> > >
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Do we want to restart from my lazy POC from a few months ago?
> > > > >
> > > > > On Fri, Nov 22, 2019, 08:40 Jens Deppe 
> wrote:
> > > > >
> > > > > > Hello All,
> > > > > >
> > > > > > We'd like to propose moving gfsh and all associated commands into
> > its
> > > > own
> > > > > > gradle submodule (implicitly thus also producing a separate maven
> > > > > > artifact). The underlying intent is to decouple geode core from
> any
> > > > > Spring
> > > > > > dependencies.
> > > > > >
> > > > > > The proposal is outlined here:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> > > > > >
> > > > > > Please provide feedback for this proposal *on this email thread*
> > and
> > > > not
> > > > > in
> > > > > > the comment section of the proposal page.
> > > > > >
> > > > > > The deadline for this proposal will be Monday, December 2.
> > > > > >
> > > > > > Thanks in advance for feedback / comments.
> > > > > >
> > > > > > --Jens & Patrick
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Charlie Black | cbl...@pivotal.io
> > > >
> > >
> >
>