Re: [VOTE] Move geode to the attic

[Donal Evans]

+1

From: Dan Smith 
Sent: Monday, October 24, 2022 10:51 AM
To: dev@geode.apache.org 
Subject: [VOTE] Move geode to the attic

⚠ External Email

Hi folks,

Last week we discussed moving Geode to the attic [1]. I'm sad to find us at 
this point. But given that we will soon be without three active members to form 
a functional PMC, it's time to put this to a vote. I propose we dissolve the 
Geode PMC and move the Geode project to the attic.

Please cast your vote by Monday Oct 31st.

Thanks,
-Dan

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fbx6t1cppbj7nmfjnf9gtcqjljp8bdf0ydata=05%7C01%7Cdoevans%40vmware.com%7C8268958f47aa48e1618408dab5e87991%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638022307329173787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=cra1wz4IVADJwrLR%2Fl2qgcovGpTwTQOJokQwWaZL7yE%3Dreserved=0



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

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

[Donal Evans]

+1 to Anthony's suggestion

I strongly supported the idea behind CODEOWNERS when it was originally 
implemented, but the reality of the process has been a lot more disruptive to 
smooth workflows than I anticipated, both as someone who's waiting for code 
review and as someone who gets tagged to review PRs that I may not actually 
have context for or expert-level understanding of.

From: Anthony Baker 
Sent: Wednesday, June 29, 2022 9:33 AM
To: dev@geode.apache.org 
Subject: CODEOWNERS? (was Re: Pending PR reviews)

⚠ External Email

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

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

Thoughts?

Anthony

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7820data=05%7C01%7Cdoevans%40vmware.com%7Cdbae452fb50648fb880208da59ed3a82%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172683584236%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=FWL%2Fl5rYbTtIj5mLQXfjNfY2bPcS%2BLTSutwt158sn08%3Dreserved=0


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

Re: [VOTE] Apache Geode 1.15.0.RC1

[Donal Evans]

+1

Verified that performance across a variety of workloads is on par with previous 
releases.

From: Owen Nichols 
Sent: Friday, June 17, 2022 9:22 AM
To: dev@geode.apache.org 
Subject: [VOTE] Apache Geode 1.15.0.RC1

⚠ External Email

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.15.0.RC1.  Thank you to 
all
community members for your contributions to this release over the past 490 days!

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

Voting deadline:
3PM PST Wed, June 22 2022.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.15.0data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=1Jh2qL5j5uLqpcT7UsH%2BAxSd9SAbTvtbJAloOvt95Nc%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.15.0.RC1%2Fdata=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=hg5QXyPY9tGEXVHeMXOkjICIZn7p4sM%2BVx3yAFLUKYQ%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1138data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Dqp5pW5UFWg4P%2Fl0j1rnq1YjhGVyiuHuNdymAQuBDmU%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.15.0.RC1data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=pA2U7tRLdfcQvJfE1Jkkcs5PPOj9EzcUDugPFmg1WPs%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.15.0.RC1data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=A9jlDbACLA7dckkqgEI2yKb1zy7gVUMBP6S4%2FA959Io%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.15.0.RC1data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ds5BxaLZ%2BdCJtzgdUdG%2FYZORZB2vPE2bplcGNgKwfqA%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.15.0.RC1data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6dS5Avqw%2BrJsov0%2Bjh%2Bj0jo%2F7EWUK1Ia9kjPVj3nPb8%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-15-maindata=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=9EaCLqQg6Q1RwsjxI3459rnl9DwS19xtDxQvmNpamoE%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-15-rcdata=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=aB4MDvwtxzE%2FIYW1uy77CAbKzgaLqNjy4NWb32z0bMQ%3Dreserved=0

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

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

[Donal Evans]

Alexander, thank you for your response. If the situation is unchanged from when 
you investigated this a while ago then there are three options, I think:

  1.  Don't implement this change
  2.  Pay for the commercial JIRA extensions
  3.  Make "Affects Version" mandatory for all issue types

I'm not sure how feasible option 2 is, as I don't know how or by whom decisions 
regarding spending money on Geode-related products and services are made, but I 
would hope that there is some room for discussion around this, providing we 
think that the value provided by the JIRA extensions is worth it.

For option 3, I wonder if there might be a compromise we can find between 
wanting to ensure that bug tickets get created with all relevant information 
and not wanting to force developers to fill in unnecessary or non-applicable 
information for non-bug tickets. Would it be possible to add an "N/A" version 
to the list of versions in JIRA for use in cases when using a "real" version 
doesn't make sense? Would this just cause confusion, or is it something that 
could work?


Udo, I don't disagree at all that a bug ticket with missing information should 
be considered incomplete, but if the process of marking it so is manual, then I 
suspect that it'll rarely actually get done, since it would fall into the 
"everyone's responsibility" bucket of tasks that often translates to "nobody's 
responsibility." I really hope that we can find a way to automatically enforce 
certain rules around ticket creation, rather than trying to "fix" tickets after 
they've been created.

You also raise an interesting point about the Description field being 
necessary. Do you think that this field should also be mandatory for all issue 
types? Personally, I think there's a fairly strong argument to be made that a 
ticket should always have a description, so I'd be in favour of that change too.

From: Udo Kohlmeyer 
Sent: Thursday, May 26, 2022 2:44 PM
To: dev@geode.apache.org 
Subject: Re: [Proposal] Make "Affects Version" field mandatory for new tickets 
with "Bug" issue type in JIRA

⚠ External Email

I think it is reasonable to “reject” bug reports that don’t include simple 
things like “version” and “description”.
I agree, a bug report with the initially effected version filled in should be 
marked as incomplete and the same should be said about the description field. 
If there is not enough information in that field that explains what the bug is, 
how it manifested itself then the bug report should be marked as incomplete and 
the reporter of the issue should be notified to complete the ticket with the 
relevant information.

From: Alexander Murmann 
Date: Friday, May 27, 2022 at 4:37 AM
To: dev@geode.apache.org 
Subject: Re: [Proposal] Make "Affects Version" field mandatory for new tickets 
with "Bug" issue type in JIRA
⚠ External Email

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


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

⚠ External Email

The dialog window that opens in the Geode JIRA when creating a new ticket 
currently has three mandatory fields; Project, Issue Type and Summary, which 
are necessary for every ticket. There are also three optional fields for 
Component, Description and Affects Version, since there are cases when a ticket 
can be created without needing these details ("Affects Version" has no clear 
meaning for tickets with the "New Feature" issue type, for example).

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

Donal



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

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

[Donal Evans]

The dialog window that opens in the Geode JIRA when creating a new ticket 
currently has three mandatory fields; Project, Issue Type and Summary, which 
are necessary for every ticket. There are also three optional fields for 
Component, Description and Affects Version, since there are cases when a ticket 
can be created without needing these details ("Affects Version" has no clear 
meaning for tickets with the "New Feature" issue type, for example).

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

Donal

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

[Donal Evans]

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

From: Alexander Murmann 
Sent: Thursday, April 14, 2022 5:15 PM
To: geode 
Subject: [discuss] Future of the geode-redis module

Hi Geode community!

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

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

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

Thank you all in advance for your thoughts

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

[Donal Evans]

I agree with this proposal.

As someone who has contributed a great deal of time and effort to the 
geode-for-redis module in the past year or so, it's sad to see it go, but 
realistically, the last thing that Geode needs is more unmaintained code. Our 
track record for removing dead or deprecated code is pretty poor, so removing 
this before it gets a chance to add to the burden seems like a sensible idea. 
In addition to this, the tests in the geode-for-redis module contribute 
significantly to the total run time of CI pipeline jobs, particularly the 
acceptance tests, in which geode-for-redis tests account for over 50% of the 
total run time.

From: Alexander Murmann 
Sent: Thursday, April 14, 2022 5:15 PM
To: geode 
Subject: [discuss] Future of the geode-redis module

Hi Geode community!

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

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

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

Thank you all in advance for your thoughts

Re: [PROPOSAL] annul support/1.15

[Donal Evans]

+1

Given the amount of work that it's apparent is still needed for 1.15 to be 
ready to release, it seems like the sensible thing to do to reset and try again 
once we're closer to being done. I don't think we would have cut the branch 
when we did if we'd known what work was still left, and maintaining a 
long-lived release branch is just adding unnecessary overhead to our processes.

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.14.4.RC1

[Donal Evans]

+1

Confirmed that performance across a variety of workloads is on par with 
previous releases.

From: Dick Cavender 
Sent: Tuesday, March 15, 2022 3:41 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.14.4.RC1

Hello Geode Dev Community,

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

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.4data=04%7C01%7Cdoevans%40vmware.com%7Cd4e3086b2e1342759ce708da06d4faa8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637829809053386571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=irBWm%2Bx%2BB%2F7NuE76fmUbC13yh0Rrf448CDMQ7sL9Wms%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.4.RC1%2Fdata=04%7C01%7Cdoevans%40vmware.com%7Cd4e3086b2e1342759ce708da06d4faa8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637829809053386571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=AUf%2F4DVgDec4%2FMBSiR2r%2B2WUio7VoDXt3Opru1Xu11w%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1137data=04%7C01%7Cdoevans%40vmware.com%7Cd4e3086b2e1342759ce708da06d4faa8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637829809053386571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=FpIdAtVRcM94fp3v%2B3hKUDhGZeVpsNf%2FJVFnZZg5IkI%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.4.RC1data=04%7C01%7Cdoevans%40vmware.com%7Cd4e3086b2e1342759ce708da06d4faa8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637829809053386571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0DmjKVJegiuABMKz9iVdkYbrWgKcO%2FYHmVW1y2wD6ak%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.4.RC1data=04%7C01%7Cdoevans%40vmware.com%7Cd4e3086b2e1342759ce708da06d4faa8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637829809053386571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=71E0vMPqLzGGGBPO2oEqpNrGG8skaz2siAxhsIhV%2BEI%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.4.RC1data=04%7C01%7Cdoevans%40vmware.com%7Cd4e3086b2e1342759ce708da06d4faa8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637829809053386571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=n0Ab3GhXCln2IVVO%2BXoQxj3%2B%2F7Kn1S5scvxTFLk1n2Q%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.4.RC1data=04%7C01%7Cdoevans%40vmware.com%7Cd4e3086b2e1342759ce708da06d4faa8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637829809053386571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=TX576QubM%2Fp67yyZMPIHjmjIf4ocLVNXPw6J%2FgsAsUc%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%7Cdoevans%40vmware.com%7Cd4e3086b2e1342759ce708da06d4faa8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637829809053386571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=1GdrLE0gZwrP0Q%2BYDYIJ3aOjXaUme7tKg4WDluN05gs%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%7Cdoevans%40vmware.com%7Cd4e3086b2e1342759ce708da06d4faa8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637829809053386571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Cse%2FucKcJKiGs1p8UTTYP8gwc4thCdfznjiAS0ar8Uo%3Dreserved=0

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

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

[Donal Evans]

+1

Confirmed that performance across a variety of workloads was on par with 
previous releases.

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

Hello Geode Dev Community,

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%7Cdoevans%40vmware.com%7C8d969962f20c4b548c9008da02273258%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664617411906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=EIlATAnKnnbv2HuajxkbFmcpyiXInwG1%2F5KBq7DeH3M%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%7Cdoevans%40vmware.com%7C8d969962f20c4b548c9008da02273258%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664617411906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=vSDc6CyDuzy8zBuW9PfcRqqREKlIc7UnyGdrshvO8rU%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1135data=04%7C01%7Cdoevans%40vmware.com%7C8d969962f20c4b548c9008da02273258%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664617411906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0nDef%2BE3hXcu73vz9wW69pKcNxrVx%2BgqgZCdyleIrRc%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%7Cdoevans%40vmware.com%7C8d969962f20c4b548c9008da02273258%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664617411906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=9Irpf86xGQtolL0h9yR20ZjwqmEMWX%2Fu%2FK8KuiC7jqY%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%7Cdoevans%40vmware.com%7C8d969962f20c4b548c9008da02273258%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664617411906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=EUPH3%2FycWYME%2BvHx8CG1RYXlP7qGXMMv955TH48V8jM%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%7Cdoevans%40vmware.com%7C8d969962f20c4b548c9008da02273258%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664617568128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=RKt4zYzheC%2FWE%2BjptD4o%2BTDG6yqXXEcKmRFZf6Wko%2BI%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%7Cdoevans%40vmware.com%7C8d969962f20c4b548c9008da02273258%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664617568128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=IGwIt57MCoQY8IOp7Um43r1jmx7fsSsUHn8A2tJuFMU%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%7Cdoevans%40vmware.com%7C8d969962f20c4b548c9008da02273258%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664617568128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=LLO3nqiemUE3eSbN2uD0lSx8WW8RaFM7TMrCHDTW5dM%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%7Cdoevans%40vmware.com%7C8d969962f20c4b548c9008da02273258%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824664617568128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=gOY4qwIFXthwhfYOn1A%2F8c18GbZQKi9yVS42S%2FkBS0U%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

[Donal Evans]

+1

Confirmed that performance is on par with previous releases for a variety of 
workloads

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

Hello Geode Dev Community,

This 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%7Cdoevans%40vmware.com%7C349051c1c39b4585b05508d9fe2b230d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283497887903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=EWGwDAn6BasZ1h5i77GqOSUzFaX0MtmxHdu1xfmGcbw%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%7Cdoevans%40vmware.com%7C349051c1c39b4585b05508d9fe2b230d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283497887903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=L9uwXBhYpltOjSkp8TF5grsnbId2%2FOAVoGqT4gt1nqM%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1131data=04%7C01%7Cdoevans%40vmware.com%7C349051c1c39b4585b05508d9fe2b230d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283497887903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=mMEIbYIOGEb0P09aCxXuF8vMxealNiA4B4vCCbATWfw%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%7Cdoevans%40vmware.com%7C349051c1c39b4585b05508d9fe2b230d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283497887903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=77O1fJ1QRewJbHl5LEQJSYkv9RFzuVuMceMLMTbFPvE%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%7Cdoevans%40vmware.com%7C349051c1c39b4585b05508d9fe2b230d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283497887903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=DzLWpZzzVelUz%2BhHrVh4IFTJmZhHnef%2BnNzDO%2BAjQIU%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%7Cdoevans%40vmware.com%7C349051c1c39b4585b05508d9fe2b230d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283497887903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=RWv%2FGLdYkzJfvH3OhuumBjpnrqoKDNcdBd6UGKnOQc8%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%7Cdoevans%40vmware.com%7C349051c1c39b4585b05508d9fe2b230d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283497887903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=KfyIUMeESo8fk2donuoLQCnteMyb4w8Xnbp0LRlITqA%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%7Cdoevans%40vmware.com%7C349051c1c39b4585b05508d9fe2b230d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283497887903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=WRfuOClyiPG3N6fhahUU3HtgIu%2FtCp%2BUx3MFATOl1sg%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%7Cdoevans%40vmware.com%7C349051c1c39b4585b05508d9fe2b230d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637820283497887903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=NjxfeWhW1EzZ0sG1qwEUv9PMmDbcGJ9kYsn15xMRBDA%3Dreserved=0

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

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

[Donal Evans]

To clarify what I think might be a misunderstanding here, there is zero 
evidence of any kind that the large warning clean-up PR has introduced any 
issues, performance-related or otherwise.

For my two cents on cutting the branch at the commit before the big change, I'm 
of the same opinion as Robert, that we should cut the branch at HEAD and revert 
only if it's determined to be necessary. The changes were broad, but the nature 
of the changes were benign and low-risk, being simple, automated refactors of 
trivial things like removing unnecessary casts or adding "final" to variables.

I understand the argument that we often don't see all the consequences of a 
change until some time after it's been merged, but that argument applies to 
every change that gets made, and historically, new features and bug fixes have 
a far higher change of introducing problems than automated refactors. The 
choice of the warning clean-up change seems based almost entirely on the fact 
that it touched a lot of files, not in the actual risk associated with those 
changes.

From: Raymond Ingles 
Sent: Wednesday, January 26, 2022 10:16 AM
To: dev@geode.apache.org 
Subject: Re: Proposal: Cut 1.15 release branch from SHA 
8f7193c827ee3198ae374101221c02039c70a561

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

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



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

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

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

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

Thanks,
Mark

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

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

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

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

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

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

Hi everyone,

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

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

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

[Donal Evans]

+1

Confirmed that performance across a variety of workloads is on par with 
previous releases.

From: Dick Cavender 
Sent: Friday, January 21, 2022 9:25 AM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.14.3.RC1

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.14.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 PST Tuesday, January 25 2022

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.3data=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=j5LpgLLJ5HyohirEoSu4f67c6FAx12prlfpb5zI2QZY%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.3.RC1%2Fdata=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=1stKj1J2i115zjK%2Bcx4xvGsBoPwbRkB2%2F4BYS1AkOF8%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1128data=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Dv1xXcR7Ylo%2Fax9KKHU4i0Mv8SdwSDYXpiamP1912CE%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.3.RC1data=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=yFWl932ocYn6v9DvDlMFWGX9SDnLmBm6Inzsb7o346A%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.3.RC1data=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ocbN2bo9ud7O7zj0LyQmpPMlrJL%2Ba7J%2B%2FH6LAFrelMw%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.3.RC1data=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2BKfOx4amXgkERqAbgvtUBH0w9YawVAtcT8srTm2BXUQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.3.RC1data=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0mHfFYU13%2BVf%2Fni3STqLHqXYs%2Bkt92s42btwtdPoBE0%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%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=vz%2FDJ9IiVQJy1ssCjKXFvXdcODgGFdij8KpUk4If9K4%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%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=t0ih5l%2FwiUirz4493xIMd1x8xA7GcXc4l2m3quOFQuE%3Dreserved=0

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

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

[Donal Evans]

+1

Tested that performance across a variety of workloads is on par with previous 
released versions and no performance degradations have been introduced.

From: Dick Cavender 
Sent: Monday, January 17, 2022 11:20 AM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [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%7Cdoevans%40vmware.com%7C644ece1c1626405d8b3f08d9d9ee6eb6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440352773988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=LuK%2B6g5%2BjrxYdD4MVzLr7MfgfxAqq8r4IE6%2FIproAnQ%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%7Cdoevans%40vmware.com%7C644ece1c1626405d8b3f08d9d9ee6eb6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440352773988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=yULZOm1C0OdZe%2F7p8cpoxQ0x7E9cCRPqvSJMZXFliVs%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1126data=04%7C01%7Cdoevans%40vmware.com%7C644ece1c1626405d8b3f08d9d9ee6eb6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440352773988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=GUorLXqn4YWk%2F0dBcD5hZWI3zUXEq5kHSXd9f%2FwuXcU%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%7Cdoevans%40vmware.com%7C644ece1c1626405d8b3f08d9d9ee6eb6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440352773988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=IaDOEWLurjE%2FZGuwcFe%2FHs%2FRwIeWScG8l4qyw8CK4lc%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%7Cdoevans%40vmware.com%7C644ece1c1626405d8b3f08d9d9ee6eb6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440352773988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=DNGhKYJGICjZqBw9%2BOfZ7mWs%2F0%2B1XVYGAGlMDsZnjyU%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%7Cdoevans%40vmware.com%7C644ece1c1626405d8b3f08d9d9ee6eb6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440352773988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=xtZot0YcQ69ElezPJ2VnQ5LcmuAHE7rzb3Yw7Io35CU%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%7Cdoevans%40vmware.com%7C644ece1c1626405d8b3f08d9d9ee6eb6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440352773988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2Fv4PT3sojTDcgwG4xQWs2El17ezweP7dmONvQix0HDs%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%7Cdoevans%40vmware.com%7C644ece1c1626405d8b3f08d9d9ee6eb6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440352773988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=WYwZjjk3x0rq5QXHbEZJzcP59jeCpuBW9aEVzAgd%2F60%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%7Cdoevans%40vmware.com%7C644ece1c1626405d8b3f08d9d9ee6eb6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440352773988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=EpPeDV2nkpniB8SJ1sdXH8wb%2F%2BQGEFl2C6f6pT7n2Ts%3Dreserved=0

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

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

[Donal Evans]

+1 on releasing this

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

+1 to move along with this release.

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

Regards
Naba


[1]https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.confluent.io%2Fhome%2Fconnect%2Fconfluent-hub%2Fcomponent-archive.htmldata=04%7C01%7Cdoevans%40vmware.com%7C976d5d23599d45e7ae7b08d9d564d0a5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637775451252718005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=YbLpP1ev8qOgsQ5v9GS%2F%2FQjHBTHxVw8Tw5hRm%2B1jNAQ%3Dreserved=0

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 

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

[Donal Evans]

+1

Verified that performance across a variety of workloads is on par with previous 
versions.

From: Dick Cavender 
Sent: Monday, January 10, 2022 3:34 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.8.RC1

Hello Geode Dev Community,

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

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

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

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

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

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

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1124data=04%7C01%7Cdoevans%40vmware.com%7C4042b0436a464a1d1db708d9d491b96a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637774544638218789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=A6ZKvYg99MDh%2Bh%2F4xi1J6%2F26H6TYdkcWB4Wlo3TgTGg%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.8.RC1data=04%7C01%7Cdoevans%40vmware.com%7C4042b0436a464a1d1db708d9d491b96a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637774544638218789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=1%2B1GXU9AaZ2Sw%2FrLPfknOtFmtA0U%2Bc76pXFQLEvdKAI%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.8.RC1data=04%7C01%7Cdoevans%40vmware.com%7C4042b0436a464a1d1db708d9d491b96a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637774544638218789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=qGwD6ZxKhLVeZqeEc3xPWQ1RDC4ohnqaS%2Fdw8wMWKwI%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.8.RC1data=04%7C01%7Cdoevans%40vmware.com%7C4042b0436a464a1d1db708d9d491b96a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637774544638218789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=hyFqmk%2FWmLlIdMZ%2FC9orlEYqP2Ef7NmttI7fAjoZjV0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.8.RC1data=04%7C01%7Cdoevans%40vmware.com%7C4042b0436a464a1d1db708d9d491b96a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637774544638218789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=pqQHuOul%2B4NgzFYGF0UW5HoKqBjAbz2KTqs9aT%2Frqh4%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%7Cdoevans%40vmware.com%7C4042b0436a464a1d1db708d9d491b96a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637774544638218789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=LAp%2Fi6qkixcC2ir%2FY%2BhQNVDUuLIQkdA9qGV7ii4ST8w%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%7Cdoevans%40vmware.com%7C4042b0436a464a1d1db708d9d491b96a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637774544638218789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=t41HNHA0NHpwY1IJ0n4vfzm%2F5qolqXsdQcWKt%2Fq5Ips%3Dreserved=0

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

LGTM as a gating job on PRs not actually gating?

[Donal Evans]

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

The comment from LGTM showing that there are newly introduced alerts in the PR: 
https://github.com/apache/geode/pull/7219#issuecomment-1005181341
The "passing" LGTM job for the PR showing newly introduced alerts: 
https://github.com/apache/geode/pull/7219/checks?check_run_id=4707178926

I'm not sure what the solution to this is, but it certainly seems like the 
intended result wasn't achieved when making the LGTM check a required 
pre-checkin job.

Re: [DISCUSS] batch patch release voting

[Donal Evans]

The thing I wonder about with this decision is what happens if there are no 
problems with two of the releases, but one of them has some showstopping issue 
that needs to be addressed.

Given that not every fix that's going into 1.14.1 is going into 1.12.6, it's 
possible that an unrelated issue with the 1.14 patch release could hold up the 
release of the perfectly fine 1.12 release if the vote is on releasing all 
three. In that case, would there need to be a new RC for the 1.12 and 1.13 
releases, given that the vote for them would technically have failed? Would 
there need to be a new vote on all three releases, or just go ahead with the 
1.12 and 1.13 release and re-vote on the 1.14 once the issue is fixed?

From: Owen Nichols 
Sent: Wednesday, December 1, 2021 11:45 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] batch patch release voting

Geode's N-2 support policy can lead to "waves" of patch releases.  For example, 
1.12.6, 1.13.5 and 1.14.1 are all likely this month, with many of the same 
fixes in each.

Some open source projects group waves of patch releases into a single 
announcement.  It might be nice to do this for Geode.

For voting, does anyone have any preference whether to still hold three 
separate votes, or would it be ok to vote on a batch of patch releases at once? 
 If so, would 3 days still be enough time for the voting deadline?

Re: @TestOnly or @VisibleForTesting

[Donal Evans]

The main time I use the @VisibleForTesting annotation is when I'm unit testing 
a method that includes static calls that can't be mocked or verified. A random 
example from the codebase is LatestLastAccessTimeMessage.process() which has a 
call to sendReply(dm, lastAccessed) as the last line of the method. This method 
has been extracted and marked @VisibleForTesting to allow verification and 
mocking in unit tests as it just wraps a static call:

  @VisibleForTesting
  void sendReply(ClusterDistributionManager dm, long lastAccessTime) {
ReplyMessage.send(getSender(), this.processorId, lastAccessTime, dm);
  }

I agree that ideally we wouldn't need to use these annotations, but given a 
choice between developers using them to improve unit test coverage on classes 
that are severely lacking in it and not adding test coverage at all because, in 
order to avoid using these annotations, a prohibitively huge refactor of 
multiple classes would be required, I would definitely see using them as the 
lesser of two evils.

From: Alexander Murmann 
Sent: Thursday, November 4, 2021 5:02 PM
To: dev@geode.apache.org 
Subject: Re: @TestOnly or @VisibleForTesting

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

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

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

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

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

[Donal Evans]

+1

Verified that performance across a variety of workloads is on par with previous 
releases.

From: Dick Cavender 
Sent: Wednesday, October 20, 2021 4:32 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.5.RC1

Hello Geode Dev 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%7Cdoevans%40vmware.com%7Cb985c36d6889439c506e08d99421f7de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637703695887278177%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=gmfIVFeoeI84ikOXtIPE8kCmvQox2B7WN6iuhMRjrvU%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%7Cdoevans%40vmware.com%7Cb985c36d6889439c506e08d99421f7de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637703695887288131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=atebhHwo6wup3eUvc0559NZ72JQQCtPkeiXRd6I%2Bwg0%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1113data=04%7C01%7Cdoevans%40vmware.com%7Cb985c36d6889439c506e08d99421f7de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637703695887288131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=dgJe75YdIUFAEJAfpag2xgapUGbkunOYMPYz7gKz3Rs%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%7Cdoevans%40vmware.com%7Cb985c36d6889439c506e08d99421f7de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637703695887288131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=I7BuhMH0A39L4C3R682HnzpVRuEH7HnW28Ar6U4VptA%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%7Cdoevans%40vmware.com%7Cb985c36d6889439c506e08d99421f7de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637703695887288131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=O4WY5ftXs%2BQf6FcW6T9Fra%2BkoSEDCs9WP8jQmqbnQjo%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%7Cdoevans%40vmware.com%7Cb985c36d6889439c506e08d99421f7de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637703695887288131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Q9gwaa8fuOkVg7x38J0ke8haILBYjwpIB69viOhYaB4%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%7Cdoevans%40vmware.com%7Cb985c36d6889439c506e08d99421f7de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637703695887288131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=rrOw553NsGR3RNwkCKy%2BzEP1tSn6nTzQdx9aIqV2lPM%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%7Cdoevans%40vmware.com%7Cb985c36d6889439c506e08d99421f7de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637703695887288131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=QgrtttDyZ1vbI%2FVs0SaZNpwsgVBAW8z0nlvNtziRZII%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%7Cdoevans%40vmware.com%7Cb985c36d6889439c506e08d99421f7de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637703695887288131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=iQgOgvlTrBz8BUKMRCt5EnVUeHEHIGEqtomq%2FCwYmJo%3Dreserved=0

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

Re: [VOTE] Apache Geode 1.14.0.RC2

[Donal Evans]

+1

Validated that performance across a range of workloads is equivalent to 
previous releases

From: nabarun nag 
Sent: Tuesday, August 31, 2021 5:36 PM
To: dev@geode.apache.org 
Subject: [VOTE] Apache Geode 1.14.0.RC2

Hello Geode Dev Community,

This is a release 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.0data=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=cJWZ%2BgtEEKontEsDKm0y3YOvnVZ6cFeF5WzjVZF41f8%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.0.RC2%2Fdata=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=seJKNwaisxT0g9tMJpsg2O9fZEpB3JONZTMlFTIU6D0%3Dreserved=0

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

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3dZJbHhEYbKalCW7R9Zaqnm6Y4TRgIDCnW6%2BX1Gynrk%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=F0H7s%2Fid%2FM613DshfSFF88DJ8VF7rA1iTmX%2BM6OCZvM%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=syiMhfgtMnu0RRcOYJOHJV24UKfX1TO%2FEaIFxkqlL2Q%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Bt2rS4kMZPtLXST1VHUEBBUpBeRAJN%2FlzJTw%2Bxy6p6Q%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%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7MbP67Duzw7syMknmQyssHu8n42Q2aBblsUy1NlFc28%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%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CmXU8PzOkjgd66rzP6GKj52ZN0towKzMk9geG8A31AQ%3Dreserved=0

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

Re: [VOTE] Apache Geode 1.13.4.RC1

[Donal Evans]

+1

Confirmed that performance across a variety of workloads is on par with 
previous releases.

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

Hello Geode Dev Community,

This is a 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%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682790133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=pZ6rcGwVcvkIZCtZpjPLAGQXXLQz606sc5eay7l6%2FNo%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%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682790133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=tqdIEWvexyzD4KFpzvJrdXWMTZq%2FkgfE%2BhE2%2F6nm2yA%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1087data=04%7C01%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682790133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sIiSNWwjMGlgJLu004vHXzmZe9Ea%2FS5%2BC25rlsRNsiE%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%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682790133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=gCEmjzi0idYaqcGPgj319JazeNYVPFyTMT12qTEYoEg%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%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682800090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=u7JQrZFpvrnZkQuafC3YVOqkZLFJSXOGaTMPs9C8uAk%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%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682800090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KdScjfvdSPhGeWZZKgI2qTFFnLBFCOLsVFXPQ1cgw7g%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%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682800090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=l%2BC7Mdi5FK4%2FQJ6DpBHwED6Vg1x8atRm8u9Sgsuw4dk%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%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682800090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WTvSv4OSafEpuw1aSjRdsDV7dqxuzdjYlv3XCPA%2Fc7o%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%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682800090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kpSBlbt6fR1hnoERrNkdgzzQ%2BzwGBoNPy2V6lXA1hUs%3Dreserved=0

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

Re: [VOTE] Apache Geode 1.12.4.RC1

[Donal Evans]

+1 from me. Confirmed that performance across a wide range of workloads is on 
par with previous releases.

From: Dick Cavender 
Sent: Wednesday, July 21, 2021 4:35 PM
To: dev@geode.apache.org 
Subject: [VOTE] Apache Geode 1.12.4.RC1

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.12.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 Mon, July 26 2021*

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.4data=04%7C01%7Cdoevans%40vmware.com%7C7f968784dca24286514308d94ca03341%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073205178122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=lcxa2xDIH8ElL7F1YkoDDJ2jcb%2FIZmZVcdZu7iRQkAU%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.4.RC1%2Fdata=04%7C01%7Cdoevans%40vmware.com%7C7f968784dca24286514308d94ca03341%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073205178122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=56tswKn7FK0pwIpjooy9xmb7fOvv9XXeMO3E17JgXME%3Dreserved=0

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

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.4.RC1data=04%7C01%7Cdoevans%40vmware.com%7C7f968784dca24286514308d94ca03341%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073205178122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2BgfbrvRF%2FCDpKgljIuYrE9FC%2BtrADbLYr%2BQESc2ugcQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.4.RC1data=04%7C01%7Cdoevans%40vmware.com%7C7f968784dca24286514308d94ca03341%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073205178122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nf0VrLcEQFxzP%2BpkHFQAttSrh04fE1aelOoXNqs605c%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.4.RC1data=04%7C01%7Cdoevans%40vmware.com%7C7f968784dca24286514308d94ca03341%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073205178122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=IGlXwgRhgCPe4wxrOwQhg4eZOf2r54KgYUNY7r7E9nM%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.4.RC1data=04%7C01%7Cdoevans%40vmware.com%7C7f968784dca24286514308d94ca03341%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073205178122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=tzh4cd1GKpZ74zjLBIwl8sk0jMKcWTgRk5%2BsaFJcxzw%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%7Cdoevans%40vmware.com%7C7f968784dca24286514308d94ca03341%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073205178122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=u5z3o7zqX5wAycqGoJpz6pPov0ozNH6nb5WusZxnrrc%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%7Cdoevans%40vmware.com%7C7f968784dca24286514308d94ca03341%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073205188102%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=zQN9GnQ80v1cO8O8dcYRYIp%2F9uVnv9VFKhvflPu6LBE%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

[Donal Evans]

I definitely approve of this proposal. I accidentally merged (rather than 
squashed and merged) a PR a while back because my GitHub session had expired 
and refreshing the page after trying to squash and merge resulted in the 
default merge option being used, much to my frustration. I've yet to see any 
explanation of why we would need to merge PRs rather than squash and 
merge/rebase and merge, so removing it as an option just seems like a good idea.

From: Nabarun Nag 
Sent: Monday, June 28, 2021 1: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

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.13.3.RC1

[Donal Evans]

+1

Performance is comparable to 1.13.2 in a suite of performance tests.

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

Hello Geode Dev Community,

I'd like to propose an 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%7Cdoevans%40vmware.com%7Ced933b53805c44168b4e08d934deb71e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953424916981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=9GqH%2BdBLC%2F0OUpaFalarNPy1T5JfV04jkOrnanIxQxk%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%7Cdoevans%40vmware.com%7Ced933b53805c44168b4e08d934deb71e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953424916981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=LcVJx0CnHB%2BnOJhX7A1VtlDm1nyMf48g4PPqf7Q9%2B%2FM%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1085data=04%7C01%7Cdoevans%40vmware.com%7Ced933b53805c44168b4e08d934deb71e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953424916981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Zm%2FK9niy3glAfweqoQVo%2Be3Ys2qZ7fg4vNodP97nokc%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%7Cdoevans%40vmware.com%7Ced933b53805c44168b4e08d934deb71e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953424916981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fIE7AM2bMZNLKO0LUq3IdlT3hU2oHXsJbVXAjxFY8SM%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%7Cdoevans%40vmware.com%7Ced933b53805c44168b4e08d934deb71e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953424916981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5oOfRL06wp65coq81B%2Bx2s4n2IRFjLe3bC2QhevR9d4%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%7Cdoevans%40vmware.com%7Ced933b53805c44168b4e08d934deb71e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953424916981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=k368oQZEYhC7vLhTvL4SjLvW8JcjYeT%2BDxf68jgchmU%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%7Cdoevans%40vmware.com%7Ced933b53805c44168b4e08d934deb71e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953424916981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=j5eYXq7pArtYmB5gvEQGPi95teeOc4H0Ru9EbFXsGh8%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%7Cdoevans%40vmware.com%7Ced933b53805c44168b4e08d934deb71e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953424916981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=UTr%2F0PAjCrqjwabZAtuyz%2BsdxidJIqw8hFOaSbFm3aw%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%7Cdoevans%40vmware.com%7Ced933b53805c44168b4e08d934deb71e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637598953424916981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=lk2BWP3voANlI4deumXAvNACnqj4thai74fpEZRkoKM%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

[Donal Evans]

I think that there should be room for developers to bypass the stress-new-test 
jobs requirement in cases like this, where the test that's failing is an 
existing flaky test and that failure is blocking other flaky tests/bugs from 
being fixed. Splitting the class up won't save us, because stress-new-test runs 
on any changed or newly created test class, so no matter what you try and do, 
you'll have to run with the remaining flaky test at some point, which will 
block a PR. In Kirk's case, short of re-running the job until you get lucky and 
don't hit the existing flaky failure, there is no way to merge the fix for the 
other flaky tests other than bypassing stress-new-test or @Ignore-ing the 
existing flaky test (and if we're going to allow that approach, we may as well 
just ignore all of them until they're fixed).

We already allow stress-new-test to be skipped in situations where the number 
of modified test classes is large (like the recent change to use curly brackets 
on all control flow statements, which almost certainly would have hit flaky 
failures in pre-checkin if stress-new-test had run despite not changing any 
logic) so there's some precedence for bypassing the job when the value of the 
changes (or the cost of running the job) outweighs the benefits of ensuring 
that new flakiness isn't being introduced. However, I do think that in the 
majority of cases, stress-new-test should run, and should block PRs if a test 
fails, as there is real value being provided by it in terms of preventing new 
flaky tests being added.

I like the idea of allowing code owners to bypass stress-new-test failures, but 
I'm a little unclear on the practicalities of how this would actually work. How 
would this bypassing be achieved? If a PR has multiple code owners spanning 
multiple areas of code, would all of them be able to bypass stress-new-test, or 
just the code owners for the class showing the flaky failure? If the latter, 
what would happen if two classes with different code owners were modified and 
both had existing flaky tests in them? Would a separate override be needed from 
code owners for each class?

I think we need to strike a balance between making it *possible* to override 
stress-new-test failures and making it *easy* to override them, because I don't 
think it should be something that's ever done casually and without careful 
thought. With that in mind, I would suggest that it might be best to bring 
these rare cases to the dev list and make it a community decision (or at least 
not just a code-owner decision), even if that can be a slow and bureaucratic 
process at times.

Also, big +1 to the idea of having a continued, concerted effort to tackle 
flaky tests. Such efforts have been made in the past and were really 
successful, both in terms of reducing overall test flakiness and providing 
valuable insight into how to avoid creating flaky tests in the first place.

From: Mark Hanson 
Sent: Wednesday, June 9, 2021 10:16 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

One other thing to think about is perhaps having a rotating team to deal with 
flaky tests,  a small team commissioned every three or 6 months to clear out 
flaky tests for 1 month. It is good experience

Thanks,
Mark

On 6/9/21, 10:04 AM, "Mark Hanson"  wrote:

One other thing is that we have code owners. If the PR submitter decides to 
ignore the stress new test, the code owner can still request a fix. That is 
probably a sufficient process.

On 6/9/21, 10:02 AM, "Mark Hanson"  wrote:

I agree, I am willing to concede this discussion, as long as we are 
judicious and specifically only use it when it is not our test that is failing. 
It is a real problem.

Thanks,
Mark
On 6/9/21, 9:46 AM, "Kirk Lund"  wrote:

I did think about splitting up dunit tests, but I believe
testEventIdOutOfOrderInPartitionRegionSingleHop will remain flaky 
even if I
move it to a new dunit test. No matter how you dice it up, we end 
up with a
PR that cannot be merged to develop unless you get lucky after 
running
stress-new-test many times.

One could try being tricky by marking it with @ignore or deleting 
the flaky
test in one PR, and then re-add it in a 2nd PR. But, even then that 
2nd PR
is very unlikely to pass stress-new-test unless someone fixes the 
cause of
that test's flakiness.

As it stands, stress-new-test just ends up being a dead-end or an 
endless
time-sync for fixing multiple flaky tests in one dunit.

On Tue, Jun 8, 2021 at 12:09 PM Dan Smith  
wrote:

> Would it be possible to just split that test up into multiple 
classes? It
> sounds like the issue is that there is so many flaky tests in 
that class
> that you can't fix them 

Re: Cleaning up the codebase - use curly braces everywhere

[Donal Evans]

Given the positive response to this idea, I'm going to mark the PR as ready for 
review and contact the code owners required to get it merged. Thanks for all 
the feedback, and hopefully this can be the first step towards a concerted 
clean-up effort.

Donal

From: Kirk Lund 
Sent: Friday, May 28, 2021 3:19 PM
To: dev@geode.apache.org 
Subject: Re: Cleaning up the codebase - use curly braces everywhere

+1 Also, I think if the entire work is done by IntelliJ then just mention
that in the PR description and I'm happy to add approval without stepping
through every line. I'd probably just pick a dozen random ones to check and
then approve it.

On Thu, May 27, 2021 at 6:36 PM Darrel Schneider  wrote:

> +1 thanks for working on this
> 
> From: Donal Evans 
> Sent: Thursday, May 27, 2021 10:22 AM
> 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%7Cdoevans%40vmware.com%7C6d413e51e7814ee308d92226b180%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637578371864383775%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=4An8MCpjP60dPIt%2BXbkmplHh6F8pc%2F0KdpTPO2KnvNI%3Dreserved=0
> [2]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6523data=04%7C01%7Cdoevans%40vmware.com%7C6d413e51e7814ee308d92226b180%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637578371864383775%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=pufQ770JEdbJ%2FfWgT0rqQmrLJyFqQQjFc98Q%2FkYnHq4%3Dreserved=0
>

Re: Cleaning up the codebase - use curly braces everywhere

[Donal Evans]

Regarding doing the changes at package level, there would still be a huge 
amount to review for certain code owners, and some code owners would get tagged 
to review multiple of the PRs, all of which would consist of nearly identical 
changes repeated over and over. For more complex change sets, breaking them up 
to make them more manageable makes sense, but for something like this, where 
it's an automatically applied process to do one very specific thing, expecting 
reviewers to look at every single line changed is excessive, I think.

I believe a similar situation occurred when spotless was first applied to the 
project; an automatic process was applied, and reviewers trusted that it had 
been applied correctly (maybe checking that nothing was obviously wrong in a 
few files) but didn't manually check every single changed line.

From: Anilkumar Gingade 
Sent: Thursday, May 27, 2021 1:20 PM
To: dev@geode.apache.org 
Subject: Re: Cleaning up the codebase - use curly braces everywhere

+1

Instead of big merge; can this be done at package level; just a thought.

-Anil.

On 5/27/21, 10:51 AM, "Dale Emery"  wrote:

We might also use IntelliJ to enforce any guidelines that we want to 
enforce. You can run inspections on the command line: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jetbrains.com%2Fhelp%2Fidea%2Fcommand-line-code-inspector.htmldata=04%7C01%7Cdoevans%40vmware.com%7C9c71bf203b4d474515ea08d9214cdbb1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637577436255763312%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=i91hCIEYZGStlSLSFZWgmvrj4rv1vlvv7bPJ2ChlHIM%3Dreserved=0

An advantage of using IntelliJ inspections is that we can provide an 
inspection profile that treats violations as errors. Then developers can use 
this profile while editing to spot violations immediately as they’re introduced.

A disadvantage is that this somewhat couples Geode to a particular IDE.

Dale

From: Donal Evans 
Date: Thursday, May 27, 2021 at 10:22 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%7Cdoevans%40vmware.com%7C9c71bf203b4d474515ea08d9214cdbb1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637577436255773270%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Twrc0TddPBTxgAeCBecbyMMSAW42X1SfyECBZwm9oeY%3Dreserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6523data=04%7C01%7Cdoevans%40vmware.com%7C9c71bf203b4d474515ea08d9214cdbb1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637577436255773270%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5ivxrQAyGmGQ9zCRKOZuK0%2F8bHVKTeJqXVhVLxzVpFM%3Dreserved=0

Cleaning up the codebase - use curly braces everywhere

[Donal Evans]

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://cwiki.apache.org/confluence/display/GEODE/Code+Style+Guide
[2] https://github.com/apache/geode/pull/6523

Re: Reminder to use draft mode

[Donal Evans]

+1 to Naba's PR flow described above.

Creating PRs in draft mode is almost always the best choice, as it prevents 
people from being tagged to review a set of changes that may change 
significantly due to test failures and only requires a single click to convert 
to the "ready to review" state - hardly a major inconvenience.

However, the real tricky question here seems to be "When should you move a PR 
from "Ready to review" back into draft mode?" I tend to agree with Jens that a 
flaky test failure by itself isn't enough to warrant putting a PR back into 
draft mode, as it's often possible to identify the failure as being due to an 
existing known bug and merge the PR knowing that your changes aren't the cause. 
We don't require that all PR tests are green before merging, just some of them, 
so it's reasonable to assume that we don't require all PR tests to be green 
before a PR is considered ready for review either.

Minor edits due to review comments (like spelling mistakes or minor code 
quality/style changes) also don't feel like they should cause a PR to be put 
back into draft mode, as while the contents of the PR may change because of 
them, it won't invalidate other in-progress reviews if it does, or 
significantly alter the nature of the PR.

For me, the bar for whether a PR should be put back into draft mode is if you 
know that its current state is not reflective of the final state that will be 
merged into develop. In general, the only time that should happen is if you've 
received review feedback that will require a change of approach or significant 
refactoring/additional code. It's the difference between "needs a little 
polish" and "needs more work," I think. Obviously, what counts as "significant" 
is entirely subjective, so this isn't much use as a hard and fast rule, but a 
rough guide might be that if a reviewer has requested changes that would 
invalidate or render obsolete/redundant any additional reviews that come in 
before those changes are applied, moving back to draft mode would probably be a 
good idea.

Donal

From: Nabarun Nag 
Sent: Thursday, May 6, 2021 10:22 AM
To: dev@geode.apache.org 
Subject: Re: Reminder to use draft mode

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 

Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

[Donal Evans]

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: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

[Donal Evans]

+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%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=FrmRSQZPUtL3pciiAZ7LnGokKWITJgbl6N9KNdCBidQ%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%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0dc%2FB9Hnf1wK4NpLXBUpy7v7H1xj9btZgsf1EjHW2IY%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1080data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=2T06JC%2BaRCVgViSmbwDqP6Z%2F6Y10zeIlOaTNpVwWkRA%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%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=VyruqqFrBFtwop5L9dPW%2BUI69D2ijqZS7rf1ZnHIloM%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%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=keT%2FsAuuqJ2jh1OAQgyAysVqNHqP%2BSJzlV%2F%2B6Yfjc9k%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%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=r8HofpAFHtOKoKaeDmZFQx3x%2FLViCem3fwB5Hd1Zjvs%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%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=fHlniSX58ttlHa1PegR5fY5y2ISh0hU8uPUH%2FQHsldg%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%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Ck4trXdfeLSrRB%2BZBU3gytEmfDHN3E52Dw6tYjKxeu0%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%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Fg7B1wfQN09lrTi%2FhvdtwdiPj8DCZjq5dD9YDjTU1FQ%3Dreserved=0

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

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

[Donal Evans]

+1

In theory, every commit is now associated with a GEODE jira ticket, so leaving 
a comment in the code when putting in a fix saying that it's for that ticket is 
redundant. Good commit names and messages would provide the broader context for 
changes, and regular comments that don't refer to a ticket at all can provide 
the fine-detail explanation that's sometimes needed to clarify code.

From: Hale Bales 
Sent: Tuesday, March 30, 2021 2:24 PM
To: dev@geode.apache.org 
Subject: Deleting old references to ticket numbers and avoiding new ones

Hi all,

I have noticed in the past that there are a lot of ticket numbers in the code 
(along the lines of "fixes #") that reference tickets in a system that very few 
people still have access to. Since the average Geode developer does not have 
access to this system, having these in the code does not provide any value. I 
would like to propose that we remove all references to old ticket numbers when 
we come across them. If you happen to be one of the few people with access to 
this information, you could potentially remove the reference to the ticket 
number and add a note about the contents of that ticket. Finally, I would like 
to propose that we work to avoid this issue in the future (in case we every 
stop using Jira) by avoiding having just the Jira ticket number in a comment. 
Instead, we should provide both the ticket number and a short description of 
that ticket so that we can get all the necessary information from the comment.

~hale (they/them)

Re: Precheckin job failed to fork JVM during compile

[Donal Evans]

Hi Kirk,

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

Donal

From: Kirk Lund 
Sent: Thursday, March 25, 2021 1:42 PM
To: dev@geode.apache.org 
Subject: Precheckin job failed to fork JVM during compile

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fbuilds%2F17742data=04%7C01%7Cdoevans%40vmware.com%7C20e8e017a3554007e10608d8efce81a1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637523017517864370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nxaQczcFxF8x%2FyYfy%2FU8OfL7CL2lLNoDpuIjJebJsIg%3Dreserved=0
 core dumped during
compilation of one of the modules.

I believe exit code 134 means that it failed to fork a new Java VM.

I wonder what would cause a test job to be unable to fork a process. It
seems to have forked processes for compiling all of the other modules, so
it's not a persistent problem.

> Task :geode-membership:compileJava
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (methodData.cpp:1252), pid=8491, tid=0x7f1716a78700
#  fatal error: unexpected tag 32
#
# JRE version: OpenJDK Runtime Environment (8.0_282-b08) (build
1.8.0_282-b08)
# Java VM: OpenJDK 64-Bit Server VM (25.282-b08 mixed mode linux-amd64
compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/geode/geode/geode-membership/hs_err_pid8491.log

<<>>

> Task :geode-membership:compileJava
#
# Compiler replay data is saved as:
# /home/geode/geode/geode-membership/replay_pid8491.log
#
# If you would like to submit a bug report, please visit:
#   
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbugreport.java.com%2Fbugreport%2Fcrash.jspdata=04%7C01%7Cdoevans%40vmware.com%7C20e8e017a3554007e10608d8efce81a1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637523017517864370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=VLG8CUFcDaO8OpeMtX%2FBPoCNwt1dPOQrOJ%2BC4dTw%2FXE%3Dreserved=0

<<>>

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':geode-membership:compileJava'.
> Compilation failed with exit code 134; see the compiler error output for
details.

Re: [ANNOUNCE] New Geode Committer - Matt Reddington

[Donal Evans]

Congrats Matt!

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

The Apache Geode Project Management Committee has invited Matt Reddington to 
join the Geode as a 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: [VOTE] Apache Geode 1.13.2.RC1

[Donal Evans]

I'm okay with waiting until we know what the situation is with this register 
interest issue before releasing or scrapping this RC. Making a decision before 
we fully understand the consequences seems unwise.

From: Alexander Murmann 
Sent: Monday, March 22, 2021 1:59 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.13.2.RC1

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

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

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

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

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

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

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

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

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

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

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

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

Hello Geode Dev Community,

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

 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%7Cdoevans%40vmware.com%7C5a7ec6a4041e4056e2dc08d8ed756223%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637520435719318610%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0WMDfKxYtq%2FlEAXpliSTWWTB9F6du534fCZsxfLDXZE%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%7Cdoevans%40vmware.com%7C5a7ec6a4041e4056e2dc08d8ed756223%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637520435719318610%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Pg36nBZcxtOHCXXdHYwX1b2VvrmkOQeCa3oQEzzdRiE%3Dreserved=0

Maven staging repo:

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

[Donal Evans]

That 4.6% degradation is within our thresholds so it is possible this came in 
well before the first time it was detected.
After doing some bisecting, I've found that Geode SHA 986733ec (committed on 
Nov 20th 2020) shows an average degradation of ~1% compared to the 1.13 
baseline, whereas e26d7595 (committed on Dec 3rd) shows an average degradation 
of ~5%, so there's definitely been a performance degradation introduced 
somewhere between those two commits. The fact that these numbers are coming 
from an average of 10 runs is relevant too, since part of the reason we have a 
threshold is because we know that there is some noise associated with the test. 
An individual degradation of 5% is nothing to worry about, but a consistent 
average degradation of the same amount is much more serious. I'm continuing 
work to bisect to an individual SHA and hope to get it pinned down eventually 
(I currently have a range of about 20 that it could be), but it's slow going as 
I have to run the benchmark multiple times.

From: Jacob Barrett 
Sent: Friday, March 12, 2021 1:55 PM
To: dev@geode.apache.org 
Subject: Re: Proposal: Add GEODE-8950 (performance degradation in 
P2pPartitionedPutLongBenchmark) to 1.14 blockers list

That 4.6% degradation is within our thresholds so it is possible this came in 
well before the first time it was detected.

Some context on the benchmark for those unfamiliar: 
P2pPartitionedPutLongBenchmark performs a fire hose of puts with Long key and 
Long value directly from each of the two servers. This results in a lot of 
little p2p messages being exchanged between the servers. Presumably 50% of the 
puts result in forward to the primary bucket plus the replication message for 
every put. This test can be susceptible to the smallest alteration in garbage 
production/collection, hot methods, locks, etc.

This test is a very unlikely scenario in production. I am not sure that 
constitutes a blocking condition but is troubling. I will give a neutral vote 
on making it a blocker.

> On Mar 12, 2021, at 11:19 AM, Donal Evans  wrote:
>
> 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%7Cdoevans%40vmware.com%7C0f5c6ee03ce8422a03d108d8e5a18490%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637511829192332012%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=hEKlAAtNvguEdp1Ey6vVxzMV%2FuR76jIvcqwt2CAa6JU%3Dreserved=0

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

[Donal Evans]

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://issues.apache.org/jira/browse/GEODE-8950

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

[Donal Evans]

+1

Confirmed that performance across a broad range of workloads is comparable to 
that seen in the 1.13.1 release.

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

Hello 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%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675471182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WXM3CGWfFZ4JJsIgGSZandkMpPFncY33mD4ELJyU7qc%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%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675471182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vos%2B8SWMXWp4xHbLDKVTJbxXj%2Bobh89ET0oQhQzbOKY%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1079data=04%7C01%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675471182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=a1DG6HNCXMskDmR1blZWcNZzsRKwgOP1zZCknYLysbA%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%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675471182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=bSf8cZY7Bkon%2BB2navQDAG1vh0OqcpbBgI4Gm8%2BSDUk%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%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675481174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TSN%2FzxIfiCLq%2BzaWLYLgKJFeisywDMasb8PJZEUUJdM%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675481174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=tq%2BeYgMptmxM%2FZ4BMznA2dxqcARrLimcGAhFJmayQ1Q%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675481174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=VVWobTd7COd%2Bz7bVRL8UTwBqwb4XwXcHSisPwj0xSgY%3Dreserved=0

Pipelines:

Re: Avoid PowerMockito

[Donal Evans]

Turns out I should have refreshed the ticket comments before submitting my PR, 
because Michael Oleske beat me to it yesterday: 
https://github.com/apache/geode/pull/6107

Sorry for the email spam!

From: Donal Evans 
Sent: Wednesday, March 10, 2021 11:55 AM
To: dev@geode.apache.org 
Subject: Re: Avoid PowerMockito

I've just submitted a PR to remove three uses of PowerMock.when that can be 
trivially replaced with Mockito.when: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6112data=04%7C01%7Cdoevans%40vmware.com%7C8dc2e892bddd4165b16e08d8e3fe903d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510029773259071%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wP7iJXJzYV6fkl%2FXzOmVbkp%2BhcH4eL0ZhrYf4lks0Oo%3Dreserved=0

and updated the ticket with a comment listing the remaining classes that are 
using PowerMock. Only 7 files remain, so this feels like a very achievable task 
now.

From: Kirk Lund 
Sent: Tuesday, March 9, 2021 12:13 PM
To: dev@geode.apache.org 
Subject: Avoid PowerMockito

I just reviewed a PR that was adding a unit test using PowerMockito. We've
had lots of problems with PowerMockito leaving the unit testing JVM
corrupted for later tests. Using PowerMockito also discourages us from
refactoring product code to have better design and be easier to unit test.
So in previous threads here on dev-list, the community decided to axe our
usage of PowerMockito.

There are lots of Jira tickets about PowerMockito in Geode:
https://nam04.safelinks.protection.outlook.com/?url=https:%2F%2Fissues.apache.org%2Fjira%2Fissues%2F%3Fjql%3Dproject%2520%253D%2520GEODE%2520AND%2520text%2520~%2520%2522PowerMockito%2522data=04%7C01%7Cdoevans%40vmware.com%7C8dc2e892bddd4165b16e08d8e3fe903d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510029773259071%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=mQ43v09i2hfiwumibgekykyNu%2FdXlpmn9ZDG41R0Tko%3Dreserved=0

There is one open ticket for removing PowerMockito from Geode:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-6143data=04%7C01%7Cdoevans%40vmware.com%7C8dc2e892bddd4165b16e08d8e3fe903d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510029773259071%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2B1arhtioR6OiHuFYe2AlB6CkO8CUqtIYH2GyZTP30Iw%3Dreserved=0

Unfortunately the assignee is no longer active in this community so we need
someone or everyone to pitch in. If you find yourself working on an area of
code that has a unit test using PowerMockito, please rewrite the test using
regular Mockito and refactor the code that it tests so that you can pass
all of its dependencies in via the constructor(s).

If anyone would like to volunteer to take on GEODE-6143, please feel free
to reassign it. I would be happy to help you out.

Thanks,
Kirk

Re: Avoid PowerMockito

[Donal Evans]

I've just submitted a PR to remove three uses of PowerMock.when that can be 
trivially replaced with Mockito.when: https://github.com/apache/geode/pull/6112

and updated the ticket with a comment listing the remaining classes that are 
using PowerMock. Only 7 files remain, so this feels like a very achievable task 
now.

From: Kirk Lund 
Sent: Tuesday, March 9, 2021 12:13 PM
To: dev@geode.apache.org 
Subject: Avoid PowerMockito

I just reviewed a PR that was adding a unit test using PowerMockito. We've
had lots of problems with PowerMockito leaving the unit testing JVM
corrupted for later tests. Using PowerMockito also discourages us from
refactoring product code to have better design and be easier to unit test.
So in previous threads here on dev-list, the community decided to axe our
usage of PowerMockito.

There are lots of Jira tickets about PowerMockito in Geode:
https://nam04.safelinks.protection.outlook.com/?url=https:%2F%2Fissues.apache.org%2Fjira%2Fissues%2F%3Fjql%3Dproject%2520%253D%2520GEODE%2520AND%2520text%2520~%2520%2522PowerMockito%2522data=04%7C01%7Cdoevans%40vmware.com%7C5ab7c4badf1342ceb86408d8e337e25e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637509176457807900%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=MUmrWogUil8YVFdFDhq8x9K%2B6%2F3C%2Fri6avfIZL0RnOI%3Dreserved=0

There is one open ticket for removing PowerMockito from Geode:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-6143data=04%7C01%7Cdoevans%40vmware.com%7C5ab7c4badf1342ceb86408d8e337e25e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637509176457807900%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3BMSkWfQ%2BU%2BOuhkSheMRGRZlg65usvgSl%2Brv0635Wnk%3Dreserved=0

Unfortunately the assignee is no longer active in this community so we need
someone or everyone to pitch in. If you find yourself working on an area of
code that has a unit test using PowerMockito, please rewrite the test using
regular Mockito and refactor the code that it tests so that you can pass
all of its dependencies in via the constructor(s).

If anyone would like to volunteer to take on GEODE-6143, please feel free
to reassign it. I would be happy to help you out.

Thanks,
Kirk

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

[Donal Evans]

+1

Verified that no regressions in performance were present compared to previous 
versions using some private performance tests. Everything looks good!

From: Owen Nichols 
Sent: Sunday, February 21, 2021 12:07 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.1.RC4

Hello Geode Dev Community,

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

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

Voting deadline:
3PM PST Thu, February 25 2021.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.1data=04%7C01%7Cdoevans%40vmware.com%7C9e9f4072c4b54d9b719b08d8d6a46285%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637495348807684447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=449EWxP6TrW77Q%2FrBUyRdct54gPs%2B4SkSwEBV57qyjo%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.1.RC4%2Fdata=04%7C01%7Cdoevans%40vmware.com%7C9e9f4072c4b54d9b719b08d8d6a46285%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637495348807684447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fYaFDL%2BdbNIrejCt0OnCp8WfNa9MO1dSvdAKve%2FLo%2Bo%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1075data=04%7C01%7Cdoevans%40vmware.com%7C9e9f4072c4b54d9b719b08d8d6a46285%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637495348807684447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FZF8F%2FOW9nQqcEOlnNyQ3bUKPf4zSyamVuDTkhUJOvM%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Cdoevans%40vmware.com%7C9e9f4072c4b54d9b719b08d8d6a46285%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637495348807684447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=H1jixeRDcqaA8gsS0%2F2tGHO10eaZPPm8zSGomCIuV8o%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Cdoevans%40vmware.com%7C9e9f4072c4b54d9b719b08d8d6a46285%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637495348807694447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=g%2Berl3o%2FGdIkvkmcKrgP3bv49GBFi2D8CeswopKovgc%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Cdoevans%40vmware.com%7C9e9f4072c4b54d9b719b08d8d6a46285%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637495348807694447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=VHc7CyQAUPhRMG%2BrFE2a2aMcs6XyDpcMtkHkrfDHTUU%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Cdoevans%40vmware.com%7C9e9f4072c4b54d9b719b08d8d6a46285%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637495348807694447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Eoa0I12Zd8kB8socErFsd6SNHOWwSoGXnPDCHvLshTk%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%7Cdoevans%40vmware.com%7C9e9f4072c4b54d9b719b08d8d6a46285%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637495348807694447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=YLhmB77FkA5mQFuykkiKvEOuSGO6e%2Bcw5RQtKK0lgUU%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%7Cdoevans%40vmware.com%7C9e9f4072c4b54d9b719b08d8d6a46285%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637495348807694447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=OZSUrRMHEo%2BjtsdDvMLbkewtsCUHAzxttzbi%2Fuiohvo%3Dreserved=0

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

Re: Proposal to add GEODE-8947 to blocker list

[Donal Evans]

+1

I can confirm that the performance degradations I saw that led to me opening 
GEODE-8974 are no longer present with the fix that has been merged to the 
develop branch.

Get Outlook for Android


From: Owen Nichols 
Sent: Tuesday, February 16, 2021 7:14:22 PM
To: dev@geode.apache.org 
Subject: Proposal to add GEODE-8947 to blocker list

GEODE-8947 “Performance degradations due to GEODE-8930” fixes the issue that 
blocked 1.12.1 RC3 (and would block 1.14.0 as well if we tried to release it 
today).  In order to backport the fix to 1.12, it also needs to be backported 
to later support branches including 1.14, which currently requires community 
approval to add it to the blocker board for 1.14.0.

I’ve looked at some test results with this fix and reviewed the changes, and it 
looks like a low-risk way of restoring previous performance levels in most 
cases.  If there are no objections, I’ll go ahead and mark it as blocks-1.14.0 
so the fix can be immediately brought from develop back to all support branches.

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

[Donal Evans]

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

Thanks,
Donal

From: Owen Nichols 
Sent: Thursday, February 11, 2021 3:00 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.1.RC3

Hello Geode Dev Community,

One year ago this month, Geode adopted a plan to maintain N-2 support branches 
[1] and support/1.12 was created.  Over 140 fixes have now been backported to 
support/1.12 since 1.12.0 was released, so I’d like to propose a maintenance 
release!

My apologies, RC1 and RC2 were DOA so I did not send an email for them.  Please 
ignore any RC1/RC2 tags and focus your review on RC3.

This is a release candidate for Apache Geode version 1.12.1.RC3.
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, February 16 2021.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.1data=04%7C01%7Cdoevans%40vmware.com%7C5b1ae01e339d413b1c0408d8cee0e252%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637486812577750239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qvW2BDcZ4kt20ZjXD2Yt9MYusOz3PQu%2FpohF0gkFED4%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.1.RC3%2Fdata=04%7C01%7Cdoevans%40vmware.com%7C5b1ae01e339d413b1c0408d8cee0e252%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637486812577750239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=DyMNWi6InEbfMPwhFgt7t6ZvJwBML3Who3mXc3p5kb4%3Dreserved=0

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

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.1.RC3data=04%7C01%7Cdoevans%40vmware.com%7C5b1ae01e339d413b1c0408d8cee0e252%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637486812577760238%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RRjYuMAmXj4TLFQSxhr6HLQWp5MYRoHQZ9G6EiVcSqc%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.1.RC3data=04%7C01%7Cdoevans%40vmware.com%7C5b1ae01e339d413b1c0408d8cee0e252%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637486812577760238%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KgXT3Dfjx%2FN%2BL4Q3ndvlCE%2B0vQ0u%2F7fj8QwzORnTQ3E%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.1.RC3data=04%7C01%7Cdoevans%40vmware.com%7C5b1ae01e339d413b1c0408d8cee0e252%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637486812577760238%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wV8u7Xqg9y7uXG8t85cmzrmcYK4NPGXXAShzzAGLHqo%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.1.RC3data=04%7C01%7Cdoevans%40vmware.com%7C5b1ae01e339d413b1c0408d8cee0e252%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637486812577760238%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sqN1N2G6vmfkGYrlDyPxstWi2Ghf84M4UEASfky5dhw%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%7Cdoevans%40vmware.com%7C5b1ae01e339d413b1c0408d8cee0e252%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637486812577760238%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=W7A13Y6rLzm8ZqcPdO3VO2q5dgl%2F1oLcA5u1MgmE5m0%3Dreserved=0

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

[Donal Evans]

Thank you to everyone who participated in this discussion.

After a quick tally of responses, it looks like there are 6 people in favour of 
the change happening right now and 3 who are in favour but would prefer it to 
wait for a major version change. While this isn't a strong consensus, I do 
think that it demonstrates a solid majority in favour of the proposal as part 
of a minor version, so I have opened a pull request[1] with the necessary 
changes and invite everyone to provide feedback on it, particularly with 
regards to updating/expanding documentation around this change.

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

From: Dan Smith 
Sent: Wednesday, December 9, 2020 11:22 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false

I will go ahead and withdraw my objection to this change. Based on some side 
conversations, at least at VMWare it sounds like we don't have customers that 
are not setting this flag. So the scenario I'm worried about where a customer 
upgrades their production cluster and has it crash due to this change seems 
less likely. I do agree false is a better default.

I would also be fine waiting until 2.0 to make this change.

-Dan

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

[Donal Evans]

Regarding behaviour during RollingUpgrade; I created a draft PR with this 
change to test the feasibility and see what problems, if any, would be caused 
by tests assuming the default setting to be true. After fixing two DUnit tests 
that were not explicitly setting the value of conserve-sockets to true, no test 
failures were observed. I also ran a large suite of proprietary tests that 
include rolling upgrade and observed no problems there. This doesn't mean that 
there would definitely be no problems caused by this change, but I can at least 
say that none of the testing we currently have showed any problems.

From: Anthony Baker 
Sent: Friday, November 20, 2020 8:52 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false

Question:  how would this work with a rolling upgrade?  If the user did not set 
this property and we changed the default I believe that we would prevent the 
upgraded member from rejoining the cluster.

Of course the user could explicitly set this property as you point out.


Anthony


> On Nov 20, 2020, at 8:49 AM, Donal Evans  wrote:
>
> While I agree that the potential impact of having the setting changed out 
> from a user may be high, the cost of addressing that change is very small. 
> All users have to do is explicitly set the conserve-sockets value to true if 
> they were previously using the default and they will be back to where they 
> started with no change in behaviour or resource requirements. This could be 
> as simple as adding a single line to a properties file, which seems like a 
> pretty small inconvenience.
>
> Get Outlook for 
> Android<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36data=04%7C01%7Cdoevans%40vmware.com%7C5707a5b4d38c451cf58908d88d74ce81%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637414880110757318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=oKeeQ5Z6DPJAsQRUoZalfyahVRrmVq47CjYsFCKMios%3Dreserved=0>
>
> 
> From: Anthony Baker 
> Sent: Thursday, November 19, 2020 5:57:33 PM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false
>
> I think there are many good reasons to flip the default value for this 
> property. I do question whether requiring a user to allocate new hardware to 
> support the changed resource requirements is appropriate for a minor version 
> bump. In most cases I think that would come as an unwelcome surprise during 
> the upgrade.
>
> Anthony
>
>> On Nov 19, 2020, at 10:42 AM, Dan Smith  wrote:
>>
>> Personally, this has caused enough grief in the past (both ways, actually!) 
>> that I 'd say this is a major version change.
>> I agree with John. Either value of conserve-sockets can crash or hang your 
>> system depending on your use case.
>>
>> If this was just a matter of slowing down or speeding up performance, I 
>> think we could change it. But users that are impacted won't just see their 
>> system slow down. It will crash or hang. Potentially only with production 
>> sized workloads.
>>
>> With conserve-sockets=false every thread on the server creates its own 
>> sockets to other servers. With N servers that's N sockets per thread. With 
>> our default of a max of 800 threads for client connections and a 20 server 
>> cluster you are looking at a worst case of 800 * 20 = 16K sending sockets 
>> per server, with another 16K receiving sockets and 16K receiving threads. 
>> That's before considering function execution threads, WAN receivers, and 
>> various other executors we have on the server. Users with too many threads 
>> will hit their file descriptor or thread limits. Or they will run out of 
>> memory for thread stacks, socket buffers, etc.
>>
>> -Dan
>>
>

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

[Donal Evans]

While I agree that the potential impact of having the setting changed out from 
a user may be high, the cost of addressing that change is very small. All users 
have to do is explicitly set the conserve-sockets value to true if they were 
previously using the default and they will be back to where they started with 
no change in behaviour or resource requirements. This could be as simple as 
adding a single line to a properties file, which seems like a pretty small 
inconvenience.

Get Outlook for Android


From: Anthony Baker 
Sent: Thursday, November 19, 2020 5:57:33 PM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false

I think there are many good reasons to flip the default value for this 
property. I do question whether requiring a user to allocate new hardware to 
support the changed resource requirements is appropriate for a minor version 
bump. In most cases I think that would come as an unwelcome surprise during the 
upgrade.

Anthony

> On Nov 19, 2020, at 10:42 AM, Dan Smith  wrote:
>
> Personally, this has caused enough grief in the past (both ways, actually!) 
> that I 'd say this is a major version change.
> I agree with John. Either value of conserve-sockets can crash or hang your 
> system depending on your use case.
>
> If this was just a matter of slowing down or speeding up performance, I think 
> we could change it. But users that are impacted won't just see their system 
> slow down. It will crash or hang. Potentially only with production sized 
> workloads.
>
> With conserve-sockets=false every thread on the server creates its own 
> sockets to other servers. With N servers that's N sockets per thread. With 
> our default of a max of 800 threads for client connections and a 20 server 
> cluster you are looking at a worst case of 800 * 20 = 16K sending sockets per 
> server, with another 16K receiving sockets and 16K receiving threads. That's 
> before considering function execution threads, WAN receivers, and various 
> other executors we have on the server. Users with too many threads will hit 
> their file descriptor or thread limits. Or they will run out of memory for 
> thread stacks, socket buffers, etc.
>
> -Dan
>

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

[Donal Evans]

Just to clarify a comment from Owen, conserve-sockets=true does show improved 
performance over conserve-sockets=false in certain specific scenarios, but this 
isn't a hard and fast rule that applies everywhere, even excluding the cases 
where using conserve-sockets=true can lead to distributed deadlocks. As an 
example, with the new default setting of false, the UpgradeTest job in the CI 
pipeline takes about 10% longer, indicating that, at least for the scenarios 
being tested there, there is some performance impact. That being said, all of 
the geode-benchmarks tests explicitly set conserve-sockets=false, so from the 
point of view of what we're actually testing in terms of performance, no impact 
will be seen due to this change.

From: Jacob Barrett 
Sent: Thursday, November 19, 2020 8:02 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false

I would argue that is doesn’t change the outward behavior of the product. It 
does change the internal workings of the product. It does improve the 
performance and reliability. As long as changes to the internals don’t have 
effect on the outward facing behavior of the product I see no problem making 
these internal changes. Yes this may lead to more resource utilization but so 
can and have so other changes along the way between majors. I would also expect 
in the scenarios where this would make the most impact on resources they are 
already configured to use this feature.

+1 make the change.


> On Nov 19, 2020, at 1:16 AM, Ju@N  wrote:
>
> I'm all in for changing the default to *false* but, unfortunately and for
> all the reasons already stated in the thread, I'm hesitant to include this
> change as part of a minor release.
> Best regards.
>
> On Thu, 19 Nov 2020 at 02:48, John Blum  wrote:
>
>> The downside of conserve-sockets = false is that you are (essentially)
>> back to a Thread|Socket / Request model (though Geode limits this system
>> resource consumption to a degree by the use of Thread Pools in p2p
>> distribution layer) and thus, you can run out of file descriptors (per
>> newly opened Socket) pretty quickly if you are not careful.
>>
>> conserve-sockets set to true limits the use of finite system resources why
>> risking deadlocks (i.e. A -> B -> C -> A), which is also contingent on ACKS
>> (and the infamous ReplyProcessor21; at least at 1 time, not sure if it is
>> still in play, but probably!).
>>
>> conserve-sockets set to false uses more system resources but avoids
>> deadlocks.
>>
>> If this change is made, I'd minimally make sure to document that users
>> should adjust their (soft & hard) ulimits accordingly, based on use cases,
>> load, etc.
>>
>> Personally, this has caused enough grief in the past (both ways,
>> actually!) that I 'd say this is a major version change.
>>
>> -j
>>
>>
>> 
>> From: Nabarun Nag 
>> Sent: Wednesday, November 18, 2020 6:09 PM
>> To: dev@geode.apache.org 
>> Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to
>> false
>>
>> +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 o

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

[Donal Evans]

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://geode.apache.org/docs/guide/113/managing/monitor_tune/performance_controls_controlling_socket_use.html
[2] 
https://geode.apache.org/docs/guide/113/managing/monitor_tune/sockets_and_gateways.html

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

[Donal Evans]

Hi Geode dev,

I would like to backport the fixes for the below issues to the 1.13.1 support 
branch:
GEODE-8536[1] is a StackOverflow that can occur when creating a Lucene 
IndexWriter. The fix has been on develop for several weeks now without any 
issues.
GEODE-8686[2] is a potential Java-level deadlock that can occur rarely when GII 
and Tombstone GC are happening at the same time. While difficult to reproduce 
the issue, the fix removes the possibility of it occurring and verifies that 
other behaviour is unchanged.

[1] https://issues.apache.org/jira/browse/GEODE-8536
[2] https://issues.apache.org/jira/browse/GEODE-8686

Re: PR process and etiquette

[Donal Evans]

As a (relatively) new committer, one of the more difficult aspects of the PR 
process is knowing who to tag as a reviewer. The last person to touch a class 
may not actually have the context or depth of knowledge needed for a thorough 
review if, say, their changes were just refactoring or code cleanup, and if you 
don't have the luxury of working directly with other committers, it's not 
always clear who is the "right" person to ask for review. Add to that the fear 
of overburdening the more knowledgeable committers with endless requests for 
review, and you can find yourself in a position where the reviews you do end up 
getting are somewhat perfunctory or only address surface-level issues rather 
than potential more serious and fundamental problems.

The reverse of this is also something I have struggled with as one of the newer 
and less knowledgeable members of the community, as I'll sometimes see a PR sat 
waiting for review that changes areas of the code that I don't know much about 
and, wanting to help out, make some comments or requests for changes related to 
things like test naming, code style or other mostly cosmetic issues. Once those 
have been addressed, I can approve the PR, but I know that I haven't really​ 
reviewed it to the standard necessary to have confidence that it's not going to 
break something. On the one hand, I want to be active and help ensure the 
quality of code contributions in any way that I can, but on the other, I don't 
want my approval of a set of changes based on my limited understanding to be 
taken as a solid confirmation that there are no problems with them.

In terms of things that make the PR process easier as a reviewer, marking PRs 
as drafts until they're ready for comprehensive review is good, but I also have 
no problem with offering comments on a draft PR if they relate to things that 
are unlikely to change, like method or variable names, or even the broad 
approach being taken, so I don't view the draft status as a barrier to review. 
I also find it very helpful when the PR description gives an overview of what 
the PR is doing, not just repeating what's in the JIRA ticket associated with 
it, since the description of a bug and the description of its fix are often 
very different. Along a similar vein, descriptive commit messages are valuable 
since they can help provide context or motivation for why changes were made. 
The more I understand the contents of a PR in terms of what is being changed, 
why, and what the (intended) consequences are, the more confident I feel in 
being able to provide a thorough review.

Donal

From: Udo Kohlmeyer 
Sent: Wednesday, October 28, 2020 5:50 PM
To: dev@geode.apache.org 
Subject: Re: PR process and etiquette

So far I would like to thank everyone for their thoughts and input.

@Dave, I would love to find a solution to the partial sign-off. I’ve been 
experimenting with the “Projects” setting. I wonder if we cannot have a 
“Documentation Check” project, that is added to every PR as a default project. 
We could have different states with the project, which would allow the docs 
folk to know what PRs are new and which still need to be reviewed for docs 
changes.

Now, I don’t know if we can restrict the merging of a PR based upon a state in 
the Project, but at the very least it will provide the ability to have an 
overview of PR with/without docs review. You can have a look at the “Quality 
Review” project I have created. Which I use to track all PRs that I would like 
to review for quality purposes. (code, structure, tests, etc)… I think Docs 
could have something similar.

@Bruce, I’m not trying to create another rule for the sake of creating a rule. 
Why do you believe that we as a community will give any submitter a stink-eye 
just because they did not submit a draft? I certainly would not. I would 
suggest that the submitter maybe submit a draft IF the PR is not in a ready 
state and needs a few more iterations to get to a ready state.

I believe it is easier and better for committers to go through a list of PRs to 
review if they know that the PR passes all of the testing checks.. As a failure 
in one area might actually cause some code components to change. Which might 
void an earlier review of the code. Also, I’m not suggesting that there are no 
reviews before the commit checks go green. You can easily request someone else 
to review whilst in a draft state.

As for knowing what reviewers to tag for a review is more limiting. How would I 
as a new PR submitter know WHO I should tag in the PR? Over time we have built 
up a great understanding of who might be a good person to review our code. But 
for a new community member, they do not know this. For them, they submit the 
PR, and someone in the community will review it.

I would also like everyone to think back on their own approach on deciding what 
PRs to review.

Do you look at the PR and decide to wait until all commit 

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

[Donal Evans]

+1

From: Anthony Baker 
Sent: Tuesday, October 27, 2020 2:53 PM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] backport GEODE-8651 to 1.13, 9.10, 9.9

+1 from me

> On Oct 27, 2020, at 2:21 PM, Xiaojian Zhou  wrote:
>
> Hi, all:
>
> The fix is to resolve a hang when Connection called notifyHandshakeWaiter the 
> 2nd time and cleared the NioFilter’s unwrapped buffer by mistake.
>
> The 2nd call should consider if the 1st call has finished handshake. If yes, 
> do nothing. The fix is fully tested and has no risk. This problem exists in 
> earlier versions and should be backported.
>
> Regards
>
> Xiaojian Zhou

[PROPOSAL] Backport fix for GEODE-8620 to 1.13.1

[Donal Evans]

Hi Geode dev,

I would like to backport the fix for 
https://issues.apache.org/jira/browse/GEODE-8620 to the 1.13.1 branch. This bug 
causes incorrect redundancy levels to be reported for regions in which not all 
buckets have been created when using the Restore/StatusRedundancy features 
introduced in 1.13.0. The fix is minimal and has passed all tests run against 
the develop pipeline.

Thanks,
Donal

Reviews requested for LGTM alert fix PR

[Donal Evans]

Hi Geode dev,

As part of continued efforts to address alerts generated by LGTM analysis of 
the Geode codebase, I've opened a PR that addresses 108 of the "Potential 
input/output resource leak" alerts currently flagged: 
https://github.com/apache/geode/pull/5582. This encompasses most (but not all, 
see below) of that type of alert in the codebase and reduces the total number 
of LGTM alerts by 20%.

The majority of these alerts were fixed by simply introducing a 
try-with-resources block around the relevant lines, which ensures that 
resources are correctly released in the event of exceptions being thrown. This 
approach is equivalent to, but more concise than, the try/catch/finally style 
of resource handling in which resources are declared prior to the try block, 
assigned in the try block, and released/closed in the finally block.

Some of the alerts flagged by LGTM were false positives or could not use the 
try-with-resources approach, such as these two in ClientSideHandshakeImpl.java: 
https://lgtm.com/projects/g/apache/geode/snapshot/f21e8b26cbfc5af9aca2160811921cba4c46635e/files/geode-core/src/main/java/org/apache/geode/cache/client/internal/ClientSideHandshakeImpl.java?sort=name=ASC=heatmap#xbef4ecbd7219d16e:1
 where closing the DataInputSteam or DataOutputStream on method exit would also 
close the parent streams on the socket, rendering the connection unusable. 
False positives such as this, and more complex scenarios which could not be 
addressed with minimal changes are left as future work.

If anyone could spare some time to review the changes, I would much appreciate 
it.

Thanks,
Donal

Re: Colocated regions missing some buckets after restart

[Donal Evans]

Hi Mario,

I've tried using 12 colocated regions, starting the servers within 0.2 seconds 
of each other (according to the locator logs) and ensuring that the order 
they're started in is the same as the order they were shut down in, but I'm 
still unable to reproduce this issue. Is there anything else that I might be 
missing or doing differently from you?

Donal

From: Mario Kevo 
Sent: Monday, September 28, 2020 10:49 PM
To: dev@geode.apache.org 
Subject: Odg: Colocated regions missing some buckets after restart

Hi Donal,

Sometimes you need to do restart two or three times, but mostly it is 
reproduced by first restart.
start locator --name=locator1 --port=10334
start locator --name=locator2 --port=10335 --locators=localhost[10334]
start server --name=server1 --locators=127.0.0.1[10334],127.0.0.1[10335] 
--server-port=40404
start server --name=server2 --locators=127.0.0.1[10334],127.0.0.1[10335] 
--server-port=40405
I'm putting 1 entries, but you can use a lower value.

You need to be really quick with commands. There is an example from my locator 
log.
[info 2020/09/29 07:41:52.060 CEST  
tid=0x1d] Received a join request from 192.168.0.145(server4:22852):41002
[info 2020/09/29 07:41:52.406 CEST  
tid=0x1d] Received a join request from 192.168.0.145(server3:22879):41003

I prepare commands to start server in two terminals, so I can start them almost 
in the same time.
Sorry, I forgot to mention that you need to see which server is stopped first 
and starts him first (The issue was first reproduced on kubernetes, and that is 
how pods restarts servers).
Also if you are not able to reproduce the issue, try to set 10 or more 
colocated regions.

BR,
Mario


Šalje: Donal Evans 
Poslano: 28. rujna 2020. 23:48
Prima: dev@geode.apache.org 
Predmet: Re: Colocated regions missing some buckets after restart

Hi Mario,

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

  *   Do you see this behaviour 100% of the time with these steps, or is still 
only on some restarts that it shows up?
  *   Could you describe in more detail how exactly you're starting the 
locators/servers? I'm just using the gfsh "start locator" and "start server" 
commands, only specifying ports, with no other settings, so if you're doing 
anything different that may be a factor.
  *   How many entries are you putting into the region, and does the issue 
still reproduce if you use fewer entries? I'm using 1 entries as described 
in your earlier email.
  *   How quick do you have to be when restarting the servers in the two 
terminals at the same time? I'm currently just manually clicking between them 
and executing the two start server commands within a second of each other, but 
if that's not fast enough then I should probably be using a script or something.

Hopefully if we can understand what's different between what I'm doing and what 
you're doing then it will help us understand exactly what's going wrong.

- Donal

From: Mario Kevo 
Sent: Monday, September 28, 2020 6:23 AM
To: dev@geode.apache.org 
Subject: Odg: Colocated regions missing some buckets after restart

Hi all,

After more investigation I found that for some buckets is problem to define 
which server is primary.
While doing getPrimary if existing primary is null it waits for a new primary 
and after some time return null for it.

From what I found is while doing setHosting( 
grabBucket[PartitionedRegionDataStore.java]->grabFreeBucket[PartitionedRegionDataStore.java]->setHosting[ProxyBucketRegion.java]->setHosting[BucketAdvisor.java])
 it volunteer for primary and sendProfileUpdate to all other servers.
There it calls BucketProfileUpdateMessage.send and there is stucked as it 
cannot get response from the other members.

Ticket is opened on GEODE: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8546data=02%7C01%7Cdoevans%40vmware.com%7Cdd061beb634d4fd7805708d8643b6b70%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637369553660830374sdata=J79mRS8BYs2oTHGgz%2BqgmDIXO1zICK%2FIXSxKj%2FvWXF8%3Dreserved=0
How to reproduce the issue:

  1.   Start two locators and two servers
  2.   Create PARTITION_REDUNDANT_PERSISTENT region with redundant-copies=1
  3.   Create few PARTITION_REDUNDANT regions(I used six regions) colocated 
with persistent region and redundant-copies=1
  4.   Put some entries.
  5.   Restart servers(you can simply run "kill -15 " and then 
from two terminals start both of them at the same time)
  6.   It will take a time to get server startup finished and for the latest 
region bucketCount will be zero on one 

Re: Colocated regions missing some buckets after restart

[Donal Evans]

Hi Mario,

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

  *   Do you see this behaviour 100% of the time with these steps, or is still 
only on some restarts that it shows up?
  *   Could you describe in more detail how exactly you're starting the 
locators/servers? I'm just using the gfsh "start locator" and "start server" 
commands, only specifying ports, with no other settings, so if you're doing 
anything different that may be a factor.
  *   How many entries are you putting into the region, and does the issue 
still reproduce if you use fewer entries? I'm using 1 entries as described 
in your earlier email.
  *   How quick do you have to be when restarting the servers in the two 
terminals at the same time? I'm currently just manually clicking between them 
and executing the two start server commands within a second of each other, but 
if that's not fast enough then I should probably be using a script or something.

Hopefully if we can understand what's different between what I'm doing and what 
you're doing then it will help us understand exactly what's going wrong.

- Donal

From: Mario Kevo 
Sent: Monday, September 28, 2020 6:23 AM
To: dev@geode.apache.org 
Subject: Odg: Colocated regions missing some buckets after restart

Hi all,

After more investigation I found that for some buckets is problem to define 
which server is primary.
While doing getPrimary if existing primary is null it waits for a new primary 
and after some time return null for it.

From what I found is while doing setHosting( 
grabBucket[PartitionedRegionDataStore.java]->grabFreeBucket[PartitionedRegionDataStore.java]->setHosting[ProxyBucketRegion.java]->setHosting[BucketAdvisor.java])
 it volunteer for primary and sendProfileUpdate to all other servers.
There it calls BucketProfileUpdateMessage.send and there is stucked as it 
cannot get response from the other members.

Ticket is opened on GEODE: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8546data=02%7C01%7Cdoevans%40vmware.com%7C4a51a06464f34b8cf6ed08d863b1c66f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637368962530124201sdata=cfW3BI0K906FutWL9QQBDlDharQdK08%2FRY1iUgyImWk%3Dreserved=0
How to reproduce the issue:

  1.   Start two locators and two servers
  2.   Create PARTITION_REDUNDANT_PERSISTENT region with redundant-copies=1
  3.   Create few PARTITION_REDUNDANT regions(I used six regions) colocated 
with persistent region and redundant-copies=1
  4.   Put some entries.
  5.   Restart servers(you can simply run "kill -15 " and then 
from two terminals start both of them at the same time)
  6.   It will take a time to get server startup finished and for the latest 
region bucketCount will be zero on one member

If someone with more experience with bucket initialization have a time to help 
me with this I will appriciate it.
For any more info, please contact me.

BR,
Mario



Šalje: Mario Kevo 
Poslano: 17. rujna 2020. 15:00
Prima: dev@geode.apache.org 
Predmet: Odg: Colocated regions missing some buckets after restart

Hi Anil,

Thread dump is in an attachment.
For now we found difference between server logs, on the one which have this 
problem has this log "Colocation is incomplete".
So it seems that colocation is not finished for this region on this member. 
This part of code can be found on this 
link.
We will continue investigation on this and try to find what cause the issue.

BR,
Mario


Šalje: Anilkumar Gingade 
Poslano: 16. rujna 2020. 16:55
Prima: dev@geode.apache.org 
Predmet: Re: Colocated regions missing some buckets after restart

Mario,

Take a thread dump; couple of times at an interval of a minute...See if you can 
find threads stuck in region creation...This will show if there are any lock 
contention.

-Anil.


On 9/16/20, 6:29 AM, "Mario Kevo"  wrote:

Hi Anil,

From server logs we see that have some threads stucked and continuosly get 
on server2 the following message(bucket missing on server2 for DfSessions 
region):
[warn 2020/09/15 14:25:39.852 CEST  
tid=0x251] 15 secs have elapsed waiting for a primary for bucket [BucketAdvisor 
/__PR/_B__DfSessions_18:935: 

Re: [Discussion] - ClassLoaderService RFC proposal

[Donal Evans]

Sounds good to me. One question though: is it likely that the 
ClassLoaderService configuration will need to be persisted at all? For example, 
would it be reasonable to provide a user with the ability to specify a new 
ClassLoaderService implementation to be used upon cluster restart (via GFSH or 
REST), which would require some sort of persisted configuration? If this is 
likely, will the currently proposed implementation provide this functionality, 
or will that be left for future work? I only ask because I'm not sure how easy 
it is to convert something into a persistent service vs creating it as one in 
the first place. If it's trivial, then no worries.

From: Udo Kohlmeyer 
Sent: Monday, September 14, 2020 3:42 AM
To: geode 
Subject: [Discussion] - ClassLoaderService RFC proposal

Hi there Apache Geode Devs, (try 2)

Please find attached a proposal for a ClassLoaderService. Please review and 
ponder on it.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FIntroduction%2Bof%2BClassLoaderService%2Binto%2BGeodedata=02%7C01%7Cdoevans%40vmware.com%7C7cf5b252f85a4deb173f08d8589ae792%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637356769617910090sdata=lDloqR55FH9dkUD9cyboujDkf8GjUdrAqdCzSpB8QCA%3Dreserved=0

All comments are please to be made in this mail thread.

—Udo

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

[Donal Evans]

+1

From: Dave Barnes 
Sent: Tuesday, September 1, 2020 10:25 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] port GEODE-8467 to support/1.13

> Assuming that it's passed applicable testing AND GETS AT LEAST 3 VOTES,
let's do it.

On Tue, Sep 1, 2020 at 10:24 AM Dave Barnes  wrote:

> +1
> GEODE-8467 addresses one of the few remaining 1.13 release blockers.
> I see it's been approved and merged into the develop branch. Assuming that
> it's passed applicable testing, let's do it.
>
> On Tue, Sep 1, 2020 at 7:37 AM Bruce Schuchardt  wrote:
>
>> I’d like to cherry-pick this change into support/1.13:
>>
>> There is a flaw in the code that handles a server being forced out of the
>> cluster.  The flaw keeps the server from shutting down and leaves the
>> server in a hung state.  The PR adds error handling to two methods, one in
>> the Cache’s XML-generation method and the other in a Membership class to
>> ensure that tear-down of the cache is performed.
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5490data=02%7C01%7Cdoevans%40vmware.com%7Ca03fd376ab304881170c08d84e9c0cda%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637345779446436246sdata=XorixZ6YCvZbEk8hV%2Bm2g6Db6jKyZPlFlRTg91PREvU%3Dreserved=0
>>
>>

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

[Donal Evans]

+1

We still have outstanding release blockers for 1.13, so getting this fix in now 
just prevents extra work in the future without slowing us down now.

From: Owen Nichols 
Sent: Monday, August 31, 2020 4:19 PM
To: dev@geode.apache.org 
Subject: Proposal to bring GEODE-8456 (shiro upgrade) to support branches

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

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

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

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

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

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

[Donal Evans]

The proposed changes have now been applied to the GEODE Jira. Hopefully it will 
now be easier for people to input the relevant information at time of ticket 
creation.

From: Mark Bretl 
Sent: Tuesday, August 18, 2020 2:38 PM
To: geode 
Subject: Re: [PROPOSAL] Remove "Fix Version/s" and "Sprint" from Jira "Create 
Issue" dialogue and include "Affects Version/s"

+1

--Mark

On Tue, Aug 18, 2020 at 9:39 AM Raymond Ingles  wrote:

> +1
>
> On 8/17/20, 3:04 PM, "Donal Evans"  wrote:
>
> Looking at the dialogue that opens when you attempt to create a new
> ticket in the GEODE Jira[1], there are two fields included that aren't
> really necessary and may cause confusion. The "Fix Version/s" field should
> presumably not be filled out until the issue has actually been fixed,
> rather than at the time of ticket creation. The "Sprint" field seems to no
> longer serve any purpose at all that I can discern, having only been filled
> in 13 tickets, the most recent of which was created in December 2018[2].
> With the expansion of the community contributing to the Geode project, it's
> important to provide a straightforward experience for people who are new to
> the project and wish to file tickets, so the presence of these fields may
> cause issues.
>
> I propose that these two fields be removed from the "Create Issue"
> dialogue and that the "Affects Version/s" field be added, since that field
> is far more important at time of ticket creation. There are currently 3851
> bug tickets in the Jira with no "Affects Version/s" value entered at
> all[3], which I suspect is in part due to that field not being an option in
> the "Create Issue" dialogue, meaning you have to remember to go back after
> creating the ticket and enter it. With Geode moving to a model of having
> support branches and patch releases, properly capturing the versions
> affected by a given issue becomes even more important.
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.imgur.com%2FoQ8CW87.pngdata=02%7C01%7Cdoevans%40vmware.com%7C8c4967640fb44f8fd09408d843bf1d9c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637333835403616624sdata=rWJx71Oq%2FpUireASonw49GJbfcPh9%2BRtzIllWRB3Dms%3Dreserved=0
> [2]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fprojects%2FGEODE%2Fissues%2FGEODE-8433%3Ffilter%3Dallissues%26orderby%3Dcf%255B12310921%255D%2BASC%252C%2Bcreated%2BDESCdata=02%7C01%7Cdoevans%40vmware.com%7C8c4967640fb44f8fd09408d843bf1d9c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637333835403626627sdata=0RCAZn8n5ZGJkbQm4YntSnXlX4GCGrwAvHJrSbpXNgQ%3Dreserved=0
> [3]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8433%3Fjql%3Dproject%2520%253D%2520GEODE%2520AND%2520issuetype%2520%253D%2520Bug%2520AND%2520affectedVersion%2520%253D%2520EMPTY%2520ORDER%2520BY%2520created%2520DESC%252C%2520affectedVersion%2520ASC%252C%2520cf%255B12310921%255D%2520ASCdata=02%7C01%7Cdoevans%40vmware.com%7C8c4967640fb44f8fd09408d843bf1d9c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637333835403626627sdata=TRhfor1SP1QYC6LQ2U1ydbhVhvmaJEChEC2VOz3njyw%3Dreserved=0
>
>

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

[Donal Evans]

Looking at the dialogue that opens when you attempt to create a new ticket in 
the GEODE Jira[1], there are two fields included that aren't really necessary 
and may cause confusion. The "Fix Version/s" field should presumably not be 
filled out until the issue has actually been fixed, rather than at the time of 
ticket creation. The "Sprint" field seems to no longer serve any purpose at all 
that I can discern, having only been filled in 13 tickets, the most recent of 
which was created in December 2018[2]. With the expansion of the community 
contributing to the Geode project, it's important to provide a straightforward 
experience for people who are new to the project and wish to file tickets, so 
the presence of these fields may cause issues.

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

[1] https://i.imgur.com/oQ8CW87.png
[2] 
https://issues.apache.org/jira/projects/GEODE/issues/GEODE-8433?filter=allissues=cf%5B12310921%5D+ASC%2C+created+DESC
[3] 
https://issues.apache.org/jira/browse/GEODE-8433?jql=project%20%3D%20GEODE%20AND%20issuetype%20%3D%20Bug%20AND%20affectedVersion%20%3D%20EMPTY%20ORDER%20BY%20created%20DESC%2C%20affectedVersion%20ASC%2C%20cf%5B12310921%5D%20ASC

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

[Donal Evans]

+1

From: Mark Hanson 
Sent: Wednesday, August 12, 2020 4:40 PM
To: dev@geode.apache.org 
Subject: [Proposal] Backport GEODE-8422 to support/1.13

Hi All,

We have found a case where tombstones were being cleared when the region was 
not initialized. This was causing some test failures and potential field 
failures. We would like to put this into support/1.13.

Thanks,
Mark

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

[Donal Evans]

+1

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

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

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

[Donal Evans]

+1

From: Darrel Schneider 
Sent: Monday, August 3, 2020 4:05 PM
To: dev@geode.apache.org 
Subject: [PROPOSAL] backport GEODE-6564 to support/1.13

GEODE-6564 is a memory leak that has impacted users so it would be good to have 
it in 1.13. It has a simple, low risk, fix.

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

[Donal Evans]

+1

Nice catch!

Get Outlook for Android


From: Jinmei Liao 
Sent: Saturday, August 1, 2020 11:09:45 PM
To: dev@geode.apache.org 
Subject: Re: Proposal to backport GEODE-8395 (gfsh help banner) to support 
branches

+1

On Aug 1, 2020 10:30 PM, Owen Nichols  wrote:
This issue was present since Geode 1.0.  There is zero risk from this fix, 
which is already on develop.  It is critical because Geode releases are a legal 
Act of the Apache Foundation and should not misrepresent the identity of the 
project.

Here’s the issue:

$ gfsh
_ __
   / _/ __/ __/ // /
  / /  __/ /___  /_  / _  /
/ /__/ / /  _/ / // /
/__/_/  /__/_//_/1.12.0

Monitor and Manage Apache Geode<-- right product name

$gfsh --help
Pivotal GemFire(R) v1.12.0 Command Line Shell   <-- WRONG product name

The “right” instance above was fixed 5 years ago.  GEODE-8395 fixes gfsh to use 
the “right” code in both places.  Please vote +1 to backport this fix to 
support/1.13 and support/1.12.

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

[Donal Evans]

+1

From: Owen Nichols 
Sent: Friday, July 31, 2020 10:21 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] back-port GEODE-8388 native client doc fixes to 
support/1.13

+1

On 7/31/20, 10:20 AM, "Dave Barnes"  wrote:

GEODE-8388: Geode Native Client user guide: delete unused sources

Housekeeping: The geode-native docs directory contains unused sources from
the pre-open-source days. The problem is that while they're not linked to
the user guide's T of C, these out-of-date docs are still included in the
manual build (a quirk of the toolset), where they can be accidentally
discovered via web searches.

These unused files need to be identified and deleted.

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

[Donal Evans]

I may be mistaken, but I think the develop/highwater tag was used by the 
geode-benchmarks project. Can we get confirmation that it's no longer in use?

+1 conditional on that

Get Outlook for Android


From: Ju@N 
Sent: Thursday, July 30, 2020 3:10:44 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] one-time cleanup of stray and obsolete tags in geode 
repo

+1

On Thu 30 Jul 2020 at 08:21, Owen Nichols  wrote:

> Tags in the rel/ namespace should be created by the Geode release manager
> as part of an official Geode release only, yet we seem to have some extra
> ones somehow.
> Further, I don't see any value in keeping RC tags forever long after the
> release is final.
>
> Please vote +1 in favor of trimming the current list of 110 tags down to
> 20 to make it nice and easy for newcomers (as well as the rest of us) to
> find and checkout a specific version of Geode; otherwise vote -1.  If the
> majority vote is +1 at 3PM PDT Fri Aug 7, I will proceed to archive and
> delete the 90 unnecessary tags as detailed below.
>
> I propose to KEEP only the following tags, corresponding to official Geode
> releases:
>
> rel/v1.12.0
> rel/v1.11.0
> rel/v1.10.0
> rel/v1.9.2
> rel/v1.9.1
> rel/v1.9.0
> rel/v1.8.0
> rel/v1.7.0
> rel/v1.6.0
> rel/v1.5.0
> rel/v1.4.0
> rel/v1.3.0
> rel/v1.2.1
> rel/v1.2.0
> rel/v1.1.1
> rel/v1.1.0
> rel/v1.0.0-incubating
> rel/v1.0.0-incubating.M3
> rel/v1.0.0-incubating.M2
> rel/v1.0.0-incubating.M1
>
> I propose a one-time cleanup to DELETE all other tags, specifically:
>
> develop/highwater
> modules-pre-merge
> rel/v1.0.0-incubating.M1.RC1
> rel/v1.0.0-incubating.M1.RC2
> rel/v1.0.0-incubating.M2.RC1
> rel/v1.0.0-incubating.M2.RC2
> rel/v1.0.0-incubating.M3.RC1
> rel/v1.0.0-incubating.M3.RC2
> rel/v1.0.0-incubating.M3.RC3
> rel/v1.0.0-incubating.M3.RC4
> rel/v1.0.0-incubating.M3.RC5
> rel/v1.0.0-incubating.M3.RC6
> rel/v1.0.0-incubating.M3.RC7
> rel/v1.0.0-incubating.RC1
> rel/v1.0.0-incubating.RC2
> rel/v1.1.0.RC1
> rel/v1.1.0.RC2
> rel/v1.1.0manualrev-2017-02-16
> rel/v1.1.0manualrev-2017-10-19
> rel/v1.1.1.RC1
> rel/v1.1.1.RC2
> rel/v1.10.0.1
> rel/v1.10.0.1.RC1
> rel/v1.10.0.2
> rel/v1.10.0.RC1
> rel/v1.10.0.RC2
> rel/v1.11.0.1
> rel/v1.11.0.2
> rel/v1.11.0.23755
> rel/v1.11.0.23755_2
> rel/v1.11.0.23755_3
> rel/v1.11.0.3
> rel/v1.11.0.4
> rel/v1.11.0.5
> rel/v1.11.0.6
> rel/v1.11.0.7
> rel/v1.11.0.7565
> rel/v1.11.0.8
> rel/v1.11.0.RC1
> rel/v1.11.0.RC2
> rel/v1.11.0.RC3
> rel/v1.11.0.RC4
> rel/v1.12.0.1
> rel/v1.12.0.1234
> rel/v1.12.0.2
> rel/v1.12.0.23755
> rel/v1.12.0.3
> rel/v1.12.0.4
> rel/v1.12.0.5
> rel/v1.12.0.6
> rel/v1.12.0.RC1
> rel/v1.12.0.RC2
> rel/v1.12.0.RC3
> rel/v1.12.0.RC4
> rel/v1.14.0.23755
> rel/v1.2.0.RC1
> rel/v1.2.0.RC2
> rel/v1.2.1.RC1
> rel/v1.2.1.RC2
> rel/v1.2.1.RC3
> rel/v1.2.1.RC4
> rel/v1.2.1manualrev-2017-10-19
> rel/v1.3.0.RC1
> rel/v1.3.0.RC2
> rel/v1.3.0.RC3
> rel/v1.3.0.RC4
> rel/v1.4.0.RC1
> rel/v1.4.0.RC2
> rel/v1.5.0.RC1
> rel/v1.5.0.RC2
> rel/v1.6.0.RC1
> rel/v1.7.0.RC1
> rel/v1.7.0.RC2
> rel/v1.8.0.RC1
> rel/v1.8.0.RC2
> rel/v1.9.0.1
> rel/v1.9.0.1.RC1
> rel/v1.9.0.2
> rel/v1.9.0.RC1
> rel/v1.9.0.RC2
> rel/v1.9.0.RC3
> rel/v1.9.0.RC4
> rel/v1.9.1-nordix
> rel/v1.9.1.RC1
> rel/v1.9.1.RC2
> rel/v1.9.1.RC3
> rel/v1.9.2.RC1
> sga2-core
> v1.1.0manualrev-2017-10-19
> v9.0.0-beta.1
>
--
Ju@N

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

[Donal Evans]

+1

From: Bruce Schuchardt 
Sent: Wednesday, July 29, 2020 8:04 AM
To: dev@geode.apache.org 
Subject: [PROPOSAL] port GEODE-8385 changes to support/1.13

This concerns a hang during recovery from disk.  The problem was introduced in 
1.13.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8385data=02%7C01%7Cdoevans%40vmware.com%7Cd0ed0388a525424e4d4808d833d0ba84%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637316318862952224sdata=9yXYbEgFgFpRniqjytq5q7y%2FTEeb7gTBvLT8F6WoB4s%3Dreserved=0

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

[Donal Evans]

+1

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

+1

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

This is to address HARegionQueue GII events not properly removed issue, which 
could potentially resurrect a strayed event in client cache.

Regards,
Eric

Re: [PROPOSAL] Postpone Geode 1.14

[Donal Evans]

+1

From: Owen Nichols 
Sent: Tuesday, July 28, 2020 4:38 PM
To: Alexander Murmann ; dev@geode.apache.org 

Subject: Re: [PROPOSAL] Postpone Geode 1.14

+1


---
Sent from Workspace ONE 
Boxer

On July 28, 2020 at 4:34:55 PM PDT, Alexander Murmann  
wrote:
Hi all,

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

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

Re: [Discuss] Cutting Geode 1.14

[Donal Evans]

+1 to postponing 1.14.

Given the limited resources we have in terms of people who shepherd the release 
process and ensure the quality of what we end up releasing, it would put an 
unsustainable amount of strain on those who have already been working extremely 
hard on getting 1.13 finished if we rolled right into 1.14 without time to 
breathe and hopefully ramp up some more people to take over parts of the 
release process.

I'm also not in favour of abandoning 1.13 entirely, as there's been a huge 
effort on the part of some community members to get it into a good state to 
release, and dropping 1.13 now would effectively be seeing all that work go to 
waste. It also wouldn't address the core issue that those most heavily involved 
in the release process and in identifying and addressing potential release 
blockers are in danger of being exhausted by the non-stop process of finding 
and fixing bugs in the release, since 1.14 will have all of the same blockers 
that 1.13 currently has, plus an undetermined number of additional ones that we 
may not know about yet.

From: Jacob Barrett 
Sent: Monday, July 20, 2020 9:38 AM
To: dev@geode.apache.org 
Subject: Re: [Discuss] Cutting Geode 1.14

Alternatively, why not abandon 1.13 and try again with 1.14?

> On Jul 20, 2020, at 9:21 AM, Alexander Murmann  wrote:
>
> Hi everyone,
>
> TL;DR: Let's discuss 1.14 once 1.13 is out.
>
> If we stick to our cadence of cutting a release every 3 months and shipping
> it 1 month later, 1.14 is due to be cut two weeks from today. However, we
> haven't shipped 1.13 yet and are still struggling with some issues.
>
> I suggest that we postpone cutting the 1.14 release till we've actually
> shipped 1.13. Once we've shipped 1.13, we should have another conversation
> about timing of 1.14. I know the 1.13 release has been taxing on many
> people in our community and we might want to consider giving ourselves a
> little bit of a gap between releases.

Re: [Proposal] - RFC etiquette

[Donal Evans]

Udo,

You're right, and I agree wholeheartedly with your proposal to give RFCs enough 
time and enough context for proper review by as many people as possible. Sorry 
if that didn't come across in my original reply.

From: Udo Kohlmeyer 
Sent: Thursday, July 9, 2020 3:55 PM
To: dev@geode.apache.org 
Subject: Re: [Proposal] - RFC etiquette

Donal,

You have very valid points. All of which only pertain to the “HOW” or “IF” an 
RFC should be written. This being a completely different problem to what I’m 
proposing. I’m willing to comment on any proposal that were to address these 
issues. :)

This proposal is largely aimed at, if there is an existing RFC, we don’t try 
and rush it through and provide more context to reviewers to better comment on 
use case, technical approach or overall soundness of the proposal. If we keep 
aiming RFC’s at specialized technical knowledge, we will definitely lose 
reviewers who have not looked at that code in a long time. If the use case(s) 
are at least described than we can have many reviewers who can comment on the 
feature or technical approach without being intimate with all the inner 
workings of the system.

I believe this approach will help with an overall better understanding of the 
systems behavior.

—Udo
On Jul 9, 2020, 1:46 PM -0700, Donal Evans , wrote:
While I definitely approve of these proposals in principle (especially the "Use 
Cases" section, which could really help facilitate discussions around other 
potential solutions/approaches to a problem), the fact that the RFC process is 
still entirely voluntary on the part of the contributor(s) who intend to 
add/modify features in Geode makes me slightly hesitant to add extra 
work/complexity to it. If someone feels like it's too much effort to write an 
RFC, they may decide to skip it and go straight to PR, which for large/complex 
change sets can lead to a lot of missing context for why a particular approach 
was taken and a greater chance of only one or two committers actually reviewing 
the changes in detail rather than the larger community being able to weigh in 
on an RFC.

I feel that RFCs can be a very valuable process to help determine the best 
solution to complex problems, but if there is "too much" work involved in 
creating one and nothing compelling committers to write them, we may end up 
losing out on the value they provide. Perhaps the community could agree on some 
criteria for work that would *require* an RFC, related to the scope/breadth of 
the intended changes and how many different approaches there might be? This 
would have to go hand-in-hand with a commitment from the community to promptly 
and thoroughly review RFCs, though, otherwise people could end up being put to 
the trouble of writing a comprehensive RFC only to have barely any actual 
feedback.

From: Udo Kohlmeyer 
Sent: Thursday, July 9, 2020 1:18 PM
To: geode 
Subject: [Proposal] - RFC etiquette

Hi there Geode Dev's

I would like to propose the following changes to the RFC process that we have 
in place at the moment.

1. All submitted RFC’s will provide a minimum 2 week review period. This is to 
allow the community to review the RFC in a reasonable timeframe. If we rush 
things, we will miss things. I’d rather have a little more time spent on the 
RFC review and getting the approach “correct” than rushing the RFC and then at 
a later point in time (either at PR review or worse production issue) find out 
that the approach was less than optimal.
2. Add a new section to the RFC. I would like to propose this section to be 
labelled “Use Cases”. In this section I would like all submitters to describe 
the use case that this RFC is to fulfill. This would include all possible 
combinations (success and failure) and expected outcomes of each.

I hope with the additions to the RFC process and template we can better round 
out each RFC. Causing less delays later in the process and allowing all 
community members to actively participate in the review process regardless of 
technical skill level.

Thoughts or comments?

—Udo

Re: [Proposal] - RFC etiquette

[Donal Evans]

While I definitely approve of these proposals in principle (especially the "Use 
Cases" section, which could really help facilitate discussions around other 
potential solutions/approaches to a problem), the fact that the RFC process is 
still entirely voluntary on the part of the contributor(s) who intend to 
add/modify features in Geode makes me slightly hesitant to add extra 
work/complexity to it. If someone feels like it's too much effort to write an 
RFC, they may decide to skip it and go straight to PR, which for large/complex 
change sets can lead to a lot of missing context for why a particular approach 
was taken and a greater chance of only one or two committers actually reviewing 
the changes in detail rather than the larger community being able to weigh in 
on an RFC.

I feel that RFCs can be a very valuable process to help determine the best 
solution to complex problems, but if there is "too much" work involved in 
creating one and nothing compelling committers to write them, we may end up 
losing out on the value they provide. Perhaps the community could agree on some 
criteria for work that would *require* an RFC, related to the scope/breadth of 
the intended changes and how many different approaches there might be? This 
would have to go hand-in-hand with a commitment from the community to promptly 
and thoroughly review RFCs, though, otherwise people could end up being put to 
the trouble of writing a comprehensive RFC only to have barely any actual 
feedback.

From: Udo Kohlmeyer 
Sent: Thursday, July 9, 2020 1:18 PM
To: geode 
Subject: [Proposal] - RFC etiquette

Hi there Geode Dev's

I would like to propose the following changes to the RFC process that we have 
in place at the moment.

  1.  All submitted RFC’s will provide a minimum 2 week review period. This is 
to allow the community to review the RFC in a reasonable timeframe. If we rush 
things, we will miss things. I’d rather have a little more time spent on the 
RFC review and getting the approach “correct” than rushing the RFC and then at 
a later point in time (either at PR review or worse production issue) find out 
that the approach was less than optimal.
  2.  Add a new section to the RFC. I would like to propose this section to be 
labelled “Use Cases”. In this section I would like all submitters to describe 
the use case that this RFC is to fulfill. This would include all possible 
combinations (success and failure) and expected outcomes of each.

I hope with the additions to the RFC process and template we can better round 
out each RFC. Causing less delays later in the process and allowing all 
community members to actively participate in the review process regardless of 
technical skill level.

Thoughts or comments?

—Udo

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

[Donal Evans]

+1

From: Bruce Schuchardt 
Sent: Thursday, July 9, 2020 8:00 AM
To: dev@geode.apache.org 
Subject: [PROPOSAL] backport fix for GEODE-8020 to support/1.13

There are reports that SSL performance is off on the support/1.13 branch with 
respect to the support/1.12 branch,  but performance on develop okay.  The only 
communications changes in develop that aren’t in 1.13 are those that fixed this 
long-standing bug, so I’d like to backport it to the 1.13 branch.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5048data=02%7C01%7Cdoevans%40vmware.com%7C2fb1536164944cdb5c2808d82418dc26%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637299036483136624sdata=u5UoE8C7bJdwc7RohfFCE1T%2FnbD%2FWGF7Cg%2F%2Fk9lIIA4%3Dreserved=0

The error was in the cluster communications message-streamer class that created 
some extra objects during message transmission.  The fix is small and has been, 
at this point, through many test iterations.

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

[Donal Evans]

+1

Get Outlook for Android


From: Ju@N 
Sent: Friday, July 3, 2020 6:06:27 AM
To: dev@geode.apache.org 
Subject: [PROPOSAL]: Backport GEODE-8029 to support/1.12 and support/1.13

Hello devs,

I'd like to propose bringing GEODE-8029 [1] to the support/1.12 and
support/1.13 branches.
No, you're not having deja vú (neither this is an error within the Matrix):
a couple of weeks ago I've backported another fix for the same ticket to
the mentioned branches and sent the proposal to the list with exactly the
same subject, but it has proven to be problematic and introduced some
regressions... sorry about that.
The new fix uses a different approach, solves the original issue and
doesn't introduce any new problems (feel free to have a look at the ticket
for further details); it has been merged into develop already through
commit fdc4401 [2]. As a side note, I've also created a new ticket
(GEODE-8325 [3]) to improve the internal behavior and implement a long term
solution to avoid the proliferation of unused drf files.
Best regards.

[1]: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8029data=02%7C01%7Cdoevans%40vmware.com%7C68acb95b6e734022961e08d81f51ef51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637293784078289285sdata=RrRnhT2O9m3JflNV9U5rDHTlKkemFUpgkbUuyYbC1zs%3Dreserved=0
[2]:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2Ffdc440131f0d562d97f2340d2e7ba5aacf935d62data=02%7C01%7Cdoevans%40vmware.com%7C68acb95b6e734022961e08d81f51ef51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637293784078289285sdata=qNLbi57hwj%2B8TuhBcrEEqb4MZLRU9FEZ4weKiUIUxfw%3Dreserved=0
[3]: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8325data=02%7C01%7Cdoevans%40vmware.com%7C68acb95b6e734022961e08d81f51ef51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637293784078289285sdata=bZNUigpakU1%2FhCGu5gFLNX1HjP7B64rNnxBU6d%2B8NpI%3Dreserved=0


--
Ju@N

Re: Us vs Docker vs Gradle vs JUnit

[Donal Evans]

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

From: Jinmei Liao 
Sent: Tuesday, June 30, 2020 12:28 PM
To: dev@geode.apache.org 
Subject: Re: Us vs Docker vs Gradle vs JUnit

I would vote for fixing the tests to use gradle's normal forking. If we are 
going to invest time and effort, let's invest in an option that can reduce our 
dependencies

From: Jacob Barrett 
Sent: Tuesday, June 30, 2020 11:30 AM
To: dev@geode.apache.org 
Subject: Us vs Docker vs Gradle vs JUnit

All,

We are in a bit of a pickle. As you recall from a few years back in an effort 
to both stabilize and parallelize integration, distributed and other 
integration/system like test we use Docker. Many of the tests reused the same 
ports for services which cause them to fail or interact with each other when 
run in parallel. By using Docker to isolate a test we put a bandage on that 
issue. The plugin overrides Gradle’s default forked runner by starting the 
runners in Docker containers and marshaling the execution parameters to those 
Dockerized runners.

The Docker test plugin is effectively unmaintained. The author seems content on 
keeping it compatible with Gradle 4. We forked it to work with Gradle 5 and 
various other issues we have hit over the years. We have shared patches in the 
past with little luck in having them merged and still its only compatible with 
Gradle 4.8 at best. I spent some time trying to port it to Gradle 6 but its 
going to be a larger undertaking given that Gradle 6 is fully Java modules 
compatible. They added new members throughout to handle modules in addition to 
class paths.

Long story short because our tests can’t be parallelized without a container 
system we are stuck. We can’t go to JUnit 5 without updating Docker plugin 
(potentially minor changes). We can’t go to Gradle 6 without updating the 
Docker plugin (potentially huge changes). Being stuck is not a good place. I 
see two paths out of this:

1) We buckle down and fix the tests so they can run in parallel via the normal 
forking mechanism of Gradle. I know some effort has been expended in this by 
using our new rules for starting servers. We should need to go further.

2) Fully invest in the Docker plugin. We would need to fork this off as a fully 
maintain sub-project of Geode. We would need to add to it support for both 
Gradle 6 and JUnit 5.

My money is on fixing the tests. It is clear, at least from my exhaustive 
searching, nobody in the Gradle and JUnit communities are isolating their tests 
with containers. They are creating containers to host service for system level 
testing, see Testcontainers project. The tests themselves run in the local 
kernel space (not in container).

We made this push in the C++ and .NET tests, a much smaller set of tests, and 
it works great. The framework takes care to create clusters that do not 
interact with each other on the same host. Some things in Geode make this 
harder than others, like http service not support ephemeral port selection, and 
gfsh not providing machine readable output about ephemeral port selections. We 
use port knocking to prevent the OS from assigning the port ephemerally to 
another process. The framework knocks, opens and then closes, all the ports it 
needs for the server/locator services and starts them explicitly on those 
ports. Because of port recycling rules in the OS another ephemeral port request 
won’t get those ports for some time after they are closed. It's not perfect but 
it works. Fixing Geode to support ephemeral port selection and a better 
reporting mechanisms for those port choices would be more ideal. Also, we only 
start services necessary for the test, like don’t start the http ports if they 
aren’t going to be used.

I would love some feedback and thoughts on this issue. Does anyone else see a 
different path forward?

-Jake

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

[Donal Evans]

+1

From: Owen Nichols 
Sent: Monday, June 29, 2020 10:35 AM
To: dev@geode.apache.org 
Subject: Re: [Proposal] Back-port doc fixes to support/1.13

+1

On 6/29/20, 10:32 AM, "Jinmei Liao"  wrote:

+1, yay to doc changes.

From: Dave Barnes 
Sent: Monday, June 29, 2020 10:30 AM
To: dev@geode.apache.org 
Subject: [Proposal] Back-port doc fixes to support/1.13

These five doc changes correct doc bugs and format errors that have caused
users pain. I propose that we back-port them to support/1.13:

GEODE-8193: Broken link in statistics list

GEODE-7956, GEODE-7519: Docs should mention dot as a valid region name
character

GEODE-8304: Better highlight steps for building documentation

GEODE-8237: Add note about 'alter region' and cluster conf service in doc

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

[Donal Evans]

When restore-redundancy was first proposed, the question was asked whether a 
REST api would be part of that, and the answer was an emphatic "no" (largely 
due to the continuing "experimental" labeling on the REST API, as I recall).  
So I reject that argument that this is about "including the entire feature"
The "no" regarding the inclusion of a REST api was specifically referring to 
the inclusion of that api's design in the RFC for the restore redundancy 
feature, not whether a REST api for it should exist at all. From the RFC: "It 
is also not within the scope of this RFC to describe any REST API that may be 
created at a future point in 
time."[1]<https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands#RedundancyGfshCommands-Anti-Goals>
 It was always intended to create a REST api for the restore redundancy 
feature, but it was outside of the scope of my knowledge at the time the RFC 
was created to describe it fully there, so the decision was to move forward 
with the "partial" RFC rather than get bogged down in fully describing every 
facet of the feature before beginning implementation.

As for the risk associated with this last stage of the restore redundancy 
feature, as far as I can tell, it's very low. The core changes are already in 
the 1.13 release branch, and have been since mid May, with no issues found 
since then. The proposed changes to be backported to the 1.13 release branch 
merely expose the REST endpoints associated with those changes, and don't touch 
core Geode at all, as far as I'm aware.

[1] 
https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands#RedundancyGfshCommands-Anti-Goals

From: Owen Nichols 
Sent: Friday, June 26, 2020 2:09 PM
To: dev@geode.apache.org 
Subject: Re: [Proposal] Add REST command for Restore Redundancy to 1.13 
(GEODE-8095)

When restore-redundancy was first proposed, the question was asked whether a 
REST api would be part of that, and the answer was an emphatic "no" (largely 
due to the continuing "experimental" labeling on the REST API, as I recall).  
So I reject that argument that this is about "including the entire feature"

Our "critical fixes rule" notes that our quarterly release cadence ensures that 
there is always an upcoming release vehicle for new features -- we will be 
cutting support/1.14 in just a few weeks on Aug 3.  Can you make the case that 
this feature is critical to release sooner?  As I understand it this feature is 
just an optimization -- existing code can already use the rebalance API to 
restore redundancy, it just might take a little longer.

That said, all you need is three votes, so make your case.  Especially as we 
are already 8 weeks past the branch cut of support/1.13, and hopefully getting 
very close to an RC1, concern about risk weighs on my mind more than the 
merits.  What level of testing has this been through?  Does it touch core code? 
 You may be able to get the votes just by demonstrating that the risk is very 
low.

I'm a +0 for this based on the information presented so far.

On 6/26/20, 11:50 AM, "Donal Evans"  wrote:

+1

Although normally features wouldn't really count as "critical fixes" that 
would warrant inclusion after the release branch has been cut, in this case, 
the internal API and gfsh commands for restore redundancy are already in the 
release, and it makes much more sense to include the entire feature in one 
release rather than having a semi-complete feature in 1.13 and forcing the REST 
component to wait for a later release.

From: Mark Hanson 
Sent: Friday, June 26, 2020 10:06 AM
To: dev@geode.apache.org 
Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 
(GEODE-8095)

Hello All,

The core of the restore redundancy call structure has been refactored to 
allow there to be a REST call to invoke a restore redundancy. At this point, 
looking forward to the 1.13 release it would be great if we could fit this into 
the 1.13 release.

What do people think?

Thanks,
Mark

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

[Donal Evans]

+1

Although normally features wouldn't really count as "critical fixes" that would 
warrant inclusion after the release branch has been cut, in this case, the 
internal API and gfsh commands for restore redundancy are already in the 
release, and it makes much more sense to include the entire feature in one 
release rather than having a semi-complete feature in 1.13 and forcing the REST 
component to wait for a later release.

From: Mark Hanson 
Sent: Friday, June 26, 2020 10:06 AM
To: dev@geode.apache.org 
Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

Hello All,

The core of the restore redundancy call structure has been refactored to allow 
there to be a REST call to invoke a restore redundancy. At this point, looking 
forward to the 1.13 release it would be great if we could fit this into the 
1.13 release.

What do people think?

Thanks,
Mark

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

[Donal Evans]

+1

From: Owen Nichols 
Sent: Friday, June 26, 2020 9:59 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12

+1

On 6/26/20, 7:58 AM, "Ju@N"  wrote:

+1

On Fri, 26 Jun 2020 at 15:51, Bruce Schuchardt  wrote:

> This small fix avoids a failure of one cluster to communicate with the
> locators of another cluster, ensuring that a proper handshake for WAN
> communications occurs.  Without the fix it’s possible that WAN connections
> will not be formed and updates will not be transmitted between sites.
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5306data=02%7C01%7Cdoevans%40vmware.com%7Cf0fdfd0e9f3f4d1225c508d819f24b53%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637287875728618402sdata=ROQYORRw357JRmVBW3gCxRFoptOz%2F%2Fg6oEMoRN4vrhg%3Dreserved=0
>
>

--
Ju@N

Re: [PROPOSAL] Add windows jobs to PR checks

[Donal Evans]

+1

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

From: Jinmei Liao 
Sent: Thursday, June 25, 2020 10:01 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Add windows jobs to PR checks

+1, what was the reason for it not being included the PR before?

From: Dick Cavender 
Sent: Thursday, June 25, 2020 9:54 AM
To: dev@geode.apache.org 
Subject: RE: [PROPOSAL] Add windows jobs to PR checks

+1

-Original Message-
From: Owen Nichols 
Sent: Thursday, June 25, 2020 9:38 AM
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] Add windows jobs to PR checks

+1 for adding all JDK11 Windows tests to PR pipeline.

On 6/25/20, 9:29 AM, "Kirk Lund"  wrote:

I merged some new AcceptanceTests to develop after having my PR go GREEN.
But now these tests are failing in Windows.

I'd like to propose that we add the Windows jobs to our PR checks if we
plan to keep testing on Windows in CI.

Please vote or discuss.

Thanks,
Kirk

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

[Donal Evans]

+1

From: Nabarun Nag 
Sent: Friday, June 19, 2020 12:15 PM
To: dev@geode.apache.org 
Subject: [VOTE] Backporting of GEODE-8261 to 1.13 release branch.

Hi Geode devs,

Requesting vote to backport of GEODE-8261 to 1.13

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

SHA
720a4caea2ddb22296aa3225fc5264d2096cdf20


Regards
Nabarun

Re: Refactor to Restore Redundancy Command for 1.13?

[Donal Evans]

+1 for getting the feature fully implemented in one release rather than 
spreading it out over 2.

From: Mark Hanson 
Sent: Monday, June 15, 2020 1:23 PM
To: dev@geode.apache.org 
Subject: Refactor to Restore Redundancy Command for 1.13?

Hi All,

So we are working on refactoring the Restore Redundancy gfsh command code and 
we have made a change to a class that is getting serialized. We are curious if 
this is something we could maybe get into 1.13 ( the first release of this 
command? Or should we just make our serialization/deserialization work for 2 
versions?

Thanks,
Mark

Re: No more hardcoded region separators!

[Donal Evans]

Sadly not, unless it was incredibly convoluted and complex. There are plenty of 
String literal "/" still in the codebase, in URIs/URLs, filepaths and log 
output (for example "Updated 5/6 values") so it's not really possible to 
determine if the presence of a "/" is "correct" without looking at the actual 
code and how it's used.

From: Murtuza Boxwala 
Sent: Thursday, May 28, 2020 10:37 AM
To: dev@geode.apache.org 
Subject: Re: No more hardcoded region separators!

Is there any way to enforce that with some kind of LGTM or spotless rule?

On 5/28/20, 12:46 PM, "Donal Evans"  wrote:

I'm happy to say that as of about 5 minutes ago, there are no uses of 
hardcoded "/" in region paths/names in the geode codebase, as all of them have 
been replaced by the Region.SEPARATOR constant (with the exception of a few 
occurrences in the geode-management module, which while not having an explicit 
dependency on geode-core has implicit dependencies on some things like the 
region separator, index types etc). I'd like to request that going forward, we 
maintain this convention of only using Region.SEPARATOR and avoid introduction 
of any new hardcoded "/" characters in code pertaining to region paths or 
names, both in our own commits and in commits we review from other developers.

Re: No more hardcoded region separators!

[Donal Evans]

Thanks for the suggestion, Dave. I'll be sure to add something soon.

From: Dave Barnes 
Sent: Thursday, May 28, 2020 10:32 AM
To: dev@geode.apache.org 
Subject: Re: No more hardcoded region separators!

Excellent, Donal!
If you have not already done so, please consider documenting the practice
you're advocating in a place where all community contributors have a chance
of seeing it. Maybe
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FHow%2Bto%2BContributedata=02%7C01%7Cdoevans%40vmware.com%7Cff0d3580ae404c540c9a08d8032d27ad%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637262839764198680sdata=CattsXf3p8X%2BiFalU2uu9be6nxdzLkJ4dXCfL7tE0ec%3Dreserved=0?

On Thu, May 28, 2020 at 9:46 AM Donal Evans  wrote:

> I'm happy to say that as of about 5 minutes ago, there are no uses of
> hardcoded "/" in region paths/names in the geode codebase, as all of them
> have been replaced by the Region.SEPARATOR constant (with the exception of
> a few occurrences in the geode-management module, which while not having an
> explicit dependency on geode-core has implicit dependencies on some things
> like the region separator, index types etc). I'd like to request that going
> forward, we maintain this convention of only using Region.SEPARATOR and
> avoid introduction of any new hardcoded "/" characters in code pertaining
> to region paths or names, both in our own commits and in commits we review
> from other developers.
>

No more hardcoded region separators!

[Donal Evans]

I'm happy to say that as of about 5 minutes ago, there are no uses of hardcoded 
"/" in region paths/names in the geode codebase, as all of them have been 
replaced by the Region.SEPARATOR constant (with the exception of a few 
occurrences in the geode-management module, which while not having an explicit 
dependency on geode-core has implicit dependencies on some things like the 
region separator, index types etc). I'd like to request that going forward, we 
maintain this convention of only using Region.SEPARATOR and avoid introduction 
of any new hardcoded "/" characters in code pertaining to region paths or 
names, both in our own commits and in commits we review from other developers.

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

[Donal Evans]

I'm fine with leaving the geode-management module out of this refactor and
leaving the SEPARATOR definition inside the Region interface in geode-code
if that's what's best to maintain proper modularity. However, looking at
the geode-management module, there is already a Region class which has
methods to strip "/" from the start of region paths, an Index class which
does the same, and RegionType and IndexType Enums which are basically
reimplementations of the RegionShortcut and IndexType classes in
geode-core, so it looks like if we want to have it so that the only module
that knows about Region internals is geode-core, then there's potentially
some amount of work to be done to make that happen.

On Mon, May 18, 2020 at 10:16 AM Udo Kohlmeyer  wrote:

> I was wondering. Why do we require to add this Region.SEPERATOR to be
> anywhere outside of Region.
>
> Geode-management was purposefully designed NOT to have a dependency on
> core. Creating a new dependency on a donor module, just means that
> management module will now start knowing about geode.
>
> I suggest if you want to make sure that management also uses a common
> Region.SEPARATOR, then maybe create a class inside of management for now OR
> we have to look at management to better understand WHY it requires this
> knowledge and if there could not be a different implementation to avoid
> creating a new donor project.
>
> The whole idea behind modularity is that modules don't expose their
> internals. The Region Separator is REGION specific. That knowledge should
> be kept there. It should not be proliferated around or moved into a
> "common" module, just because there is a leak.
>
> @Donal you are closest to the code, but would it maybe not make more sense
> to just define that constant and maybe raise a JIRA so that we can address
> this "leakage" at a later stage?
>
> --Udo
> 
> From: Jacob Barrett 
> Sent: Saturday, May 16, 2020 11:02 PM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] Move definition of Region separator character to
> geode-common
>
> Probably. Unfortunately we haven’t been very good and cleaning these up
> and moving forward with a Java modules plan. It’s gunna bite us.
>
> > On May 16, 2020, at 8:08 PM, Donal Evans  wrote:
> >
> > In that case, would it also make sense to move the existing
> GeodeGlossary
> > class to org.apache.geode.common.internal, from its current location in
> > org.apache.geode.util.internal?
> >
> >> On Sat, May 16, 2020 at 8:02 PM Jacob Barrett 
> wrote:
> >>
> >> I am fine as long as you make sure you use a package name that is going
> to
> >> be Java 9 modules safe. Two modules cannot export the same package. So
> if
> >> geode-commons is going to export org.apache.geode.util I think we will
> have
> >> collisions. I suggest org.apache.geode.common.
> >>
> >> -Jake
> >>
> >>
> >>>> On May 16, 2020, at 1:23 PM, Donal Evans  wrote:
> >>>
> >>> I've recently been working on a little side project to replace every
> use
> >> of
> >>> a hardcoded "/" character in region names/paths with a reference to the
> >>> Region.SEPARATOR constant. I ran into some problems though, since the
> >>> geode-management module needs to know about the separator character (in
> >> the
> >>> Region and Index classes) but does not have a dependency on geode-core,
> >>> where the character is currently defined.
> >>>
> >>> Since the whole point of the exercise is to attempt to provide a single
> >>> place where the region separator character is defined, pulling the
> >>> definition down into a module upon which both geode-core and
> >>> geode-management depend seems like the sensible choice, so I'm
> proposing
> >> to
> >>> create a GeodePublicGlossary class (name entirely up for change) in the
> >>> geode-common/src/main/java/org/apache/geode/util/ package, moving the
> >>> definition there, then deprecating the definitions in the Region
> >> interface
> >>> in geode-core.
> >>>
> >>> To preempt a possible question, there already exists a GeodeGlossary
> >> class
> >>> (which defines the GEMFIRE_PREFIX constant), but it's in an internal
> >>> package, so isn't a suitable place to move the definition of the
> >> currently
> >>> user-visible region separator character.
> >>>
> >>> Any feedback or suggestions on this idea would be very welcome.
> >>
> >>
>

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

[Donal Evans]

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

The changes touch 880 files, so the PR is broken up by module/package, in
case anyone really wants to review specific areas, but the main structural
changes can be found in the first commit

in
the PR.

To verify that all changes are correct and that no instances of "/" in
region names/paths have been missed, I replaced the character in
GeodePublicGlossary with a "~", updated oql.g to allow queries to be
correctly parsed using the new character, and ran all tests on a draft PR
branch. All failing tests were either directly comparing the region
separator to "/", creating caches from XML files containing regions/indexes
using "/," or involved older client/server versions which would not be
compatible with the changed separator, so I am confident that no non-region
slashes have been changed, and none missed.

Hopefully, if this PR is approved and merged, we can establish a totally
consistent convention of always using the constant in region names/paths
going forward.

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

[Donal Evans]

In that case, would it also make sense to move the existing GeodeGlossary
class to org.apache.geode.common.internal, from its current location in
org.apache.geode.util.internal?

On Sat, May 16, 2020 at 8:02 PM Jacob Barrett  wrote:

> I am fine as long as you make sure you use a package name that is going to
> be Java 9 modules safe. Two modules cannot export the same package. So if
> geode-commons is going to export org.apache.geode.util I think we will have
> collisions. I suggest org.apache.geode.common.
>
> -Jake
>
>
> > On May 16, 2020, at 1:23 PM, Donal Evans  wrote:
> >
> > I've recently been working on a little side project to replace every use
> of
> > a hardcoded "/" character in region names/paths with a reference to the
> > Region.SEPARATOR constant. I ran into some problems though, since the
> > geode-management module needs to know about the separator character (in
> the
> > Region and Index classes) but does not have a dependency on geode-core,
> > where the character is currently defined.
> >
> > Since the whole point of the exercise is to attempt to provide a single
> > place where the region separator character is defined, pulling the
> > definition down into a module upon which both geode-core and
> > geode-management depend seems like the sensible choice, so I'm proposing
> to
> > create a GeodePublicGlossary class (name entirely up for change) in the
> > geode-common/src/main/java/org/apache/geode/util/ package, moving the
> > definition there, then deprecating the definitions in the Region
> interface
> > in geode-core.
> >
> > To preempt a possible question, there already exists a GeodeGlossary
> class
> > (which defines the GEMFIRE_PREFIX constant), but it's in an internal
> > package, so isn't a suitable place to move the definition of the
> currently
> > user-visible region separator character.
> >
> > Any feedback or suggestions on this idea would be very welcome.
>
>

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

[Donal Evans]

I've recently been working on a little side project to replace every use of
a hardcoded "/" character in region names/paths with a reference to the
Region.SEPARATOR constant. I ran into some problems though, since the
geode-management module needs to know about the separator character (in the
Region and Index classes) but does not have a dependency on geode-core,
where the character is currently defined.

Since the whole point of the exercise is to attempt to provide a single
place where the region separator character is defined, pulling the
definition down into a module upon which both geode-core and
geode-management depend seems like the sensible choice, so I'm proposing to
create a GeodePublicGlossary class (name entirely up for change) in the
geode-common/src/main/java/org/apache/geode/util/ package, moving the
definition there, then deprecating the definitions in the Region interface
in geode-core.

To preempt a possible question, there already exists a GeodeGlossary class
(which defines the GEMFIRE_PREFIX constant), but it's in an internal
package, so isn't a suitable place to move the definition of the currently
user-visible region separator character.

Any feedback or suggestions on this idea would be very welcome.

Re: 1.13 potential change

[Donal Evans]

I'm also bad at using my eyes, apparently. The PR was right there in the
list of open ones. I don't know how I missed it.

On Fri, May 15, 2020 at 4:59 PM Anthony Baker  wrote:

> https://github.com/apache/geode/pull/5110
>
> Sorry, I’m bad at emailing today.
>
> On May 15, 2020, at 4:28 PM, Donal Evans  doev...@pivotal.io>> wrote:
>
> Is there a link to the PR in question? I don't see anything on GitHub.
>
> On Fri, May 15, 2020 at 4:23 PM Anthony Baker  bak...@vmware.com>> wrote:
>
> Whoops, this got stuck on the wrong thread.  Resending.
>
> We’re continuing to investigate some compatibility issues; there may be
> further changes needed.
>
>
> Anthony
>
>
> On May 15, 2020, at 11:46 AM, Anthony Baker  bak...@vmware.com>> wrote:
>
> Barry and I tossed up a draft PR to fix a problem in session state
> replication with Tomcat.  If we can get this completed I’d like to include
> it with v1.13.0.  I believe our tests will fail with any version of Tomcat
> after 9.0.21.
>
> Anthony
>
>
> On May 15, 2020, at 1:27 AM, Ju@N  jujora...@gmail.com>> wrote:
>
> +1
>
> On Thu, 14 May 2020 at 22:19, Mark Hanson  mhan...@pivotal.io>> wrote:
>
> +1. The more we can automate this types of checks the better.
>
> Thanks,
> Mark
>
>
>
> --
> Ju@N
>
>
>
>
>

Re: 1.13 potential change

[Donal Evans]

Is there a link to the PR in question? I don't see anything on GitHub.

On Fri, May 15, 2020 at 4:23 PM Anthony Baker  wrote:

> Whoops, this got stuck on the wrong thread.  Resending.
>
> We’re continuing to investigate some compatibility issues; there may be
> further changes needed.
>
>
> Anthony
>
>
> > On May 15, 2020, at 11:46 AM, Anthony Baker  wrote:
> >
> > Barry and I tossed up a draft PR to fix a problem in session state
> replication with Tomcat.  If we can get this completed I’d like to include
> it with v1.13.0.  I believe our tests will fail with any version of Tomcat
> after 9.0.21.
> >
> > Anthony
> >
> >
> >> On May 15, 2020, at 1:27 AM, Ju@N  wrote:
> >>
> >> +1
> >>
> >> On Thu, 14 May 2020 at 22:19, Mark Hanson  wrote:
> >>
> >>> +1. The more we can automate this types of checks the better.
> >>>
> >>> Thanks,
> >>> Mark
> >>>
> >>>
> >>
> >> --
> >> Ju@N
> >
>
>

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

[Donal Evans]

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: [DISCUSS] enable GitHub PR blocking on API breaking changes

[Donal Evans]

Given that this job takes less than 10 minutes to run, pass or fail, I
don't see it adding any additional friction to the PR process in terms of
having to wait for things to finish. I am curious if there are any
circumstances we could envisage where skipping or bypassing this check
would be warranted though, and what the procedure would be in those cases.
For example, how would it handle the removal of a deprecated method from an
API? It's not something that happens often, but it will happen eventually
(I would hope).

On Wed, May 13, 2020 at 2:32 PM Robert Houghton 
wrote:

> 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: [PROPOSAL] Merge PR 5103 (GEODE-8083) to support/1.13

[Donal Evans]

+1 Having parity between develop and support branches in terms of
checks/tests seems like a sensible idea.

On Tue, May 12, 2020 at 4:05 PM Owen Nichols  wrote:

> I see that ApiChecker PR Check <
> https://concourse.apachegeode-ci.info/builds/156385> is passing for 1.13
> so it’s a +1 from me!
>
> > On May 12, 2020, at 3:57 PM, Robert Houghton 
> wrote:
> >
> > This is a squash of GEODE-8083 and 8087, to bring the Java  API
> comparison
> > jobs from Gradle and Concourse to the support branch. Currently runs
> > cleanly from my terminal, and has been green on develop for a week or so.
> >
> > @Dave Barnes  , as release manager, what say you?
>
>

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

[Donal Evans]

+1

On Mon, May 11, 2020 at 4:11 PM Anilkumar Gingade 
wrote:

> +1
>
> On Mon, May 11, 2020 at 4:10 PM Jinmei Liao  wrote:
>
> > https://issues.apache.org/jira/browse/GEODE-8091
> >
> > We've had users that were trying to use the
> > "--load-cluster-configuration-from-dir=true" when starting up a locator
> > with a security manager and came across this failure on Geode1.12 and
> would
> > this to be fixed. Can I get a few +1s to port this back to the support
> > branches?
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: Over usage of @SuppressWarnings

[Donal Evans]

>
> You can disable inspection for a warning that is otherwise benign...
>

Is there a consensus on what constitutes a benign warning? I think the only
times I use @SuppressWarnings is in parameterized tests to suppress the
unused method warning for the parameters method, or for unchecked casts, as
below:

 PartitionedRegion detailRegion1 = mock(PartitionedRegion.class);
 when(cache.getRegion(regionPath1)).thenReturn(detailRegion1);

where the thenReturn() would complain, since it's expecting to return a
Region.

Would these be considered things that could safely just be ignored (and so
for which I can turn off inspection), or is the use of @SuppressWarnings
here warranted?

On Fri, May 8, 2020 at 11:58 AM John Blum  wrote:

> Let's try this again :P.
>
> +1 to Kirk's comments.  Plus...
>
> Another tip (for IJ IDEA users, probably same for Eclipse and other IDEs):
>
> You can disable inspection for a warning that is otherwise benign (or not
> correct) *rather than* unnecessarily annotating the code with
> @SuppressWarnings.
>
> However, disable inspections judiciously.  Warnings in code are telling you
> something that needs to be paid attention to and disabling the warning with
> (@SuppressWarnings) or disabling the inspection makes it easy to lose sight
> that the warning is there when the code is revisited.
>
> -j
>
>
> On Fri, May 8, 2020 at 11:55 AM Jacob Barrett  wrote:
>
> > I submitted and PR a while ago that started making warnings errors on
> > certain modules. Through lazy consensus it was approved and merged. I
> would
> > love to apply it to more. To set a baseline, I tried to fix most of the
> > deprecated and other warnings as possible in the effected code. Many were
> > so bad off that to just keep from getting worse I marked some
> suppressions.
> > I tried to isolate to single statements, often by extracting the
> offending
> > line out into its own method and annotating it.
> >
> > Prior to this almost ever bit of free space in the warning/error gutter
> in
> > IntelliJ was take up by these warnings. The hope was by making them
> errors,
> > fixing most and suppressing where necessary that it wouldn’t get any
> worse.
> > It was hoped it would be signal to the next person in there deprecating
> > something, using generics, or whatever, to do it right and clean up the
> > effected code too. Just suppressing errors because you want to get it
> done
> > is not a good practice. Effort should be taken and only as a last resort
> > should something be suppressed That suppression should be limited to the
> > smallest possible set of statements, which may mean extracting a bit fo
> > code into a method.
> >
> > We most definitely should make it so we don’t add anymore suppressions
> but
> > absolutely not at the expense of allowing warnings. The code should be
> > fixed or refactored to remove the suppression.
> >
> > -Jake
> >
> >
> > > On May 8, 2020, at 11:45 AM, Kirk Lund  wrote:
> > >
> > > I'm reviewing lots of PRs which are
> > > adding @SuppressWarnings("deprecation"), etc. I think this is a bad
> > trend.
> > > We should not be suppressing warnings in our code. That's hiding a
> > problem
> > > that we'll need to or want to deal with in the future. Also, if you add
> > > several of these suppress annotations into a class or a method or a
> test,
> > > it really diminishes the readability. It adds noise and suppresses
> valid
> > > warnings.
> > >
> > > On one of Jinmei's PRs, she responded saying she has to add these to
> her
> > > code because of some change that Jake made to the build. Can we make it
> > so
> > > we don't have to add these suppressions?
> > >
> > > Thanks,
> > > Kirk
> >
> >
>
> --
> -John
> Spring Data Team
>

Re: [DISCUSS] Geode Redis API Improvements

[Donal Evans]

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

On Thu, May 7, 2020 at 8:35 AM Raymond Ingles  wrote:

> Just a quick nudge - we set a deadline for comments for tomorrow. Anyone
> had a chance to look this over yet? Thanks!
>
> On Thu, Apr 30, 2020 at 2:09 PM Raymond Ingles  wrote:
>
> > Hi all,
> >
> > The current Redis API support in Geode has been marked experimental for a
> > couple years and has several bugs and inconsistencies compared to native
> > Redis. We created a RFC for updating the Geode Redis API support, to
> > address issues in the implementation, improve performance and add High
> > Availability support.
> >
> > Please review and comment by 5/8/2020.
> >
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+API+Improvements
> >
> > Thanks!
> >
>

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

[Donal Evans]

+1

From: Dick Cavender 
Sent: Thursday, May 7, 2020 8:52 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

+1

On Thu, May 7, 2020 at 7:47 AM Ju@N  wrote:

> Hello devs,
>
> I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and
> *support/1.13* branches.
> The bug was introduced in Geode 1.8.0 and, long story short, prevents
> locators from gracefully shutting down whenever a rebalance operation is
> launched from gfsh (doesn't matter whether the rebalance is successful or
> not).
> The fix has been merged into develop through commit
> d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
> Best regards.
>
> [1]: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8071data=02%7C01%7Cdoevans%40vmware.com%7Cf6695e01cedc47f5fb5308d7f29eae55%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244635652121432sdata=pc%2BpNBYlK6M1QP%2BTBH4GLRO2JYwhuDp%2BdbY1UVS4BHo%3Dreserved=0
> [2:]
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2Fd8e86cb720c054b154a16cc88fee88e73db709f3data=02%7C01%7Cdoevans%40vmware.com%7Cf6695e01cedc47f5fb5308d7f29eae55%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244635652121432sdata=f008tzyxlF7X%2FDwPhoMg4Z6n%2Foc6BtkkMo8ea5T2Xjk%3Dreserved=0
>
> --
> Ju@N
>

PR Review

[Donal Evans]

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

It'll be a very tedious process, but if anyone would be willing to check it
over and approve it (or reject it, if there are problems with it I haven't
foreseen) I'd be very appreciative. I should also point out that this
wasn't an attempt to replace ALL uses of hardcoded slashes in region paths,
just those occurrences where the "/" string is used. A second pass to
replace all uses of slashes in region paths with the Region.SEPARATOR
constant may follow if I'm feeling particularly masochistic one weekend.