Re: Question about INDEX_THRESHOLD_SIZE

[Nabarun Nag]

Hi Mario,

Regarding this issue, we are investigating how we can move forward with this 
issue. After discussing with the team, and with the 1.15 release schedule 
coming up this month, we have planned to move this solution to 1.16.0 release. 
We have planned to go forward with this plan.

  *   Revert GEODE-9632 from develop and backport the revert to 1.15.0 ( This 
needs to be done to follow protocol) to get 1.15.0 release task complete.
  *   Work with you and the team to find a complete solution/improvement and 
push the solution to develop again and release in 1.16.0
  *   Document the additional purpose of INDEX_THRESHOLD_SIZE in the Apache 
Geode docs.

Please do reach us if you have any questions.

Regards
Nabarun Nag


From: Mario Kevo 
Sent: Tuesday, June 7, 2022 2:55 AM
To: dev@geode.apache.org 
Subject: Odg: Question about INDEX_THRESHOLD_SIZE

⚠ External Email

Hi all,

I dig it more in this problem and saw that if we have some range query like 
this:


query --query="SELECT  e.key, e.value from /example-region.entrySet e 
where e.value.positions['SUN'] LIKE 'abc%'"

It will turn it into two comparisons. First, it will check all that are < 'abd' 
and store them into intermediate results and then the second comparison will 
find all entries that have this attribute >= 'abc'. And their intersection can 
be null, when doing the first comparison(LT) it will store all entries that 
have this attribute lower than 'abd' which can also be something like '1234', 
'aab',... as all of them are lower by ASCII table. The problem is when adding 
entries to results it has a limit checked after every iteration. 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fgeode-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fgeode%2Fcache%2Fquery%2Finternal%2Findex%2FCompactRangeIndex.java%23L859data=05%7C01%7Cnnag%40vmware.com%7C521ece5f5f324b0c361d08da486bff8e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637901925947631598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mfvHgPewuNmWFurIcyHr7zC0xrGwFjbvFt2LRYs2lGE%3Dreserved=0
This limit is set in 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fgeode-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fgeode%2Fcache%2Fquery%2Finternal%2Findex%2FCompactRangeIndex.java%23L485data=05%7C01%7Cnnag%40vmware.com%7C521ece5f5f324b0c361d08da486bff8e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637901925947631598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=OubRAWJ2S%2Fi4Dubh2wATXvdyhdIEoFOPKgHINk7yq6c%3Dreserved=0
In that case, it stores only the first 100 entries that it found and there is 
the possibility that many of them are not starting with 'abc'.
This limit is different from the one added in the query to limit printing 
results.

If we just go with checking >= 'abc' this will include also entries whose 
attribute looks like 'bcd', ...

If we change indexThresholdSize while starting servers this limit can be 
changed and can get correct results if the indexThresholdSize is high as the 
region has entries (The user in many cases couldn't know how many entries it 
will have in the region).

I tried to change it by default to Integer.MAX_VALUE, but then have some test 
failing, so think it is not the best solution.
The test that reproduces the problem is available on 
#7754<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7754data=05%7C01%7Cnnag%40vmware.com%7C521ece5f5f324b0c361d08da486bff8e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637901925947631598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ZDZkPK6PGZw%2F0uXvjLc9M%2BClBK75wSfyDUbH%2FReblus%3Dreserved=0>.

Does anyone have some idea what is the best solution for this issue?

Thanks and BR,
Mario


Šalje: Jason Huynh 
Poslano: 15. ožujka 2022. 21:11
Prima: dev@geode.apache.org 
Predmet: Re: Question about INDEX_THRESHOLD_SIZE

Additional thought:
It would be nice to set/check CAN_APPLY_LIMIT_AT_INDEX on a per node basis or 
at least a finer grained setting.


  *   AND junctions probably it probably shouldn’t be applied at an index level
  *   OR junctions could as it’s a union
Combinations of the two or ancestor nodes should be smarter but that requires 
additional changes to make elegant…

From: Jason Huynh 
Date: Tuesday, March 15, 2022 at 1:03 PM
To: dev@geode.apache.org 
Subject: Re: Question about INDEX_THRESHOLD_SIZE
Hi Mario,



Digging a little bit more, I’m assuming the CompiledLike probably should 
reassess whether limits should be applied at the index level.  I imagine the 
“someth%” is currently being turned into two compiled comparisons joined by an 
AND?
T

Re: [PROPOSAL] annul support/1.15

[Nabarun Nag]

+1

From: Owen Nichols 
Sent: Wednesday, March 16, 2022 2:12 PM
To: geode 
Subject: [PROPOSAL] annul support/1.15

Seven weeks after cutting support/1.15, Jira now shows 11 blockers, up from 5 a 
few weeks ago.  I wonder if perhaps we cut the release branch prematurely?  I 
propose that we abandon this branch and focus on getting develop closer to what 
we want to ship, then discuss re-cutting the branch.

If this proposal is approved, I will archive support/1.15 as support/1.15.old, 
revert develop's numbering to 1.15.0, and bulk-update all Jira tickets fixed in 
1.16.0 to fixed in 1.15.0 instead.  Build numbering would start from 
1.15.0-build.1000 to easily distinguish pre- and post- recut.

Please vote/discuss with a goal of reaching consensus by 3PM PDT Monday Mar 21.

Thanks,
-Geode 1.15.0 Release Manager

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

[Nabarun Nag]

+1 based on pipeline status of the artifacts

Regards
Naba


From: Dick Cavender 
Sent: Wednesday, March 9, 2022 3:47 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.8.RC1

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.13.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 Tue, March 15 2022.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.8data=04%7C01%7Cnnag%40vmware.com%7C795a550738dd46063b5f08da022733e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664643772191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=K46pZc0SOhbcz8WKyso7mvURmbdVCeTX5%2BrJPtKYtw4%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.8.RC1%2Fdata=04%7C01%7Cnnag%40vmware.com%7C795a550738dd46063b5f08da022733e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664643772191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=AUy6%2BJ%2F4i0Cw84r%2BfgxsZnKOCOoo6CE%2BURY97B9HDgQ%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1135data=04%7C01%7Cnnag%40vmware.com%7C795a550738dd46063b5f08da022733e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664643772191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=OQWKVgUtFgqsCfBCJZKLN7dZLYLAx5D7VsJBmc7JTFw%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.8.RC1data=04%7C01%7Cnnag%40vmware.com%7C795a550738dd46063b5f08da022733e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664643772191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=dxEpJ8mN%2FpFyid8Zdba5HOat9Lb78A7%2BE606acj6IcA%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.8.RC1data=04%7C01%7Cnnag%40vmware.com%7C795a550738dd46063b5f08da022733e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664643772191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=frvwNYThwTIMbOkcZ47ZaEx9fmNrbPmFaQoDYJWmFnU%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.8.RC1data=04%7C01%7Cnnag%40vmware.com%7C795a550738dd46063b5f08da022733e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664643772191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0yI7jZcBEDFSeCHKzJ3cZ7zpczJbUAFPfXV4hcDnY48%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.8.RC1data=04%7C01%7Cnnag%40vmware.com%7C795a550738dd46063b5f08da022733e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664643772191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=1uT4jD4PITzEaMR0lD2BECAUJEbt4dG9jkWietEsAmQ%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%7Cnnag%40vmware.com%7C795a550738dd46063b5f08da022733e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664643772191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=lHxRq41vigftPzwx2yKFwXFc%2BZ06PbFPwzRziAK54dM%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%7Cnnag%40vmware.com%7C795a550738dd46063b5f08da022733e2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664643772191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=SKSCKUP5yaDM4wBbjloxZDMXMhsO2zDh7XLw%2BDZ95cA%3Dreserved=0

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

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

[Nabarun Nag]

+1 based on the test results of artifacts on the pipeline

Regards
Naba


Get Outlook for iOS

From: Dick Cavender 
Sent: Friday, March 4, 2022 2:05:36 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.9.RC1

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.12.9.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 Wed, March 9 2022.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.9data=04%7C01%7Cnnag%40vmware.com%7Ce78a841e03414da1252b08d9fe2b25ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283545611031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=7GvIe8%2FOlMmLHacue3w8YwbbGHlSllU%2BN5%2BqdIg2IIc%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.9.RC1%2Fdata=04%7C01%7Cnnag%40vmware.com%7Ce78a841e03414da1252b08d9fe2b25ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283545611031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=M67i2C5%2BAXsS1CR%2FYZJniGT0E99wxMwJfTzIfAmXELU%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1131data=04%7C01%7Cnnag%40vmware.com%7Ce78a841e03414da1252b08d9fe2b25ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283545611031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=bF77PVc71SOU1SHmLlIy6RTFPlDQujn%2FH3tH1coF0So%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.9.RC1data=04%7C01%7Cnnag%40vmware.com%7Ce78a841e03414da1252b08d9fe2b25ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283545611031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=7NjskDFM0KI57pK3kctEBDOGg1Am3%2BoG0R1NrMz8sno%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.9.RC1data=04%7C01%7Cnnag%40vmware.com%7Ce78a841e03414da1252b08d9fe2b25ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283545611031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=yLEJpEUdXdvNoPgzTXtyK25J3BjCBzLt3sQHd9mN3gQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.9.RC1data=04%7C01%7Cnnag%40vmware.com%7Ce78a841e03414da1252b08d9fe2b25ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283545611031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=duZjUX75P8q6o%2Blg%2B8t%2FIRzbBCGZhKtjB0wsXjyj8S4%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.9.RC1data=04%7C01%7Cnnag%40vmware.com%7Ce78a841e03414da1252b08d9fe2b25ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283545611031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Z894kl4naP28mAgNJkibOPszN5%2BAeDR%2Bx211MukPUnQ%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%7Cnnag%40vmware.com%7Ce78a841e03414da1252b08d9fe2b25ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283545611031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=GD9Io9RL1sWItXSHlcFNHRUnCTFzGE%2Bp9q7SG7M66K4%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rcdata=04%7C01%7Cnnag%40vmware.com%7Ce78a841e03414da1252b08d9fe2b25ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283545611031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=18HK44Xj%2FAxRn1iEfFrfbqq4UbpBqJ9v%2BefQLdmu58Y%3Dreserved=0

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

Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

[Nabarun Nag]

As, there are no more feedback on this report I am submitting this report to 
the board. Thank you all.

Regards
Nabarun

From: Nabarun Nag 
Sent: Friday, February 4, 2022 3:52 PM
To: dev@geode.apache.org 
Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

Thank you all for the valuable feedback, below is the final draft, please do 
let me know if this is anything more to add.

> ## Description:
> The mission of Apache Geode is the creation and maintenance of software
> related
> to a data management platform that provides real-time, consistent access to
> data-intensive applications throughout widely distributed cloud
> architectures.
>
> ## Issues:
> There are no Board-level issues at this time.
>
> ## Membership Data:
> Apache Geode was founded 2016-11-15 (5 years ago)
> There are currently 115 committers and 54 PMC members in this project.
> The Committer-to-PMC ratio is roughly 2:1.
>
> Community changes, past quarter:
> - No new PMC members. Last addition was Donal Evans on 2021-03-22.
> - No new committers. Last addition was Alberto Bustamante on 2021-05-13.
>
  > ## Project Activity:
> We issued 9 releases this quarter, all do which include an updated Log4j2 
version
> to handle the remote code execution CVE.
> Apache Geode Kafka Connector 1.1.0 was also released
> this quarter.
> We have also started the effort to remove the use of deprecated components
> in the project.
>
> > Recent Releases of Apache Geode:
> > - 1.14.3 was released on 2022-01-25
> > - 1.13.7 was released on 2022-01-22
> > - 1.12.8 was released on 2022-01-13
> > - 1.12.7 was released on 2021-12-17
> > - 1.13.6 was released on 2021-12-17
> > - 1.14.2 was released on 2021-12-17
> > - 1.12.6 was released on 2021-12-11
> > - 1.13.5 was released on 2021-12-11
> > - 1.14.1 was released on 2021-12-11
>
>
> Work on releasing 1.15.0 is progressing as planned.
>
> Apache Geode Kafka Connector 1.1.0 was released on 2022-01-18.
>
> ## Community Health:
> - Continuing our monthly video conferences.
> - Addition of Kafka Connector project to grow the community.
> - Mailing lists are seeing the usual amount of traffic involving
> discussions
> related to improving performance, operation protocols, etc.

From: Dan Smith 
Sent: Friday, February 4, 2022 3:20 PM
To: dev@geode.apache.org 
Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

Sounds good. BTW, I don't mean to discount all the hard work folks did getting 
these patches out quickly. Thanks again for everyone who helped with that 
effort!

-Dan

From: Owen Nichols 
Sent: Friday, February 4, 2022 2:52 PM
To: dev@geode.apache.org 
Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

That's a much better way to put it, Mark.  Thanks!

On 2/4/22, 2:50 PM, "Mark Bretl"  wrote:

I agree with Dan here that bragging about 'one of the quickest' is not
needed, but noting we are up-to-date with Log4J patches and have
documentation for mitigation might be a better approach.

My $.02

--Mark

On Fri, Feb 4, 2022 at 11:34 AM Dan Smith  wrote:

> Counting the kafka connector I'm not sure bragging about CVE patching
> speed is justified, but otherwise looks good to me!
>
> -Dan
> 
> From: Nabarun Nag 
> Sent: Tuesday, February 1, 2022 2:25 PM
> To: dev@geode.apache.org 
> Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th
>
> Thank you for the feedback, please find the new draft with the added
> review comments.
>
> ## Project Activity:
> We issued 9 releases this quarter which include an updated Log4j2 version
> to handle the remote code execution CVE. The project had one of the
> quickest turnaround times from the Log4j2 CVE disclosure to the patch
> releases with the fix. Apache Geode Kafka Connector 1.1.0 was also 
released
> this quarter.
> We have also started the effort to remove the use of deprecated components
> in the project.
>
> > Recent Releases of Apache Geode:
> > - 1.14.3 was released on 2022-01-25
> > - 1.13.7 was released on 2022-01-22
> > - 1.12.8 was released on 2022-01-13
> > - 1.12.7 was released on 2022-12-17
> > - 1.13.6 was released on 2021-12-17
> > - 1.14.2 was released on 2021-12-17
> > - 1.12.6 was released on 2021-12-11
> > - 1.13.5 was released on 2021-12-11
> > - 1.14.1 was released on 2021-12-11
>
>
> 

Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

[Nabarun Nag]

Thank you all for the valuable feedback, below is the final draft, please do 
let me know if this is anything more to add.

> ## Description:
> The mission of Apache Geode is the creation and maintenance of software
> related
> to a data management platform that provides real-time, consistent access to
> data-intensive applications throughout widely distributed cloud
> architectures.
>
> ## Issues:
> There are no Board-level issues at this time.
>
> ## Membership Data:
> Apache Geode was founded 2016-11-15 (5 years ago)
> There are currently 115 committers and 54 PMC members in this project.
> The Committer-to-PMC ratio is roughly 2:1.
>
> Community changes, past quarter:
> - No new PMC members. Last addition was Donal Evans on 2021-03-22.
> - No new committers. Last addition was Alberto Bustamante on 2021-05-13.
>
  > ## Project Activity:
> We issued 9 releases this quarter, all do which include an updated Log4j2 
version
> to handle the remote code execution CVE.
> Apache Geode Kafka Connector 1.1.0 was also released
> this quarter.
> We have also started the effort to remove the use of deprecated components
> in the project.
>
> > Recent Releases of Apache Geode:
> > - 1.14.3 was released on 2022-01-25
> > - 1.13.7 was released on 2022-01-22
> > - 1.12.8 was released on 2022-01-13
> > - 1.12.7 was released on 2021-12-17
> > - 1.13.6 was released on 2021-12-17
> > - 1.14.2 was released on 2021-12-17
> > - 1.12.6 was released on 2021-12-11
> > - 1.13.5 was released on 2021-12-11
> > - 1.14.1 was released on 2021-12-11
>
>
> Work on releasing 1.15.0 is progressing as planned.
>
> Apache Geode Kafka Connector 1.1.0 was released on 2022-01-18.
>
> ## Community Health:
> - Continuing our monthly video conferences.
> - Addition of Kafka Connector project to grow the community.
> - Mailing lists are seeing the usual amount of traffic involving
> discussions
> related to improving performance, operation protocols, etc.

From: Dan Smith 
Sent: Friday, February 4, 2022 3:20 PM
To: dev@geode.apache.org 
Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

Sounds good. BTW, I don't mean to discount all the hard work folks did getting 
these patches out quickly. Thanks again for everyone who helped with that 
effort!

-Dan

From: Owen Nichols 
Sent: Friday, February 4, 2022 2:52 PM
To: dev@geode.apache.org 
Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

That's a much better way to put it, Mark.  Thanks!

On 2/4/22, 2:50 PM, "Mark Bretl"  wrote:

I agree with Dan here that bragging about 'one of the quickest' is not
needed, but noting we are up-to-date with Log4J patches and have
documentation for mitigation might be a better approach.

My $.02

--Mark

On Fri, Feb 4, 2022 at 11:34 AM Dan Smith  wrote:

> Counting the kafka connector I'm not sure bragging about CVE patching
> speed is justified, but otherwise looks good to me!
>
> -Dan
> 
> From: Nabarun Nag 
> Sent: Tuesday, February 1, 2022 2:25 PM
> To: dev@geode.apache.org 
> Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th
>
> Thank you for the feedback, please find the new draft with the added
> review comments.
>
> ## Project Activity:
> We issued 9 releases this quarter which include an updated Log4j2 version
> to handle the remote code execution CVE. The project had one of the
> quickest turnaround times from the Log4j2 CVE disclosure to the patch
> releases with the fix. Apache Geode Kafka Connector 1.1.0 was also 
released
> this quarter.
> We have also started the effort to remove the use of deprecated components
> in the project.
>
> > Recent Releases of Apache Geode:
> > - 1.14.3 was released on 2022-01-25
> > - 1.13.7 was released on 2022-01-22
> > - 1.12.8 was released on 2022-01-13
> > - 1.12.7 was released on 2022-12-17
> > - 1.13.6 was released on 2021-12-17
> > - 1.14.2 was released on 2021-12-17
> > - 1.12.6 was released on 2021-12-11
> > - 1.13.5 was released on 2021-12-11
> > - 1.14.1 was released on 2021-12-11
>
>
> 
> From: Owen Nichols 
> Sent: Tuesday, February 1, 2022 12:39 PM
> To: dev@geode.apache.org 
> Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th
>
> 1.12.8 seems to be missing from the list of releases. Also consider

Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

[Nabarun Nag]

Thank you for the feedback, please find the new draft with the added review 
comments.

## Project Activity:
We issued 9 releases this quarter which include an updated Log4j2 version
to handle the remote code execution CVE. The project had one of the quickest 
turnaround times from the Log4j2 CVE disclosure to the patch releases with the 
fix. Apache Geode Kafka Connector 1.1.0 was also released this quarter.
We have also started the effort to remove the use of deprecated components in 
the project.

> Recent Releases of Apache Geode:
> - 1.14.3 was released on 2022-01-25
> - 1.13.7 was released on 2022-01-22
> - 1.12.8 was released on 2022-01-13
> - 1.12.7 was released on 2022-12-17
> - 1.13.6 was released on 2021-12-17
> - 1.14.2 was released on 2021-12-17
> - 1.12.6 was released on 2021-12-11
> - 1.13.5 was released on 2021-12-11
> - 1.14.1 was released on 2021-12-11



From: Owen Nichols 
Sent: Tuesday, February 1, 2022 12:39 PM
To: dev@geode.apache.org 
Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

1.12.8 seems to be missing from the list of releases. Also consider bragging 
about Geode’s turnaround time from CvE disclosure to patch release…only one 
other ASF project got theirs out faster than we did.


---
Sent from Workspace ONE 
Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=04%7C01%7Cnnag%40vmware.com%7Ccae2b6b4828940093e1608d9e5c2eca7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637793447636413292%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=as8W0ayQwB98tl3wTAmU0VLXeNBIc6Nkvf12gAvPvPg%3Dreserved=0>

On January 31, 2022 at 1:57:18 PM PST, Dave Barnes  wrote:
LGTM +1

On Mon, Jan 31, 2022 at 12:50 PM Nabarun Nag  wrote:

> This is a draft of our report to the board. Please let me know if there
> are details you'd like me to add!
>
> --Naba
>
> ## Description:
> The mission of Apache Geode is the creation and maintenance of software
> related
> to a data management platform that provides real-time, consistent access to
> data-intensive applications throughout widely distributed cloud
> architectures.
>
> ## Issues:
> There are no Board-level issues at this time.
>
> ## Membership Data:
> Apache Geode was founded 2016-11-15 (5 years ago)
> There are currently 115 committers and 54 PMC members in this project.
> The Committer-to-PMC ratio is roughly 2:1.
>
> Community changes, past quarter:
> - No new PMC members. Last addition was Donal Evans on 2021-03-22.
> - No new committers. Last addition was Alberto Bustamante on 2021-05-13.
>
> ## Project Activity:
> We issued 8 releases this quarter which include an updated Log4j2 version
> to handle the remote code execution CVE. Apache Geode Kafka Connector 1.1.0
> was also released this quarter.
> We have also started the effort to remove the use of deprecated components
> in
> the project.
>
> Recent Releases of Apache Geode:
> - 1.14.3 was released on 2022-01-25
> - 1.13.7 was released on 2022-01-22
> - 1.12.7 was released on 2022-12-17
> - 1.13.6 was released on 2021-12-17
> - 1.14.2 was released on 2021-12-17
> - 1.12.6 was released on 2021-12-11
> - 1.13.5 was released on 2021-12-11
> - 1.14.1 was released on 2021-12-11
>
> Work on releasing 1.15.0 is progressing as planned.
>
> Apache Geode Kafka Connector 1.1.0 was released on 2022-01-18.
>
> ## Community Health:
> - Continuing our monthly video conferences.
> - Addition of Kafka Connector project to grow the community.
> - Mailing lists are seeing the usual amount of traffic involving
> discussions
> related to improving performance, operation protocols, etc.
>
>
>

[DRAFT] Apache Geode Board report due by Wed Feb 9th

[Nabarun Nag]

This is a draft of our report to the board. Please let me know if there are 
details you'd like me to add!

--Naba

## Description:
The mission of Apache Geode is the creation and maintenance of software related
to a data management platform that provides real-time, consistent access to
data-intensive applications throughout widely distributed cloud architectures.

## Issues:
There are no Board-level issues at this time.

## Membership Data:
Apache Geode was founded 2016-11-15 (5 years ago)
There are currently 115 committers and 54 PMC members in this project.
The Committer-to-PMC ratio is roughly 2:1.

Community changes, past quarter:
- No new PMC members. Last addition was Donal Evans on 2021-03-22.
- No new committers. Last addition was Alberto Bustamante on 2021-05-13.

## Project Activity:
We issued 8 releases this quarter which include an updated Log4j2 version
to handle the remote code execution CVE. Apache Geode Kafka Connector 1.1.0
was also released this quarter.
We have also started the effort to remove the use of deprecated components in
the project.

Recent Releases of Apache Geode:
- 1.14.3 was released on 2022-01-25
- 1.13.7 was released on 2022-01-22
- 1.12.7 was released on 2022-12-17
- 1.13.6 was released on 2021-12-17
- 1.14.2 was released on 2021-12-17
- 1.12.6 was released on 2021-12-11
- 1.13.5 was released on 2021-12-11
- 1.14.1 was released on 2021-12-11

Work on releasing 1.15.0 is progressing as planned.

Apache Geode Kafka Connector 1.1.0 was released on 2022-01-18.

## Community Health:
- Continuing our monthly video conferences.
- Addition of Kafka Connector project to grow the community.
- Mailing lists are seeing the usual amount of traffic involving discussions
related to improving performance, operation protocols, etc.

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

[Nabarun Nag]

+1 based on the results of the pipeline tests.

Regards
Nabarun Nag


From: Dick Cavender 
Sent: Monday, January 17, 2022 11:20 AM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.7.RC1

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.13.7.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 Thursday, January 20 2022.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.7data=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=V5yh9gXa39eKG7MY0uXruCe0qgODD3ef94YwMJcoKRw%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.7.RC1%2Fdata=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=NhGIBZQCPTvIdXFaxCTYqatC13cJkrjyx4AVgKk5698%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1126data=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=rpF5i%2B1MUSkt%2FTU%2BKSv9d%2BjLiO3Vt8KPHXhSnMcBfhM%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.7.RC1data=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=cDmYAZN8vKLs5bRVmOPDGw6YshASiNiXX9I7PoxGZyc%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.7.RC1data=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6WKvYUp52vm0qhBeNJKkAZYMiagI7hp1d7UIizTvAqw%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.7.RC1data=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ZsDwPqv6gq%2B9z9g30M5xHAtT2e3T5AepXheqob2m8j0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.7.RC1data=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=hCAbePGsAZllyrXVhQoiuq%2BBANvLe%2BcpQQ0puQCeps0%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%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=7C8JYijQu0VFpObgZj3GQDI%2FicP48lFcbn7Ji60%2FuXI%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%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=MAqZ9jupVC%2B52z%2B7YaJZdbn7sZ4Bb36h0tbj1aH8YUM%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2FKEYSdata=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata

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

[Nabarun Nag]

+1 to move along with this release.

Here is the URI of the component archive specification set by Confluent[1]. Our 
first delivery had to be changed to meet these requirements.

Regards
Naba


[1]https://docs.confluent.io/home/connect/confluent-hub/component-archive.html

From: Jason Huynh 
Sent: Tuesday, January 11, 2022 9:35 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

+1 for this release

On 1/6/22, 9:22 AM, "Dan Smith"  wrote:

Quibbles:
- artifact naming does not follow standard naming convention of 
THING-VERSION.tgz and THING-VERSION-src.tgz (also Geode decided to stop 
distributing .zip files years ago)
- not based on the latest Geode 1.12 patch.  I would like to see Geode 
1.12.8 picked up once it's available later this month.
- the log4j version 2.16.0 advertised in this release fixes only 2 of the 4 
recent log4j vulnerabilities.  I would prefer to see log4j 2.17.1.
- vote email is missing a link to release notes and a link to the KEYS file 
used to sign the release.
- artifact paths and email subject are missing "RC1" qualifier
Agreed, I think we'll want to do another release later to pickup the latest 
geode and log4j. The lack of RC1 is intentional - this is creating an official 
release based on what was already linked from the confluent hub.

Concerns:
- NOTICE and LICENSE are found inside a "doc" folder instead of at the top 
level of the artifact
- Some dependencies are missing from LICENSE.  While most deps are Apache2 
and don't require a mention, LatencyUtils is BSD-2 and should be mentioned, and 
likely a few others from Geode's LICENSE need to be there as well because they 
are incorporated in source form into geode-core.
​Good catch! I created GEODE-9925 for the missing dependencies.

Looking at the list of things to do and conflicts with Geode / Confluent 
requirements. We can remove it from the Apache domain and move it to internal 
open source repo like gpdb or rabbitMQ while keeping the Apache License. 
Alternatives can be the VMware or VMware-labs opensource orgs in Github.

Can you clarify which things are in conflict? I think the file name for 
geode is not a hard requirement, just a convention we picked. Also the location 
of LICENSE and NOTICE files - is there some confluent requirement? Apache says 
those files should be at the top level for a source distribution, but I'm not 
clear about a binary distribution. For example, our jar files put them under 
META-INF, which I think is the java convention.

My inclination is to continue with this release as is and create a follow 
up release that updates log4j and the LICENSE, NOTICE files, so I'm leaving 
this VOTE open in hopes of getting some more votes.

-Dan
________
From: Nabarun Nag 
Sent: Tuesday, January 4, 2022 5:13 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

As it is primarily created for Confluent Marketplace we need to follow the 
steps required for hosting in the marketplace, which included how things are to 
be named, folder structure etc.

Looking at the list of things to do and conflicts with Geode / Confluent 
requirements. We can remove it from the Apache domain and move it to internal 
open source repo like gpdb or rabbitMQ while keeping the Apache License. 
Alternatives can be the VMware or VMware-labs opensource orgs in Github.

We can definitely add the missing licenses and wait for 1.12.8 release of 
Apache Geode to update those dependencies.


Regards
Naba


From: Owen Nichols 
Sent: Tuesday, January 4, 2022 4:45 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

Quibbles:
- artifact naming does not follow standard naming convention of 
THING-VERSION.tgz and THING-VERSION-src.tgz (also Geode decided to stop 
distributing .zip files years ago)
- not based on the latest Geode 1.12 patch.  I would like to see Geode 
1.12.8 picked up once it's available later this month.
- the log4j version 2.16.0 advertised in this release fixes only 2 of the 4 
recent log4j vulnerabilities.  I would prefer to see log4j 2.17.1.
- vote email is missing a link to release notes and a link to the KEYS file 
used to sign the release.
- artifact paths and email subject are missing "RC1" qualifier

Concerns:
- NOTICE and LICENSE are found inside a "doc" folder instead of at the top 
level of the artifact
- Some dependencies are missing from LICENSE.  While most deps are Apache2 
and don't require a mention, LatencyUtils is BSD-2 and should be mentioned, and 
likely a few others from Geode's LICENSE need to be there as well because they 
are incorporated in source form into geode-core.

 

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

[Nabarun Nag]

As it is primarily created for Confluent Marketplace we need to follow the 
steps required for hosting in the marketplace, which included how things are to 
be named, folder structure etc.

Looking at the list of things to do and conflicts with Geode / Confluent 
requirements. We can remove it from the Apache domain and move it to internal 
open source repo like gpdb or rabbitMQ while keeping the Apache License. 
Alternatives can be the VMware or VMware-labs opensource orgs in Github.

We can definitely add the missing licenses and wait for 1.12.8 release of 
Apache Geode to update those dependencies.


Regards
Naba


From: Owen Nichols 
Sent: Tuesday, January 4, 2022 4:45 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

Quibbles:
- artifact naming does not follow standard naming convention of 
THING-VERSION.tgz and THING-VERSION-src.tgz (also Geode decided to stop 
distributing .zip files years ago)
- not based on the latest Geode 1.12 patch.  I would like to see Geode 1.12.8 
picked up once it's available later this month.
- the log4j version 2.16.0 advertised in this release fixes only 2 of the 4 
recent log4j vulnerabilities.  I would prefer to see log4j 2.17.1.
- vote email is missing a link to release notes and a link to the KEYS file 
used to sign the release.
- artifact paths and email subject are missing "RC1" qualifier

Concerns:
- NOTICE and LICENSE are found inside a "doc" folder instead of at the top 
level of the artifact
- Some dependencies are missing from LICENSE.  While most deps are Apache2 and 
don't require a mention, LatencyUtils is BSD-2 and should be mentioned, and 
likely a few others from Geode's LICENSE need to be there as well because they 
are incorporated in source form into geode-core.

Please consider above suggestions for next time.

+0

On 1/4/22, 2:19 PM, "Dan Smith"  wrote:

Hello Geode Dev Community,

This is a release candidate for Apache Geode Kafka Connector version 1.1.0.
This contains a bump to log4j 2.16.

Please do a review and give your feedback.

Voting deadline:
3PM PST Tuesday, Jan 11, 2022.

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

Source and Binary Distributions: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2Fkafka-connector-1.1.0%2Fdata=04%7C01%7Cnnag%40vmware.com%7C446cbaa9b22e405c8ab908d9cfe4af60%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637769403373246616%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=rIRSVkdDIlv0c2yFZDSXZe9fDFrOX0usjDtyyEDa0%2Bg%3Dreserved=0
Github: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector%2Ftree%2Frel%2Fv1.1.0data=04%7C01%7Cnnag%40vmware.com%7C446cbaa9b22e405c8ab908d9cfe4af60%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637769403373246616%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=3yvWDc7u%2FNi%2FkF5zXQKDYkkEOImzOMxWnDAgFzm8P%2B4%3Dreserved=0

Command to build the connector:
mvn package

Thanks!
-Dan

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

[Nabarun Nag]

+1
Checked with building source and running tests.

Regards
Naba

From: Dan Smith 
Sent: Tuesday, January 4, 2022 2:37 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

This is the same release I started a VOTE on in December and canceled due to 
Christmas. Here was my earlier comment on where this release is coming from:

On Dec 16, 2021 11:33 AM, Dan Smith  wrote:
This is related to the earlier discussion about the kafka connector. This code 
was already linked from the confluent hub, but I want to make sure we're in 
compliance with the apache release policy.

To create this release, I took the source code and binaries Naba mentioned and 
compared them with the rel/1.1.0 source tag and the results of building that 
tag. They were identical except for the build date in the metadata.json file 
for the binary.

I added gpg and sha256sum signatures and uploaded the artifacts to the apache 
staging repo for you all to review.

I checked out the license, notice, and source code headers and everything 
looked ok to me from that perspective.

In the future, we may want to release this in sync with the rest of the geode 
artifacts, but for now I'm just trying to create an official release that 
follows the release policy - 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.htmldata=04%7C01%7Cnnag%40vmware.com%7Ceb251e5e0a4f42bf46e108d9cfd2db04%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637769326818200926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=h%2BC1DQJsrqYTbs1nDOvdKvnr73SSeEtGEpMU3IyPS9o%3Dreserved=0


From: Dan Smith 
Sent: Tuesday, January 4, 2022 2:18 PM
To: dev@geode.apache.org 
Subject: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

Hello Geode Dev Community,

This is a release candidate for Apache Geode Kafka Connector version 1.1.0.
This contains a bump to log4j 2.16.

Please do a review and give your feedback.

Voting deadline:
3PM PST Tuesday, Jan 11, 2022.

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

Source and Binary Distributions: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2Fkafka-connector-1.1.0%2Fdata=04%7C01%7Cnnag%40vmware.com%7Ceb251e5e0a4f42bf46e108d9cfd2db04%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637769326818200926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=9Ompca49Q%2FGwVVxp6JwYFW%2FR03aAjAxz5TdQGACAaRw%3Dreserved=0
Github: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector%2Ftree%2Frel%2Fv1.1.0data=04%7C01%7Cnnag%40vmware.com%7Ceb251e5e0a4f42bf46e108d9cfd2db04%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637769326818200926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ulk3r0c7kttqzeb9i1GGY%2Bmy8CVNdKNQE0gDrLgX8fE%3Dreserved=0

Command to build the connector:
mvn package

Thanks!
-Dan

Re: ANNOUNCE : Apache Geode Kafka Connector v1.1.0

[Nabarun Nag]

Hi Dan,

It can be definitely done that way. Please feel free to send out the vote email 
and signatures. The staging artifacts can be found in the release section of 
the github page. Please do let me know if you need any additional information.

Regards,
Nabarun


From: Dan Smith 
Sent: Wednesday, December 15, 2021 4:16 PM
To: dev@geode.apache.org 
Subject: Re: ANNOUNCE : Apache Geode Kafka Connector v1.1.0

Hi Naba,

Thanks for patching log4j in the kafka connector!

However, I think we should be following the official apache release policy [1] 
for this connector, which means a VOTE requiring 3 PMC signatures, signed 
artifacts, releasing the artifacts first on the apache downloads site, etc.

In this case, I think the thing to do is retroactively vote on the release you 
created. I can help create a VOTE email tomorrow with signatures and staging 
artifacts if you like. On the off chance something comes up in the VOTE that 
requires a change we can just release an official 1.1.1 release.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.htmldata=04%7C01%7Cnnag%40vmware.com%7C6d18c25c3e964c840cdd08d9c0295a1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752106109940344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0nqpZhGJrISks%2BfDqCbPncUZTWeh8G8oc8ts88YAQuA%3Dreserved=0



From: Nabarun Nag 
Sent: Wednesday, December 15, 2021 9:52 AM
To: dev@geode.apache.org 
Subject: ANNOUNCE : Apache Geode Kafka Connector v1.1.0

Hi all,

I would like to announce that Apache Geode Kafka Connector v1.1.0 has been 
released. This is also available in Confluent Hub.

Notable changes are upgrading of Log4J libraries to 2.16.0 and Apache Geode 
libraries to 1.12.6.

Binaries and source code are available at: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector%2Freleases%2Ftag%2Frel%252Fv1.1.0data=04%7C01%7Cnnag%40vmware.com%7C6d18c25c3e964c840cdd08d9c0295a1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752106109940344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=fkplwVHE%2FrHxNzLeJ1%2Bw%2FgxOzN0Fhz7Tuxs8UiPU%2B68%3Dreserved=0

Regards
Nabarun Nag
[https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopengraph.githubassets.com%2Fc2a01e14394ffb0f85e3ec2470786eb2d8c1ab16f34bbcddea1ccdbf7549a9ef%2Fapache%2Fgeode-kafka-connector%2Freleases%2Ftag%2Frel%2Fv1.1.0data=04%7C01%7Cnnag%40vmware.com%7C6d18c25c3e964c840cdd08d9c0295a1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752106109940344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=E48T7r4ck778N%2ForWqm%2FJhuAz9PLFNNUardGha2C8IA%3Dreserved=0]<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector%2Freleases%2Ftag%2Frel%252Fv1.1.0data=04%7C01%7Cnnag%40vmware.com%7C6d18c25c3e964c840cdd08d9c0295a1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752106109940344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=fkplwVHE%2FrHxNzLeJ1%2Bw%2FgxOzN0Fhz7Tuxs8UiPU%2B68%3Dreserved=0>
Release v1.1.0 · 
apache/geode-kafka-connector<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector%2Freleases%2Ftag%2Frel%252Fv1.1.0data=04%7C01%7Cnnag%40vmware.com%7C6d18c25c3e964c840cdd08d9c0295a1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752106109940344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=fkplwVHE%2FrHxNzLeJ1%2Bw%2FgxOzN0Fhz7Tuxs8UiPU%2B68%3Dreserved=0>
Upgraded Log4j to 2.16.0 Apache Geode upgraded to 1.12.6
github.com

Re: [VOTE] Apache Geode 1.14.2.RC1

[Nabarun Nag]

+1 to 1.14.2.RC1


  *   Build from source
  *   WAN clusters with SSL
  *   puts/gets
  *   validate data integrity after rolling restart.

Regards
Nabarun Nag


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

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.14.2.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.14.2.RC1

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.2data=04%7C01%7Cnnag%40vmware.com%7Cbb2255a5bba1432619eb08d9bf7160f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315947705375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=5dcNasfn8%2BRMEMQc2efDduF33AhK5S8Tc8Y1qdbUllc%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.14.2.RC1%2Fdata=04%7C01%7Cnnag%40vmware.com%7Cbb2255a5bba1432619eb08d9bf7160f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315947705375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Hwjrb7tw8jtgcC9kSOPJHxGUQyQGLAfRU5cIvJ0MyJA%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1122data=04%7C01%7Cnnag%40vmware.com%7Cbb2255a5bba1432619eb08d9bf7160f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315947705375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2BPiAxfsR%2BP6%2FcysRive%2B98Yss%2B18Rf5ZiQ3CuFnXz6k%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.2.RC1data=04%7C01%7Cnnag%40vmware.com%7Cbb2255a5bba1432619eb08d9bf7160f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315947705375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ZcdFVZtDSVDDuJTPdP9lJU7Mcmv6oerA6YXqqG48S8I%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.2.RC1data=04%7C01%7Cnnag%40vmware.com%7Cbb2255a5bba1432619eb08d9bf7160f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315947705375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=oQmLI3G4dRogzJM78PCqJgYXpFPp0OQvLR8%2BKZoLfhc%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.2.RC1data=04%7C01%7Cnnag%40vmware.com%7Cbb2255a5bba1432619eb08d9bf7160f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315947705375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=qqKHLjme8fUhP2Ftg6XzwtCUxin1kN4Ex3f6FG%2FaNEY%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.2.RC1data=04%7C01%7Cnnag%40vmware.com%7Cbb2255a5bba1432619eb08d9bf7160f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315947705375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Xe8OMkFHS8fRss0px6AAXa3%2FliPcTNRFYKUedajFb4E%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-maindata=04%7C01%7Cnnag%40vmware.com%7Cbb2255a5bba1432619eb08d9bf7160f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315947705375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=BYVhc3EQWHWrIqEaG%2FiWIC7IndaeBQa08R5InNN4fN4%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-rcdata=04%7C01%7Cnnag%40vmware.com%7Cbb2255a5bba1432619eb08d9bf7160f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315947705375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=WKrZ888tqx1gQG2poOM6DEvpEZGQOeIjLZwIjp9Z4VU%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2FKEYSdata=04%7C01%7Cnnag%40vmware.com%7Cbb2255a5bba1432619eb08d9bf7160f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315947705375%7CUnknown

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

[Nabarun Nag]

+1 to 1.13.6.RC1


  *   Build from source
  *   WAN clusters with SSL
  *   puts/gets
  *   validate data integrity after rolling restart.

Regards
Nabarun Nag


From: Owen Nichols 
Sent: Tuesday, December 14, 2021 6:19 PM
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%7Cnnag%40vmware.com%7C277ee8e8d4a7497d98fa08d9bf715d56%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315892864874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=KGHoW8y6jd6dlP7k%2FRjq0kpxorgLdPbsAq%2F9mqwg3Sw%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%7Cnnag%40vmware.com%7C277ee8e8d4a7497d98fa08d9bf715d56%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315892864874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=z%2BdmoYE0eKr7ETBbh9hopVQfamFt7jOSvJEWj7LyI58%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1121data=04%7C01%7Cnnag%40vmware.com%7C277ee8e8d4a7497d98fa08d9bf715d56%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315892864874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=N%2Bg3562kgwJGc0D2xO26YN%2F34TGxDpVx%2F5OVHP%2FOBYM%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%7Cnnag%40vmware.com%7C277ee8e8d4a7497d98fa08d9bf715d56%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315892864874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=CskJL5zY%2F4%2FSYGFSAO2jNrHvYwkeMeOWyRae%2FEY1H%2Fo%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%7Cnnag%40vmware.com%7C277ee8e8d4a7497d98fa08d9bf715d56%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315892864874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2BcV7CC1lU9PqQXhKDKosDpny3dS0RJ20PQVN8GecadM%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%7Cnnag%40vmware.com%7C277ee8e8d4a7497d98fa08d9bf715d56%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315892864874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Y96N%2BkU8cvVBxlJVjucrumpqm6hzq0i4EhCZXO78pwI%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%7Cnnag%40vmware.com%7C277ee8e8d4a7497d98fa08d9bf715d56%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315892864874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=5PuqNo1rHDanaR5oFO%2BOU25gL9pz4f6M6abxhC8Os90%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%7Cnnag%40vmware.com%7C277ee8e8d4a7497d98fa08d9bf715d56%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315892864874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ymjBNn%2Fp5mn08YaYqL6eLWSFPjYdPv22MLSjT1ttxOU%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%7Cnnag%40vmware.com%7C277ee8e8d4a7497d98fa08d9bf715d56%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315892864874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=nKDHO%2FTOD1r%2B%2BQMzea3KEtgKyNetwVjp48HAHLoiR%2FY%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2FKEYSdata=04%7C01%7Cnnag%40vmware.com%7C277ee8e8d4a7497d98fa08d9bf715d56%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315892864874%7CUnknown

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

[Nabarun Nag]

+1 to 1.12.7.RC1


  *   Build from source
  *   WAN clusters with SSL
  *   puts/gets
  *   validate data integrity after rolling restart.

Regards
Nabarun Nag


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

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.12.7.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.12.7.RC1

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.7data=04%7C01%7Cnnag%40vmware.com%7Cb6149a91c0ca40afe1db08d9bf715d08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315881303053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=5NWatQYLT4dKsh%2B%2Bch7CKooQy2d0avPJr%2F6odrKY4AA%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.7.RC1%2Fdata=04%7C01%7Cnnag%40vmware.com%7Cb6149a91c0ca40afe1db08d9bf715d08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315881303053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=FQpNRivBgTR3AAJTzeQR1Ek%2Bg1BfmXTbT9bbWGbY64s%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1120data=04%7C01%7Cnnag%40vmware.com%7Cb6149a91c0ca40afe1db08d9bf715d08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315881303053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=NibtToa22W64F1FTTcTJScDa0XhiZsPezfqP7rsu2tE%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.7.RC1data=04%7C01%7Cnnag%40vmware.com%7Cb6149a91c0ca40afe1db08d9bf715d08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315881303053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=lBJXzLslaVVqoGnLA2f1vIObBRWA%2BVzo%2FMyv79sSvKk%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.7.RC1data=04%7C01%7Cnnag%40vmware.com%7Cb6149a91c0ca40afe1db08d9bf715d08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315881303053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Xp9YJbvqTDEBItV%2B4AJs9bam%2FtdUcMdakJ9DZyUiGBE%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.7.RC1data=04%7C01%7Cnnag%40vmware.com%7Cb6149a91c0ca40afe1db08d9bf715d08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315881303053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=f9LdQdWnWQDxuSkjqtIZVCatr5Q6k%2BJkPWRtICy3u8Q%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.7.RC1data=04%7C01%7Cnnag%40vmware.com%7Cb6149a91c0ca40afe1db08d9bf715d08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315881303053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=mu28Do6JXa4vkZ4kkmdJMxwrijulp8pErB0DuP0JpFk%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%7Cnnag%40vmware.com%7Cb6149a91c0ca40afe1db08d9bf715d08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315881303053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=hm4kbTUBY3sN67AbKGLYWQA%2BUft99vXPe47UTEiXJeM%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rcdata=04%7C01%7Cnnag%40vmware.com%7Cb6149a91c0ca40afe1db08d9bf715d08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315881303053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=jYvFt5a44QxLY7QB1VURQWH38diJU3gHhPoR7m93OlY%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2FKEYSdata=04%7C01%7Cnnag%40vmware.com%7Cb6149a91c0ca40afe1db08d9bf715d08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315881303053%7CUnknown

ANNOUNCE : Apache Geode Kafka Connector v1.1.0

[Nabarun Nag]

Hi all,

I would like to announce that Apache Geode Kafka Connector v1.1.0 has been 
released. This is also available in Confluent Hub.

Notable changes are upgrading of Log4J libraries to 2.16.0 and Apache Geode 
libraries to 1.12.6.

Binaries and source code are available at: 
https://github.com/apache/geode-kafka-connector/releases/tag/rel%2Fv1.1.0

Regards
Nabarun Nag
[https://opengraph.githubassets.com/c2a01e14394ffb0f85e3ec2470786eb2d8c1ab16f34bbcddea1ccdbf7549a9ef/apache/geode-kafka-connector/releases/tag/rel/v1.1.0]<https://github.com/apache/geode-kafka-connector/releases/tag/rel%2Fv1.1.0>
Release v1.1.0 · 
apache/geode-kafka-connector<https://github.com/apache/geode-kafka-connector/releases/tag/rel%2Fv1.1.0>
Upgraded Log4j to 2.16.0 Apache Geode upgraded to 1.12.6
github.com

Re: [VOTE] Apache Geode 1.14.1.RC2

[Nabarun Nag]

+1 to 1.14.1.RC2


  *   Build from source
  *   WAN clusters with SSL
  *   puts/gets
  *   validate data integrity after rolling restart.

Regards
Nabarun Nag

From: Owen Nichols 
Sent: Friday, December 10, 2021 2:09 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.14.1.RC2

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.14.1.RC2.
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.

EXPEDITED Voting deadline:
3PM PST Sat, December 11 2021.

Please note that we are voting upon the source tag:
rel/v1.14.1.RC2

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.1data=04%7C01%7Cnnag%40vmware.com%7C768ede9a0d4947681e2f08d9bc29b656%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709603897025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2BHgI%2FaCFlcasSSeDN1G4O%2B%2BU9RTcB0TPdX7ExIDPcyE%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.14.1.RC2%2Fdata=04%7C01%7Cnnag%40vmware.com%7C768ede9a0d4947681e2f08d9bc29b656%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709603897025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=pDmQpDNuOQ35sGkEyvyb5Y2eufC3pZURH1KX4%2ByQ6dM%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1118data=04%7C01%7Cnnag%40vmware.com%7C768ede9a0d4947681e2f08d9bc29b656%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709603897025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=T66wAExRVgmdRVVJziE%2BMyjO7LnfQRvLeNdBD%2FtH44M%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.1.RC2data=04%7C01%7Cnnag%40vmware.com%7C768ede9a0d4947681e2f08d9bc29b656%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709603897025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=wB1hb%2BmUPGSPBRCP0CKYis0UvGd9Hu7T0oXFdYks5JQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.1.RC2data=04%7C01%7Cnnag%40vmware.com%7C768ede9a0d4947681e2f08d9bc29b656%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709603897025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=EMr8gwURPdt6p%2BAim9kRtQvdfTJudK9oE%2BmlnPmIIjE%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.1.RC2data=04%7C01%7Cnnag%40vmware.com%7C768ede9a0d4947681e2f08d9bc29b656%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709603897025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=l0JIJBipkRHY8JWW9BW4A2OmkpCeNOQH%2BB1axjMTWHU%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.1.RC2data=04%7C01%7Cnnag%40vmware.com%7C768ede9a0d4947681e2f08d9bc29b656%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709603897025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=IQAzJOsAbiOU3mCqWfgSBGV7b1XGka7zL6TW1wakX5Q%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-maindata=04%7C01%7Cnnag%40vmware.com%7C768ede9a0d4947681e2f08d9bc29b656%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709603897025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=W544QqewkTcyuGH0nrxbM2JAHeKK0AjM9xQEvSV9UAE%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-rcdata=04%7C01%7Cnnag%40vmware.com%7C768ede9a0d4947681e2f08d9bc29b656%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709603897025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=KAlI%2FFdcxv0hdSnthHrkf6uSE4VwgTOS5eOVg3l5nXs%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2FKEYSdata=04%7C01%7Cnnag%40vmware.com%7C768ede9a0d4947681e2f08d9bc29b656%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709603897025

Re: [VOTE] Apache Geode 1.13.5.RC2

[Nabarun Nag]

+1 to 1.13.5.RC2


  *   Build from source
  *   WAN clusters with SSL
  *   puts/gets
  *   validate data integrity after rolling restart.

Regards
Nabarun Nag


From: Owen Nichols 
Sent: Friday, December 10, 2021 2:09 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.5.RC2

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.13.5.RC2.
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.

EXPEDITED Voting deadline:
3PM PST Sat, December 11 2021.

Please note that we are voting upon the source tag:
rel/v1.13.5.RC2

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.5data=04%7C01%7Cnnag%40vmware.com%7C17e13de4eceb4988aa9508d9bc29b472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709577804804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=y5WMNH50Y6%2FxNCKfo8KhxLLa%2FyfloH0SA08hdvhTz6s%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.5.RC2%2Fdata=04%7C01%7Cnnag%40vmware.com%7C17e13de4eceb4988aa9508d9bc29b472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709577804804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=kPzpuBa9HTvikJfQTvMecp8T0yA%2B8s%2F9MaXSH5IhQZY%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1117data=04%7C01%7Cnnag%40vmware.com%7C17e13de4eceb4988aa9508d9bc29b472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709577804804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=oRAH0XyNTpDxHEO4V3LbDyn6TGg%2FglVipiX7zhcHnNw%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.5.RC2data=04%7C01%7Cnnag%40vmware.com%7C17e13de4eceb4988aa9508d9bc29b472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709577804804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=XU9yUw3DtBGg%2FE%2FUyUZv1ls0xA0vwAWDcxVSaUkw61g%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.5.RC2data=04%7C01%7Cnnag%40vmware.com%7C17e13de4eceb4988aa9508d9bc29b472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709577804804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=PWHpBx498V8bdvCgtRWSEo0RqyjTvzp%2Bi5uUekuFGP0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.5.RC2data=04%7C01%7Cnnag%40vmware.com%7C17e13de4eceb4988aa9508d9bc29b472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709577804804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=McvQba9ZeTys5pH0fvWgP4bLiMqnxiGVQTOnfmX7NQg%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.5.RC2data=04%7C01%7Cnnag%40vmware.com%7C17e13de4eceb4988aa9508d9bc29b472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709577804804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=egKl%2FLT9ZM2H4eZYby7QwCZM3YzEBy5j%2BNSNeMBDsBQ%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%7Cnnag%40vmware.com%7C17e13de4eceb4988aa9508d9bc29b472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709577804804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=GFe%2F3mnlMkW5PReklgSVG19C%2BP%2BAG8BCReSWGo91pEg%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%7Cnnag%40vmware.com%7C17e13de4eceb4988aa9508d9bc29b472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709577804804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=GnjtXDRkCy6Rm5%2B0MGtYKPQbvE%2BpJOKmUcuxdzvwdrQ%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2FKEYSdata=04%7C01%7Cnnag%40vmware.com%7C17e13de4eceb4988aa9508d9bc29b472%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709577804804

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.6.RC2

[Nabarun Nag]

+1 to 1.12.6.RC2


  *   Build from source
  *   WAN clusters with SSL
  *   puts/gets
  *   validate data integrity after rolling restart.

Regards
Nabarun Nag


From: Owen Nichols 
Sent: Friday, December 10, 2021 2:08 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.6.RC2

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.12.6.RC2.
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.

EXPEDITED Voting deadline:
3PM PST Sat, December 11 2021.

Please note that we are voting upon the source tag:
rel/v1.12.6.RC2

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.6data=04%7C01%7Cnnag%40vmware.com%7C19313e99e6a440b8aedb08d9bc29b377%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709562961934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=S8jKcBCFw1d6xFoqDkxjpnzYl0ZRLBb0XJ3XtZX80Ug%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.6.RC2%2Fdata=04%7C01%7Cnnag%40vmware.com%7C19313e99e6a440b8aedb08d9bc29b377%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709562961934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=VE%2Bl7oNNm0BhUF1VUA3ID1ljex9o54N7%2FqSM3J8zNIY%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1119data=04%7C01%7Cnnag%40vmware.com%7C19313e99e6a440b8aedb08d9bc29b377%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709562961934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=eNmxePKXKz1LlZ985cw3SltKGfqkJ%2BasF55TYr5ceqU%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.6.RC2data=04%7C01%7Cnnag%40vmware.com%7C19313e99e6a440b8aedb08d9bc29b377%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709562961934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=XeC8Gd4eiLNMPOL0WErHM1wceQnXKxugpTl7V1S20r8%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.6.RC2data=04%7C01%7Cnnag%40vmware.com%7C19313e99e6a440b8aedb08d9bc29b377%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709562961934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=eAynqL0xluzRAGAHVvT8xRvv%2F5x4L%2BHgT%2BYC5Ul9rDQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.6.RC2data=04%7C01%7Cnnag%40vmware.com%7C19313e99e6a440b8aedb08d9bc29b377%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709562961934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=epEAKxXKODGWfol%2BWrBsw3Rh2Ye4Dc5DRiHvLHqFATY%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.6.RC2data=04%7C01%7Cnnag%40vmware.com%7C19313e99e6a440b8aedb08d9bc29b377%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709562961934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=QukVZPDM2a48dTSCtA%2FclSMmlkPyVXPhq5OPEa7UKeU%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%7Cnnag%40vmware.com%7C19313e99e6a440b8aedb08d9bc29b377%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709562961934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=UaDN8n%2FvK%2BvUDFS%2Bn5he%2F3n%2Fr1mjQhfI4wVUmtrE6HM%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rcdata=04%7C01%7Cnnag%40vmware.com%7C19313e99e6a440b8aedb08d9bc29b377%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709562961934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=QXqTMXfp2VFjpz%2FIXBHDjC9R5lHhyEAvBZW2SUKHcJk%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2FKEYSdata=04%7C01%7Cnnag%40vmware.com%7C19313e99e6a440b8aedb08d9bc29b377%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709562961934

Re: [VOTE] Apache Geode 1.12.5.RC1

[Nabarun Nag]

+1 to 1.12.5.RC4


  *   WAN
  *   Rolling restart from 1.12.4
  *   puts/gets
  *   validate data integrity after rolling restart.

Regards,
Nabarun



From: Dan Smith 
Sent: Friday, October 22, 2021 9:26 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.12.5.RC1

+1 to 1.12.5.RC4. Reviewed changes, geode-release-check.

-Dan


From: Dave Barnes 
Sent: Thursday, October 21, 2021 3:30 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] Re: [VOTE] Apache Geode 1.12.5.RC1

+1 docs check out: javadocs, user guide (manual build), user guide (script
build)


On Wed, Oct 20, 2021 at 4:33 PM Dick Cavender  wrote:

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.12.5.RC4.
> Earlier RC1, RC2 and RC3 had issues.
> 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 Mon, October 25 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.5.RC4
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.5data=04%7C01%7Cnnag%40vmware.com%7Cbd706d67b3b14f51895208d99578ba48%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637705168032249513%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=RG3br7rogGiZDgiiP3GhBsmcufBAM03HnekXYmg29kY%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.5.RC4%2Fdata=04%7C01%7Cnnag%40vmware.com%7Cbd706d67b3b14f51895208d99578ba48%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637705168032249513%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=CTF%2F5FfCxbLtHtgyElgPcgQ3j1KFee9I%2Bs5jNiZGNKk%3Dreserved=0
>
> Maven staging repo:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1113data=04%7C01%7Cnnag%40vmware.com%7Cbd706d67b3b14f51895208d99578ba48%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637705168032259508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=SMS%2BBPo4xdMv4Ad%2B5L7GcgjKNG6IkQLOoATMbJOfSY0%3Dreserved=0
>
> GitHub:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.5.RC4data=04%7C01%7Cnnag%40vmware.com%7Cbd706d67b3b14f51895208d99578ba48%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637705168032259508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=fLLXtqzdX%2Bcpz5nZ0lQoAPbfn7i%2FXehC7SKnGBkKNqg%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.5.RC4data=04%7C01%7Cnnag%40vmware.com%7Cbd706d67b3b14f51895208d99578ba48%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637705168032259508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=co6jPgNvGXf2i%2BJJOeYvJgi%2FMv2BDC8WcZuTGMuqVAQ%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.5.RC4data=04%7C01%7Cnnag%40vmware.com%7Cbd706d67b3b14f51895208d99578ba48%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637705168032259508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=7tGbXieHVsqg62AcWJTQUoi6BNre1uTABLzc9P6B1ik%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.5.RC4data=04%7C01%7Cnnag%40vmware.com%7Cbd706d67b3b14f51895208d99578ba48%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637705168032259508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=dVBLIZlI4OLWHYJM%2FKaRkM23nL3m63okthvDk75M9YE%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%7Cnnag%40vmware.com%7Cbd706d67b3b14f51895208d99578ba48%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637705168032259508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=tPLEWN7VKxVmdm02KxJAx6wzI8jJBWrDBLcQNcVzAEA%3Dreserved=0
>
> 

Re: [DISCUSS] Upgrading to Lucene 7.1.0

[Nabarun Nag]

But Mario, just for my clarification, if we re-enable the queries in the tests 
in the mixed version servers mode, it goes into a stackoverflow situation. That 
what i saw when i set hasLuceneVersionMismatch(host) to false in the test so 
that it does the query.

Regards
Naba


From: Mario Kevo 
Sent: Tuesday, September 28, 2021 4:49 AM
To: dev@geode.apache.org 
Subject: Odg: [DISCUSS] Upgrading to Lucene 7.1.0

Hi all,

Just a small clarification of the reverted PR.

There were a lot of changes between Lucene versions 6.x and 7.x. There is an 
article for that 
Upgrading+to+Lucene+7.1.0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FUpgrading%2Bto%2BLucene%2B7.1.0data=04%7C01%7Cnnag%40vmware.com%7C1e6e4524534549d419cf08d982760f65%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637684265872534660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=jTD3ZIUk69DR77NWRMaS%2BG2ajpPa1Spgg0q1iYxc34I%3Dreserved=0>.

The first larger change was in the scoring mechanism. We adapt it to one that 
is correct for us. (verified by DistributedScoringJUnitTest)

The main change was in Lucene index format. There we come into a problem with 
our tests.
Lucene 6.x cannot read the index format of Lucene 7.x.
Through PRs we decided to include Lucene uplift in Geode 1.15.0 and add check 
if all members are on 1.15.0 version or higher (after uplift Lucene to a newer 
version with index format changes this should be changed). If a check is passed 
it will allow doing Lucene query, if not there will be a printed log that not 
all members on 1.15.0 or higher version.

Also, you can found a discussion on dev list from 2 years ago about Lucene 
upgrade: Lucene 
Upgrade<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarkmail.org%2Fmessage%2Fqwooctuz7ekaezor%3Fq%3Dlist%3Aorg.apache.geode.dev%2Border%3Adate-backward%2BLucene%2Bupgrade%26page%3D4%23query%3Alist%253Aorg.apache.geode.dev%2520order%253Adate-backward%2520Lucene%2520upgrade%2Bpage%3A4%2Bmid%3Aygjhsuikdrbuihap%2Bstate%3Aresultsdata=04%7C01%7Cnnag%40vmware.com%7C1e6e4524534549d419cf08d982760f65%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637684265872544660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=E%2FIR9IdWMBWOrZl%2FYYnRHOOuLccmbvet6fyOgx%2FFeBk%3Dreserved=0>

BR,
Mario




Šalje: Udo Kohlmeyer 
Poslano: 28. rujna 2021. 1:44
Prima: dev@geode.apache.org 
Predmet: Re: [DISCUSS] Upgrading to Lucene 7.1.0

Might I propose something here.

There is currently a significant amount of work going into completing 
Geode-8705, which is the Classloader isolation. We are currently targeting to 
getting this release in Geode 1.16.

My proposal is, that we use the capability that Patrick demo’d at the Community 
meeting (on this topic) where one, at runtime, can unload /  load extensions 
(like our integration with Lucene). This means that one could possibly do a 
rolling upgrade on the existing system, and keep the versions of the Lucene 
integration stable.

Once the whole system has been upgraded, the existing Lucene extension 
component is then unloaded, and the newer version of the extension component is 
then loaded. What this means, is that at runtime, there will be a period of 
time where Lucene queries will not be available and as part of the “load” 
lifecycle of the extension, there needs to be an initialization step, which 
will initialize the extension component safely.

Once initialized, Lucene queries can then become available again, etc.

This if course requires some work around the lifecycles of extension components 
and making sure that I can add the extension on at runtime and safely 
initialize it.

I think this approach allows for a more seamless (lower downtime) upgrading of 
system and extension components.

Thoughts?

--Udo

From: Nabarun Nag 
Date: Tuesday, September 28, 2021 at 7:33 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Upgrading to Lucene 7.1.0
The solution for preventing the query executions to occur in the mixed version 
mode also caused some problems where the query function executions get 
repeatedly executed and that results in stack overflow.


____
From: Nabarun Nag 
Sent: Monday, September 27, 2021 2:30 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Upgrading to Lucene 7.1.0

In simple words,  if Lucene indexes were created by a new version (7.1.0), then 
replicated to others that are still in the older version, they won't understand 
the index, and the event processors start throwing exceptions.

This can be simply seen by just re-enabling the query execution in the DUnit 
tests and commenting out the check blocks: [develop SHA: 
68629356f561a932f5dfbace70b01d9971a42473]

In LuceneEventListener
if (cache.hasMemberOlderThan(KnownVersion.

Re: [DISCUSS] Upgrading to Lucene 7.1.0

[Nabarun Nag]

The solution for preventing the query executions to occur in the mixed version 
mode also caused some problems where the query function executions get 
repeatedly executed and that results in stack overflow.



From: Nabarun Nag 
Sent: Monday, September 27, 2021 2:30 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Upgrading to Lucene 7.1.0

In simple words,  if Lucene indexes were created by a new version (7.1.0), then 
replicated to others that are still in the older version, they won't understand 
the index, and the event processors start throwing exceptions.

This can be simply seen by just re-enabling the query execution in the DUnit 
tests and commenting out the check blocks: [develop SHA: 
68629356f561a932f5dfbace70b01d9971a42473]

In LuceneEventListener
if (cache.hasMemberOlderThan(KnownVersion.GEODE_1_15_0)) {
  logger.info("Some members are older than " + 
KnownVersion.GEODE_1_15_0.getName());
  return false;
}

In IndexRepositoryFactory:
if (userRegion.getCache() != null
&& userRegion.getCache().hasMemberOlderThan(KnownVersion.GEODE_1_15_0)) 
{
  logger.info("Some members are older than " + 
KnownVersion.GEODE_1_15_0.getName());
  return null;
}


This is the exception that will be encountered:

[Exception]

[vm2_v1.2.0] [warn 2021/09/27 14:24:42.251 PDT  tid=102] An Exception occurred. 
The dispatcher will continue.
[vm2_v1.2.0] org.apache.geode.InternalGemFireError: Unable to create index 
repository
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.AbstractPartitionedRepositoryManager.lambda$computeRepository$0(AbstractPartitionedRepositoryManager.java:118)
[vm2_v1.2.0] at 
java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1853)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.AbstractPartitionedRepositoryManager.computeRepository(AbstractPartitionedRepositoryManager.java:108)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.AbstractPartitionedRepositoryManager.getRepository(AbstractPartitionedRepositoryManager.java:137)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.AbstractPartitionedRepositoryManager.getRepository(AbstractPartitionedRepositoryManager.java:76)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.LuceneEventListener.process(LuceneEventListener.java:87)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.LuceneEventListener.processEvents(LuceneEventListener.java:64)
[vm2_v1.2.0] at 
org.apache.geode.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:154)
[vm2_v1.2.0] at 
org.apache.geode.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:80)
[vm2_v1.2.0] at 
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:609)
[vm2_v1.2.0] at 
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:1051)
[vm2_v1.2.0] Caused by: org.apache.lucene.index.IndexFormatTooNewException: 
Format version is not supported (resource 
BufferedChecksumIndexInput(segments_2)): 7 (needs to be between 4 and 6)
[vm2_v1.2.0] at 
org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:216)
[vm2_v1.2.0] at 
org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:302)
[vm2_v1.2.0] at 
org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:286)
[vm2_v1.2.0] at org.apache.lucene.index.IndexWriter.(IndexWriter.java:938)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.IndexRepositoryFactory.computeIndexRepository(IndexRepositoryFactory.java:84)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.PartitionedRepositoryManager.computeRepository(PartitionedRepositoryManager.java:42)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.AbstractPartitionedRepositoryManager.lambda$computeRepository$0(AbstractPartitionedRepositoryManager.java:116)
[vm2_v1.2.0] ... 10 more



Also:
[vm2_v1.2.0] [warn 2021/09/27 14:24:42.134 PDT  tid=106] An Exception occurred. 
The dispatcher will continue.
[vm2_v1.2.0] org.apache.geode.InternalGemFireError: Unable to create index 
repository
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.AbstractPartitionedRepositoryManager.lambda$computeRepository$0(AbstractPartitionedRepositoryManager.java:118)
[vm2_v1.2.0] at 
java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1853)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.AbstractPartitionedRepositoryManager.computeRepository(AbstractPartitionedRepositoryManager.java:108)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.AbstractPartitionedRepositoryManager.getRepository(AbstractPartitionedRepositoryManager.java:137)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.AbstractPartitionedRepositoryManager.getRepository(AbstractPartitio

Re: [DISCUSS] Upgrading to Lucene 7.1.0

[Nabarun Nag]

tCallbackDispatcher.java:154)
[vm2_v1.2.0] at 
org.apache.geode.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:80)
[vm2_v1.2.0] at 
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:609)
[vm2_v1.2.0] at 
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:1051)
[vm2_v1.2.0] Caused by: org.apache.lucene.index.IndexFormatTooNewException: 
Format version is not supported (resource 
BufferedChecksumIndexInput(segments_2)): 7 (needs to be between 4 and 6)
[vm2_v1.2.0] at 
org.apache.lucene.codecs.CodecUtil.checkHeaderNoMagic(CodecUtil.java:216)
[vm2_v1.2.0] at 
org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:302)
[vm2_v1.2.0] at 
org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:286)
[vm2_v1.2.0] at org.apache.lucene.index.IndexWriter.(IndexWriter.java:938)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.IndexRepositoryFactory.computeIndexRepository(IndexRepositoryFactory.java:84)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.PartitionedRepositoryManager.computeRepository(PartitionedRepositoryManager.java:42)
[vm2_v1.2.0] at 
org.apache.geode.cache.lucene.internal.AbstractPartitionedRepositoryManager.lambda$computeRepository$0(AbstractPartitionedRepositoryManager.java:116)
[vm2_v1.2.0] ... 10 more



From: Jacob Barrett 
Sent: Monday, September 27, 2021 2:08 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Upgrading to Lucene 7.1.0



> On Sep 27, 2021, at 11:48 AM, nabarun nag  wrote:
>
> Recently, a commit was pushed to develop which upgraded the Lucene
> version used in Apache Geode to 7.1.0. These new Lucene indexes are
> not compatible with the previous versions hence it breaks the rolling
> upgrade contract. We are no longer able to execute Lucene queries when
> there are severs of mixed versions in the cluster.


Can you describe the problem with a little more detail? Does this mean that 
while there is a mix the execution throws an exception on all servers or is 
there a subset for which it works? If there is a subset for which it works, are 
those instances sufficient to provide accurate results if the instances that 
fail are ignored?

-Jake

[DISCUSS] Upgrading to Lucene 7.1.0

[nabarun nag]

Hi dev team,

Recently, a commit was pushed to develop which upgraded the Lucene
version used in Apache Geode to 7.1.0. These new Lucene indexes are
not compatible with the previous versions hence it breaks the rolling
upgrade contract. We are no longer able to execute Lucene queries when
there are severs of mixed versions in the cluster. One solution that
was provided was to not allow Lucene queries to be executed when there
are mixed versions of servers present in the cluster.

After a discussion, it was put forward that this was not an optimal
user experience. Also, that this change of default behavior was not
discussed in the dev list.

Alternative solutions that were put forward were that Geode allowed
the user to pick the version of Lucene to be used. Another that since
this is a major upgrade to Lucene with some breaking API changes,
should we sync this upgrade with the release of Apache Geode 2.0

We would love to hear your thoughts or alternative solutions to this issue.

Regards
Nabarun.

[ANNOUNCE] Apache Geode 1.14.0

[nabarun nag]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.14.0

Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with high concurrency
processing.

This release includes a significant number of bug fixes, improvements
in current behavior along with the addition of a few statistics to
monitor the cluster health.

Few notable changes are:

1. The creation of OQL indexes now works on sub-regions.
2. Proper exceptions are thrown when a region is destroyed during
function execution.
3. Daemon threads are now used while rebalancing regions.
4. Gateway receivers can be configured with the same
hostname-for-senders and port. The reason for such a setup is
deploying a Geode cluster on a Kubernetes cluster where all GW
receivers are reachable from the outside world on the same IP and
port.
5. Disk stores are recovered in parallel during cluster restarts.
6. New option in GFSH command "start gateway sender" to control
clearing of existing queues.
7. New member field added in OQL query GFSH command to point to the
member on which the query will be executed.
8. No more ConcurrentModificationException when using JTA transactions.
9. Setting SNI server name is now not needed if endpoint verification
is disabled.
10. A new REST interface for disk-store creation has been introduced.
11. GFSH command to create defined indexes now works if connected to a
new locator which joined the cluster after indexes were defined.
12. Session state modules dependencies were cleaned up and made more efficient.
13. Limited retries while trying to create Lucene indexes to prevent
stack overflow issues.
14. A new statistic was added to get the heap memory occupied by the
gateway sender's queue.
15. maximum-time-between-pings set when creating a gateway receiver is
now honored instead of being ignored.
16. Deadlocks are prevented when java garbage collection and tombstone
collection occur simultaneously.
17. 'conserve-sockets' default value is now set to false when the
members are started.
18. Slower receivers with async-distribution-timeout greater than 0
are now not allowed with cluster TLS/SSL.
19. Clients trying to register interest in an older version server
will now receive a ServerRefusedConnectionException.
20. The speed of registering interest during rolling upgrades has been improved.
21. A new feature was added to print out the tenured heap in the log
files after garbage collection.
22. Bucket statistics were fixed.

For the full list of changes please review the release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.14.0

The release artifacts can be downloaded from the project website:
https://geode.apache.org/releases/

The release documentation is available at:
https://geode.apache.org/docs/guide/114/about_geode.html

We would like to thank all the contributors that made the release possible.
Regards,
Nabarun Nag on behalf of the Apache Geode team

Apache Geode 1.14.0 RELEASE

[nabarun nag]

It's past the announced deadline and we have enough votes to close the vote.
Thank you to all for your time to validate the release candidate

Voting status
==
+1: 7 binding votes
* Donal Evans  (PMC member)
* Dave Barnes (PMC member)
* Jianxia Chen <https://home.apache.org/phonebook.html?uid=jchen21> (PMC
member)
* John Blum (PMC member)
* Dan Smith (PMC member)
* Donal Evans (PMC member)
* Jason Huynh (PMC member)
* Mario Kevo (Committer)

+0: zero votes

-0: zero votes

-1: zero votes

The voting meets the requirements of at least 3 PMC members with +1
votes and has the required majority of +1 votes.

Apache Geode 1.14.0.RC2 has passed the vote and we will finalize the
release shortly.

Thanks everyone for the great work!

-Nabarun Nag

[VOTE] Apache Geode 1.14.0.RC2

[nabarun nag]

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.14.0.RC2.
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: Please note that this is an expedited voting process
3PM PST Thur, September 02 2021.

Please note that we are voting upon the source tag:
rel/v1.14.0.RC2

Release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.14.0

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.14.0.RC2/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachegeode-1098

GitHub:
https://github.com/apache/geode/tree/rel/v1.14.0.RC2
https://github.com/apache/geode-examples/tree/rel/v1.14.0.RC2
https://github.com/apache/geode-native/tree/rel/v1.14.0.RC2
https://github.com/apache/geode-benchmarks/tree/rel/v1.14.0.RC2

Pipelines:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-rc

Geode's KEYS file containing PGP keys we use to sign the release:
https://github.com/apache/geode/blob/develop/KEYS

Command to run geode-examples:
./gradlew -PgeodeReleaseUrl=
https://dist.apache.org/repos/dist/dev/geode/1.14.0.RC2
-PgeodeRepositoryUrl=
https://repository.apache.org/content/repositories/orgapachegeode-1098
build runAll

Regards
Naburun Nag

Re: [INFO] Apache Geode 1.14.0 Release Manager

[Nabarun Nag]

Hi Alberto,

We are starting tests this weekend, and with the condition that the tests are 
all good, we should have a release candidate for voting next week. I will keep 
you updated!

Regards
Nabarun

From: Alberto Gomez 
Sent: Tuesday, August 24, 2021 2:58 AM
To: dev@geode.apache.org 
Subject: Re: [INFO] Apache Geode 1.14.0 Release Manager

Hi Naba,

Is there any new information about the 1.14 Geode release?

Thanks in advance,

Alberto

From: Nabarun Nag 
Sent: Tuesday, June 1, 2021 6:46 PM
To: dev@geode.apache.org 
Subject: Re: [INFO] Apache Geode 1.14.0 Release Manager

Hi Alberto,

For releasing 1.14 we are waiting on two more backports.

GEODE-8609 - DUnit runners were not checking the logs for suspicious 
errors/fatal messages in VMs that were being restarted in a test. A fix is 
ready and is in PR review stage[1]

GEODE-9289 - A problem with Cluster Configuration where a new locator sends its 
configuration to an old locator, the old locator is unable to deserialize it, 
causes NPEs and clears out certain fields in the configuration. A PR is ready 
and is in review phase but this will need GEODE-8609 checked in first.[2]

Once these two PRs are merged and backported, we are going to start the process 
for voting on the release branch and release candidates. My personal estimate 
is that we can start with the voting process within next week, if we do not 
detect any serious issues.

Please do reach out if you require any additional information.

Regards,
Nabarun

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6526data=04%7C01%7Cnnag%40vmware.com%7C60c8954316a542ace8e608d966e5b527%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637653959043733474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZZDeZkEiKWyaEGqMjxvZu7T6rZKhqsSD%2BnYDx6Fd060%3Dreserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6495data=04%7C01%7Cnnag%40vmware.com%7C60c8954316a542ace8e608d966e5b527%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637653959043733474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=cP9cmUb1tVoULPx6brwoChMSpeJiEU0AFFTgKhwsC6M%3Dreserved=0

From: Alberto Gomez 
Sent: Monday, May 31, 2021 8:08 AM
To: dev@geode.apache.org 
Subject: Re: [INFO] Apache Geode 1.14.0 Release Manager

Hi Naba,

Can you please provide some information about how the 1.14 release is going and 
if is there any planned date for it?

Thanks in advance,

Alberto

From: Nabarun Nag 
Sent: Monday, March 22, 2021 5:27 PM
To: dev@geode.apache.org 
Subject: [INFO] Apache Geode 1.14.0 Release Manager

Hi everyone,

I hope you all are doing well. This is to inform the Apache Geode community 
that I will be volunteering as the Release Manager for 1.14.0 release. Thank 
you, Owen, for all the work that has been done to get the release to this point.

As for backporting, as a developer, you just need to create a PR against the 
support/1.14 branch, and you are done. As a release manager, I will take over 
from there.

Just ensure the following:

  *   The PR is a cherry-pick (cherry-pick -x) of a commit that is already in 
develop
  *   Ensure that there are no merge conflicts.

Regards
Nabarun Nag

Re: [VOTE] Apache Geode 1.13.4.RC1

[Nabarun Nag]

+1 based on the following:

  *   build from source
  *   running gfsh
  *   starting 2 site WAN cluster with ssl security enabled
  *   verifying data propagation from the 2 sites using puts and gets
  *   Rolling clusters from 1.12 to the release candidate.
  *   Rebalance operations during upgrades.


From: Dick Cavender 
Sent: Wednesday, July 28, 2021 2:49 PM
To: dev@geode.apache.org 
Subject: [VOTE] Apache Geode 1.13.4.RC1

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.13.4.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 Fri, July 30 2021
*NOTE: THIS IS AN  ABBREVIATED 2 DAY VOTE *

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.4data=04%7C01%7Cnnag%40vmware.com%7Cbbcf652af3364ad1d54f08d9521191e0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057684181664%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=eqCEV6vy0ZdBVTNoECM9C%2BkT7F%2FN4ToCthQ3RHefNLM%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.4.RC1%2Fdata=04%7C01%7Cnnag%40vmware.com%7Cbbcf652af3364ad1d54f08d9521191e0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057684181664%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yo2j2NEezL7CppnY5i9lbTm53oqziy1leDwQRfG4EU8%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1087data=04%7C01%7Cnnag%40vmware.com%7Cbbcf652af3364ad1d54f08d9521191e0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057684191659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Amgp8sKQ1ybGOiduQlSK7rr5Qhc6phETeAyul6fMlow%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.4.RC1data=04%7C01%7Cnnag%40vmware.com%7Cbbcf652af3364ad1d54f08d9521191e0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057684191659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=xgrofKpe2nYBsdzApFU%2F74b%2FmaJavY4Cq6%2FtRh60ZFM%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.4.RC1data=04%7C01%7Cnnag%40vmware.com%7Cbbcf652af3364ad1d54f08d9521191e0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057684191659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=GEHh0AXqsXurox%2FM3PHjjYzZJgvqPpa8Ogs%2BgFzEsvk%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.4.RC1data=04%7C01%7Cnnag%40vmware.com%7Cbbcf652af3364ad1d54f08d9521191e0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057684191659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=1pvgB82Qmo5o%2BsStB0my0zMM%2F1maKuMLf%2B69dneBzII%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.4.RC1data=04%7C01%7Cnnag%40vmware.com%7Cbbcf652af3364ad1d54f08d9521191e0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057684191659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nqa%2FQziQXkleQY9LQTXQfr2IWEuHQFFsKH1JXoPy9Zo%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%7Cnnag%40vmware.com%7Cbbcf652af3364ad1d54f08d9521191e0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057684191659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RVBi0pBevzehYBjSvpxvY3G93ganPaVcmiymFGvjxY8%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%7Cnnag%40vmware.com%7Cbbcf652af3364ad1d54f08d9521191e0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057684191659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TQjgIRVS22j9k2Gan5IuUWL1SEzvHlBdpwdjQTp11a0%3Dreserved=0

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

Re: [DISCUSS] Backporting to support branches

[Nabarun Nag]

This was done to reduce the workload on the developers.
It's a kind of "fire and forget" methodology.
Why make the author come back and merge the PR after my(release manager's) 
approval when I can do it myself.

But yeah, blocking the PR, till the release manager approves it makes sense.


Regards
Nabarun


From: Jacob Barrett 
Sent: Tuesday, June 29, 2021 4:44 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Backporting to support branches

Why not a model where the release manager is a blocking review and let the 
author merge only when they blocking review is complete? That makes the process 
largely identical to that of the develop branch abs removes this ambiguity of 
who merges and when.

> On Jun 29, 2021, at 4:19 PM, Nabarun Nag  wrote:
>
> I just do the merging to have a sanitized and approved list of PRs go into 
> the support/1.14. Limit the number of commits that may cause an explosion.
>
> Also, I communicate with the author about PR, if it is ready to be merged or 
> if I have concerns about the PR.
>
> I will not merge your PR but feel free to ping me when all your testing is 
> done and then I will take the necessary steps.
>
> Regards,
> Nabarun
> 
> From: Owen Nichols 
> Sent: Tuesday, June 29, 2021 3:51 PM
> To: dev@geode.apache.org 
> Subject: Re: [DISCUSS] Backporting to support branches
>
> Hi Naba, is it still the case that only you will merge the PRs to 
> support/1.14?  Or can committers merge their own 1.14 PRs anytime after you 
> have approved the PR?
>
> I sometimes forget to create my PRs in Draft mode, and may still be running 
> additional tests, so I'd prefer not to have anyone but me merging my PR.
>
> On 3/19/21, 10:47 AM, "Nabarun Nag"  wrote:
>
>Just a small change, a PR against the support branch is enough. (No need 
> to add reviewers etc.). I just realized we can filter on a branch in the PR 
> list.
>
>Regards,
>Nabarun
>
>From: Nabarun Nag 
>Sent: Friday, March 19, 2021 10:31 AM
>To: dev@geode.apache.org 
>Subject: [DISCUSS] Backporting to support branches
>
>Hi,
>
>I would like to propose that if any JIRA needs to be backported to support 
> branches:
>
>For Developers:
>
>  *   Add the label "blocks-1.1x" to the JIRA ticket
>  *   There is no need to send out a PROPOSAL email to dev
>  *   Just create the cherry-picked  PR to the support branch and tag the 
> Release Manager as a reviewer or just tag in the comments section if you are 
> not a committer. (ensure no merge conflicts)
>
>NOTE: Ensure that the commit you are trying to backport is already merged 
> into develop. Also, the PR against the support branch needs to be a cherry 
> pick. (git cherry-pick -x)
>
>For Release Manager:
>
>  *   Monitor the release dashboard for "blocks-1.1x" tickets
>  *   Send out communications if there are any issues.
>  *   Squash-merge the PR if it the commit message is properly structured 
> with cherry pick message in the last line.
>
>Regards
>Nabarun
>
>
>
>

Re: [DISCUSS] Backporting to support branches

[Nabarun Nag]

I just do the merging to have a sanitized and approved list of PRs go into the 
support/1.14. Limit the number of commits that may cause an explosion.

Also, I communicate with the author about PR, if it is ready to be merged or if 
I have concerns about the PR.

I will not merge your PR but feel free to ping me when all your testing is done 
and then I will take the necessary steps.

Regards,
Nabarun

From: Owen Nichols 
Sent: Tuesday, June 29, 2021 3:51 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Backporting to support branches

Hi Naba, is it still the case that only you will merge the PRs to support/1.14? 
 Or can committers merge their own 1.14 PRs anytime after you have approved the 
PR?

I sometimes forget to create my PRs in Draft mode, and may still be running 
additional tests, so I'd prefer not to have anyone but me merging my PR.

On 3/19/21, 10:47 AM, "Nabarun Nag"  wrote:

Just a small change, a PR against the support branch is enough. (No need to 
add reviewers etc.). I just realized we can filter on a branch in the PR list.

Regards,
Nabarun

From: Nabarun Nag 
Sent: Friday, March 19, 2021 10:31 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Backporting to support branches

Hi,

I would like to propose that if any JIRA needs to be backported to support 
branches:

For Developers:

  *   Add the label "blocks-1.1x" to the JIRA ticket
  *   There is no need to send out a PROPOSAL email to dev
  *   Just create the cherry-picked  PR to the support branch and tag the 
Release Manager as a reviewer or just tag in the comments section if you are 
not a committer. (ensure no merge conflicts)

NOTE: Ensure that the commit you are trying to backport is already merged 
into develop. Also, the PR against the support branch needs to be a cherry 
pick. (git cherry-pick -x)

For Release Manager:

  *   Monitor the release dashboard for "blocks-1.1x" tickets
  *   Send out communications if there are any issues.
  *   Squash-merge the PR if it the commit message is properly structured 
with cherry pick message in the last line.

Regards
Nabarun

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

[Nabarun Nag]

Looking at the positive feedback, to this, I am skipping the red tape of 
creating a separate vote thread. The PR has been created and reviewed.[1]


Regards,
Nabarun

[1] https://github.com/apache/geode/pull/6661



From: Darrel Schneider 
Sent: Tuesday, June 29, 2021 9:13 AM
To: dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

+1

From: Jens Deppe 
Sent: Tuesday, June 29, 2021 7:44 AM
To: dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

+1 For Naba’s proposal

From: Joris Melchior 
Date: Tuesday, June 29, 2021 at 7:40 AM
To: dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 for Naburan’s proposed options.

From: Nabarun Nag 
Date: Monday, June 28, 2021 at 4:06 PM
To: Owen Nichols , dev@geode.apache.org 

Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.

The options I am proposing to be kept in the PRs are:

  *   Squash and merge
  *   Rebase and merge

Regards,
Nabarun

From: Owen Nichols 
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag ; dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Sounds like a good idea. I can’t find any example of an intentional merge 
commit on develop…but plenty of accidental ones.

Upon releases we do a command line merge commit to the main trunk, which should 
still be fine as this proposal only applies to PRs.

I agree with still allowing rebase commits. I have seen several PRs use them to 
good effect.

You can disable merge commits through .asf.yaml, so changing the setting is as 
easy as opening a PR (and, if we don’t like it, reverting is just as easy)


---
Sent from Workspace ONE 
Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=04%7C01%7Cnnag%40vmware.com%7C7bf2d2f76d0b4178ced608d93b18d831%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605800176784198%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=gm1WMtsbaSzCffY84dCjCEgNSSezeROj24bVWupCQoo%3Dreserved=0>

On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag  wrote:
Hi all,

Last year, we had a discussion on rebase and squash merge PRs to the develop 
branch,

  *   to have linear git history
  *   help with bisecting
  *   easier root cause analysis of failures
  *   easier to backport changes

However, many developers have reached out mentioning that sometimes they have 
clicked the merge button in hurry when they meant to rebase/squash. Once 
clicked there is no going back. All of them suggested that to have the GitHub 
setting on develop branch to rebase and squash merge option and hence there is 
no room for mistakes to occur.

I would like to propose to that we set the GitHub setting on develop PR to 
rebase and squash buttons.

Please do note that this is reversible and can be changed back, hence there is 
no harm in trying it out.


Regards
Nabarun Nag



From: Owen Nichols (Pivotal) 
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org 
Subject: Re: [REQUEST] Squash merge please

I’ve noticed quite a few PRs in the last week that were merged with “Merge” 
rather than “Squash and Merge”.

While the community consensus was to continue to allow all merge options, 
please try to default to “Squash and Merge” whenever you can to keep history as 
linear as possible. GitHub will save the last method you used in a cookie, 
which helps, but then it’s easy to miss when it resets itself back to the 
default of “Merge” some months later because you cleared cookies, changed 
browsers, etc.

> On 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: [Suspected Spam] [VOTE] Apache Geode 1.12.3.RC3

[Nabarun Nag]

+1 based on the following:

  *   build from source
  *   running gfsh
  *   starting 2 site WAN cluster
  *   verifying data propagation from the 2 sites using puts and gets
  *   Rolling clusters from 1.12 to the release candidate.
  *   Rebalance operations during upgrades.



From: Owen Nichols 
Sent: Friday, June 25, 2021 1:15 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.3.RC3

Hello Geode Dev Community,

I'd like to propose a 1.12 patch release.

This is a release candidate for Apache Geode version 1.12.3.RC3.
Note: This is the first vote email due to a build issue with the first two RCs.
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 PDT Wed, June 30 2021.

Please note that we are voting upon the source tag:
rel/v1.12.3.RC3

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=HS9vNQnqaQ61%2F6t6dS%2F5A8DxugClKwc%2BrJMXnaLVs7Q%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.3.RC3%2Fdata=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=56Fa2%2BC%2Bv2uCLxa6iRchEynUS%2B6OZAspwmwXzsya4eM%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1084data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=iqjfSfVDYzuaj%2FzJs8YRLedEGBmI%2Fr4xTLFWMgRqzEg%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KLkcUfgn1ZkXB6OBwOVzkECUCd1xU7YZWd1mc%2FZAlIU%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=AQ8H4jHhSPm9f9evixDBNQJdJl0cWLOwGey8%2BkSf9Y0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8IykbiM2prxCQ1tMM%2Ft15gryVmvc6jUFjegwplbBxGw%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Gxw%2FT0BQPjiOmjlR8Sv4jwGj0wm8Z%2BSW4FUUnBQh8QE%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%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=y6ln0WC5b%2BVKdgIOR6W%2BLTbI4IUhG0p0u1A8YiqhDdk%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rcdata=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=LO4BQWVFjjGKOUX1XPEIEwT98PGtzPyCCS07mn2dCTU%3Dreserved=0

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

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

[Nabarun Nag]

Just a clarification.

The options I am proposing to be kept in the PRs are:

  *   Squash and merge
  *   Rebase and merge

Regards,
Nabarun

From: Owen Nichols 
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag ; dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Sounds like a good idea. I can’t find any example of an intentional merge 
commit on develop…but plenty of accidental ones.

Upon releases we do a command line merge commit to the main trunk, which should 
still be fine as this proposal only applies to PRs.

I agree with still allowing rebase commits. I have seen several PRs use them to 
good effect.

You can disable merge commits through .asf.yaml, so changing the setting is as 
easy as opening a PR (and, if we don’t like it, reverting is just as easy)


---
Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer>

On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag  wrote:
Hi all,

Last year, we had a discussion on rebase and squash merge PRs to the develop 
branch,

  *   to have linear git history
  *   help with bisecting
  *   easier root cause analysis of failures
  *   easier to backport changes

However, many developers have reached out mentioning that sometimes they have 
clicked the merge button in hurry when they meant to rebase/squash. Once 
clicked there is no going back. All of them suggested that to have the GitHub 
setting on develop branch to rebase and squash merge option and hence there is 
no room for mistakes to occur.

I would like to propose to that we set the GitHub setting on develop PR to 
rebase and squash buttons.

Please do note that this is reversible and can be changed back, hence there is 
no harm in trying it out.


Regards
Nabarun Nag



From: Owen Nichols (Pivotal) 
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org 
Subject: Re: [REQUEST] Squash merge please

I’ve noticed quite a few PRs in the last week that were merged with “Merge” 
rather than “Squash and Merge”.

While the community consensus was to continue to allow all merge options, 
please try to default to “Squash and Merge” whenever you can to keep history as 
linear as possible. GitHub will save the last method you used in a cookie, 
which helps, but then it’s easy to miss when it resets itself back to the 
default of “Merge” some months later because you cleared cookies, changed 
browsers, etc.

> On 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.
>
>

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

[Nabarun Nag]

Hi all,

Last year, we had a discussion on rebase and squash merge PRs to the develop 
branch,

  *   to have linear git history
  *   help with bisecting
  *   easier root cause analysis of failures
  *   easier to backport changes

However, many developers have reached out mentioning that sometimes they have 
clicked the merge button in hurry when they meant to rebase/squash. Once 
clicked there is no going back. All of them suggested that to have the GitHub 
setting on develop branch to rebase and squash merge option and hence there is 
no room for mistakes to occur.

I would like to propose to that we set the GitHub setting on develop PR to 
rebase and squash buttons.

Please do note that this is reversible and can be changed back, hence there is 
no harm in trying it out.


Regards
Nabarun Nag



From: Owen Nichols (Pivotal) 
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org 
Subject: Re: [REQUEST] Squash merge please

I’ve noticed quite a few PRs in the last week that were merged with “Merge” 
rather than “Squash and Merge”.

While the community consensus was to continue to allow all merge options, 
please try to default to “Squash and Merge” whenever you can to keep history as 
linear as possible. GitHub will save the last method you used in a cookie, 
which helps, but then it’s easy to miss when it resets itself back to the 
default of “Merge” some months later because you cleared cookies, changed 
browsers, etc.

> On 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: [VOTE] Apache Geode 1.13.3.RC1

[Nabarun Nag]

+1 based on the following:

  *   build from source
  *   running gfsh
  *   starting 2 site WAN cluster
  *   verifying data propagation from the 2 sites using puts and gets
  *   Rolling clusters from 1.12 to the release candidate.
  *   Rebalance operations during upgrades.

Regards,
Nabarun




From: Owen Nichols 
Sent: Monday, June 21, 2021 11:02 AM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.3.RC1

Hello Geode Dev Community,

I'd like to propose an expedited 1.13 patch release (24-hour voting deadline 
instead of 72).

This is a release candidate for Apache Geode version 1.13.3.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 PDT Tue, June 22 2021.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.3data=04%7C01%7Cnnag%40vmware.com%7C088d7d4bb3a94cefb86a08d934deb6a7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953423878021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=r6NJTMhZ9ZEQGCH8M5ATe1sOUolp1fXnCiuyRba2Cd4%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.3.RC1%2Fdata=04%7C01%7Cnnag%40vmware.com%7C088d7d4bb3a94cefb86a08d934deb6a7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953423878021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=e2LwTX6dgGJm4ZRljOEVe0srO3JdAn1ruW%2FZBiUTlBE%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1085data=04%7C01%7Cnnag%40vmware.com%7C088d7d4bb3a94cefb86a08d934deb6a7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953423878021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=b1ukDrsyXxPneH9zhfk7kY9TsnOfM8RnxRzgHo7McW4%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.3.RC1data=04%7C01%7Cnnag%40vmware.com%7C088d7d4bb3a94cefb86a08d934deb6a7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953423878021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=feSa2U597Nn%2BuYADBKhdtG2EX8oGut1UtY3j8%2BxYkek%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.3.RC1data=04%7C01%7Cnnag%40vmware.com%7C088d7d4bb3a94cefb86a08d934deb6a7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953423878021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CV1jQCvP7QnBH4f6bPFPGGdHqp2zvaDxc1iAgrg%2F3Jw%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.3.RC1data=04%7C01%7Cnnag%40vmware.com%7C088d7d4bb3a94cefb86a08d934deb6a7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953423878021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KaILttWnWYJkM9zgMOAUVinJMdMfxmKd%2FlsIX08QFG8%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.3.RC1data=04%7C01%7Cnnag%40vmware.com%7C088d7d4bb3a94cefb86a08d934deb6a7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953423888014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Bv%2Fo41qO%2FzlWv%2FIEID%2BuIafXAVG2BdJtANVU%2BKSeRjc%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%7Cnnag%40vmware.com%7C088d7d4bb3a94cefb86a08d934deb6a7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953423888014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=W%2BlPjejIv%2FSMt2NpgXorZ0IdLw8mUlKerpRIOETTJcg%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%7Cnnag%40vmware.com%7C088d7d4bb3a94cefb86a08d934deb6a7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953423888014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TMSOpXgzfRl8h4uYXfcIoGYGGYWyqPsfNkN4r%2FDWKbQ%3Dreserved=0

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

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

[Nabarun Nag]

Hi all,


  *   We need to discuss how to prevent more flaky tests to be introduced now 
that stress-test is not mandatory for PRs to be merged? Reviewers checking the 
PR must check the tests failing in stress test and if it is a test that has 
been introduced or changed in the PR, the PR must be blocked with a change 
request or rejected.
  *   Also, in my opinion, we need to re-introduce the stress test as a 
mandatory check for PRs to be merged once the flaky test percentage has been 
reduced.

Owen, will it be possible to put out a list of all the flaky tests and we can 
try to get these resolved collectively as a community. (results of the mass 
tests maybe). Thank you.


Regards
Nabarun Nag

From: Kirk Lund 
Sent: Thursday, June 10, 2021 9:37 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

Ok, I wanted to give this discussion another night and we still have
consensus for making both stress-new-test non-required.

I just filed PR #6602 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6602data=04%7C01%7Cnnag%40vmware.com%7C33d0e8c6a7d44c692dd808d92c2e1563%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637589398736131723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=oxThcHojPNnLZmo8y2wJJDYnZzELNPN6cntY%2FMgvd%2Fw%3Dreserved=0>
 to change
stress-new-test from required to non-required. Please review!

On Wed, Jun 9, 2021 at 2:11 PM Anthony Baker  wrote:

> If we have consensus, no need to VOTE.
>
> > On Jun 9, 2021, at 12:52 PM, Owen Nichols  wrote:
> >
> > Ok, I'm on board with changing stress-new-test from a required PR check
> to non-required.  It's simple, codeowners still have the final say, and it
> neatly avoids the whole topic of overrides.  Time to take a [VOTE]?
> >
>
>

Re: [INFO] Apache Geode 1.14.0 Release Manager

[Nabarun Nag]

Hi Alberto,

For releasing 1.14 we are waiting on two more backports.

GEODE-8609 - DUnit runners were not checking the logs for suspicious 
errors/fatal messages in VMs that were being restarted in a test. A fix is 
ready and is in PR review stage[1]

GEODE-9289 - A problem with Cluster Configuration where a new locator sends its 
configuration to an old locator, the old locator is unable to deserialize it, 
causes NPEs and clears out certain fields in the configuration. A PR is ready 
and is in review phase but this will need GEODE-8609 checked in first.[2]

Once these two PRs are merged and backported, we are going to start the process 
for voting on the release branch and release candidates. My personal estimate 
is that we can start with the voting process within next week, if we do not 
detect any serious issues.

Please do reach out if you require any additional information.

Regards,
Nabarun

[1] https://github.com/apache/geode/pull/6526
[2] https://github.com/apache/geode/pull/6495

From: Alberto Gomez 
Sent: Monday, May 31, 2021 8:08 AM
To: dev@geode.apache.org 
Subject: Re: [INFO] Apache Geode 1.14.0 Release Manager

Hi Naba,

Can you please provide some information about how the 1.14 release is going and 
if is there any planned date for it?

Thanks in advance,

Alberto

From: Nabarun Nag 
Sent: Monday, March 22, 2021 5:27 PM
To: dev@geode.apache.org 
Subject: [INFO] Apache Geode 1.14.0 Release Manager

Hi everyone,

I hope you all are doing well. This is to inform the Apache Geode community 
that I will be volunteering as the Release Manager for 1.14.0 release. Thank 
you, Owen, for all the work that has been done to get the release to this point.

As for backporting, as a developer, you just need to create a PR against the 
support/1.14 branch, and you are done. As a release manager, I will take over 
from there.

Just ensure the following:

  *   The PR is a cherry-pick (cherry-pick -x) of a commit that is already in 
develop
  *   Ensure that there are no merge conflicts.

Regards
Nabarun Nag

Re: Cleaning up the codebase - use curly braces everywhere

[Nabarun Nag]

This is great clean up idea. I think you should go for it.


Regarding the check, I think we can try to incorporate it in our spotless 
script to fix it if we miss brackets in blocks .

Regards
Nabarun


Get Outlook for iOS

From: Donal Evans 
Sent: Thursday, May 27, 2021 10:22:21 AM
To: dev@geode.apache.org 
Subject: Cleaning up the codebase - use curly braces everywhere

Hi Geode dev,

I've recently been looking at ways to improve code quality in small ways 
throughout the codebase, and as a starting point, I thought it would be good to 
make it so that we're consistently using curly braces for control flow 
statements everywhere, since this is something that's specifically called out 
in the Geode Code Style Guide wiki page[1] as one of the "more important 
points" of our code style.

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

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

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

Donal

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FCode%2BStyle%2BGuidedata=04%7C01%7Cnnag%40vmware.com%7Cc82e3e06a3fb4021675e08d921340678%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637577329595666744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=pfi%2FBR%2FTNzlQM%2BUbo3Bwze%2Fg%2FOPbpkrjvIPprH5vVU4%3Dreserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6523data=04%7C01%7Cnnag%40vmware.com%7Cc82e3e06a3fb4021675e08d921340678%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637577329595666744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=idYV4eKaAC3gEpu9hr0x%2BLXUtbwHEcLJC3ZIwOZlLHo%3Dreserved=0

Re: Reminder to use draft mode

[Nabarun Nag]

I feel that Owen has a valid point and I myself feel that it is ok to start the 
PR in draft mode till the pre-check tests pass.

There has been this situation where,

  *   PR is created (reviewers are assigned)
  *   approved
  *   Tests fail
  *   code is changed
  *   no reviews
  *   code is merged

Hence code that is not reviewed has been merged

This way of doing work also has the following advantages:

  *   A reviewer does not have to review a code that causes tests to fail
  *   A reviewer does not have to review code twice before failure and then 
again after changing the code to fix the failure
  *   Unreviewed code post-test fixes do not get merged

I think this way of working saves a critical amount of time for engineers who 
review code.

This flow of PRs feels more efficient:


  *   Create PR in draft mode - no reviewers assigned
  *   PRechecks fail
  *   change/fix code
  *   tests pass - all green
  *   convert PR to ready for review - reviewers assigned
  *   reviewers review

Regards
Naba




From: Owen Nichols 
Sent: Thursday, May 6, 2021 9:59 AM
To: dev@geode.apache.org 
Subject: Re: Reminder to use draft mode

Given the lack of consensus, it sounds like it will not be possible to make any 
assumptions about a PR based on whether it is in Draft mode or not.  I will 
stop retriggering flaky checks or changing PRs to draft status.  My apologies 
for the inconvenience this has caused.

On 5/6/21, 9:47 AM, "Jens Deppe"  wrote:

I don’t think we can presume everyone has the same working style. For 
myself I’ll happily review a PR that has a failing check. I’m OK if it has some 
innocuous ‘housekeeping’ error or unrelated failure.

I don’t retrigger PR failures, for unrelated errors, just to ‘get to green’ 
– related, I don’t expect anyone to do that on my part either. It would be 
frustrating if I was about to merge something and someone retriggers a job. Yes 
I do merge if I’m 100% confident the failed check is unrelated. I don’t merge 
if any checks are still pending.

Perhaps this is just relevant to my current situation, but most of my PRs 
are module specific and so there is collaboration between my team and we 
typically know the state of our various PRs. I don’t feel like there is much 
need for any process around switching in and out of Draft mode. Much less for 
an ‘external’ contributor to make decisions on our behalf.

Has some situation arisen that is driving this? It feels like there is some 
underlying issue that isn’t being fully communicated.

--Jens

From: Owen Nichols 
Date: Thursday, May 6, 2021 at 9:12 AM
To: dev@geode.apache.org 
Subject: Re: Reminder to use draft mode
A PR in "Draft" mode simply conveys that at least one more commit is coming 
before it will be "done".  Reviewers generously volunteer their time to look at 
your PR, and are welcome to look at it while in draft mode if they wish, but if 
they are quite busy, some may prefer to wait until the PR is plausibly 
code-complete before setting aside time to review it.

Sorry if I wasn't clear, I don't mean that flaky failures should mean a PR 
is not done.  You can always refer to the latest mass test report for a list of 
known flaky failures, but often I will see those and retrigger them for you 
anyway.

I expect that most PR submitters will be monitoring their own PR checks and 
taking it back to draft mode as soon as they realize more changes are needed.  
But if as a community we agree to use draft mode to communicate status in this 
way, it shouldn't matter who does it.

Due to CODEOWNERS, some reviewers have a huge number of PRs in their queue. 
 Clearly communicating the status of your PR allows reviewers to focus their 
time on PRs that are ready for review.

On 5/6/21, 8:51 AM, "Jens Deppe"  wrote:

Comments inline…

Please keep your PR in draft mode anytime it is not ready to be 
reviewed.

This includes if you have received request for changes, or if any PR 
checks are not passing.

How do I know if everyone is done reviewing? Or even who might be 
reviewing? Different reviewers may be looking at different areas, depending on 
the scope of the change. If the PR suddenly switches back to ‘Draft` what does 
that mean if I’m reviewing it? Worse still, if I’m the owner and someone else 
switches it to Draft I’m not notified.

Additionally, many PR checks fail for reasons unrelated to the PR so 
switching blindly to ‘Draft’ seems pointless.


If you’re reviewing someone’s PR, and notice any checks not passing or 
you are requesting changes, please also click “Convert to draft”.

I really don’t agree with this – if you have an issue with a PR for 
whatever reason, please respect the author and address it directly with them. I 
certainly feel uncomfortable ‘messing’ with someone else’s PR and, by the same 
token, don’t want my PRs adjusted without my input.

 

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

[Nabarun Nag]

Reversing the previous -1 to a +1
Please continue the vote.


  *   The rebalance behavior has been fixed in later releases as a part of 
GEODE-7830

Regards
Nabarun

From: Nabarun Nag 
Sent: Monday, April 19, 2021 10:05 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

-1

Potential rebalance issue during upgrade to 1.12.2RC1

The investigation is ongoing.  Please do give me a little more time on this.


Regards
Nabarun

From: John Blum 
Sent: Monday, April 19, 2021 9:40 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

+1

Spring Data for Apache Geode 1.12.2 built successfully.

From: Dave Barnes 
Sent: Monday, April 19, 2021 9:19 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

+1
Built and reviewed User Guide and API docs. LGTM.

On Wed, Apr 14, 2021 at 3:43 PM Donal Evans  wrote:

> +1
>
> Confirmed that performance in multiple scenarios is on par with the
> previous 1.12 release.
> 
> From: Owen Nichols 
> Sent: Wednesday, April 14, 2021 3:38 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1
>
> Hello Geode Dev Community,
>
> Geode’s support/1.12 has gathered a few more fixes since 1.12.1 was
> released two months ago.  I’d like to propose another patch release.
>
> This is a release candidate for Apache Geode version 1.12.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 PDT Mon, April 19 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.2.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.2data=04%7C01%7Cnnag%40vmware.com%7C68db670b534c4024556a08d9035566e1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544487610369049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=79HBEKE%2FpKgtO6n888ReWtLF8PU0iQb%2F8Z%2BcIsPqwQs%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.2.RC1%2Fdata=04%7C01%7Cnnag%40vmware.com%7C68db670b534c4024556a08d9035566e1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544487610369049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=rpYmgE6bGoTdJLOPRyiHftYpUEReFn13PpzfpG4ufCY%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1080data=04%7C01%7Cnnag%40vmware.com%7C68db670b534c4024556a08d9035566e1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544487610369049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=HxxU1VupmnyWmiXKcn2cOmscR%2Fa9xnhJoSNr9OU%2FHRM%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cnnag%40vmware.com%7C68db670b534c4024556a08d9035566e1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544487610369049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JFTld6ML39FFAqvz0dQMNT22VCB4lWaWF%2B4I6Q0dTeo%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cnnag%40vmware.com%7C68db670b534c4024556a08d9035566e1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544487610379045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=QEl6658zwMZejzD%2B1M5M0r33OISMrVl59GRAtmWpJew%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cnnag%40vmware.com%7C68db670b534c4024556a08d9035566e1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544487610379045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=LJvWjMCwS7bZ5wHKMnuRJxDpw5%2BSEXhk%2BXhGpVezxrU%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cnnag%40vmware.com%7C68db670b534c4024556a08d9035566e1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544487610379045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL

Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

[Nabarun Nag]

Congrats Kamila!! Welcome!!!

From: Donal Evans 
Sent: Monday, April 19, 2021 2:48 PM
To: dev@geode.apache.org 
Subject: Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

Congrats Kamilla!

From: Mark Hanson 
Sent: Monday, April 19, 2021 2:37 PM
To: dev@geode.apache.org 
Subject: Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

Congratulations Kamilla!

On 4/19/21, 2:33 PM, "Sarah Abbey"  wrote:

Congratulations, Kamilla!!!

From: Ernie Burghardt 
Sent: Monday, April 19, 2021 5:22 PM
To: dev@geode.apache.org 
Subject: [ANNOUNCE] New Geode Committer - Kamilla Aslami

The Apache Geode Project Management Committee has invited Kamilla Aslami to 
join the Geode as a Committer and we are pleased to announce she has
accepted.

Please join me in welcoming Kamilla!

Best regards,
EB
On behalf of the Apache Geode PMC

Re: Geode retry/acknowledge improvement

[Nabarun Nag]

Hi Mario,

Will it be possible to provide a README doc to recreate this environment to 
test the failure.  (even a DUnit test or even scripts using baremetal GemFire 
will work too)


Regards
Naba



From: Mario Ivanac 
Sent: Monday, April 19, 2021 7:16 AM
To: dev@geode.apache.org 
Subject: Geode retry/acknowledge improvement

Hi all,

we have deployed geode cluster in kubernetes environment, and Istio/SideCars 
are injected between cluster members.
While running traffic, if any Istio/SideCar is restarted, thread will get stuck 
indefinitely, while waiting for reply on sent message.
It seams that due to restarting of proxy, in some cases, messages are lost, and 
sending side is waiting indefinitely for reply.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-9075data=04%7C01%7Cnnag%40vmware.com%7C138a80f7772245d748a108d9033dcbbd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637544386215065161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=5XCiXedKhyFdBTU7s1qFQC834OxaaamUIAZkjfQyaoo%3Dreserved=0

My question is, what is your estimation, how much effort/work is needed to 
implement message retry/acknowledge logic in geode,
to solve this problem?

BR,
Mario

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

[Nabarun Nag]

-1

Potential rebalance issue during upgrade to 1.12.2RC1

The investigation is ongoing.  Please do give me a little more time on this.


Regards
Nabarun

From: John Blum 
Sent: Monday, April 19, 2021 9:40 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

+1

Spring Data for Apache Geode 1.12.2 built successfully.

From: Dave Barnes 
Sent: Monday, April 19, 2021 9:19 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

+1
Built and reviewed User Guide and API docs. LGTM.

On Wed, Apr 14, 2021 at 3:43 PM Donal Evans  wrote:

> +1
>
> Confirmed that performance in multiple scenarios is on par with the
> previous 1.12 release.
> 
> From: Owen Nichols 
> Sent: Wednesday, April 14, 2021 3:38 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1
>
> Hello Geode Dev Community,
>
> Geode’s support/1.12 has gathered a few more fixes since 1.12.1 was
> released two months ago.  I’d like to propose another patch release.
>
> This is a release candidate for Apache Geode version 1.12.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 PDT Mon, April 19 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.2.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.2data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410940144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KFYfIsguFRxPpBXMQfNq33D9cdS%2FgRSQ2SJD39KNerk%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.2.RC1%2Fdata=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410940144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=rCqkmfL9WZXuZdOX4tmR2Hw5L1atvcEuDbt5xXyD1tg%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1080data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410940144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=udlvzlTc5z%2BLUJkrZ5urztDD%2BgTUASjuu5bRWzrggFI%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410940144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=eHH9mYRrWssVvZwICeOOLphzrsivyWHIZS6QOS7CIco%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410940144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Er32Xs2l6tx0QvSL1MlSBiAlcS63z1So0QC6TUsBtbE%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410950132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=w17mCNgbi12aZvnKKCIug%2B%2F5v6LnWDqcq85lUlPY4Ng%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410950132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nWhs85ihp%2FfU0j2CqMOK%2Be7OBlEWwdqHnZ2pAWn47rk%3Dreserved=0
>
> Pipelines:
>
> 

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

[Nabarun Nag]

Hi Jens,


With respect to the work we did with geode-kafka-connector, we did the initial 
development in a private branch. (gradle dependencies on geode, separate from 
Geode source code)

Later when we were feature complete and ready for Confluence Certification, we 
created a new apache repo in geode org and published it there.

We are also doing the partition region clear work in a feature branch, which 
will be merged to develop, when it is feature complete, fully vetted, and 
tested.

I would say, if this protobuf code will be merged into develop when it is 
ready, feature-complete, and tested. We can do the dev work as a branch in 
apache/geode.git repo, with periodic rebasing on develop.


Regards,
Nabarun




From: Jens Deppe 
Sent: Wednesday, March 31, 2021 9:50 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface

I'd volunteer to do that.

If it gets deleted and then 'revived' under another repo, does that still 
require it to be an Apache project? What are the requirements?

--Jens

On 3/30/21, 8:02 AM, "Bruce Schuchardt"  wrote:

Does anyone want to take on the work of moving these sub-projects to 
another repository?  I picked up the ticket because it's costing us development 
and testing time but am not interested in being the owner of it in some other 
repo.


On 3/30/21, 5:45 AM, "Joris Melchior"  wrote:

+1 On this approach. If we could somehow have side project to implement 
this I think it would be really helpful.

I also think it's less intimidating to contribute to for a lot of 
people.

Joris

On 2021-03-29, 2:55 PM, "John Blum"  wrote:

How hard is it to put the work like Protobuf in a separate 
repository (attached to Geode in some way)? I am not sure what the (Apache) 
procedure is.

We need stop baking everything into the "core" of Apache Geode.  
Most things that are non-essential (meaning, they are not required for Geode to 
carry out its primary responsibility as a data store, also & e.g. Redis 
Adapter) should be an "extension" (add-on), enabled with a plugin.

I fear this work would get lost if removed completely.  How would 
new (or even existing members) know where to find this work if interested? 
Branches are not a good alternative. A separate repo would make the entire 
process (e.g. releases) easier, not unlike the Kafka connector, or even Spring 
Data for that matter.

$0.02
-j


From: Bruce Schuchardt 
Sent: Monday, March 29, 2021 11:41 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf 
client/server interface

That's true John, but the Protobuf i/f is using the same code as 
the REST server to serialize/deserialize JSON documents.  It isn't any better 
at it.

On 3/29/21, 10:33 AM, "John Blum"  wrote:

Correction! Although a different/separate issue, Geode's JSON 
document handling is incomplete at best. It does not properly handle all forms 
of JSON or types (e.g. Java 8 Data/Time types).

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

I worked on the protobuf client/server interface as long as 
anyone else but still fail to see the value in keeping it in anything but a 
branch unless someone is going to pick it up soon and complete it.

As Dan pointed out, we already have a good interface for 
storing Json documents and we never got beyond that as cache values with the 
protobuf i/f.  People want to store data in Geode in a way that works with 
queries, delta propagation and other advanced features.  That was, and remains, 
the main problem for this interface.  Without that it's not even as good as the 
current REST interface.

On 3/24/21, 5:06 PM, "Jens Deppe"  wrote:

I was very excited when the protobuf support became 
available as it allowed for the fairly quick development of a Go client. 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-clientdata=04%7C01%7Cnnag%40vmware.com%7Cf65716b19378402f4ed408d8f4651f1a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637528062452588820%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=iXjw3gFEBG1VMIKDLjG%2BJpJFUwI4xwpJT6BLPQNSPtc%3Dreserved=0).
 As Udo already mentioned, removing this functionality reduces our potential 
exposure to new use cases and language bindings. Just because it isn't 'feature 
complete' doesn't mean it isn't useful to someone. In fact, just today, 

Re: [Proposal] backport GEODE-8761 to support/1.14

[Nabarun Nag]

I will handle the PR and merge into support/1.14

Thank you Darrel,

Regards
Nabarun

From: Darrel Schneider 
Sent: Tuesday, March 30, 2021 1:49 PM
To: dev@geode.apache.org 
Subject: [Proposal] backport GEODE-8761 to support/1.14

The previous fix for GEODE-8761 that was backported to support/1.14 had a 
problem.
So I'd like to backport the fix for it that can be found in this pull request: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6236data=04%7C01%7Cnnag%40vmware.com%7C658e972f1bea443c117508d8f3bd681c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637527342114181537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CYGjeyk0wHLqwHAL8uGck56BCwIesPEfHKueRolnBNc%3Dreserved=0

Re: [DISCUSS] CODEOWNERS mechanism feedback

[Nabarun Nag]

We will get these approved as soon as possible.

Regards,
Nabarun

From: Mario Ivanac 
Sent: Thursday, March 25, 2021 4:17 AM
To: dev@geode.apache.org 
Subject: Odg: [DISCUSS] CODEOWNERS mechanism feedback

Hi all,

just to remind on this topic.

Could we expand list of CODEOWNERS in some areas that are bottleneck.
For examples I have 2 PR`s that are waiting on review from WAN area for several 
weeks:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6013data=04%7C01%7Cnnag%40vmware.com%7C8118e3d4a0f04955b4c208d8ef7f9bc5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637522678650905214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sP9CgS6ZHrz%2BcfslYxFg7y9%2FzNhZLGV%2BsX5ccjO2N2A%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6048data=04%7C01%7Cnnag%40vmware.com%7C8118e3d4a0f04955b4c208d8ef7f9bc5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637522678650905214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=VH1ntlmmHR2fUaNiylYq6LpmGhOBt7UKXNWVTCn919c%3Dreserved=0

BR,
Mario

Šalje: Anthony Baker 
Poslano: 17. ožujka 2021. 18:08
Prima: dev@geode.apache.org 
Predmet: Re: [DISCUSS] CODEOWNERS mechanism feedback

I think for an active, healthy project community we need to balance two things 
that are somewhat oppositional:  make it easy to contribute and ensure the 
project meets the needs of our users for stability and robust behaviors in the 
face of failures.

> On Mar 17, 2021, at 9:45 AM, Jacob Barrett  wrote:
>
>



> My opinion, I think we need some metric by which to quantify the positive 
> impact against the negative impact otherwise the drag this process has on 
> progress may be discouraging to people joining or staying with this community.
>
> -Jake
>

Re: [ANNOUNCE] New Geode Committer - Matt Reddington

[Nabarun Nag]

Welcome!! 

Regards
Naba

From: Sarah Abbey 
Sent: Tuesday, March 23, 2021 11:17 AM
To: dev@geode.apache.org 
Subject: Re: [ANNOUNCE] New Geode Committer - Matt Reddington

Congratulations, Matt!! 

From: Ernie Burghardt 
Sent: Tuesday, March 23, 2021 1:56 PM
To: dev@geode.apache.org 
Subject: [ANNOUNCE] New Geode Committer - Matt Reddington

The Apache Geode Project Management Committee has invited Matt Reddington to 
join the Geode as a Committer and we are pleased to announce he has
accepted.

Please join me in welcoming Mat!

Best regards,
EB
On behalf of the Apache Geode PMC

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

[Nabarun Nag]

+1

Get Outlook for iOS

From: Darrel Schneider 
Sent: Tuesday, March 23, 2021 8:46:24 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface

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.

[INFO] Apache Geode 1.14.0 Release Manager

[Nabarun Nag]

Hi everyone,

I hope you all are doing well. This is to inform the Apache Geode community 
that I will be volunteering as the Release Manager for 1.14.0 release. Thank 
you, Owen, for all the work that has been done to get the release to this point.

As for backporting, as a developer, you just need to create a PR against the 
support/1.14 branch, and you are done. As a release manager, I will take over 
from there.

Just ensure the following:

  *   The PR is a cherry-pick (cherry-pick -x) of a commit that is already in 
develop
  *   Ensure that there are no merge conflicts.

Regards
Nabarun Nag

Re: [DISCUSS] Backporting to support branches

[Nabarun Nag]

Just a small change, a PR against the support branch is enough. (No need to add 
reviewers etc.). I just realized we can filter on a branch in the PR list.

Regards,
Nabarun

From: Nabarun Nag 
Sent: Friday, March 19, 2021 10:31 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Backporting to support branches

Hi,

I would like to propose that if any JIRA needs to be backported to support 
branches:

For Developers:

  *   Add the label "blocks-1.1x" to the JIRA ticket
  *   There is no need to send out a PROPOSAL email to dev
  *   Just create the cherry-picked  PR to the support branch and tag the 
Release Manager as a reviewer or just tag in the comments section if you are 
not a committer. (ensure no merge conflicts)

NOTE: Ensure that the commit you are trying to backport is already merged into 
develop. Also, the PR against the support branch needs to be a cherry pick. 
(git cherry-pick -x)

For Release Manager:

  *   Monitor the release dashboard for "blocks-1.1x" tickets
  *   Send out communications if there are any issues.
  *   Squash-merge the PR if it the commit message is properly structured with 
cherry pick message in the last line.

Regards
Nabarun

[DISCUSS] Backporting to support branches

[Nabarun Nag]

Hi,

I would like to propose that if any JIRA needs to be backported to support 
branches:

For Developers:

  *   Add the label "blocks-1.1x" to the JIRA ticket
  *   There is no need to send out a PROPOSAL email to dev
  *   Just create the cherry-picked  PR to the support branch and tag the 
Release Manager as a reviewer or just tag in the comments section if you are 
not a committer. (ensure no merge conflicts)

NOTE: Ensure that the commit you are trying to backport is already merged into 
develop. Also, the PR against the support branch needs to be a cherry pick. 
(git cherry-pick -x)

For Release Manager:

  *   Monitor the release dashboard for "blocks-1.1x" tickets
  *   Send out communications if there are any issues.
  *   Squash-merge the PR if it the commit message is properly structured with 
cherry pick message in the last line.

Regards
Nabarun

Re: PROPOSAL: Backport GEODE-9044 - Introduce RedisKey as key object for RedisData entries

[Nabarun Nag]

+1

Get Outlook for iOS

From: Jens Deppe 
Sent: Friday, March 19, 2021 7:35:03 AM
To: dev@geode.apache.org 
Subject: PROPOSAL: Backport GEODE-9044 - Introduce RedisKey as key object for 
RedisData entries

This work builds on GEODE-9023 which added sharding support to the compatible 
with Redis region.

This change cleans up data structures and will allow for easier, future rolling 
upgrades and data migrations if necessary.

Thanks
--Jens

Re: [DISCUSS] CODEOWNERS mechanism feedback

[Nabarun Nag]

Hi Alberto,

Here are some of my opinions on this matter.

"the review process is taking longer now. "
I agree that the review process is taking a bit longer, but that is the price I 
believe needs to be paid to improve the probability of good quality code is 
being merged to Geode. More eyes on the code mean that more issues may be 
detected. Our goal should not be to merge code as fast as possible but 
well-vetted code goes into the codebase.

"Some code owners might be getting more reviews than they can cope with and 
they have become a bottleneck."
Yes, that may be true, committers are free to decrease the load by modifying 
the CODEOWNERS file through a PR to remove themselves from certain areas.

" reviewers required to approve a pull request can be much higher than two, 
depending on the number of areas touched by the PR."
Yes, I agree but it is also necessary if multiple areas of the code are 
modified. Geode is a complex distributed system, and we have engineers who are 
experts in certain areas of the code. It is unfair to a single engineer to 
approve code in areas that are not in their knowledge domain. Also, I think the 
engineers involved in the approval process are involved in tasks of their own 
hence it is ok to increase the time window a bit to accommodate them.

Also, a pointer, not all code owners in the reviewers' panel in the PR need to 
approve the PR for it to be merged. Github at the bottom of the PR lists the 
smallest set of approvals needed to merge the PR. You can email them if it is a 
priority.

In my opinion, quality and correctness are more important than the speed of 
merging code. We need to reduce the number of bugs/issues that have greatly 
reduced the process of releasing Apache Geode.

Regards
Nabarun



From: Alberto Gomez 
Sent: Wednesday, March 17, 2021 8:46 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] CODEOWNERS mechanism feedback

Hi,

It's been more than two months since the CODEOWNERS file has been in place to 
automatically add reviewers to pull requests. While we have seen the great 
benefit of having the experts in the matter being automatically assigned as 
reviewers to each pull request, I have the feeling that the review process is 
taking longer now. Some possible reasons could be:
1. Some code owners might be getting more reviews than they can cope with and 
they have become a bottleneck.
2. While prior to this change only two approvals were necessary, with the new 
process the number of approvals from reviewers required to approve a pull 
request can be much higher than two, depending on the number of areas touched 
by the PR.

Again, this might just be my feeling or something incidental and only related 
to the pull requests I have been working on. In any case, I would like to know 
if others are experiencing this slowdown in the review of their pull requests.

Also, I do not know if there are metrics available for the review process. For 
example, the average time taken since a pull request is submitted or a change 
is made on it until there is a review. Having these types of metrics would be 
very useful because they would allow us to evaluate this mechanism from 
perspectives other than the quality of the reviews and to propose corrective 
actions if necessary.

Best regards,

Alberto

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

[Nabarun Nag]

+1
Based on forward compatibility tests.

  *   1.13.2 clients we able to connect to develop locator and servers and 
execute data ops.
  *   In mixed version cluster (1.13.2 and develop) locators were able to 
execute rebalance commands


From: Dan Smith 
Sent: Tuesday, March 16, 2021 11:31 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] RE: [VOTE] Apache Geode 1.13.2.RC1

+1

Ran geode-release-check against this RC, looks good to me.

-Dan

From: Mark Hanson 
Sent: Tuesday, March 16, 2021 11:02 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] RE: [VOTE] Apache Geode 1.13.2.RC1

+1 for release.

Fixed a spelling error in release notes.
Tested release

Thanks,
Mark

On 3/16/21, 10:31 AM, "Dick Cavender"  wrote:

Please vote by 3pm today for 1.13.2. At this time we don't have enough 
votes to release although there are no -1s.

From: Dick Cavender
Sent: Thursday, March 11, 2021 1:34 PM
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%7Cnnag%40vmware.com%7Cfc6595bcb4dd4d7d6d1108d8e8a9c04a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515163062275711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KX25FMDNhSCljJxq9ms3M6hoJpkM7HM0wtKYug5IJjM%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%7Cnnag%40vmware.com%7Cfc6595bcb4dd4d7d6d1108d8e8a9c04a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515163062275711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KrvZLSPyShe3iuYbLdZxi3jouRrwyx15FCULYBsk7sE%3Dreserved=0

Maven staging repo:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1079data=04%7C01%7Cnnag%40vmware.com%7Cfc6595bcb4dd4d7d6d1108d8e8a9c04a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515163062275711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2B53Glh9KIXfIeLUmU0c5RVGmGmxLmEviphCHr%2BGLeiw%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%7Cnnag%40vmware.com%7Cfc6595bcb4dd4d7d6d1108d8e8a9c04a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515163062275711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nPe3NCkgqGPYXjyAnDMZKvv5k0Mv20UiYBrqGVOfvQY%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%7Cnnag%40vmware.com%7Cfc6595bcb4dd4d7d6d1108d8e8a9c04a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515163062285705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3V1r%2Fk1X6y1oWQKDybLCnm5gjPsSEiDEfaZATrofuIM%3Dreserved=0

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

[Nabarun Nag]

+1

From: Donal Evans 
Sent: Friday, March 12, 2021 11:19 AM
To: dev@geode.apache.org 
Subject: Proposal: Add GEODE-8950 (performance degradation in 
P2pPartitionedPutLongBenchmark) to 1.14 blockers list

After some investigation, it appears that a degradation has been introduced 
that causes the P2pPartitionedPutLongBenchmark to fail at an increased rate. 
Efforts are underway to narrow down the cause to a single commit, but the 
degradation was definitely introduced in 1.14, so I believe this should be 
considered a 1.14 release blocker: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8950data=04%7C01%7Cnnag%40vmware.com%7C725b916c911e47e0561408d8e58bc355%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637511735732610115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=zWmQr%2FUvmR9bnE%2BeOyL0sHTz03qYW3Hd3aydKabTbyA%3Dreserved=0

Re: [Proposal] Backport GEODE-9016 to 1.14, 1.13 and 1.12

[Nabarun Nag]

 +1

Get Outlook for iOS

From: Anilkumar Gingade 
Sent: Thursday, March 11, 2021 11:59:17 AM
To: dev@geode.apache.org 
Subject: Re: [Proposal] Backport GEODE-9016 to 1.14, 1.13 and 1.12

+1 to backport.

On 3/11/21, 11:38 AM, "Jianxia Chen"  wrote:

Hi,

I would like to backport the fix of GEODE-9016 to Geode 1.14, 1.13 and 1.12
branches. This would help resolve the NPE for certain cases of PutAll with
CQ.

Thanks,
Jianxia

[Poposal] Backport GEODE-9019 to Apache Geode 1.14.0 branch

[Nabarun Nag]

Hi everyone,

Putting forward the proposal to backport GEODE-9091 (Serialization 
Improvements) to support/1.14 branch,

What does GEODE-9091 do?

  *   It adds serialVersionUID to the Serializable classes in geode-redis module
  *   It converts all DataSerializable classes to DataSerializableFixedID 
classes

Why do we need to backport these changes?

  *   These changes future-proofs the geode-redis data structures from being 
used in mixed version clusters.
  *   This will ensure that changes to serializable classes do not break 
backward compatibility.
  *   If these classes get changed in the future, the serialVersionUIDs will 
remain the same and can be used with older and newer versions.
  *   If we don't backport these changes to 1.14.0 then future releases of 
geode-redis will not be compatible with it.

Reference PR:[link<https://github.com/apache/geode/pull/6115>]


Regards
Nabarun Nag

Re: [DISCUSS] Geode 1.14

[Nabarun Nag]

Added a couple of tickets with the blocker label and are now available on the 
dashboard.

Please feel free to pick up those tasks.

Do reach out if anyone needs more information.

Regards
Nabarun

From: Alexander Murmann 
Sent: Wednesday, January 6, 2021 7:39 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Geode 1.14

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.
 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: [PROPOSAL] Change the default value of conserve-sockets to false

[Nabarun Nag]

+1

  *   As nearly all of the production use-cases need "conserve-sockets" to be 
set to false, I think we can aim for changing the default value to false for 
1.14.0 release.
  *   We can highlight this change in the release notes and emails.

Regards,
Nabarun


From: Udo Kohlmeyer 
Sent: Wednesday, November 18, 2020 6:00 PM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false

Hi there Donal,

Thank you for raising this. It is not an uncommon request to change the default 
value of this field.

This has been discussed many times in the past. I would LOVE to approve this 
change, but this would mean that users that don’t set this property might 
suddenly have this property changed. We are not sure that this would mean for 
these users. BUT

That said, there have been very little (to none) complaints about the product 
stability when `conserve-sockets=false` are set.

+1 - if we are allowed to make this change outside of a major version change.

--Udo

From: Donal Evans 
Date: Thursday, November 19, 2020 at 12:04 PM
To: dev@geode.apache.org 
Subject: [PROPOSAL] Change the default value of conserve-sockets to false
Hi Geode dev,

First, from the docs[1], a brief explanation of the purpose of the 
conserve-sockets property:

"The conserve-sockets setting indicates whether application threads share 
sockets with other threads or use their own sockets for member communication. 
This setting has no effect on communication between a server and its clients, 
but it does control the server’s communication with its peers or a gateway 
sender’s communication with a gateway receiver."

The current default value for the conserve-sockets property is true, which at 
first glance makes sense, since in an ideal world, existing sockets could be 
shared between threads and there would be no need to create and destroy new 
sockets for each process, which can be somewhat resource-intensive. However, in 
practice, there are several known issues with using the default setting of 
true. From the docs[1]:

"For distributed regions, the put operation, and destroy and invalidate for 
regions and entries, can all be optimized with conserve-sockets set to false. 
For partitioned regions, setting conserve-sockets to false can improve general 
throughput.
Note: When you have transactions operating on EMPTY, NORMAL or PARTITION 
regions, make sure that conserve-sockets is set to false to avoid distributed 
deadlocks."

and[2]:

"WAN deployments increase the messaging demands on a Geode system. To avoid 
hangs related to WAN messaging, always set `conserve-sockets=false` for Geode 
members that participate in a WAN deployment."

Given that it is generally accepted as best practice to set conserve-sockets to 
false for almost all use cases of Geode beyond the most simple, it would make 
sense to also change the default value to false, to prevent people having to 
encounter a problem, search for the solution, then change the setting to what 
is almost always the "correct" value.

I have done some experimenting to see what it would take to make this proposal 
a reality, and the changes required are very minimal, with only two existing 
DUnit tests that need to be modified to explicitly set the value of 
conserve-sockets that were previously relying on the default being true.

Any feedback on this proposal would be very welcome, and if the response is 
positive, I can create a PR with the changes as soon as a decision is reached.

Thanks,
Donal

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fmanaging%2Fmonitor_tune%2Fperformance_controls_controlling_socket_use.htmldata=04%7C01%7Cnnag%40vmware.com%7Cb3a63185f8f948ce5e1708d88c2ee809%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637413480399258567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=hwVkxp99IM%2FeRWDt39P81GO%2Bq7LD7maQewAKLYqQlj0%3Dreserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fmanaging%2Fmonitor_tune%2Fsockets_and_gateways.htmldata=04%7C01%7Cnnag%40vmware.com%7Cb3a63185f8f948ce5e1708d88c2ee809%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637413480399268565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FOBKgXh1tOj3WDsLZRbBXoufPeaUu4YTKkSDKD81P9A%3Dreserved=0

Re: [VOTE] Apache Geode 1.13.1.RC2

[Nabarun Nag]

+1
Started gfsh, created cluster, create region, entry put and get, query 
execution.
Build from source.

Regards
Nabarun Nag


From: Joris Melchior 
Sent: Tuesday, November 17, 2020 12:25 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.13.1.RC2

+1

Looks good to me. Did a build and gfsh test-drive.

From: Dan Smith 
Date: Monday, November 16, 2020 at 1:29 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.13.1.RC2
+1

Looks good to me! I ran the geode-release-check against it, looked for binary 
artifacts, checked the pipeline.

-Dan

From: Dick Cavender 
Sent: Thursday, November 12, 2020 5:00 PM
To: dev@geode.apache.org 
Subject: [VOTE] Apache Geode 1.13.1.RC2

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.13.1.RC2.
Issues with creation of RC1 forced moving to RC2.
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, November 17 2020.

Please note that we are voting upon the source tag:
rel/v1.13.1.RC2

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.1data=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153729481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FpwSk4ZPaG4UbxnCceQupEqHmqK7%2BXXlxsgoTnlqsrs%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.1.RC2%2Fdata=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153729481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=XYUPMs%2F%2FK6%2Bn7j9iEFtOoocBjMiOHimqrsA7fyhN2vY%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1071data=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153729481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=W%2BmuOe9mXgOXqYsyJBklpU77zMKhKIHn98ov1K6j6Qc%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.1.RC2data=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153729481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=75YEv2p7%2B5qeUPJ%2Fy%2FL0vDnGmD86D3yHo3XFo2NPxZ8%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.1.RC2data=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153729481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0eN4wZ0EFwoeAG7xBwLTE4OLtnxKhpXk5hA0ZYQb7%2BM%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.1.RC2data=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153739471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2F6NntnNnUpjb9wFBa6QSpo4WUd%2BWblX4nlYIeljkSX4%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.1.RC2data=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153739471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=MH9EKYiC%2FGSJHkTrWoyo2qtUrr1UoF2VhzhjkWQyB%2Fw%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%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153739471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=l%2BIGtYOdVbIehggAw6xSN%2F4Os%2FJqpcGGZ4bl8N9HYlA%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%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153739471

Geode Kafka Connector Verification and availability on Confluent Hub

[Nabarun Nag]

Hello everyone,


I would like to inform you that Confluent Inc. has completed its evaluation of 
the Geode-Kafka connector and has certified it as a "Verified Gold" level 
connector. They are also hosting it on the Confluent Hub and available at 
<https://www.confluent.io/hub/apache/kafka-connect-geode> 
https://www.confluent.io/hub/apache/kafka-connect-geode


The source code is open-sourced and is being hosted in Apache Software 
Foundation repositories: <https://github.com/apache/geode-kafka-connector> 
https://github.com/apache/geode-kafka-connector


This effort was spearheaded by Jason Huynh, with code contributions from Donal 
Evans, Anthony Baker, and Nabarun Nag

Thank you all for the great contributions.


We have a couple of upcoming 
features<https://github.com/apache/geode-kafka-connector#possible-upcoming-featured>
 and would love contributions from the community.


Regards

Nabarun Nag

Geode-Kafka Connector 
Quickstart<https://github.com/apache/geode-kafka-connector/wiki/Quickstart>
Deploying Kafka connect Geode on Confluent 
Platform<https://github.com/apache/geode-kafka-connector/wiki/Deploying-Kafka-connect-Geode-on-Confluent-Platform>

Re: [PROPOSAL] Backport usability improvements to support 1.13 branch

[Nabarun Nag]

+1

From: Jason Huynh 
Sent: Wednesday, September 23, 2020 4:22 PM
To: dev@geode.apache.org 
Subject: [PROPOSAL] Backport usability improvements to support 1.13 branch

Hello,

I’d like to merge the pull request: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5524data=02%7C01%7Cnnag%40vmware.com%7Cc4fb6d3fd211433f8a1408d86017a2b4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637365001921254357sdata=wHr0IaJgsKVpZaWTH6SAqtunaD5WwVn1SAvuOnVgHQg%3Dreserved=0
 into a support 1.13 branch.  The commits are focused on a few usability 
improvements for Geode that were thought to have made it into 1.13 but actually 
did not make it.

What this pull request back ports:

  *   GEODE-8203: Logging to std out along with to the regular log file
  *   GEODE-8283: Rest API for disk store creation
  *   GEODE-8200: Fix for Rebalance API stuck “IN_PROGRESS” state forever and 
GEODE-8200: Enhance GfshRule
  *   GEODE-8241: Locator observers locator-wait-time
  *   GEODE-8078: Log and report error at the correct place


The PR pipeline is failing due to Redis tests (that I don’t think are on 1.13). 
 Everything else appears to be passing.

Thanks,
-Jason

Re: [VOTE] Apache Geode 1.13.0.RC1

[Nabarun Nag]

+1 Based on the following tasks
Clean build
Starting gfsh, executing queries.
meld comparison of artifacts directories.


From: Jinmei Liao 
Sent: Tuesday, September 8, 2020 11:16 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.13.0.RC1

+1
Verified geode management rest urls are working as expected.

On 9/8/20, 9:53 AM, "Owen Nichols"  wrote:

+1

I have reviewed test results for a battery of internal functional and 
performance tests, reviewed the LICENSE file for accuracy, looked at the logs 
for all checks in the rc pipeline, confirmed that artifact files are now named 
consistently as requested last time, confirmed gfsh and gfsh version --full 
output, reviewed the release notes in the wiki, reviewed that the fixed list in 
Jira is accurate, and checked that the RC1 tag shows as "Verified" in github.

On 9/7/20, 8:23 PM, "Dave Barnes"  wrote:

Hello Geode Dev Community,


This is a release candidate for Apache Geode version 1.13.0.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 PDT Wed, September 9, 2020.


Please note that we are voting upon the source tag:

rel/v1.13.0.RC1


Release notes:


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.0data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=rKGO6MdK93hSTJF%2F%2BN%2FIJ3Vd5vNeq1BQBRAGI77Ip4g%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.0.RC1%2Fdata=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=x6vVgr6ceI0196EMCbmUq6WxAqixcSgARBhC0D1T%2BdM%3Dreserved=0


Maven staging repo:


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1069data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=fs1Mi7y3fEt7Bnfyl9KnJTKXWHTazsFdCmtUtUMS4Hs%3Dreserved=0


GitHub:


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=awSnw4fkDLxhVamoAM%2FsBSAGhaTi9KroI4Jlp5Lg8%2FE%3Dreserved=0


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=rK5NNxqocS0v1CakZ5xdNi7lq1IHz4UojJzx5AS7LVw%3Dreserved=0


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=rQG4MSWw%2FHxWAj4tdBLrE24Q1ukFa5ipI%2FWsDka9GaI%3Dreserved=0


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=9o7QtQAGg%2BSkjc5xNmxElJPJfFvJ1I8%2FvlErm1LMGc8%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=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424628973sdata=OR6viVpRZtN6rSz9qOH6xPwdYoUuaJDUCXp%2FIcd2ens%3Dreserved=0


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-rcdata=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424628973sdata=1DZpvfgMWnNJWg%2BHz2%2B9qJPeQytWo5sVAFVKsI2PZHc%3Dreserved=0


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


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2FKEYSdata=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424628973sdata=HfjFYZbYa772XQ1mfeG1oy7Md46OnE5IHfCNBW4kL9M%3Dreserved=0

Re: Draft of August 2020 Geode report to the board

[Nabarun Nag]

Hi Udo,

I think the wrapped links appear only in outlook. In Apache archives, they 
appear to be medium links.
Safelinks is feature enabled by default  in Outlook

Regards
Naba

Get Outlook for iOS

From: Udo Kohlmeyer 
Sent: Sunday, August 9, 2020 7:18:08 PM
To: dev@geode.apache.org 
Subject: Re: Draft of August 2020 Geode report to the board

Hi there Karen,

Any chance that you could pls change the URL to the proper Medium URLs and not 
the wrapped URLs?

—Udo
On Aug 7, 2020, 5:04 PM -0700, Karen Miller , wrote:
Thanks, Anthony. Here is Draft 2 of the August board report. Corrections
and comments by Monday at noon please.

## Description:
The mission of Apache Geode is the creation and maintenance of software
related
to a data management platform that provides real-time, consistent access to
data-intensive applications throughout widely distributed cloud
architectures.

## Issues:
There are no issues requiring board attention.
- 309 issues opened in JIRA, past quarter (-3% decrease)
- 244 issues closed in JIRA, past quarter (1% increase)

## Membership Data:
Apache Geode was founded 2016-11-15 (4 years ago)
There are currently 109 committers and 54 PMC members in this project.

Community changes, past quarter:
- No new PMC members. Last addition was Alexander Murmann on 2020-03-26.
- No new committers. Last addition was Mario Kevo on 2020-03-23.

## Project Activity:
We're actively working on the version 1.13 release, with many discussions
over
code inclusions that delay the release, but provide a higher quality
product.

There is significant discussion and activity surrounding:
- WAN Configuration for an Ingress Proxy
- Avoiding the queuing of dropped events by the primary gateway sender when
the gateway sender is stopped
- Geode Redis API improvements
- Modularization / classloader isolation
- Support for an operation that clears a partitioned region

## Community Health:
The Apache Geode dev mailing list had a 26% decrease in traffic, while the
issues mailing list experienced a 32% increase in traffic in Q2.

We are planning a Geode content track for ApacheCon @Home. We have two days
of content based on submissions from the community.

May-July brought 7 new blog posts:
- "Spring Security & Geode" by community member Juan José Ramos at
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40jujoramos%2Fspring-security-geode-4670faff47a0data=02%7C01%7Cnnag%40vmware.com%7Ce9610fcb2cde44f0815a08d83cd3aa08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637326227074347826sdata=xIzBXV2AMyAnWyMlIVWvQa3FWHB49fS9X8HZZxqH8wo%3Dreserved=0
- "Logging Apache Geode GatewaySender Queue Events" by community member
Barry
Oglesby at 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2Fdata=02%7C01%7Cnnag%40vmware.com%7Ce9610fcb2cde44f0815a08d83cd3aa08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637326227074347826sdata=GL6K7aaErRc5oInNPxBwjbS%2FvVUEDRliwgQX4zhxKww%3Dreserved=0

@boglesby_2508/logging-apache-geode-gatewaysender-queue-events-e7e19937a542
- "Verifying Apache Geode Region Consistency in Different Distributed
Systems"
by community member Barry Oglesby at
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40boglesby_2508%2Fverifying-apdata=02%7C01%7Cnnag%40vmware.com%7Ce9610fcb2cde44f0815a08d83cd3aa08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637326227074347826sdata=%2BMGjWjRcNtZzzVkeRQjQy2KCl%2BQ9I2fG49Lp5eH4reg%3Dreserved=0

ache-geode-region-consistency-in-different-distributed-systems-e15d6edfe15d
- "Geode Write-Behind Event Handling with Spring JPA" by community member
Juan
José Ramos at 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.co%2Fdata=02%7C01%7Cnnag%40vmware.com%7Ce9610fcb2cde44f0815a08d83cd3aa08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637326227074347826sdata=nfK%2FXnRiB0J2jmfzvQdlWvKIia%2FHVak2Rt30fYblNjM%3Dreserved=0

m/@jujoramos/geode-write-behind-event-handling-with-spring-jpa-a54f17e19709
- "Calculating the Size of an Apache Geode Region" by community member Barry
Oglesby at https://

medium.com/swlh/calculating-the-size-of-an-apache-geode-region-5ffb3b141464
- "Improving the Performance of Apache Geode Persistence Recovery" by
community member Jianxia Chen at 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40luckycjxdata=02%7C01%7Cnnag%40vmware.com%7Ce9610fcb2cde44f0815a08d83cd3aa08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637326227074347826sdata=XWMxVfmFpBsB9nwo6d7iQYk8Ody1ytsUK57uuNdD9fY%3Dreserved=0

/improving-the-performance-of-apache-geode-persistence-recovery-af08918d2ef
- "Threads Used in Apache Geode Function Execution" by community member
Barry
Oglesby at https://m

edium.com/swlh/threads-used-in-apache-geode-function-execution-9dd707cf227c

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

[Nabarun Nag]

Super +1

From: Anilkumar Gingade 
Sent: Friday, August 7, 2020 10:34 AM
To: dev@geode.apache.org 
Subject: [PROPOSAL] backport GEODE-8394 to support/1.13

This causes a large object to be partially (corrupt data) stored in cache 
instead of throwing an exception.

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

[Nabarun Nag]

Thank you all for the  votes needed for the backport. It has been backported to 
support/1.13 branch

GEODE-8261: Added a null check for the proxyID. (#5251)

Regards
Naba


-Original Message-
From: Jianxia Chen  
Sent: Friday, June 19, 2020 12:22 PM
To: dev@geode.apache.org
Subject: Re: [VOTE] Backporting of GEODE-8261 to 1.13 release branch.

+1

On Fri, Jun 19, 2020 at 12:16 PM Nabarun Nag  wrote:

> Hi Geode devs,
>
> Requesting vote to backport of GEODE-8261 to 1.13
>
> Why?
> This commit fixes an issue with servers throwing null pointer 
> exceptions while a member is being shutdown and registering interest is in 
> process.
>
> SHA
> 720a4caea2ddb22296aa3225fc5264d2096cdf20
>
>
> Regards
> Nabarun
>

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

[Nabarun Nag]

Hi Geode devs,

Requesting vote to backport of GEODE-8261 to 1.13

Why?
This commit fixes an issue with servers throwing null pointer exceptions while 
a member is being shutdown and registering interest is in process.

SHA
720a4caea2ddb22296aa3225fc5264d2096cdf20


Regards
Nabarun

RE: Setting your commit email address

[Nabarun Nag]

Hi Kirk, 

I think it is also now in the privacy setting in GitHub for anyone who wants to 
keep emails private. [https://github.com/settings/emails : 
https://github.com/settings/emails ]

This setting is needed for web based git operations like squash merging PRs etc.

In GitHub:
"Keep my email addresses private
We’ll remove your public profile email and use 
nabarun...@users.noreply.github.com when performing web-based Git operations 
(e.g. edits and merges) and sending email on your behalf. If you want command 
line Git operations to use your private email you must set your email in Git."

Regards
Nabarun

-Original Message-
From: Kirk Lund  
Sent: Wednesday, June 17, 2020 1:12 PM
To: dev@geode.apache.org
Subject: Setting your commit email address

Please make sure you've setup your commit email address. It makes it much 
easier to find out who committed something and how to contact them if there's a 
problem.

You typically use the following to set your email address globally in git:

$ git config --global user.email "em...@example.com"

You can also setup different repos with different email addresses by using:

$ git config user.email "em...@example.com"

In the below example, it's much easier to follow up with the author of the 1st 
commit than the author of the 2nd commit:

commit b1107d2e403404337c22830a4964eefc2490ef50
Author: John Doe 
Date:   Tue Jun 16 12:25:30 2020 -0700

GEODE-: add something new

commit e159238175766b46cbb6fe1e3459aa2da68db756
Author: John Doe 
Date:   Tue Jun 16 10:55:16 2020 -0700

GEODE-: fix something bad

For more info, see:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Fen%2Fgithub%2Fsetting-up-and-managing-your-github-user-account%2Fsetting-your-commit-email-addressdata=02%7C01%7Cnnag%40vmware.com%7C52882c4b78a34fd2ddfe08d812faa8f2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280215074685835sdata=898w3f4jbFyTyQl8GAy1cFboW28VHCZAbl5ycwO8vX8%3Dreserved=0

Thanks,
Kirk

Re: About Geode rolling downgrade

[Nabarun Nag]

Hi Mario and Alberto,

I will sync up with couple of engineers get you a feedback within a couple of 
days.

@Barry , Jason and I were discussing once, can your idea of WAN GII achieve the 
downgrade. Like create a DS with old versions and let it do a GII from the 
newer version cluster and then shutdown the new version DS. Now we have a DS 
with lower version.


Regards
Naba


From: Mario Ivanac 
Sent: Friday, June 5, 2020 1:19:42 AM
To: geode 
Subject: Odg: About Geode rolling downgrade

Hi all,

just a reminder that Alberto is still waiting for feedback,
regarding his question.

BR,
Mario

Šalje: Alberto Gomez 
Poslano: 14. svibnja 2020. 14:45
Prima: geode 
Predmet: Re: About Geode rolling downgrade

Hi,

I friendly reminder to the community about this request for feedback.

Thanks,

-Alberto G.

From: Alberto Gomez 
Sent: Thursday, May 7, 2020 10:44 AM
To: geode 
Subject: Re: About Geode rolling downgrade

Hi again,


Considering Geode does not support online rollback for the time being and since 
we have the need to rollback even a standalone system, we were thinking on a 
procedure to downgrade Geode cluster tolerating downtime, but without a need to:

  *   spin another cluster to sync from,
  *   do a restore or
  *   import data snapshot.



The procedure we came up with is:

  1.  First step - downgrade locators:

 *   While still on the newer version, export cluster configuration.
 *   Shutdown all locators. Existing clients will continue using their 
server connections. New clients/connections are not possible.
 *   Start new locators using the old SW version and import cluster 
configuration. They will form a new cluster. Existing client connections should 
still work, but new client connections are not yet possible (no servers 
connected to locators).

  1.  Second step – downgrade servers:

 *   First shutdown all servers in parallel. This marks the beginning of 
total downtime.
 *   Now start all servers in parallel but still on the new software 
version. Servers connect to the cluster formed by the downgraded locators. When 
servers are up, downtime ends. New client connections are possible. The rest of 
the rollback should be fully online.
 *   Now per server:

   i.  Shutdown 
it, revoke its disk-stores and delete its file system.

 ii.  Start 
server using old SW version. When up, server will take over cluster 
configuration and pick up replicated data and partitioned regions buckets 
satisfying region redundancy (essentially will hold exactly the same data 
previous server had).



The above has some important prerequisites:

  1.  Partitioned regions have redundancy and region configuration allows 
recovery as described above.
  2.  Clients version allows connection to new and old clusters - i.e. clients 
must not use newer version at the moment the procedure starts.
  3.  Geode guarantees cluster configuration exported from newer system can be 
imported into older system. In case of incompatibility I expect we could even 
manually edit the configuration to adapt it to the older system but it is a 
question how new servers will react when they connect (in step 2b).
  4.  Geode guarantees communication between peers with different SW version 
works and recovery of region data works.



Could we have opinions on this offline procedure? It seems to work well but 
probably has caveats we do not see at the moment.



What about prerequisites 3 and 4? It is valid in upgrade case but not sure if 
it holds in this rollback case.


Best regards,


-Alberto G.


From: Anilkumar Gingade 
Sent: Thursday, April 23, 2020 12:59 AM
To: geode 
Subject: Re: About Geode rolling downgrade

That's right, most/always no down-time requirement is managed by having
replicated cluster setups (Disaster-recovery/backup site). The data is
either pushed to both systems through the data ingesters or by using WAN
setup.
The clusters are upgraded one at a time. If there is a failure during
upgrade or needs to be rolled back; one system will be always up
and running.

-Anil.





On Wed, Apr 22, 2020 at 1:51 PM Anthony Baker  wrote:

> Anil, let me see if I understand your perspective by stating it this way:
>
> If cases where 100% uptime is a requirement, users are almost always
> running a disaster recovery site.  It could be active/active or
> active/standby but there are already at least 2 clusters with current
> copies of the data.  If an upgrade goes badly, the clusters can be
> downgraded one at a time without loss of availability.  This is because we
> ensure compatibility across the wan protocol.
>
> Is that correct?
>
>
> Anthony
>
>
>
> > On Apr 22, 2020, at 10:43 AM, Anilkumar Gingade 
> wrote:
> >
> >>> Rolling downgrade is a 

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

[Nabarun Nag]

Thank you Aaron.

We will continue using feature branch in ASF repo for development of PR clear 
work.

Yes, we can manage access to personal/non-ASF hosted forks but I do not have 
the list of people to set that up. This is automatic default when we create in 
ASF repositories.

Also, I am vehemently against using one person's personal fork for massive 
collaborative open source feature development involving the entire Geode 
Community. Every collaborator should have the same rights on the source code 
rather than a gatekeeper.

But again, I agree it is wrong to use the repo to create short living branches 
with single contributor and then not cleaning up after the branch is merged.

Regards
Naba

-Original Message-
From: Aaron Lindsey  
Sent: Wednesday, June 3, 2020 8:50 AM
To: dev@geode.apache.org
Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches

I'm on board with using forks — the exception being Naba's use case for long 
running feature branches where developers actually want to open a PR into the 
branch


From: Bruce Schuchardt 
Sent: Wednesday, June 3, 2020 8:23 AM
To: dev@geode.apache.org
Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches

Jake, you make some good points that I hadn't considered before.

On 6/2/20, 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: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

[Nabarun Nag]

I agree, I am not justifying the use of repository for small bug fixes etc. or 
short term individual tasks

I am justifying why PR clear  has a feature branch in the geode repository.

Regards
Naba


-Original Message-
From: Jacob Barrett  
Sent: Tuesday, June 2, 2020 4:48 PM
To: dev@geode.apache.org
Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches



> On Jun 2, 2020, at 4:29 PM, Nabarun Nag  wrote:
> 
> - We are maintaining feature/GEODE-7665 which is the feature branch for PR 
> clear work on which multiple developers are working on. 
> - We are maintaining this in Geode repository.
> - All sub-tasks of GEODE-7665 are merged into this feature branch.
> - Anyone in the Geode community can work on any subtask 
> - This is a long running, and a massive feature development which is 
> manipulating core code on Apache Geode. Hence all work is pushed to the 
> feature branch to keep develop isolated from a regression introduced in PR 
> clear work.
> - We have previously used release flags for Lucene work which we found to be 
> inefficient and unnecessary extra work.
> 
> We vote that PR clear feature branch be maintained in the Geode Repository as 
> this is a long running, massive effort involving everyone from the community.
> 
> When the PR clear tasks are completed, the branch will be rigorously tested 
> and then squash merged into develop and the feature branch will be deleted.

I think there can always be exceptions for any rule. I can even understand the 
desire to have long running branches for large scale refactors or features 
maintained centrally. The issue is the most of the branches are not of this 
exceptional scale. I want to eliminate this clutter and consider exceptions 
where it makes sense. Perhaps which we could ask the ASF to have its bots 
ignore specifically prefixed branches to future reduce the noise produced by 
using the Geode repo in these exceptional cases.

-Jake

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

[Nabarun Nag]

- Unified location, where anyone who wants to work on the feature can find the 
feature branch on the geode-repository 
- Visibility, the PRs to the geode repository can be viewed by everyone in the 
Geode community. Which will not happen if they are raised to my fork.
- Long running feature development happens in feature branches in Apache 
projects Eg: Lucene and Kafka.


Regards
Naba


-Original Message-
From: Jacob Barrett  
Sent: Tuesday, June 2, 2020 4:45 PM
To: dev@geode.apache.org
Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches



> On Jun 2, 2020, at 4:40 PM, Nabarun Nag  wrote:
> 
> I don’t think it is right to make the open source Geode Community to work on 
> my personal fork 

Why not? I can fork your fork. I can PR to your fork. Its sort of what Git was 
made for, no single source repository.

Can you elaborate on why you feel it isn’t right?

-Jake

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

[Nabarun Nag]

I don’t think it is right to make the open source Geode Community to work on my 
personal fork 

Regards
Naba


-Original Message-
From: Mark Hanson  
Sent: Tuesday, June 2, 2020 4:35 PM
To: dev@geode.apache.org
Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches

While I am not 100% sure, I understand your thoughts here, I am pretty sure I 
do. We have already done such work in a branch in a fork (Micrometer work). The 
only real gotcha was that there needed to be one person at least as a 
collaborator, in case of vacations and such. 

All of the things you have specified are possible within the confines of a fork.

Thanks,
Mark

On 6/2/20, 4:29 PM, "Nabarun Nag"  wrote:

- We are maintaining feature/GEODE-7665 which is the feature branch for PR 
clear work on which multiple developers are working on. 
- We are maintaining this in Geode repository.
- All sub-tasks of GEODE-7665 are merged into this feature branch.
- Anyone in the Geode community can work on any subtask 
- This is a long running, and a massive feature development which is 
manipulating core code on Apache Geode. Hence all work is pushed to the feature 
branch to keep develop isolated from a regression introduced in PR clear work.
- We have previously used release flags for Lucene work which we found to 
be inefficient and unnecessary extra work.

We vote that PR clear feature branch be maintained in the Geode Repository 
as this is a long running, massive effort involving everyone from the community.

When the PR clear tasks are completed, the branch will be rigorously tested 
and then squash merged into develop and the feature branch will be deleted.


Regards
Naba

-Original Message-
From: Jacob Barrett  
Sent: Tuesday, June 2, 2020 3:43 PM
To: dev@geode.apache.org
Subject: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches

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: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

[Nabarun Nag]

- We are maintaining feature/GEODE-7665 which is the feature branch for PR 
clear work on which multiple developers are working on. 
- We are maintaining this in Geode repository.
- All sub-tasks of GEODE-7665 are merged into this feature branch.
- Anyone in the Geode community can work on any subtask 
- This is a long running, and a massive feature development which is 
manipulating core code on Apache Geode. Hence all work is pushed to the feature 
branch to keep develop isolated from a regression introduced in PR clear work.
- We have previously used release flags for Lucene work which we found to be 
inefficient and unnecessary extra work.

We vote that PR clear feature branch be maintained in the Geode Repository as 
this is a long running, massive effort involving everyone from the community.

When the PR clear tasks are completed, the branch will be rigorously tested and 
then squash merged into develop and the feature branch will be deleted.


Regards
Naba

-Original Message-
From: Jacob Barrett  
Sent: Tuesday, June 2, 2020 3:43 PM
To: dev@geode.apache.org
Subject: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

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

New blog on Spring Security & Geode by Juan Ramos

[Nabarun Nag]

Hi Geode Community,

Juan Ramos has recently published a new article on Spring Security and Apache 
Geode. You can read it here at 
https://medium.com/@jujoramos/spring-security-geode-4670faff47a0


Thank you Juan for this article.

Regards
Nabarun Nag

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

[Nabarun Nag]

+1

On Thu, May 14, 2020 at 8:54 AM Donal Evans  wrote:

> Thanks for the explanation, Robert. Also, I realised I never explicitly
> said it in my earlier post, but this is a +1 from me
>
> On Thu, May 14, 2020 at 8:05 AM Joris Melchior 
> wrote:
>
> > This seems like a good thing to have.
> >
> > +1
> > 
> > From: Robert Houghton 
> > Sent: May 13, 2020 17:32
> > To: dev@geode.apache.org ; Mario Ivanac
> > 
> > Subject: [DISCUSS] enable GitHub PR blocking on API breaking changes
> >
> > We have enabled this job on the develop and support 1.13 branches, and it
> > is going well. I would like this to be a blocking job for our pull
> > requests.
> >
> > Are there any issues around this test that we want to address, or reasons
> > to *not* have it be a blocking job in the PR pipeline?
> >
> > To seed the conversation, there is an issue I am working on with @Mario
> > Ivanac  regarding exemptions to the Gradle task.
> >
> > I would like to have a [VOTE] by end of week on this.
> >
>

Re: Our May 2020 report to the board

[Nabarun Nag]

Thank you Dave for putting together the report !! Thank you all for putting 
together those amazing blogs and all the Apache Geode contributors.

Regards
Naba



Get Outlook for iOS

From: Karen Miller 
Sent: Monday, May 11, 2020 2:30:35 PM
To: dev@geode.apache.org 
Subject: Our May 2020 report to the board

Apache Geode developers, please thank Dave Barnes for putting together
the May 2020 board report that I filed today.  Here is the contents of the
report:

## Description:
The mission of Apache Geode is the creation and maintenance of software
related to a data management platform that provides real-time, consistent
access to data-intensive applications throughout widely distributed cloud
architectures.

## Issues:
296 issues opened in JIRA, past quarter (-16% decrease) 226 issues closed in
JIRA, past quarter (-26% decrease)

Given the worldwide impact of the Covid-19 pandemic disruption to our
community's work routines, we feel these figures, though lower than those of
the previous reporting period, reveal an engaged and productive development
community.

## Membership Data:
Apache Geode was founded 2016-11-15 (3 years ago)
There are currently 109 committers and 54 PMC members in this project.
The Committer-to-PMC ratio is roughly 7:4.

Community changes, past quarter:
- Alexander Murmann was added to the PMC on 2020-03-26
- Joris Melchior was added to the PMC on 2020-03-22
- Mark Hanson was added to the PMC on 2020-03-26
- Joris Melchior was added as committer on 2020-03-19
- Mario Kevo was added as committer on 2020-03-23

## Project Activity:
- version 1.12.0 was released on 2020-03-31 This release included improvements
  to the management REST API, .NET and C++ native clients, client/server
  security, and error recovery.
- version 1.13 release is under way

## Community Health:
The Apache Geode dev and issues mailing lists both experienced upticks in
discussion traffic, up 15% and 44%, respectively, in Q1.

The number of JIRA tickets opened and closed remained robust, though down 16%
and 26%, respectively, from the previous quarter. Points of emphasis included
error recovery improvements, API extensions, and compatibility to accommodate
containers such as Kubernetes and BOSH.

In February, community member Jason Huynh posted an article entitled "Apache
Geode as a remote Gradle Build Cache"
(https://jasonhuynh.blogspot.com/2020/02/apache-geode-as-remote-gradle-build.html).
In March, Jason posted "Publishing Apache Geode Metrics to Wavefront"
(https://medium.com/@huynhja/
publishing-apache-geode-metrics-to-wavefront-6e9a6cf5992b) along with an
accompanying video (https://youtu.be/BDZh-FLkDTg).

Community member Juan Jose Ramos posted an article in March entitled "Geode
Distributed Sequences"
(https://medium.com/@jujoramos/geode-distributed-sequences-12626251d5e3), and
another in April, "The Command Region Pattern"
(https://medium.com/@jujoramos/the-command-region-pattern-14bc49594eca).

In April, community member Barry Oglesby published "Remove Unused PdxTypes
from an Apache Geode Distributed System"
(https://medium.com/@boglesby_2508/remove-unused-pdxtypes-from-an-apache-geode-distributed-system-5a4f0e199e34).

Re: GitHub Project Board Applications API

[Nabarun Nag]

>
> What are you hoping to learn from the exploration?

- what features are available and how can we use them.

What hypothesis is the experiment trying to prove/disprove?
>
Hypothesis: "Github project boards can help in project management."

Hopefully we may be able to use them in the near future.

Regards
Naba


On Fri, May 1, 2020 at 4:28 PM Michael Oleske  wrote:

> What are you hoping to learn from the exploration?  What hypothesis is the
> experiment trying to prove/disprove?
>
> -michael
>
> On Fri, May 1, 2020 at 4:26 PM Nabarun Nag  wrote:
>
> > It is just an experiment at the moment. We are researching ways of
> > automating processes. It is an exploration attempt hence not being
> > discussed at this point in time as we don't have all the information.
> >
> > Regards
> > Naba
> >
> >
> > On Fri, May 1, 2020 at 4:00 PM Michael Oleske 
> wrote:
> >
> > > Hi Devs!
> > >
> > > I saw on github that the main geode project now has a project board (
> > > https://github.com/apache/geode/projects/1).  I don't remember it
> being
> > > discussed on the dev list.  Are some folks using it now for
> organization?
> > > I'm curious how that flow works since our Jira could also be doing that
> > > flow.  I ask cause I'm definitely one of those folks who'd like to
> > > consolidate things closer to code (so github issues and the like).  I'm
> > > wondering who's it is helping since we as an open source community
> > haven't
> > > really talked about making project boards/kanban boards all that often
> > with
> > > the tools we do have.
> > >
> > > -michael
> > >
> >
>

Re: GitHub Project Board Applications API

[Nabarun Nag]

We can ignore this board as it is not part of the agreed-upon open-source
process at the moment.
Regards
Naba

On Fri, May 1, 2020 at 4:26 PM Nabarun Nag  wrote:

> It is just an experiment at the moment. We are researching ways of
> automating processes. It is an exploration attempt hence not being
> discussed at this point in time as we don't have all the information.
>
> Regards
> Naba
>
>
> On Fri, May 1, 2020 at 4:00 PM Michael Oleske  wrote:
>
>> Hi Devs!
>>
>> I saw on github that the main geode project now has a project board (
>> https://github.com/apache/geode/projects/1).  I don't remember it being
>> discussed on the dev list.  Are some folks using it now for organization?
>> I'm curious how that flow works since our Jira could also be doing that
>> flow.  I ask cause I'm definitely one of those folks who'd like to
>> consolidate things closer to code (so github issues and the like).  I'm
>> wondering who's it is helping since we as an open source community haven't
>> really talked about making project boards/kanban boards all that often
>> with
>> the tools we do have.
>>
>> -michael
>>
>

Re: GitHub Project Board Applications API

[Nabarun Nag]

It is just an experiment at the moment. We are researching ways of
automating processes. It is an exploration attempt hence not being
discussed at this point in time as we don't have all the information.

Regards
Naba


On Fri, May 1, 2020 at 4:00 PM Michael Oleske  wrote:

> Hi Devs!
>
> I saw on github that the main geode project now has a project board (
> https://github.com/apache/geode/projects/1).  I don't remember it being
> discussed on the dev list.  Are some folks using it now for organization?
> I'm curious how that flow works since our Jira could also be doing that
> flow.  I ask cause I'm definitely one of those folks who'd like to
> consolidate things closer to code (so github issues and the like).  I'm
> wondering who's it is helping since we as an open source community haven't
> really talked about making project boards/kanban boards all that often with
> the tools we do have.
>
> -michael
>

Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project

[Nabarun Nag]

Hi Anthony!

Sorry for the late reply but I was doing some research. The issues and wiki
section as of now has been used by few engineers only and Confluent has not
yet entered any issues as they are still reviewing the project. I went
ahead and looked into all projects in the Apache domain using issues and
the extra features they enable.
*JIRA vs Issues:*

   - There are a sizable number of Apache projects who are using GitHub
   issues
   - One clear advantage is the automatic linking of PRs and Issues. Issues
   can be closed automatically once the PR is merged.
   - It can also enable a feature to delete the feature branch
   automatically once the PRs is merged (we have lot unused feature/GEODE-
   branches in origin which were not deleted after merging PRs)
   - It enables us to use Github Project management(Github version of
   PivotalTracker)  which is integrated with Github issues and PRs and all the
   movement from "To-do", "In-progress", "resolved" and "closed" are automated
   depending on if a PR is opened, requires reviews, reviewed and merged state.

*Github Wiki vs Confluence Wiki:*

   - As you have mentioned that visibility is more important, we can follow
   other open-source products like Greenplum, Hystrix and we can use the wiki
   page to explain stuff like how to contribute, basic architecture, internal
   knowledge, i.e information that is needed to contribute to Geode.
   - A signification advantage is the colocation of code and wiki. Any
   developer can find Geode GitHub repo and that person now has all the tools
   needed to start contributing.


A few examples of well-written wikis on GitHub:

   - https://github.com/d3/d3/wiki
   - https://github.com/Netflix/Hystrix/wiki
   - https://github.com/apache/helix/wiki


ASF: word on the street is that it was mentioned in ApacheCon, that they
support the use of Github wiki and issues in ASF projects, and this can
also be seen in multiple INFRA tickets mentioning enabling wiki.

I am also looking into ZenHub to improve our workflow. ZenHub is a very
robust project management tools used by Apache Contributors and
corporations like VMware.

Regards
Nabarun Nag


On Thu, Apr 23, 2020 at 2:40 PM Anthony Baker  wrote:

> Having used pretty every style of wiki, I care less about the wiki tech
> and more about making the content easily accessible and discoverable for
> our users and contributors.  Our current wiki has a lot of useful
> information.  I’d like to understand how we want to use repo-specific
> wiki’s to augment or replace our current project wiki (or neither)\ before
> taking any decisions.
>
> Anthony
>
>
> > On Apr 23, 2020, at 12:54 PM, Blake Bender  wrote:
> >
> > GitHub Wiki supports Markdown, our current one does not.  This means
> GitHub
> > wins by default in my book.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Thu, Apr 23, 2020 at 8:50 AM Anthony Baker  wrote:
> >
> >> Naba, do you have any updates to share?  I’m curious if you have found
> >> this useful compared to JIRA.
> >>
> >> Also, I noticed that geode-kafka-connector also has a GitHub wiki.  How
> >> does that compare with centralizing our information in the ASF
> confluence
> >> wiki?
> >>
> >> Thanks,
> >> Anthony
> >>
> >>
> >>> On Mar 21, 2020, at 5:16 PM, Nabarun Nag  wrote:
> >>>
> >>> Hello team,
> >>>
> >>> We are planning to experiment with using Github issues and wiki for the
> >>> Apache project *Geode-Kafka-Connector. *(not Apache Geode project).
> >> Please
> >>> do give your vote on this as we need to send the vote link to infra to
> >>> activate it.
> >>>
> >>> *Why are we doing this ? / Advantages* :
> >>> 1. *Unified location* to have documentation, code and issue tracking.
> >>> 2. Leverage Github tools like Github pages to create websites hosting
> >>> information about the project.
> >>> 3. No separate JIRA accounts or permission required to create issues.
> >>> 4. This will have *no impact on the broader Geode community* as right
> now
> >>> only 3-4 developers involved in this project.
> >>> 5. *This is an experiment.* If things do not work out we can always
> >> revert
> >>> back to the traditional way of having separate JIRA, documentation,
> >>> websites etc.
> >>>
> >>> *Precedence*:
> >>> 1. Kubernetes uses the github issues
> >>> 2. RabbitMQ uses github issues.
> >>>
> >>>
> >>> *NOTE: *- Please be cordial and do not use any condescending language
> and
> >>> absolutely no bullying.
> >>> - Please treat this email as a professional business email and maintain
> >>> email etiquette while replying.
> >>>
> >>> Regards
> >>> Nabarun
> >>
> >>
>
>

[ANNOUNCE] Github Wiki and Issus are now activated on geode-kafka-connector

[Nabarun Nag]

Hi,

Issues are wiki pages  are now active on the geode-kafka-connector
repository. Thank you all for the kind votes.

Regards
Nabarun Nag

[VOTE] Using Github issues and wiki for geode-kafka-connector project

[Nabarun Nag]

Hello team,

We are planning to experiment with using Github issues and wiki for the
Apache project *Geode-Kafka-Connector. *(not Apache Geode project). Please
do give your vote on this as we need to send the vote link to infra to
activate it.

*Why are we doing this ? / Advantages* :
1. *Unified location* to have documentation, code and issue tracking.
2. Leverage Github tools like Github pages to create websites hosting
information about the project.
3. No separate JIRA accounts or permission required to create issues.
4. This will have *no impact on the broader Geode community* as right now
only 3-4 developers involved in this project.
5. *This is an experiment.* If things do not work out we can always revert
back to the traditional way of having separate JIRA, documentation,
websites etc.

*Precedence*:
1. Kubernetes uses the github issues
2. RabbitMQ uses github issues.


*NOTE: *- Please be cordial and do not use any condescending language and
absolutely no bullying.
- Please treat this email as a professional business email and maintain
email etiquette while replying.

Regards
Nabarun

Re: [PROPOSAL] Include fix for GEODE-7763 into release 1.12.0

[Nabarun Nag]

+1

On Wed, Mar 18, 2020 at 11:41 AM Jason Huynh  wrote:

> Hello Dev list,
>
> I'd like to include a fix for GEODE-7763 in release 1.12.0.
> The change removes the call to exportValue, preventing a serialization,
> when no clients are waiting for the specific event.
> The reason why I think it should be in the release is that we noticed a
> negative effect on performance for a specific use case, in 1.12 from a
> change that made us more "consistent" in that use case.  This change
> doesn't modify the fix much, but does bring performance back inline (if not
> better) than before.
>
> The sha is b4c3e9413f0008635b0a0c9116c96147d1e4ceec
>
> Thanks,
> -Jason
>

Re: [PROPOSAL] eliminate file count loophole in PR StressNewTest

[Nabarun Nag]

+1

On Fri, Mar 6, 2020 at 6:33 PM Donal Evans  wrote:

> With fairly apt timing, we've recently had a PR merged (
> https://github.com/apache/geode/pull/4745) that introduced a test that has
> resulted in fairly consistently flaky failures in the pipeline (JIRA
> ticket: https://issues.apache.org/jira/projects/GEODE/issues/GEODE-7843).
> The PR was quite large and touched/created a lot of tests, so StressNewTest
> never ran on it:
> https://concourse.apachegeode-ci.info/builds/136784#L5e3ac3fc:2. Given how
> frequently the test is failing in the pipeline (11 failures on various
> IntegrationTest jobs over the past 6 commits), it seems very likely that
> had StressNewTest been allowed to run, this issue would have been caught at
> the PR stage and could have been remedied then, instead of resulting in a
> nearly constantly red pipeline.
>
> I've already given my +1 to this proposal, but this situation has prompted
> me to make it a *+1*.
>
> On Tue, Mar 3, 2020 at 2:08 PM Anilkumar Gingade 
> wrote:
>
> > The stress test is to identify the flaky-ness within the test; and
> assuming
> > any changes to the test may have introduced the flaky-ness.
> > It's about paying the cost upfront or later when the test is determined
> to
> > be flaky.
> > If 25+ tests have been changed in a PR, the cost of running stress test
> for
> > those;  and gating the PR for so long.
> > Knowing how much pain it causes to fix a flaky test after a certain/long
> > duration of time; I am +1 for doing this change.
> >
> > On Tue, Mar 3, 2020 at 10:06 AM Dan Smith  wrote:
> >
> > > What's the current timeout for StressNewTest? Maybe if we just up the
> > > threshold to 100 tests or so and up the timeout to match we can catch
> > > pretty much all PRs.
> > >
> > > I'm not sure why the job is flagging more tests than it should. It
> looks
> > > like at some point @rhoughon changed it to read the merge base from
> some
> > > file created by concourse as an optimization [1] - I suspect maybe that
> > > file is inaccurate?
> > >
> > > I originally wrote this job. It's definitely not a panacea, it will
> only
> > > catch a new flaky test if
> > >  - the test is really flaky (likely to fail more than 1/50 times)
> > >  - the change actually happened in the test file itself, and not the
> > > product or some other test file.
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/apache/geode/commit/4c06ba4625e69d44a5165aa9f2fccddfc064de87
> > >
> > > -Dan
> > >
> > > On Sun, Mar 1, 2020 at 9:00 PM Owen Nichols 
> wrote:
> > >
> > > > We don’t tend to look too closely at successful PR checks to see
> > whether
> > > > they actually checked anything at all.
> > > >
> > > > One example I found is
> > > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/StressNewTestOpenJDK11/builds/5957
> > > > <
> > > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/StressNewTestOpenJDK11/builds/5957
> > > > >:
> > > > 32 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.
> > > >
> > > > Here are 92 more examples (url’s omitted for brevity — use the
> example
> > > > above as a template and just replace the last 4 digits):
> > > > 26 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6243)
> > > > 26 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6249)
> > > > 26 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6402)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6262)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6430)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6439)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6449)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6454)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6458)
> > > > 27 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6459)
> > > > 28 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6224)
> > > > 28 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6441)
> > > > 28 is too many changed tests to stress test. Allowing this job to
> pass
> > > > without stress testing.  (build 6448)
> > > > 28 is too many changed tests to stress test. Allowing this job to
> pass

Re: [PROPOSAL] StressNewTest in Pull Request Pipeline to be made optional.

[Nabarun Nag]

What help is needed in this effort?

Regards
Naba

On Fri, Feb 28, 2020 at 11:35 AM Mark Hanson  wrote:

> Alright, so basically it seems like people are not ok with the not
> requiring stressnewtest approach. So I guess that means that we need to
> identify -1s willing to help resolve this problem…
>
> Who would like to help?
>
> Thanks,
> Mark
>
> > On Feb 28, 2020, at 11:12 AM, Ernest Burghardt 
> wrote:
> >
> > -1 to limiting any tests... if there are issues with the tests let's fix
> > that.  we have too many commits coming in with little or no testing over
> > new/changed code, so I can't see how removing any existing test coverage
> as
> > a good idea
> >
> > Best,
> > EB
> >
> > On Fri, Feb 28, 2020 at 10:58 AM Mark Hanson  wrote:
> >
> >> Just to make sure we are clear, I am not suggesting that we disable
> >> stressnewtest, but that we make it not required. It would still run and
> >> provide feedback, but it would not give us an unwarranted green in my
> >> approach.
> >>
> >>> On Feb 28, 2020, at 10:49 AM, Ju@N  wrote:
> >>>
> >>> +1 to what Owen said, I don't think disabling *StressNewTest* is a
> >>> good idea.
> >>>
> >>> On Fri, 28 Feb 2020 at 18:35, Owen Nichols 
> wrote:
> >>>
>  -1 to making StressNew not required
> 
>  +1 to eliminating the current loophole — StressNew should never give a
>  free pass.
> 
>  Any time your PR is having trouble passing StressNew, please bring it
> up
>  on the dev list. We can review on a case-by-case basis and decide
> >> whether
>  to try increasing the timeout, changing the repeat count, refactoring
> >> the
>  PR, or as an absolute last resort requesting authorization for an
> >> override
>  (for example, a change to spotless rules might touch a huge number of
> >> files
>  but carry no risk).
> 
>  One bug we should fix is that StressNew sometimes counts more files
>  touched than really were, especially if you had many commits or merges
> >> or
>  rebases on your PR branch.  Possible workarounds there include
> squashing
>  and/or creating a new PR and/or splitting into multiple PRs.  I’ve
> spent
>  some time trying to reproduce why files are mis-counted, with no
> >> success,
>  but perhaps someone cleverer with git could provide a fix.
> 
>  Another issue is that StressNew is only in the PR pipeline, not the
> main
>  develop pipeline.  This feels like an asymmetry where PRs must pass a
>  “higher” standard.  We should consider adding some form of StressNew
> to
> >> the
>  main pipeline as well (maybe compare to the previous SHA that
> passed?).
> 
>  The original motivation for the 25-file limit was an attempt to limit
> >> how
>  long StressNew might run for.  Since concourse already applies a
> >> timeout,
>  that check is unnecessary.  However, a compromise solution might be to
> >> use
>  the number of files changed to dial back the number of repeats, e.g.
> >> stay
>  with 50 repeats if fewer than 25 files changed, otherwise compute
> 1250 /
>  <#-files-changed> and do only that many repeats (e.g. if 50 files
> >> changed,
>  run all tests 25x instead of 50x).
> 
>  While StressNew is intended to catch new flaky tests, it can also
> catch
>  poorly-designed tests that fail just by running twice in the same VM.
> >> This
>  may be a sign that the test does not clean up properly and could be
>  polluting other tests in unexpected ways?  It might be useful to run a
>  “StressNew” with repeats=2 over a much broader scope, maybe even all
> >> tests,
>  at least once in a while?
> 
> 
> > On Feb 28, 2020, at 9:51 AM, Mark Hanson  wrote:
> >
> > Hi All,
> >
> > Proposal: Force StressNewTest to fail a change with 25 or more files
>  rather than pass it without running it.
> >
> > Currently, the StressNewTest job in the pipeline will just pass a job
>  that has more than 25 files changed. It will be marked as green with
> no
>  work done. There are reasons, relating to run time being too long to
> be
>  tracked by concourse, so we just let it through as a pass. I think
> this
> >> is
>  a bad signal. I think that this should automatically be a failure in
> the
>  short term. As a result, I also think it should not be required. It
> is a
>  bad signal, and I think that by making it a fail, this will at least
> not
>  give us a false sense of security. I understand that this opens the
> >> flood
>  gates so to speak, but I don’t think as a community it is a big
> problem
>  because we can still say that you should not merge if the
> StressNewTest
>  fails because of your test.
> >
> > I personally find the false sense of security more troubling than
>  anything. Hence the reason, I would like this to be
> >
> > Let me know what you think..
> >
> > Thanks,
> > Mark
> 
> 
> >>>
> >>> 

OQL Method Authorizer Blog

[Nabarun Nag]

Hi Geode Community,

Please do visit the blog that Juan Ramos has put up on the OQL Method
Authorizer :
https://jujoramos.blogspot.com/2020/02/pluggable-oql-method-authorization.html

Thank you Juan for this effort.

Regards
Nabarun Nag

[ANNOUNCE] OQL Method Invocation Security

[Nabarun Nag]

Hi Geode Community,

We are pleased to announce that the work on OQL Method Invocation Security
work has been completed and pushed to develop. It will be available in the
next release - Apache Geode 1.12

These following goals have been achieved:

   - Pluggable method authorizers.
   - OQL method invocation security "on" by default when Security is
   enabled at the cluster level.
   - Authorizers stored and retrieved through the cluster configuration
   service.
   - QueryService.allowUntrustedMethodInvocation marked as deprecated.
   - Prevents RCE (Remote Code Execution) exploits and other
   vulnerabilities in OQL expressions when security is enabled at the cluster
   level.
   - Configurable in runtime
   - Invoke methods on domain classes (present on the system classpath or
   deployed through gfsh) as part of OQL queries, relatively easy and with
   little to no configuration changes.


These following method authorizers are available out of the box:

   - RestrictedMethodAuthorizer
   - UnrestrictedMethodAuthorizer
   - RegExMethodAuthorizer
   - JavaBeanAccessorMethodAuthorizer


Details about architecture can be found here:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security


Regards
Nabarun Nag

[ANNOUNCE] geode-kafka-connector

[Nabarun Nag]

Hi Geode Community,

In the past 2 weeks, Jason Huynh coded up an Apache Kafka - Apache Geode
connector which is able to use Apache Geode as a sink and as a source.

We are very pleased to announce that the code is now open-sourced under
Apache Software Foundation repositories and is available at
https://github.com/apache/geode-kafka-connector

We have tested basic features including security and are experimenting with
integration with cloud platforms. Currently, Donal Evans and I along with
Jason are getting other features completed which are required by Confluent
to get the connector certified.

We will highly appreciate any feedback and contributions from the
community. Please do reach out to us if you have any questions or concerns.

We will reach out to the community when we are ready with the first release.

Regards
Nabarun Nag

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

[Nabarun Nag]

+1

On Thu, Feb 13, 2020 at 2:09 AM Ju@N  wrote:

> Hello devs,
>
> I'd like to include the fix for GEODE-7789 [1] in release 1.12.0.
> The change prevents a performance degradation introduced in Geode 1.11, it
> basically shows up on clusters where there's at least one client with
> subscription enabled.
> The SHA is 71e156a55228d89efafd048e1533debba606c064 [2].
> Best regards.
>
> [1]: https://issues.apache.org/jira/browse/GEODE-7789
> [2]:
>
> https://github.com/apache/geode/commit/71e156a55228d89efafd048e1533debba606c064
>
> --
> Ju@N
>

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

[Nabarun Nag]

++

On Wed, Feb 5, 2020 at 9:54 AM Alexander Murmann 
wrote:

> +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: WAN replication issue in cloud native environments

[Nabarun Nag]

Hi Alberto,

Thank you for the contributions to the Apache Geode project

Here are a few feedback and pointers that we came up with:
1. Right now looking at your solution, we can see that you are modifying
the class "ServerLocation" which is used to stored as a key in the
connectionMap in LocatorLoadSnapshot.
2. ServerLocation was modified to include the memberID to differentiate
each server with the same hostname-for-sender and same pair of start and
end ports.
3. As ServerLocation is transmitted, there were a lot of changes in terms
of serialization etc. and also modification in ops code.

Suggestion:
- Instead, can we create a new class that contains the memberID and
ServerLocation and that new class object is added as a key in the
connectionMap.
- When member leaves, only that entry is removed from the connectionMap.
- When the remote locator is requesting the receiver information we
continue sending the ServerLocation, that we extract from the newly created
class.

Advantage:
- No changes required in terms of serialization as we are still sending the
ServerLocation like before.
- No changes to the ops.
- No extra bits sent over the wire


Please do let us know what do you feel about this solution.

Regards
Naba








On Tue, Jan 21, 2020 at 7:01 AM Alberto Bustamante Reyes
 wrote:

> Hi,
>
> I have been implementing a possible solution for this issue, and although
> I have not finished yet, I would like to kindly ask for comments.
>
> I created some Helm charts to explain and reproduce the problem, if you
> are interested they are here:
> https://github.com/alb3rtobr/geode-cloudnative-wan-replication
>
> The solution consists on adding to ServerLocation the id of the member
> hosting the server, to allow to differentiate two or more gateway receivers
> with the same ip but that are in different locations. I verified that this
> change fixes the problem.
>
> After that, I have been working on fixing issues with the existing tests.
> In the meanwhile, it will be useful to get some feedback about the
> solution, specially if there are impacts I have not considered yet (maybe
> they are the reason for the failing tests Im currently working on).
>
> The code can be found on this PR:
> https://github.com/apache/geode/pull/4489
>
> Thanks in advance!
>
> Alberto B.
>
>
> 
> De: Anilkumar Gingade 
> Enviado: viernes, 6 de diciembre de 2019 18:56
> Para: geode 
> Cc: Charlie Black 
> Asunto: Re: WAN replication issue in cloud native environments
>
> Alberto,
>
> Can you please file a JIRA ticket for this. This could come up often as
> more and more deployments move to K8s.
>
> -Anil.
>
>
> On Fri, Dec 6, 2019 at 8:33 AM Sai Boorlagadda 
> wrote:
>
> > > if one gw receiver stops, the locator will publish to any remote
> locator
> > that there are no receivers up.
> >
> > I am not sure if locators proactively update remote locators about change
> > in receivers list rather I think the senders figures this out on
> connection
> > issues.
> > But I see the problem that local-site locators have only one member in
> the
> > list of receivers that they maintain as all receivers register with a
> > single  address.
> >
> > One idea I had earlier is to statically set receivers list to locators
> > (just like remote-locators property) which are exchanged with gw-senders.
> > This way we can introduce a boolean flag to turn off wan discovery and
> use
> > the statically configured addresses. This can be also useful for
> > remote-locators if they are behind a service.
> >
> > Sai
> >
> > On Thu, Dec 5, 2019 at 2:33 AM Alberto Bustamante Reyes
> >  wrote:
> >
> > > Thanks Charlie, but the issue is not about connectivity. Summarizing
> the
> > > issue, the problem is that if you have two or more gw receivers that
> are
> > > started with the same value of "hostname-for-senders", "start-port" and
> > > "end-port" (being "start-port" and "end-port" equal) parameters, if one
> > gw
> > > receiver stops, the locator will publish to any remote locator that
> there
> > > are no receivers up.
> > >
> > > And this use case is likely to happen on cloud-native environments, as
> > > described.
> > >
> > > BR/
> > >
> > > Alberto B.
> > > 
> > > De: Charlie Black 
> > > Enviado: miércoles, 4 de diciembre de 2019 18:11
> > > Para: dev@geode.apache.org 
> > > Asunto: Re: WAN replication issue in cloud native environments
> > >
> > > Alberto,
> > >
> > > Something else to think about SNI based routing.   I believe Mario
> might
> > be
> > > working on adding SNI to Geode - he at least had a proposal that he
> > > e-mailed out.
> > >
> > > Basics are the destination host is in the SNI field and the proxy can
> > > inspect and route the request to the right service instance. Plus
> we
> > > have the option to not terminate the SSL at the proxy.
> > >
> > > Full disclosure - I haven't tried out SNI based routing myself and it
> is
> > > something that I thought 

Re: [DISCUSS] Proposal to require linear commit history on develop

[Nabarun Nag]

t;> are still other ways to get non-compiling commits onto develop (e.g.
> >>> waiting a long time between running PR checks and merging to develop).
> >>> What’s more important is working well together as a community. So,
> >> perhaps
> >>> what’s best for the community is to encourage working on trust rather
> >> than
> >>> unnecessary constraints.
> >>>
> >>> -Owen
> >>>
> >>> On Dec 31, 2019, at 10:56 AM, Kirk Lund  wrote:
> >>>
> >>> I'm happy to file multiple PRs when I need to merge multiple commits to
> >>> develop.
> >>>
> >>> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson 
> wrote:
> >>>
> >>> This change to disable all but squash-merge would be really easy to
> >>> revert. How about we try it for a while and see? If people decide it is
> >>> really limiting them, we can change it back. Let’s do it for 1 month
> and
> >>> see how it goes. Does that sound reasonable?
> >>>
> >>> Thanks,
> >>> Mark
> >>>
> >>> On Dec 30, 2019, at 5:25 PM, Owen Nichols  wrote:
> >>>
> >>> Given that we adopted <
> >>>
> >>>
> >>
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
> >>>>
> >>> and still wish to continue <
> >>>
> >>
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
> >>>>
> >>> having branch protection rules to ensure every commit landing in
> develop
> >>> has passed the required PR checks, it seems like that decision alone
> >>> mandates that we disable all merge mechanisms other than
> >> squash-and-merge.
> >>>
> >>>
> >>> Allowing merge commits or rebase merges bypasses branch protection for
> >>>
> >>> all commits other than the final one in the merge or rebase set.  Given
> >>> that we decided <
> >>>
> >>
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
> >>>>
> >>> that bypassing PR checks should never be allowed, keeping this loophole
> >>> open seems untenable.
> >>>
> >>>
> >>> This is not just hypothetical — this loophole is causing real problems.
> >>>
> >>> We now have commits on develop that don’t compile.  For example:
> >>>
> >>> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> >>> ./gradlew devBuild
> >>> ...spotlessJava FAILED
> >>> We implemented branch protections to make this impossible, right?
> >>>
> >>> We can very easily close this loophole by disabling all but the
> >>>
> >>> Squash button for PRs.  This will not make more work for any
> >>> developer.  If you want to get multiple commits onto develop, simply
> >> submit
> >>> each as a separate PR — that is the only way to assure that required PR
> >>> checks have passed for each.
> >>>
> >>>
> >>> On the other hand, if we as a Geode community feel strongly that
> >>>
> >>> bypassing branch protection via merge commits and rebase commits is
> >>> important to allow, why not also allow arbitrary overrides (or get rid
> of
> >>> branch protection entirely)?
> >>>
> >>>
> >>> -Owen
> >>>
> >>> On Dec 20, 2019, at 12:31 PM, Blake Bender  wrote:
> >>>
> >>> Just FWIW, the situation described of having multiple commits in a
> >>>
> >>> single
> >>>
> >>> PR with separate associated JIRA tickets is still kind of problematic.
> >>>
> >>> It
> >>>
> >>> could well be the case that the commits are interdependent, thus when
> >>> bisecting etc it's still not possible to revert the fix for a single
> >>> bug/feature/whatever atomically.  It's all good, though, I'm satisfied
> >>>
> >>> no
> >>>
> >>> one's forcing me to adopt practice I'm opposed to.  Apologies for
> >>>
> >>> getting
> >>>
> >>> my feathers a little ruffled, or if I ruffled anyone else's in return.
> >>>
> >>> Thanks,
> >>&g

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

[Nabarun Nag]

+1 to Dan's suggestions.

- Remove in batches.
- Send review requests for those PRs to relevant committers (authors of
those tests etc.)
- A brief explanation on why these tests are being deleted, and there is no
loss of test coverage as it is covered by these other tests (or some other
reason).

Regards
Nabarun Nag

On Tue, Dec 31, 2019 at 5:32 PM Dan Smith  wrote:

> Some of these test have been ignored for a long time. However, looking at
> the history, I see we have ignored some tests as recently as in the last
> month, for what seem like some questionable reasons.
>
> I'm concerned that this could be a two step process to losing test coverage
> - someone who things the test is still valuable but intends to fix it later
> ignores it, and then someone else deletes it.
>
> So what I would suggest is that if we are going to delete them, let's do it
> in batches in get folks that have context on the code being tested to
> review the changes. Make sense?
>
> Also +1 to not ignoring any more tests - it would be nice to get down to 0
> Ignored tests and enforce that!
>
> -Dan
>
> On Tue, Dec 31, 2019 at 4:52 PM Aaron Lindsey 
> wrote:
>
> > I’m in favor of deleting all except the ones that have JIRA tickets open
> > for them, like Bruce said.
> >
> > Also going forward I’d like to see us not be checking in @Ignored tests —
> > just delete them instead. If we need to get it back we have revision
> > history. Just my two cents.
> >
> > Aaron
> >
> > > On Dec 31, 2019, at 2:53 PM, Bruce Schuchardt 
> > wrote:
> > >
> > > I agree with deleting @Ignored tests except for the few that have JIRA
> > tickets open for them.  There are less than 1/2 dozen of these and we
> > should consider keeping them since we have a way of tracking them.
> > >
> > > On 12/31/19 2:07 PM, Alexander Murmann wrote:
> > >> 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: [DISCUSS] abandon branch protection rules

[Nabarun Nag]

Please maintain the branch protection rules.
Waiting for reviews and Unit tests to pass does not stifle productivity,
but prevents us from making mistakes that are detrimental to the entire
community. If I am not mistaken, we still have pushed code which broke
builds and regressions. I would suggest not removing but improving / add
ons to the checks to prevent such issues from happening again.

Also, personally I feel that CI code can separated out of geode code base
as they have no tests to run and they can circumvent the unit test pass
criteria.

I would just like to say that fixing tests is all of our responsibility,
not a particular group of developers.

Regards
Naba







On Fri, Dec 27, 2019 at 3:05 PM Jason Huynh  wrote:

> Just to add more flavor to my previous response... I currently have a PR
> open that modified a method signature that touched a few WAN tests.  It was
> a simple change, removing an unused parameter.  StressNewTest failed and I
> had to spend another day figuring out 10 or so different failures.  A waste
> of time?  Maybe..  At first, I wasn't going to continue, but after trying a
> few things, it looks like the tests installed a listener that was hampering
> other tests.  At the end (soon once it gets reviewed/merged), we end up
> with a Green PR and hopefully have unblocked others on these specific tests
> in the future.
>
> On Fri, Dec 27, 2019 at 2:58 PM Jason Huynh  wrote:
>
> > I feel the frustration at times, but I do also think the ci/pipelines are
> > improving, breaking less often.  I'm ok with the way things are for the
> > moment
> >
> > On Fri, Dec 27, 2019 at 1:47 PM Owen Nichols 
> wrote:
> >
> >> In October we agreed to require at least 1 reviewer and 4 passing PR
> >> checks before a PR can be merged.  Now that we’re tried it for a few
> >> months, do we like it?
> >>
> >> I saw some strong opinions on the dev list recently:
> >>
> >> > Changes to the infrastructure to flat out prevent things that should
> be
> >> self policing is annoying. This PR review lock we have had already cost
> us
> >> valuable time waiting for PR pipelines to pass that have no relevance to
> >> the commit, like CI work. I hate to see process enforced that keeps us
> from
> >> getting work done when necessary.
> >>
> >>
> >> and
> >>
> >> > I think we're getting more and more bureaucratic in our process and
> >> that it stifles productivity.  I was recently forced to spend three days
> >> fixing tests in which I had changed an import statement before they
> would
> >> pass stress testing.  I'm glad the tests now pass reliably but I was
> very
> >> frustrated by the process.
> >>
> >>
> >> Just wondering if others feel the same way.  Is it time to make some
> >> changes?
> >>
> >> -Owen
> >
> >
>

Re: [DISCUSS] Proposal to require linear commit history on develop

[Nabarun Nag]

Hi Dan,

When we do squash merge all the commit messages are preserved and also the
co-authored tag works when we do squash merge.
So the authorship and history are preserved.

In my own personal experience and reverts and pinpointing regression
failures are tough when the commits are spread out. Also, reverts are
easier when it is just one commit while we are bisecting failures.


Regards
Naba

On Fri, Dec 20, 2019 at 12:07 PM Dan Smith  wrote:

> I'll change to -0.
>
> I think merge commits are a nice way to record history in some cases, and
> can also be a way to avoid messy conflicts that come with rebase. Merge
> commits also preserve authorship of commits (compared to squash-merge),
> which I think is valuable as an open source community that is trying to
> keep track of outside contributions.
>
> That said, if the rest of y'all feel it will help to disable the button, I
> won't stand in the way.
>
> -Dan
>
> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker  wrote:
>
> > Whether we are talking about the geode/ repository or the geode-native/
> > repository we are all one GEODE community.
> >
> > The idea of a native client team may matter in some contexts but in this
> > space we are all GEODE contributors.
> >
> > Adopting a common approach across our repos will make it easier for new
> > contributors to engage, learn our norms, and join our efforts.
> >
> > $0.02,
> > Anthony
> >
> >
> > > On Dec 20, 2019, at 11:32 AM, Blake Bender  wrote:
> > >
> > > Is this a policy the native client team must abide by, as well?  It
> > varies
> > > slightly with what we've been doing, and all other things being equal I
> > see
> > > no reason for us to change that.  If I am to have any measure of
> control
> > > over the nc repository, I will definitely enforce a 1:1 correspondence
> > > between commits to develop and JIRA tickets.  IMO, if your refactoring
> > in a
> > > PR is sufficiently large or complex that it's difficult to tease it out
> > > from the bug you're fixing or feature you're implementing, it merits
> its
> > > own JIRA ticket and a separate PR.  If your "actual" fix then becomes
> > > dependent on the refactored code, that's a price I'm willing to pay to
> > keep
> > > history clean.
> > >
> > > On the other hand, I see no real value in squashing to a single commit
> > > prior to submitting a PR, since your view of the changes on GitHub is
> > > essentially the same either way.  We haven't enforced this on the nc
> > repo,
> > > and I'd prefer to keep it that way.
> > >
> > > Thanks,
> > >
> > > Blake
> > >
> > >
> > > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao 
> wrote:
> > >
> > >> Merge commit is the new contributor's default setting. When we are
> > merging
> > >> new contributor's PR, since we are so used to THINKING
> > "squash-and-merge"
> > >> is the default, we forgot to check what the button really says when we
> > are
> > >> merging other people's PR.
> > >>
> > >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > eburgha...@pivotal.io>
> > >> wrote:
> > >>
> > >>> I'm a proponent of using squash-and-merge, and once a person has
> chosen
> > >>> this option once it comes up by default afterwards...
> > >>>
> > >>> Owen,  I don't think you have consensus to put forth this PR, there
> are
> > >> -1s
> > >>> above... (early voting)
> > >>>
> > >>> maybe we'll be better off socializing the norm of squash-and-merge
> and
> > >>> gaining a natural consensus that way...
> > >>>
> > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols 
> > >> wrote:
> > >>>
> > >>>> The proposed action manifests as a commit to the Geode git
> repository,
> > >> so
> > >>>> a PR is an acceptable vehicle for voting in this case.
> > >>>>
> > >>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> > >> bschucha...@pivotal.io>
> > >>>> wrote:
> > >>>>>
> > >>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> > >> thread
> > >>>> and a request to "vote" using a PR.  This all seems out of order to
> > me.
> > >>>> Our votes are suppose

Re: [DISCUSS] Proposal to require linear commit history on develop

[Nabarun Nag]

Just to reiterate. Nothing changes in the workflow of a developer. It's
just in the end, when all the reviews are done and all the tests are
passing, then the button to click in the Github web UI is "Squash and
Merge". That's all.

Regards
Naba



On Fri, Dec 20, 2019 at 11:55 AM Blake Bender  wrote:

> Very well, then, I'll abide by the group consensus but am on the record as:
> * strongly opposed to multi-commit PRs, because I believe it clutters
> history, and
> * also not a big fan of forcing devs to rebase and squash prior to
> submitting a PR.  IMO this is busy work, and *may* in some small minority
> of cases hide information that would be useful to reviewers.
>
> Thanks,
>
> Blake
>
>
> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker  wrote:
>
> > Whether we are talking about the geode/ repository or the geode-native/
> > repository we are all one GEODE community.
> >
> > The idea of a native client team may matter in some contexts but in this
> > space we are all GEODE contributors.
> >
> > Adopting a common approach across our repos will make it easier for new
> > contributors to engage, learn our norms, and join our efforts.
> >
> > $0.02,
> > Anthony
> >
> >
> > > On Dec 20, 2019, at 11:32 AM, Blake Bender  wrote:
> > >
> > > Is this a policy the native client team must abide by, as well?  It
> > varies
> > > slightly with what we've been doing, and all other things being equal I
> > see
> > > no reason for us to change that.  If I am to have any measure of
> control
> > > over the nc repository, I will definitely enforce a 1:1 correspondence
> > > between commits to develop and JIRA tickets.  IMO, if your refactoring
> > in a
> > > PR is sufficiently large or complex that it's difficult to tease it out
> > > from the bug you're fixing or feature you're implementing, it merits
> its
> > > own JIRA ticket and a separate PR.  If your "actual" fix then becomes
> > > dependent on the refactored code, that's a price I'm willing to pay to
> > keep
> > > history clean.
> > >
> > > On the other hand, I see no real value in squashing to a single commit
> > > prior to submitting a PR, since your view of the changes on GitHub is
> > > essentially the same either way.  We haven't enforced this on the nc
> > repo,
> > > and I'd prefer to keep it that way.
> > >
> > > Thanks,
> > >
> > > Blake
> > >
> > >
> > > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao 
> wrote:
> > >
> > >> Merge commit is the new contributor's default setting. When we are
> > merging
> > >> new contributor's PR, since we are so used to THINKING
> > "squash-and-merge"
> > >> is the default, we forgot to check what the button really says when we
> > are
> > >> merging other people's PR.
> > >>
> > >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > eburgha...@pivotal.io>
> > >> wrote:
> > >>
> > >>> I'm a proponent of using squash-and-merge, and once a person has
> chosen
> > >>> this option once it comes up by default afterwards...
> > >>>
> > >>> Owen,  I don't think you have consensus to put forth this PR, there
> are
> > >> -1s
> > >>> above... (early voting)
> > >>>
> > >>> maybe we'll be better off socializing the norm of squash-and-merge
> and
> > >>> gaining a natural consensus that way...
> > >>>
> > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols 
> > >> wrote:
> > >>>
> > >>>> The proposed action manifests as a commit to the Geode git
> repository,
> > >> so
> > >>>> a PR is an acceptable vehicle for voting in this case.
> > >>>>
> > >>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> > >> bschucha...@pivotal.io>
> > >>>> wrote:
> > >>>>>
> > >>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> > >> thread
> > >>>> and a request to "vote" using a PR.  This all seems out of order to
> > me.
> > >>>> Our votes are supposed to be on the email list, aren't they? and I
> > >>> haven't
> > >>>> seen a VOTE request.
> > >>>>>
> > >>>>> On 12/20/19 9:33 AM, Naba

Re: [DISCUSS] Proposal to require linear commit history on develop

[Nabarun Nag]

>>>>>> develop should be linear (no merge commits), and that the biggest
> >>>>>> obstacle
> >>>>>>> to this is that the PR merge button in GitHub creates a merge
> commit
> >> by
> >>>>>>> default.
> >>>>>>>
> >>>>>>> I propose the following changes:
> >>>>>>> 1) Change GitHub settings to remove the ability to create a merge
> >> commit.
> >>>>>>> This will make Squash & Merge the default.
> >>>>>>>
> >>>>>>> 2) Change GitHub settings to require linear history on develop.
> This
> >>>>>>> prevents merge commits via command-line (not recommended, but wiki
> >> still
> >>>>>>> has instructions for merging PRs this way).
> >>>>>>>
> >>>>>>> 3) Update the PR template to change the text "Is your initial
> >>>>>> contribution
> >>>>>>> a single, squashed commit” to “Is your initial contribution
> squashed
> >> for
> >>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
> plus
> >> a
> >>>>>>> ‘fix’ commit)"
> >>>>>>>
> >>>>>>> For clarity, I am proposing no-change in the following areas:
> >>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
> >> structured to
> >>>>>>> benefit from it (this can make it easier in a bisect to see whether
> >> the
> >>>>>>> refactoring or the “fix” broke something).
> >>>>>>> ii) Leave existing wording in the wiki as-is [stating that
> squashing
> >> is
> >>>>>>> preferred].
> >>>>>>>
> >>>>>>>
> >>>>>>> Please comment via this email thread.
> >>>>>>> -Owen
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund  wrote:
> >>>>>>>>
> >>>>>>>> I think it's already resolved Udo ;)
> >>>>>>>>
> >>>>>>>> Here's the problem, if I fixup a dunit test by removing all uses
> of
> >>>>>>> "this."
> >>>>>>>> and I rename the dunit test, then git doesn't remember that the
> file
> >>>>>> is a
> >>>>>>>> rename -- it forever afterwards interprets it as a new file that I
> >>>>>>> created
> >>>>>>>> if I touch more than 50% of the lines (which "this." can easily
> >> do). If
> >>>>>>> we
> >>>>>>>> squash two commits: the rename and the cleanup of that dunit test
> --
> >>>>>> then
> >>>>>>>> we effectively lose the history of that file and it shows that I
> >>>>>> created
> >>>>>>> a
> >>>>>>>> new file.
> >>>>>>>>
> >>>>>>>> Also for the record, I've been working on Geode since the
> beginning
> >>>>>> and I
> >>>>>>>> was never made aware of this change in our process. I never voted
> on
> >>>>>> it.
> >>>>>>>> I'm not a big fan of changing various details in our process every
> >>>>>> single
> >>>>>>>> week. It's very easy to miss these discussions unless someone
> >> points it
> >>>>>>> out
> >>>>>>>> to me.
> >>>>>>>>
> >>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> >> ukohlme...@pivotal.io>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I'm not sure what this discussion is about... WE, as a community,
> >> have
> >>>>>>>>> agreed in common practices, in two place no less...
> >>>>>>>>>
> >>>>>>>>> 1) Quoting our PR template
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>For all changes:
> >>>>&