Re: [DISCUSS] Move geode to the attic

[Owen Nichols]

Once moved to the attic, it sounds like:

  *   The geode github repo would become read-only (but remain world-readable 
in perpetuity).
  *   Geode would no longer be available for download on the geode download 
site or mirrors (but still available in releases tab in github).
  *   Geode maven artifacts would remain available from mavencentral.
  *   Geode homebrew formula would no longer be installable.
  *   Unsure whether apachegeode/geode docker image would remain available?
  *   Geode confluence wiki would become read-only.
  *   It sound like the user mailing list may be able to remain active?

Since no further release are possible without at least 3 active PMC members to 
provide the requisite 3 approving PMC votes, the Attic sounds like the best 
possible way to leave things.

From: Dan Smith 
Date: Tuesday, October 18, 2022 at 11:12 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Move geode to the attic
⚠ External Email

Hi folks,

Unfortunately, it is time to consider moving Geode to the Apache attic. After 
VMware's announcement that it will stop contributing to Geode, we've tried in 
the last couple months to recruit additional contributors to continue 
supporting the project [1]. However, this last week there was a PMC role call 
on the private list and it appears we will only have one active PMC member 
after the VMware folks completely leave.

I think at this point the responsible thing to do is dissolve the Geode PMC and 
move the project to the attic, unless some new contributors suddenly show up. 
We need a minimum of 3 PMC members to keep the project viable.

This is not yet a vote. I'll let this discussion run this week and start a vote 
next week. I believe even if we vote to dissolve the project and move to the 
attic, the soonest that process would start would be after the November board 
meeting [2].

Thanks,
-Dan

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fd88byb42gm5wplzqwkgywg3w9vtj64dr&data=05%7C01%7Conichols%40vmware.com%7C2a9ffaff8f8340e4e34008dab13441f4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638017135262081632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4q17vohWzXAM0IautFzOrJ504aHVbUHBM7UMqt88Nik%3D&reserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fattic.apache.org%2Fprocess.html&data=05%7C01%7Conichols%40vmware.com%7C2a9ffaff8f8340e4e34008dab13441f4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638017135262081632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=50%2FSaECQGRe0%2BkvN3AGiD%2B1JP8J8tiWvzeY0xgAW0R8%3D&reserved=0




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

[ANNOUNCE] Apache Geode 1.15.1

[Owen Nichols]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.15.1.

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

Apache Geode 1.15.1 contains a number of bug fixes.
Users are encouraged to upgrade to this last release.
For the full list of changes please review the release notes at:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.15.1

Release artifacts and documentation can be found at the project website:
https://geode.apache.org/releases/
https://geode.apache.org/docs/guide/115/about_geode.html

We would like to thank all the contributors that made the release possible.
Regards,
Mario Kevo and Owen Nichols on behalf of the Apache Geode team

Re: [RESULT][VOTE] Apache Geode 1.15.1.RC1

[Owen Nichols]

Sure thing, I will sign the v1.15.1 tag.  All other release artifacts will be 
what was voted on (those created and signed by Mario).  Expect release 
announcement later today.

From: Anthony Baker 
Date: Monday, October 10, 2022 at 11:30 AM
To: dev@geode.apache.org 
Cc: Owen Nichols 
Subject: [RESULT][VOTE] Apache Geode 1.15.1.RC1
The vote passes with 3 binding +1 votes.

@Owen - could you help finalize the release?

Thanks,
Anthony

Re: Release manager permissions

[Owen Nichols]

Hi Mario, a basic concourse installation[1] needs a database (e.g. Postgres), 
the concourse web service, and 1 or more concourse workers.  A secrets store 
like Vault is also recommended.  These don’t have to be especially beefy (if 
hosting in GCP, something like gcp n2-standard-4 is fine).  Baseline operating 
costs for a concourse deployment could range from $100-1000 per month depending 
on what hardware or cloud provider is used and how many workers are used.

Geode pipeline jobs spawn additional instances in GCP to actually execute the 
tests.  The CPU, RAM, and disk specs for these machines are defined in geode/ci 
[2] and some jobs use as many as 96 CPUs for parallel execution.  In total, 
these spot instances cost on the order of $25 per PR commit + $75 per PR merged.

[1] https://concourse-ci.org/install.html
[2] 
https://github.com/apache/geode/blob/develop/ci/pipelines/shared/jinja.variables.yml

From: Mario Kevo 
Date: Tuesday, September 27, 2022 at 6:41 AM
To: dev@geode.apache.org 
Subject: Odg: Release manager permissions
⚠ External Email

Hi Anthony,

I have a question regarding CI.
I saw the file in the geode repo with some values for machines on which tests 
are executed. 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fe2ac1113f8f6819095785be556bef8e080ab6988%2Fci%2Fpipelines%2Fshared%2Fjinja.variables.yml%23L92&data=05%7C01%7Conichols%40vmware.com%7C31a853c3aad94f48e55508daa08e079f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637998829122537833%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rXjrDcVdEuU62xVMR%2FHZr8%2FAZVZVGUYTY61R4x2Qw%2BY%3D&reserved=0

So I have a question, what is the setup now that it is used on Concourse CI?
Do you have one or more machines(and how many) so tests can be executed in 
parallel? How many CPUs, RAM and disk sizes are used for them?

Thanks and BR,
Mario

Šalje: Alberto Gomez 
Poslano: 27. rujna 2022. 13:12
Prima: dev@geode.apache.org 
Predmet: Re: Release manager permissions

Hi,

Do you know if any company has offered to sponsor the CI pipelines? What would 
it take for such a company besides paying the bills? Would a migration be 
needed?

Regarding the old ASF Jenkins jobs, my understanding is that they would offer 
the same CI functionality as we have today, but they would be run on ASF 
provided resources which would most likely make the time to get results longer 
and less predictable. Is that correct?


Thanks,

Alberto

From: Anthony Baker 
Sent: Friday, September 23, 2022 8:15 PM
To: dev@geode.apache.org 
Subject: Re: Release manager permissions

Just a reminder to all: we need to find an alternative to the VMware-sponsored 
CI pipelines currently in use. Any ideas? Should we try to resurrect the old 
ASF Jenkins jobs?

Anthony

> On Sep 23, 2022, at 3:26 AM, Mario Kevo  wrote:
>
> ⚠ External Email
>
> Hi devs,
>
> I need the following permissions for the release manager:
>
>  *   bulk modification permission on Apache Geode JIRA
>  *   permission to deploy pipelines to Geode CI
>  *   Docker Hub credentials with permission to upload Apache Geode to Docker 
> Hub
>
> username: mkevo
> mail: mk...@apache.org
>
> Can someone give me these permissions, so I can start building a new patch 
> release?
>
> Thanks and BR,
> Mario
>
> 
>
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

Re: Release manager permissions

[Owen Nichols]

Hi Mario, you won’t need any Concourse permissions for Geode 1.15.x patch 
release(s) in the next two months, as the relevant “main”[1] and “rc”[2] 
pipelines already exist (just skip the deploy_rc_pipeline step).

[1] 
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-15-main
[2] 
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-15-rc

From: Mario Kevo 
Date: Sunday, September 25, 2022 at 11:42 PM
To: dev@geode.apache.org 
Subject: Odg: Release manager permissions
⚠ External Email

Hi Anthony,

I still don't have permission for Concourse. I logged in with a GitHub account 
and saw that I'm not authorized to run jobs.
Username: mkevo

The username for Docker Hub is the same: mkevo.

Thanks,
Mario


Šalje: Anthony Baker 
Poslano: 23. rujna 2022. 20:15
Prima: dev@geode.apache.org 
Predmet: Re: Release manager permissions

Just a reminder to all: we need to find an alternative to the VMware-sponsored 
CI pipelines currently in use. Any ideas? Should we try to resurrect the old 
ASF Jenkins jobs?

Anthony

> On Sep 23, 2022, at 3:26 AM, Mario Kevo  wrote:
>
> ⚠ External Email
>
> Hi devs,
>
> I need the following permissions for the release manager:
>
>  *   bulk modification permission on Apache Geode JIRA
>  *   permission to deploy pipelines to Geode CI
>  *   Docker Hub credentials with permission to upload Apache Geode to Docker 
> Hub
>
> username: mkevo
> mail: mk...@apache.org
>
> Can someone give me these permissions, so I can start building a new patch 
> release?
>
> Thanks and BR,
> Mario
>
> 
>
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

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

[Owen Nichols]

+1

In the case where someone isn’t sure who might be good to request a review 
from, GitHub seems to now have a reviewer-recommendation feature based on who 
has recently touched the files in the PR.  Non-committers can always email the 
dev list if help is needed.

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

+1 for getting rid of CODEOWNERS.

> On Jun 29, 2022, at 9:33 AM, Anthony Baker  wrote:
>
> ⚠ 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%2F7820&data=05%7C01%7Conichols%40vmware.com%7Cb5a2c412552c4149154f08da59eed142%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921179501621811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uqMJrZPsXE7GcJK2EwEEiul%2FhGCPLmyfUKC2x%2FhiStU%3D&reserved=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%2F7323&data=05%7C01%7Conichols%40vmware.com%7Cb5a2c412552c4149154f08da59eed142%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921179501778038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Aqjmm0EybFdmNlmC37nHgmCT50f%2B3NFcpOrtLEXBFwo%3D&reserved=0
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7749&data=05%7C01%7Conichols%40vmware.com%7Cb5a2c412552c4149154f08da59eed142%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921179501778038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1hlNbZin%2Btdw3cBr484dIRPRCmoYaVBbKRYcoiKLs1U%3D&reserved=0
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7664&data=05%7C01%7Conichols%40vmware.com%7Cb5a2c412552c4149154f08da59eed142%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921179501778038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ouqA09rGyTcgandMR2sS7%2BK901NO0tBAYR32aaAl5uI%3D&reserved=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.
>

[ANNOUNCE] Apache Geode 1.15.0

[Owen Nichols]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.15.0.

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

Apache Geode 1.15.0 contains a number of improvements and bug fixes,
including JDK 17 support.  Users are encouraged to upgrade to this last
release.
For the full list of changes please review the release notes at:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.15.0

Release artifacts and documentation can be found at the project website:
https://geode.apache.org/releases/
https://geode.apache.org/docs/guide/115/about_geode.html

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

Re: [VOTE] Apache Geode 1.15.0.RC1

[Owen Nichols]

Today is the announced deadline and we have enough votes to close the vote.

Voting status
==
+1: 3 binding votes
* Bill Burcham (PMC member)
* Donal Evans (PMC member)
* Dave Barnes (PMC member)

+0: zero votes

-0: zero votes

-1: zero votes

The voting meets the requirements of at least 3 PMC members with +1 votes and 
has the required majority of +1 votes.
Apache Geode 1.15.0.RC1 has passed the vote and we will finalize the release 
shortly.

Thanks everyone for the great work!

-Owen Nichols
Geode 1.15.0 Release Manager

From: Bill Burcham 
Date: Friday, June 17, 2022 at 2:35 PM
To: doev...@vmware.com.invalid 
Cc: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.15.0.RC1
⚠ External Email

+1

on macOS…

downloaded examples and verified they all run and pass

BUILD SUCCESSFUL in 18m 58s
267 actionable tasks: 267 executed

Downloaded Geode tarball and verified SHA on
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.15.0.RC1%2Fapache-geode-1.15.0-src.tgz.sha256&data=05%7C01%7Conichols%40vmware.com%7C3157d6fb18fd40f264a708da50a94705%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637910985227313110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lRp4e717EfVd3x8Gqk9SoOaX%2BMglahTIVImrUCL%2BRfE%3D&reserved=0
matches checksum on
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.15.0.RC1%2Fapache-geode-1.15.0-src.tgz&data=05%7C01%7Conichols%40vmware.com%7C3157d6fb18fd40f264a708da50a94705%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637910985227313110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3iIpIte9GdHywV4%2B2AENzRYMtiHuWJFgVu7ODTvUOzo%3D&reserved=0

Verified product build: ./gradlew build -x test

BUILD SUCCESSFUL in 4m 57s
525 actionable tasks: 517 executed, 8 from cache

Verified this this distributed test passed:

○ → ./gradlew :geode-core:distributedTest --tests
org.apache.geode.distributed.internal.P2PMessagingConcurrencyDUnitTest

> Task :combineReports
All test reports at
/Users/bburcham/Downloads/geode-1-15/apache-geode-1.15.0-src/build/reports/combined

BUILD SUCCESSFUL in 1m 22s
49 actionable tasks: 2 executed, 47 up-to-date

Verified that changes in latest commit:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.15.0.RC1&data=05%7C01%7Conichols%40vmware.com%7C3157d6fb18fd40f264a708da50a94705%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637910985227313110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=l7nef%2FWkV9OlvaiCAk0xcPPcctH9Q1W0oQsKE7C7CXE%3D&reserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2F1869f2c06681bb73de727d2080d76c6215db9fb9&data=05%7C01%7Conichols%40vmware.com%7C3157d6fb18fd40f264a708da50a94705%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637910985227313110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pfkF7gJevWjiriDSuB4LipTr%2FaOUh7I4acyQNpBeHPQ%3D&reserved=0

are represented in the downloaded source.

On Fri, Jun 17, 2022 at 10:35 AM Donal Evans 
wrote:

> +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.0&data=05%7C01%7Conichols%40vmware.com%7C3157d6fb18fd40f264a708da50a94705%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637910985227313110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SNdoKkmtvgaAAowCf7dQ97W3JwYBWGzYCq%2BDqHPH2Ik%3D&reserved=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%2F&data=05%7C01%7Conichols%40vmware.com%7C3157d6fb18fd40f264a708da50a94705%7Cb3

[VOTE] Apache Geode 1.15.0.RC1

[Owen Nichols]

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://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.15.0

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.15.0.RC1/

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

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

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

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

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

Regards
-Owen Nichols
1.15.0 Geode Release Manager

Re: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo

[Owen Nichols]

The Geode project comprises several repos already, include geode, 
geode-examples, geode-benchmarks, geode-native, and geode-kafka-connector, and 
geode-site, so it’s not unreasonable to add another.  However, we still release 
all at the same time, so any “code freeze” applies equally to all geode repos.

Conceptually, “code freeze” applies to *code we ship*.  Test-only or docs-only 
commits are welcome anytime. Actually, any commits are welcome at any time -- 
“freeze” just means the branch is tagged at the point in time the release 
manager creates RC1; any commits after that tag will simply become part of a 
future release (in the event we go to RC2, post-freeze commits may or may not 
be pulled into the current release, at the release manager’s discretion).

Although the User Guide source files are currently part of the Geode source 
release, most users probably find the published website [1] more convenient.  
In my opinion, it should be fine to publish improvements to the doc site 
post-release (taking care to exclude commits related to unreleased new 
features, if any)...would that resolve the issue?

> examples and usage guidelines can be finalized only AFTER the code, with all 
> its version numbers, naming conventions, etc, are in place.
Chasing a moving target is definitely be frustrating; luckily there are things 
we can all do to minimize it.  I’ve seen many PRs that update the docs at the 
same time as they change the product -- reviewers should check for this when 
reviewing any PR that affects a public API, config setting, etc.  We also cut 
the support branch well in advance of planned release date and limit changes on 
the support branch to critical fixes only.  Whenever necessary, anyone should 
feel free to file blocker tickets for missing/incorrect docs to ensure the 
release does not ship prematurely without meeting Geode’s standard of 
documentation.
[1] https://geode.apache.org/docs/

From: Dave Barnes 
Date: Tuesday, June 14, 2022 at 3:11 PM
To: jb...@vmware.com.invalid 
Cc: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo
⚠ External Email

John,
Thanks for acknowledging that docs are just as important as code!  As a
career tech-writer, the "docs=code" model appeals to me.
I get what you're saying, and have worked in environments where release
managers have enforced such constraints.
In this vein, the Geode code is well-supplied with embedded Javadoc
comments that behave exactly as you describe, providing a reference that is
updated as the code is updated.
The difference with a user guide (as opposed to reference material), is
that examples and usage guidelines can be finalized only AFTER the code,
with all its version numbers, naming conventions, etc, are in place.
Delaying code freeze until docs are complete, in my experience, engenders
feature-creep and introduces delays, often resulting in compromises that
allow the release to go out with mis-matched docs. IMO, a separate
user-guide repo promotes a better and more timely match-up between the
software and the user guide.


On Tue, Jun 14, 2022 at 1:15 PM John Blum  wrote:

> Personally, I believe doc is a critical component to any software project,
> especially a project like Apache Geode, and so, is the project really
> “complete “(or should thee codebase  really be frozen during a release) if
> the doc is not done or consistent yet?
>
> Having the doc be part of the source allows the doc to be (theoretically)
> in-sync with the codebase as it evolves, as it should be. On the other
> hand, with a separate repo, it does allow corrections or other alterations
> to be made at the risk of growing inconsistency, which is a huge impediment
> IMO. In Asciidoc, doc can even be based on the source in part (e.g.
> interfaces).
>
> Ideally, I don’t see code and doc being separate or even fundamentally
> different.
>
> This sounds more like a process problem and a workaround to a broken
> process, to me.
>
> $0.02
> -John
>
>
> From: Dave Barnes 
> Date: Tuesday, June 14, 2022 at 12:15 PM
> To: dev@geode.apache.org 
> Subject: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo
> ⚠ External Email
>
> I'd like to move the doc sources for the Geode User Guide from the code
> repo (
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode&data=05%7C01%7Conichols%40vmware.com%7C90f35f9a69e9429c221c08da4e52c542%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637908414805059869%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w%2FOjA9CKepainPMniHOjz0kJ5TZE7VCFOetwcIojwsE%3D&reserved=0)
> to a separate geode-docs repo.
>
> The primary reason is to allow docs to cycle at their own rate, rather than
> in lock-step with the code. The present arrangement causes problems during
> releases, when code is frozen (including doc sources) to prepare a release
> candidate. This is exactly the time wh

Re: [PROPOSAL] re-cut support/1.15

[Owen Nichols]

Hello Geode Community, counting the labels in Jira I see:

May 6: 1 needsTriage and 2 blocks-1.15.0.
May 20: 0 needsTriage and 3 blocks-1.15.0.
June 8: 0 needsTriage and 0 blocks-1.15.0. Yay!

At this time, please consider support/1.15 “frozen”.  If there are any further 
changes needed, in addition to adding one of the labels above, please also 
email the dev list, otherwise I will soon begin preparing RC1 for voting next 
week.

-1.15.0 Release Manager

From: Owen Nichols 
Date: Monday, May 9, 2022 at 10:31 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] re-cut support/1.15
** The support/1.15 branch has now been (re)cut and develop is now 1.16. **

Please use your best judgement in determining what to backport.

PRs against support/1.15 are welcome (but optional!).  Committers should merge 
their own PRs.

If your backport will take some while, add the "blocks-1.15.0" label in Jira.

From: Owen Nichols 
Date: Friday, May 6, 2022 at 10:47 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] re-cut support/1.15
Great news!  I would be delighted to continue as Release Manager for 1.15.0.

To track progress toward code-complete, I will monitor the "needsTriage" and 
"blocks-1.15.0" labels (for Affects Version = 1.15.0).  Currently I see 1 
needsTriage [1] and 2 blocks-1.15.0 [2].

[1] https://tinyurl.com/5h58766f
[2] https://tinyurl.com/2p8bje4n

From: Anthony Baker 
Date: Friday, May 6, 2022 at 10:19 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] annul support/1.15
Owen, with all the recent work I think we are in an excellent position to 
resume work on the 1.15 release. While there are a few thing still outstanding, 
let’s go ahead and recut the release branch as of Monday, 2022-05-09. Would you 
be willing to resume release manager duties?

@Everyone - please chime in if you have in-progress work that you want to ship 
with 1.15 (ideally this is labeled in JIRA with “blocks-1.15.0”).

Thanks,
Anthony


> On Mar 16, 2022, at 2:12 PM, Owen Nichols  wrote:
>
> 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: [PROPOSAL] re-cut support/1.15

[Owen Nichols]

Hello Geode Community, counting the labels in Jira I see:

May 6: 1 needsTriage and 2 blocks-1.15.0.
May 20: 0 needsTriage and 3 blocks-1.15.0.

Looks like some progress.  Please continue to use the above labels to raise any 
issues.

-1.15.0 Release Manager

From: Owen Nichols 
Date: Monday, May 9, 2022 at 10:31 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] re-cut support/1.15
** The support/1.15 branch has now been (re)cut and develop is now 1.16. **

Please use your best judgement in determining what to backport.

PRs against support/1.15 are welcome (but optional!).  Committers should merge 
their own PRs.

If your backport will take some while, add the "blocks-1.15.0" label in Jira.

From: Owen Nichols 
Date: Friday, May 6, 2022 at 10:47 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] re-cut support/1.15
Great news!  I would be delighted to continue as Release Manager for 1.15.0.

To track progress toward code-complete, I will monitor the "needsTriage" and 
"blocks-1.15.0" labels (for Affects Version = 1.15.0).  Currently I see 1 
needsTriage [1] and 2 blocks-1.15.0 [2].

[1] https://tinyurl.com/5h58766f
[2] https://tinyurl.com/2p8bje4n

From: Anthony Baker 
Date: Friday, May 6, 2022 at 10:19 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] annul support/1.15
Owen, with all the recent work I think we are in an excellent position to 
resume work on the 1.15 release. While there are a few thing still outstanding, 
let’s go ahead and recut the release branch as of Monday, 2022-05-09. Would you 
be willing to resume release manager duties?

@Everyone - please chime in if you have in-progress work that you want to ship 
with 1.15 (ideally this is labeled in JIRA with “blocks-1.15.0”).

Thanks,
Anthony


> On Mar 16, 2022, at 2:12 PM, Owen Nichols  wrote:
>
> 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: [PROPOSAL] re-cut support/1.15

[Owen Nichols]

** The support/1.15 branch has now been (re)cut and develop is now 1.16. **

Please use your best judgement in determining what to backport.

PRs against support/1.15 are welcome (but optional!).  Committers should merge 
their own PRs.

If your backport will take some while, add the "blocks-1.15.0" label in Jira.

From: Owen Nichols 
Date: Friday, May 6, 2022 at 10:47 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] re-cut support/1.15
Great news!  I would be delighted to continue as Release Manager for 1.15.0.

To track progress toward code-complete, I will monitor the "needsTriage" and 
"blocks-1.15.0" labels (for Affects Version = 1.15.0).  Currently I see 1 
needsTriage [1] and 2 blocks-1.15.0 [2].

[1] https://tinyurl.com/5h58766f
[2] https://tinyurl.com/2p8bje4n

From: Anthony Baker 
Date: Friday, May 6, 2022 at 10:19 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] annul support/1.15
Owen, with all the recent work I think we are in an excellent position to 
resume work on the 1.15 release. While there are a few thing still outstanding, 
let’s go ahead and recut the release branch as of Monday, 2022-05-09. Would you 
be willing to resume release manager duties?

@Everyone - please chime in if you have in-progress work that you want to ship 
with 1.15 (ideally this is labeled in JIRA with “blocks-1.15.0”).

Thanks,
Anthony


> On Mar 16, 2022, at 2:12 PM, Owen Nichols  wrote:
>
> 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: [PROPOSAL] re-cut support/1.15

[Owen Nichols]

Sounds great, Robert.  Once your fix is on develop, no further approval is 
needed to backport. Use your best judgement (or feel free to discuss on the dev 
list if you are unsure).  If backporting will take some while, add the 
blocks-1.15.0 label to be sure this doesn’t slip through the cracks.





On May 6, 2022 at 11:17:14 AM PDT, Robert Houghton  wrote:
I would like GEODE-1028 [1] to be considered for support/1.15. It is a 
significant change to the build logic, and I think would be a benefit to 
inclusion in the release branch. PR to develop is available[2]

Thank you,
-Robert Houghton

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10283&data=05%7C01%7Conichols%40vmware.com%7C5382a71cb8c24e3c712c08da2f8ca423%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637874578340537043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XM4pI60cfPKki2BqhAZPQLdiXAhRy9bv1hghc3NFqho%3D&reserved=0
[2 
]https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7600&data=05%7C01%7Conichols%40vmware.com%7C5382a71cb8c24e3c712c08da2f8ca423%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637874578340537043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wf8pEaN3wHtpI4WoRpE%2FKrkZpoT8a7GqZgXRzu7kZl4%3D&reserved=0

From: Anthony Baker 
Date: Friday, May 6, 2022 at 10:19 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] annul support/1.15
Owen, with all the recent work I think we are in an excellent position to 
resume work on the 1.15 release. While there are a few thing still outstanding, 
let’s go ahead and recut the release branch as of Monday, 2022-05-09. Would you 
be willing to resume release manager duties?

@Everyone - please chime in if you have in-progress work that you want to ship 
with 1.15 (ideally this is labeled in JIRA with “blocks-1.15.0”).

Thanks,
Anthony


> On Mar 16, 2022, at 2:12 PM, Owen Nichols  wrote:
>
> 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: [PROPOSAL] re-cut support/1.15

[Owen Nichols]

Great news!  I would be delighted to continue as Release Manager for 1.15.0.

To track progress toward code-complete, I will monitor the "needsTriage" and 
"blocks-1.15.0" labels (for Affects Version = 1.15.0).  Currently I see 1 
needsTriage [1] and 2 blocks-1.15.0 [2].

[1] https://tinyurl.com/5h58766f
[2] https://tinyurl.com/2p8bje4n

From: Anthony Baker 
Date: Friday, May 6, 2022 at 10:19 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] annul support/1.15
Owen, with all the recent work I think we are in an excellent position to 
resume work on the 1.15 release. While there are a few thing still outstanding, 
let’s go ahead and recut the release branch as of Monday, 2022-05-09. Would you 
be willing to resume release manager duties?

@Everyone - please chime in if you have in-progress work that you want to ship 
with 1.15 (ideally this is labeled in JIRA with “blocks-1.15.0”).

Thanks,
Anthony


> On Mar 16, 2022, at 2:12 PM, Owen Nichols  wrote:
>
> 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: [PROPOSAL] RFC for migrating from springfox to springdoc

[Owen Nichols]

It would be great to make the switch to springdoc.  If you are willing, go for 
it!

Slightly outside the scope of this RFC:
Swagger was added as part of the @Experimental manageability REST API [1] and 
is used to generate API docs for each minor [2]. It looks like the API hasn’t 
changed much between the last few minors.  Does this inactivity demonstrate 
maturity (i.e. maybe we should remove the @Experimental annotation) or does it 
indicate a failed or abandoned experiment (i.e. should we consider entirely 
removing all code for this feature, following the same reasoning cited for 
removing @Experimental protobuf [3] and @Experimental redis [4])?

[1] https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
[2] 
https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service+Rest+API
[3] https://lists.apache.org/thread/zt7jphfjqqgkgjn010clq2wqo9vv2z6n
[4] https://lists.apache.org/thread/7m23h9r0tf536g414bwjsplqh1qv2ct0

From: Alexander Murmann 
Date: Thursday, May 5, 2022 at 4:09 PM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] RFC for migrating from springfox to springdoc
Thanks for your proposal, Patrick!

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

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

Hello devs!

Please review this RFC: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FMigration%2Bfrom%2Bspringfox%2Bto%2Bspringdoc&data=05%7C01%7Conichols%40vmware.com%7Cb2503a04cf1b45e6331c08da2eec45bb%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637873889588399147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T9N0dXMgG7OYBFL9aPASpklsQ2rDnMbkY2EiVLq%2FfIg%3D&reserved=0
 on migrating from springfox to springdoc for our swagger needs and provide any 
feedback you have.

Review period until Friday, May 13th.

—Patrick Johnson

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

[Owen Nichols]

Well said, Donal.

As a past Release Manager, geode-for-redis impacted release timelines for 1.13, 
1.14, and most recently 1.15.  I support this proposal in hopes that refocusing 
on core Geode makes future releases a little more predictable.

Now might also be a good time to review other features in Geode that are marked 
@Experimental, such as manageability REST API, JDBC connector, micrometer, 
SSLParameterExtension, GfshCommand, or AutoBalancer.  I hope this proposal 
encourages more proposals to either shelve or promote some of these other 
experiments.

From: Donal Evans 
Date: Thursday, April 14, 2022 at 9:10 PM
To: dev@geode.apache.org 
Subject: Re: [discuss] Future of the geode-redis module
I agree with this proposal.

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

[Owen Nichols]

Thanks for all the responses.  Sounds like there is no need to wait until 
Monday to declare consensus; I'll go ahead and get started now.

The result will be as if the branch cut had never happened.

Thanks,
-Geode 1.15.0 Release Manager

From: Dale Emery 
Date: Wednesday, March 16, 2022 at 3:11 PM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] annul support/1.15
+1

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

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

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

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

Thanks,
-Geode 1.15.0 Release Manager

[PROPOSAL] annul support/1.15

[Owen Nichols]

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: Commit message review opt-in

[Owen Nichols]

To make opt-in and opt-out less noisy for the dev list, the subscription 
mechanism has been moved to COMMITWATCHERS file under source control to provide 
self-service (like with CODEOWNERS or CODEWATCHERS).

From: Jacob Barrett 
Date: Friday, March 4, 2022 at 1:20 PM
To:
Subject: Re: Commit message review opt-in
Can we please agree to send requests for inclusion directly to 
onich...@vmware.com<mailto:onich...@vmware.com> rather than back to this thread.

On Mar 4, 2022, at 1:09 PM, Owen Nichols 
mailto:onich...@vmware.com>> wrote:

Thanks Udo, I have added kohlmu-pivotal as requested, for non-draft PRs only.

From: Udo Kohlmeyer mailto:u...@vmware.com>>
Date: Friday, March 4, 2022 at 1:03 PM
To: dev@geode.apache.org<mailto:dev@geode.apache.org> 
mailto:dev@geode.apache.org>>
Subject: Re: Commit message review opt-in
I’ll opt-in please.

--Udo

From: Owen Nichols mailto:onich...@vmware.com>>
Date: Saturday, February 26, 2022 at 10:44 AM
To: geode mailto:dev@geode.apache.org>>
Subject: Commit message review opt-in
If you received an automated-looking PR review comment from onichols-pivotal in 
the past few weeks without consent, I apologize and have withdrawn it.

If you would like to continue receiving these automated reviews, you may opt-in 
by emailing me your github username (also let me know if you want your Draft 
PRs included or not).

Geode’s guidelines for commit messages should be interpreted as suggestions, 
not rules.  All Geode committers are welcomed with "we like to work on trust, 
not unnecessary restrictions".  I hope this change to opt-in better reflects 
that spirit.

Re: Commit message review opt-in

[Owen Nichols]

If someone were to complain that PR review comments from me were made without 
consent, I would like to be able to cite a public record showing that in fact 
consent had been given.

Your mail client likely has a ‘mute this thread’ feature for this or any other 
dev list discussion to cut down on “noise” if that is your concern.

From: Jacob Barrett 
Date: Friday, March 4, 2022 at 1:26 PM
To: dev@geode.apache.org 
Subject: Re: Commit message review opt-in

> On Mar 4, 2022, at 1:22 PM, Owen Nichols  wrote:
>
> Unfortunately, I cannot add anyone to the opt-in list without a record of the 
> request on the dev list (much like wiki, jira, or similar requests).

Source?

Given this is not a request to gain access to any protected project assets I 
fail to understand why we all need to get emails regarding the requests.

Re: Commit message review opt-in

[Owen Nichols]

Unfortunately, I cannot add anyone to the opt-in list without a record of the 
request on the dev list (much like wiki, jira, or similar requests).

From: Jacob Barrett 
Date: Friday, March 4, 2022 at 1:20 PM
To:
Subject: Re: Commit message review opt-in
Can we please agree to send requests for inclusion directly to 
onich...@vmware.com<mailto:onich...@vmware.com> rather than back to this thread.

On Mar 4, 2022, at 1:09 PM, Owen Nichols 
mailto:onich...@vmware.com>> wrote:

Thanks Udo, I have added kohlmu-pivotal as requested, for non-draft PRs only.

From: Udo Kohlmeyer mailto:u...@vmware.com>>
Date: Friday, March 4, 2022 at 1:03 PM
To: dev@geode.apache.org<mailto:dev@geode.apache.org> 
mailto:dev@geode.apache.org>>
Subject: Re: Commit message review opt-in
I’ll opt-in please.

--Udo

From: Owen Nichols mailto:onich...@vmware.com>>
Date: Saturday, February 26, 2022 at 10:44 AM
To: geode mailto:dev@geode.apache.org>>
Subject: Commit message review opt-in
If you received an automated-looking PR review comment from onichols-pivotal in 
the past few weeks without consent, I apologize and have withdrawn it.

If you would like to continue receiving these automated reviews, you may opt-in 
by emailing me your github username (also let me know if you want your Draft 
PRs included or not).

Geode’s guidelines for commit messages should be interpreted as suggestions, 
not rules.  All Geode committers are welcomed with "we like to work on trust, 
not unnecessary restrictions".  I hope this change to opt-in better reflects 
that spirit.

Re: Commit message review opt-in

[Owen Nichols]

Thanks Udo, I have added kohlmu-pivotal as requested, for non-draft PRs only.

From: Udo Kohlmeyer 
Date: Friday, March 4, 2022 at 1:03 PM
To: dev@geode.apache.org 
Subject: Re: Commit message review opt-in
I’ll opt-in please.

--Udo

From: Owen Nichols 
Date: Saturday, February 26, 2022 at 10:44 AM
To: geode 
Subject: Commit message review opt-in
If you received an automated-looking PR review comment from onichols-pivotal in 
the past few weeks without consent, I apologize and have withdrawn it.

If you would like to continue receiving these automated reviews, you may opt-in 
by emailing me your github username (also let me know if you want your Draft 
PRs included or not).

Geode’s guidelines for commit messages should be interpreted as suggestions, 
not rules.  All Geode committers are welcomed with "we like to work on trust, 
not unnecessary restrictions".  I hope this change to opt-in better reflects 
that spirit.

Re: Commit message review opt-in

[Owen Nichols]

Thanks Kirk, I have added you as requested.


From: Kirk Lund 
Date: Thursday, March 3, 2022 at 10:18 AM
To: dev@geode.apache.org 
Subject: Re: Commit message review opt-in
I'd like to opt-in for this Owen. Thanks!

-Kirk

On Fri, Feb 25, 2022 at 3:43 PM Owen Nichols  wrote:

> If you received an automated-looking PR review comment from
> onichols-pivotal in the past few weeks without consent, I apologize and
> have withdrawn it.
>
> If you would like to continue receiving these automated reviews, you may
> opt-in by emailing me your github username (also let me know if you want
> your Draft PRs included or not).
>
> Geode’s guidelines for commit messages should be interpreted as
> suggestions, not rules.  All Geode committers are welcomed with "we like to
> work on trust, not unnecessary restrictions".  I hope this change to opt-in
> better reflects that spirit.
>

Re: Commit message review opt-in

[Owen Nichols]

Thanks Eric, I have added you as requested.

From: Eric Zoerner 
Date: Thursday, March 3, 2022 at 12:00 PM
To: Owen Nichols 
Cc: dev@geode.apache.org 
Subject: Re: Commit message review opt-in
I would like to opt-in. GitHub user name is ezoerner, and yes include draft PRs


From: Owen Nichols 
Date: Friday, February 25, 2022 at 15:44
To: geode 
Subject: Commit message review opt-in
If you received an automated-looking PR review comment from onichols-pivotal in 
the past few weeks without consent, I apologize and have withdrawn it.

If you would like to continue receiving these automated reviews, you may opt-in 
by emailing me your github username (also let me know if you want your Draft 
PRs included or not).

Geode’s guidelines for commit messages should be interpreted as suggestions, 
not rules.  All Geode committers are welcomed with "we like to work on trust, 
not unnecessary restrictions".  I hope this change to opt-in better reflects 
that spirit.

1.15.0 release status update

[Owen Nichols]

One month after cutting support/1.15, Jira shows 5 blockers remaining [1].  
Great work, keep those bug reports and fixes coming!
This week I will be conducting a practice exercise of creating a 1.15.0.RC0 to 
test release scripts and pipelines.  Please ignore this RC0 tag (no need to 
review or vote on it).
Thanks,
-Geode 1.15.0 Release Manager

[1] 
https://issues.apache.org/jira/browse/GEODE-10063?jql=project%3DGEODE%20AND%20(labels%3Dblocks-1.15.0%E2%80%8B)%20AND%20resolution%20is%20empty

Commit message review opt-in

[Owen Nichols]

If you received an automated-looking PR review comment from onichols-pivotal in 
the past few weeks without consent, I apologize and have withdrawn it.

If you would like to continue receiving these automated reviews, you may opt-in 
by emailing me your github username (also let me know if you want your Draft 
PRs included or not).

Geode’s guidelines for commit messages should be interpreted as suggestions, 
not rules.  All Geode committers are welcomed with "we like to work on trust, 
not unnecessary restrictions".  I hope this change to opt-in better reflects 
that spirit.

1.15.0 release status update

[Owen Nichols]

After cutting the support/1.15 branch a few weeks ago, Jira [1] shows we are 
down to 3 blockers.  Great work, keep those fixes (and bug reports) coming!

Information about upcoming releases [2] and tips for backporting [3] can now be 
found in the wiki.

PSA:
When using a search engine to quickly locate Geode wiki topics, check the url:
* cwiki.apache.org/confluence/display/GEODE  is the official URL of the Geode 
wiki.
* www.cwiki.us/display/GEODE  is NOT authorized or maintained by the ASF and is 
several years out-of-date.

Thanks,
-Geode 1.15.0 Release Manager

[1] 
https://issues.apache.org/jira/issues/?jql=project%3DGEODE%20AND%20(labels%3Dblocks-1.15.0%E2%80%8B)%20AND%20(fixVersion%20!%3D%20%221.15.0%22%20or%20fixVersion%20is%20empty%20or%20not%20status%20in(Resolved%2CClosed))%20AND%20resolution%20is%20empty
[2] https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule
[3] https://cwiki.apache.org/confluence/display/GEODE/Backporting+Tips

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

[Owen Nichols]

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

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

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

My $.02

--Mark

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

> Counting the kafka connector I'm not sure bragging about CVE patching
> speed is justified, but otherwise looks good to me!
>
> -Dan
> 
> From: Nabarun Nag 
> Sent: Tuesday, February 1, 2022 2:25 PM
> To: dev@geode.apache.org 
> Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th
>
> Thank you for the feedback, please find the new draft with the added
> review comments.
>
> ## Project Activity:
> We issued 9 releases this quarter which include an updated Log4j2 version
> to handle the remote code execution CVE. The project had one of the
> quickest turnaround times from the Log4j2 CVE disclosure to the patch
> releases with the fix. Apache Geode Kafka Connector 1.1.0 was also 
released
> this quarter.
> We have also started the effort to remove the use of deprecated components
> in the project.
>
> > Recent Releases of Apache Geode:
> > - 1.14.3 was released on 2022-01-25
> > - 1.13.7 was released on 2022-01-22
> > - 1.12.8 was released on 2022-01-13
> > - 1.12.7 was released on 2022-12-17
> > - 1.13.6 was released on 2021-12-17
> > - 1.14.2 was released on 2021-12-17
> > - 1.12.6 was released on 2021-12-11
> > - 1.13.5 was released on 2021-12-11
> > - 1.14.1 was released on 2021-12-11
>
>
> 
> From: Owen Nichols 
> Sent: Tuesday, February 1, 2022 12:39 PM
> To: dev@geode.apache.org 
> Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th
>
> 1.12.8 seems to be missing from the list of releases. Also consider
> bragging about Geode’s turnaround time from CvE disclosure to patch
> release…only one other ASF project got theirs out faster than we did.
>
>
> ---
> Sent from Workspace ONE Boxer<
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Conichols%40vmware.com%7Ce34bc117828b4af0341408d9e830c5a3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63779611835049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EE2%2BlyfKqAkVYYjbvVWaDftYeloc87GeBEv2klcnXhM%3D&reserved=0
> >
>
> On January 31, 2022 at 1:57:18 PM PST, Dave Barnes 
> wrote:
> LGTM +1
>
> On Mon, Jan 31, 2022 at 12:50 PM Nabarun Nag  wrote:
>
> > This is a draft of our report to the board. Please let me know if there
> > are details you'd like me to add!
> >
> > --Naba
> >
> > ## Description:
> > The mission of Apache Geode is the creation and maintenance of software
> > related
> > to a data management platform that provides real-time, consistent access
> to
> > data-intensive applications throughout widely distributed cloud
> > architectures.
> >
> > ## Issues:
> > There are no Board-level issues at this time.
> >
> > ## Membership Data:
> > Apache Geode was founded 2016-11-15 (5 years ago)
> > There are currently 115 committers and 54 PMC members in this project.
> > The Committer-to-PMC ratio is roughly 2:1.
> >
> > Community changes, past quarter:
> > - No new PMC members. Last addition was Donal Evans on 2021-03-22.
> > - No new committers. Last addition was Alberto Bustamante on 2021-05-13.
> >
> > ## Project Activity:
> > We issued 8 releases this quarter which include an updated Log4j2 
version
> > to handle the remote code execution CVE. Apache Geode Kafka Connector
> 1.1.0
> > was also released this quarter.
> > We have also started the effort to remove the use of deprecated
> components
> > in
> > the project.
> >
> > Recent Releases of Apache Geode:
> > - 1.14.3 was released on 2022-01-25
> > - 1.13.7 was released on 2022-01-22
> > - 1.12.7 was released on 2022-12-17
> > - 1.13.6 was released on 2021-12-17
> > - 1.14.2 was released on 2021-12-17
> > - 1.12.6 was released on 20

Re: [DISCUSS] Testing and voting on release candidates

[Owen Nichols]

Thanks for putting together this script, Dan.  It's always humbling to discover 
ways that a user's environment can differ from the tightly-controlled 
conditions of CI.

I've noticed we've shipped quite a few releases recently with the bare minimum 
of votes.  I hope this will encourage more participation from Geode's 54 PMC 
members [1].  Even if you are not a PMC member you can still run some checks 
and offer an "advisory" vote on the release candidate.

"Ad-hoc" testing is still valuable too.  Whether you have a pet project or 
full-blown application that uses Geode (or want to start one [2]), real-world 
testing of Geode can also shake out things we never thought of.

[1] https://projects.apache.org/committee.html?geode
[2] https://start.spring.io

On 2/4/22, 10:56 AM, "Dan Smith"  wrote:

Hi all,

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

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

The apache release policy [1] says

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

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

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

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23approving-a-release&data=04%7C01%7Conichols%40vmware.com%7C7bec2e36664d45df10bb08d9e8100ee5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637795977955611092%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=cslqHDG12fgy8kAwLvh1QDNoeRs9nZdnK9uz2QtckLY%3D&reserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Fdevelop%2Fdev-tools%2Frelease-testing&data=04%7C01%7Conichols%40vmware.com%7C7bec2e36664d45df10bb08d9e8100ee5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637795977955611092%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qXqCZIivE1foYg%2F3q2jzUMxMEmIQwbVeRCxvE0M1O5A%3D&reserved=0

Thanks,
-Dan

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

[Owen Nichols]

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


---
Sent from Workspace ONE Boxer

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

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

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

Re: Geode Jira Access Request

[Owen Nichols]

Hi Steve, apache ID “ssienkowski” should be assignable to GEODE Jira tickets 
now.

From: Steve Sienkowski 
Reply-To: "dev@geode.apache.org" 
Date: Monday, January 31, 2022 at 2:19 PM
To: "dev@geode.apache.org" 
Subject: Geode Jira Access Request

Hi team,

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

Thanks!
-Steve

Steve Sienkowski
Engineer, VMware Tanzu Caching
ssienkow...@vmware.com

[VMware]

Re: Changes made after 1.15 release branch is cut (SHA# 8f7193c827ee3198ae374101221c02039c70a561)

[Owen Nichols]

Hi Anil, backport process would be the same for any of these commits as for any 
other commits.  From the branch cut announcement:

Please use your best judgement in determining what to backport.
 
 PRs are welcome, but optional! Committers, please merge your own PRs.
 
 If your backport will take some while, you can add the "blocks-1.15.0" label 
in Jira to let others know.
 
 Please do raise any concerns on the dev list and/or via the blocks-1.15.0 
label.
 
 Please do test the branch as much as possible to make this the best release of 
Geode.


On 1/27/22, 8:09 AM, "Anilkumar Gingade"  wrote:

Hi Team, 1.15 release manager,

Here are the list of changes that are committed after sha# 
8f7193c827ee3198ae374101221c02039c70a561 from where 1.15 release branch is cut.
If you are the owners of these changes and feel these changes needs to be 
in 1.15 release; please make sure these changes are in the release branch (you 
may have to cherry-pick and backport it?) 

For Release Manager, 
Just wanted to make sure we take care of this; if this is already taken 
care or any process to add these changes are communicated, please ignore this. 

The list is generated using the command: "git log --pretty=fuller 
--since=2022-01-19"

GEODE-9853: get all members hosting bucket (#7144)
commit bbe9a3acf2f0812ef733dfe74f07fb9412c886e3
Author: Mario Ivanac <48509724+miva...@users.noreply.github.com> 
CommitDate: Thu Jan 27 11:23:29 2022 +0100

GEODE-9972: eliminate overnight step from release process (#7280)
commit bbe12c3217aa351422f3a61aa9a2cd1546a7b5db
Author: Owen Nichols 
<34043438+onichols-pivo...@users.noreply.github.com>
CommitDate: Thu Jan 27 00:03:08 2022 -0800

Revert "GEODE-9969: Fix unescaping the region name with underscore (#7282)" 
(#7311)
commit b7da7c25032aa921a73de3141c240b78849c334e
Author: Ray Ingles 
CommitDate: Wed Jan 26 22:23:54 2022 -0800

remove stray markdown file (#7314)
commit b33021fcbde1e92480e8759c1ed79fc1a467f2cf
Author: Dave Barnes 
CommitDate: Wed Jan 26 17:51:09 2022 -0800

GEODE-9883 Update Geode for Redis docs file (#7274)
commit 1eeccabe35466883611803ed2516145564c4cfa3
Author: Eric Zoerner 
CommitDate: Wed Jan 26 16:05:17 2022 -0800

GEODE-9973: Correct docs regarding P2P socket timeout behaviour (#7310)
commit d690f7b40e2795cdd50e59569d0c04f520089174
Author: Donal Evans 
CommitDate: Wed Jan 26 14:17:23 2022 -0800


roll develop to 1.16.0 now that support/1.15 has been created (#7309)
commit 0ec7f4807912645f2881f2e7ae5b9984a334f355
Author: Owen Nichols 
<34043438+onichols-pivo...@users.noreply.github.com>
CommitDate: Wed Jan 26 14:04:29 2022 -0800

add 1.14.3 to old versions and set as Benchmarks baseline on develop (#7307)
commit 53dae13fe02efb0f868d7d2a9ce0e03a376d679c
Author: Dick Cavender <1934150+dick...@users.noreply.github.com>
CommitDate: Wed Jan 26 11:54:49 2022 -0800

GEODE-9859: Do not copy entry if it is a destroyed entry (#7147)
commit ea91bf0f511a59b31886a137a625fdc031fb13a4
Author: Alberto Gomez 
CommitDate: Wed Jan 26 20:41:22 2022 +0100

Revert "GEODE-9973: Correct docs regarding P2P socket timeout behaviour 
(#7294)" (#7306)
commit 67d7725c818cf034670d3437173cc4ef719128f5
Author: Dave Barnes 
CommitDate: Tue Jan 25 17:03:35 2022 -0800

GEODE-9969: Fix unescaping the region name with underscore (#7282)
commit 4b5b30e379c35f17578251fe297c2b7fe7921fa4
Author: Mario Kevo <48509719+mk...@users.noreply.github.com>
CommitDate: Tue Jan 25 23:58:02 2022 +0100

GEODE-8616: Refactoring the test to remove deprecated APIs (#7301)
commit 6579b01dbfe2f7e15aaf05a4c712fcaf27498239
Author: Nabarun Nag 
CommitDate: Tue Jan 25 09:33:33 2022 -0800

GEODE-6751: Improved the tests for locator-gfsh compatibility (#7289)
commit 085b616dab895cdaa9f61f796405b11af82ffd80
Author: Nabarun Nag 
CommitDate: Mon Jan 24 17:19:49 2022 -0800

GEODE-9923: Add log message troubleshooting info from support team 
community (#7296)
commit 95210d19b5088dd0e62d4f815855d1776cd6eec7
Author: Dave Barnes 
CommitDate: Mon Jan 24 10:40:19 2022 -0800

GEODE-9958: Add gfsh-specific tests for Radish startup (#7297)
commit 77945531fafd566a0cbca7d05b5347b8ea299efc
Author: Jens Deppe 
CommitDate: Fri Jan 21 19:57:42 2022 -0800

GEODE-9922: Move Redis cross-slot checking to RegionProvider (#7295)
commit 7b0a88dbee36c6eb51513715af943f80ea6d93f9
Author: Donal Evans 
CommitDate: Fri Jan 21 17:54:03 2022 -0800

update redis svg to use new module name (#7288)
commit 66eb3f93aa44613a355515ee7d8e0bb36775d932
Author: Hale Bales 
CommitDate: Fri Jan 21 15:31:49 2022 -0800

GE

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

[Owen Nichols]

Thanks Ray for proposing this branch and Alexander for suggesting a 
branchpoint.  I will volunteer as Release Manager.

** The support/1.15 branch has now been cut from the SHA proposed in this 
thread and develop is now 1.16. **

Please use your best judgement in determining what to backport.

PRs are welcome, but optional!  Committers, please merge your own PRs.

If your backport will take some while, you can add the "blocks-1.15.0" label in 
Jira to let others know.

Please do raise any concerns on the dev list and/or via the blocks-1.15.0 label.

Please do test the branch as much as possible to make this the best release of 
Geode.

-Owen

On 1/26/22, 10:16 AM, "Raymond Ingles"  wrote:

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: Proposal: Cut 1.15 release branch from SHA 8f7193c827ee3198ae374101221c02039c70a561

[Owen Nichols]

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: Proposal: Cutting 1.15 Release branch Tuesday, 25 January

[Owen Nichols]

@Raymond any update on who will cut the branch and what time today?

On 1/20/22, 5:20 PM, "Owen Nichols"  wrote:

+1

@Raymond are you volunteering as Release Manager or asking for a volunteer? 
 If the role is still open, I'd be happy to volunteer.

On 1/20/22, 2:18 PM, "Raymond Ingles"  wrote:

Hello Geode Dev Community,

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

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

Re: Proposal: Cutting 1.15 Release branch Tuesday, 25 January

[Owen Nichols]

+1

@Raymond are you volunteering as Release Manager or asking for a volunteer?  If 
the role is still open, I'd be happy to volunteer.

On 1/20/22, 2:18 PM, "Raymond Ingles"  wrote:

Hello Geode Dev Community,

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

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

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

[Owen Nichols]

Sounds like there is consensus to implement this proposal.

Support branches and develop have been updated.  Release scripts will 
automatically check whether the protocol has changed and maintain the list 
accordingly.

On 1/4/22, 11:21 AM, "Alexander Murmann"  wrote:

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


--
Please provide anonymous feedback for me 
here<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforms.gle%2FkpUiaty3jt8X9y4H9&data=04%7C01%7Conichols%40vmware.com%7C951690bb3afc4c13b6ab08d9cfb75ec2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637769208757591829%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FSdd%2ByOW%2B0sf1u46uQr27AVPKejKY6M8cexjeC22WVk%3D&reserved=0>.

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

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

-Anil.


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

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

-Dan

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

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

-Dan

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

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

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

+1

Anthony


    > On Dec 22, 2021, at 7:13 PM, Owen Nichols  wrote:
>
> Since adopting our N-2 support policy, the list of released versions 
in /settings.gradle has ballooned to over 30 entries [1].
>
> CI tests use this list to confirm that we don’t break rolling upgrade 
ability or compatibility with older clients, but some of these tests don’t seem 
to scale well: PR#7203 to add the most recent 3 releases (bringing the total to 
33) is unable to pass CI after 8 tries.
>
> Possible solutions fall into two categories: keep the full list and 
throw developers and/or more hardware at the struggling tests, or concede that 
testing every version is not a scalable approach and find ways to shorten the 
list, e.g. randomly select a subset of old versions at runtime, or manually 
pare down the list.
>
> I propose to shorten the list [2] by keeping only the latest patch 
for each minor (unless the client or server protocol version has changed, so 
also keep the patch prior to 1.12.1 and prior to 1.13.2).  As long as a patch 
release doesn’t change the client or server protocol version, I see low value 
in testing upgrades from every patch version to every future version forever.  
The months between patch releases already provide plenty of upgrade coverage on 
that specific patch, then we can move on to the next…even if there could 
somehow be a corner-case where transitive property of upgradability doesn’t 
hold, most users probably take the latest-to-latest upgrade path anyway, which 
will always be tested.
>
> Let’s keep discussion open until 3PM PST Jan 5.  In case of no 
response, I will assume lazy consensus and update settings.gradle as proposed 
[2].
>
>
>
> [1] Current list from 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fsettings.gradle%23L72-L101&data=04%7C01%7Conichols%40vmware.com%7C951690bb3afc4c13b6ab08d9cfb75ec2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637769208757591829%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eZ3X5mtDxcSRIb%2FJwFmfwnIhK7zO1byNKC133qlZdDY%3D&reserved=0
 :
> 1.0.

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

[Owen Nichols]

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

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

Please consider above suggestions for next time.

+0

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

Hello Geode Dev Community,

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

Please do a review and give your feedback.

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

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

Source and Binary Distributions: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2Fkafka-connector-1.1.0%2F&data=04%7C01%7Conichols%40vmware.com%7C371195448ed74cdb909308d9cfd033e3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637769315400140534%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZbgkfljvRh0McQAUL0nFvClIjW2xLq5jl8804lB7Txs%3D&reserved=0
Github: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector%2Ftree%2Frel%2Fv1.1.0&data=04%7C01%7Conichols%40vmware.com%7C371195448ed74cdb909308d9cfd033e3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637769315400140534%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PgJv8d4yla2DjGWrppCxIFIkbwmrYT7fp2i5iBiOjNo%3D&reserved=0

Command to build the connector:
mvn package

Thanks!
-Dan

[DISCUSS] proposal to pare down old-version testing

[Owen Nichols]

Since adopting our N-2 support policy, the list of released versions in 
/settings.gradle has ballooned to over 30 entries [1].

CI tests use this list to confirm that we don’t break rolling upgrade ability 
or compatibility with older clients, but some of these tests don’t seem to 
scale well: PR#7203 to add the most recent 3 releases (bringing the total to 
33) is unable to pass CI after 8 tries.

Possible solutions fall into two categories: keep the full list and throw 
developers and/or more hardware at the struggling tests, or concede that 
testing every version is not a scalable approach and find ways to shorten the 
list, e.g. randomly select a subset of old versions at runtime, or manually 
pare down the list.

I propose to shorten the list [2] by keeping only the latest patch for each 
minor (unless the client or server protocol version has changed, so also keep 
the patch prior to 1.12.1 and prior to 1.13.2).  As long as a patch release 
doesn’t change the client or server protocol version, I see low value in 
testing upgrades from every patch version to every future version forever.  The 
months between patch releases already provide plenty of upgrade coverage on 
that specific patch, then we can move on to the next…even if there could 
somehow be a corner-case where transitive property of upgradability doesn’t 
hold, most users probably take the latest-to-latest upgrade path anyway, which 
will always be tested.

Let’s keep discussion open until 3PM PST Jan 5.  In case of no response, I will 
assume lazy consensus and update settings.gradle as proposed [2].



[1] Current list from 
https://github.com/apache/geode/blob/develop/settings.gradle#L72-L101 :
1.0.0-incubating
1.1.0
1.1.1
1.2.0
1.3.0
1.4.0
1.5.0
1.6.0
1.7.0
1.8.0
1.9.0
1.9.1
1.9.2
1.10.0
1.11.0
1.12.0
1.12.1
1.12.2
1.12.3
1.12.4
1.12.5
1.12.6
1.12.7*
1.13.0
1.13.1
1.13.2
1.13.3
1.13.4
1.13.5
1.13.6*
1.14.0
1.14.1
1.14.2*
*=released, but not yet added to settings.gradle due to PR#7203 not able to 
pass CI due to size of version list

[2] Proposed shortlist:
1.1.1
1.2.0
1.3.0
1.4.0
1.5.0
1.6.0
1.7.0
1.8.0
1.9.2
1.10.0
1.11.0
1.12.0
1.12.7
1.13.1
1.13.6
1.14.2

[ANNOUNCE] Apache Geode 1.12.7, 1.13.6, and 1.14.2

[Owen Nichols]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.12.7, 1.13.6, and 1.14.2

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

Geode 1.12.7, 1.13.6, and 1.14.2 include a critical security update to
Log4J v2.16.0.
ALL users MUST upgrade as soon as possible.
Release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.7
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.13.6
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.14.2

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

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

We would like to thank all the contributors that made these releases possible.
Regards,
Owen Nichols on behalf of the Apache Geode team

Re: [DISCUSS] Adding LTGM as gating PR checks

[Owen Nichols]

Requiring LGTM looks good to me.  It does not seem to have a high rate of 
false-positives like some other linters, but if we are making it gating, what 
would the process look like to override a false-positive?

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

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

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

Anthony


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

Re: [VOTE] Apache Geode 1.14.2.RC1

[Owen Nichols]

It's past the announced deadline and we have enough votes to close the vote.
 
Voting status
==
+1: 3 binding votes
* Nabarun Nag (PMC member)
* Jinmei Liao (PMC member)
* Dan Smith (PMC member)

+0: zero votes
 
-0: zero votes
 
-1: zero votes
 
The voting meets the requirements of at least 3 PMC members with +1 votes and 
has the required majority of +1 votes.
Apache Geode 1.14.2.RC1 has passed the vote and we will finalize the release 
shortly.
 
Thanks everyone for the great work!
 
-Owen

On 12/15/21, 11:25 AM, "Dan Smith"  wrote:

+1 to 1.14.2.RC1

Ran geode-release check to build from source and verify signatures on my 
machine.

-Dan

From: Nabarun Nag 
Sent: Wednesday, December 15, 2021 11:00 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.14.2.RC1

+1 to 1.14.2.RC1


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

Regards
Nabarun Nag


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

Hello Geode Dev Community,

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

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

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

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

Release notes:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.2&data=04%7C01%7Conichols%40vmware.com%7Cd4f09dbda4d64a5dd57808d9c000b49f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637751931546837619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=cF31gIx0V75neIAHcsxL%2Bew7vtcZVSx%2BqfdtTqCuZVc%3D&reserved=0

Source and binary distributions:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.14.2.RC1%2F&data=04%7C01%7Conichols%40vmware.com%7Cd4f09dbda4d64a5dd57808d9c000b49f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637751931546837619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=OrtXelsqtJw5WEpiShBDf6hoHEtV0r9Huiw1HYDQAM0%3D&reserved=0

Maven staging repo:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1122&data=04%7C01%7Conichols%40vmware.com%7Cd4f09dbda4d64a5dd57808d9c000b49f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637751931546837619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=6e9Oo9y0%2FzoxYO%2BNjbPLI8T5s1w9SMRB5zSbZG7dm0c%3D&reserved=0

GitHub:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.2.RC1&data=04%7C01%7Conichols%40vmware.com%7Cd4f09dbda4d64a5dd57808d9c000b49f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637751931546837619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ANqcTwf93TtqENg17Nk7Gotkngx5aZtaHt0JJW2Ynys%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.2.RC1&data=04%7C01%7Conichols%40vmware.com%7Cd4f09dbda4d64a5dd57808d9c000b49f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637751931546837619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=wiH61R3wD7BMRndN7YqwQgZM%2F%2BP%2BXNFhXvgI%2Fm8zHLc%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.2.RC1&data=04%7C01%7Conichols%40vmware.com%7Cd4f09dbda4d64a5dd57808d9c000b49f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637751931546837619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0mucAVER%2FHDA9SibSbdkASoUD0qiEVzHV6J%2Bs0hEe2Y%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.2.RC1&data=04%7C01%7Conichols%40vmware.com%7Cd4f09dbda4d64a5dd57808d9c000b49f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637751931546837619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=4z7cMUQNySsvg7OwEdF9kHWZHwcMIXPdUPVszGh9guw%3D&reserved=0

Pipelines:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcours

Re: [VOTE] Apache Geode 1.12.7.RC1

[Owen Nichols]

It's past the announced deadline and we have enough votes to close the vote.
 
Voting status
==
+1: 3 binding votes
* Dan Smith (PMC member)
* Nabarun Nag (PMC member)
* Jinmei Liao (PMC member)

+0: zero votes
 
-0: zero votes
 
-1: zero votes
 
The voting meets the requirements of at least 3 PMC members with +1 votes and 
has the required majority of +1 votes.
Apache Geode 1.12.7.RC1 has passed the vote and we will finalize the release 
shortly.
 
Thanks everyone for the great work!
 
-Owen

On 12/15/21, 11:08 AM, "Jinmei Liao"  wrote:

+1

From: Nabarun Nag 
Date: Wednesday, December 15, 2021 at 10:11 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.7.RC1
+1 to 1.12.7.RC1


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

Regards
Nabarun Nag


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

Hello Geode Dev Community,

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

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

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

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

Release notes:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.7&data=04%7C01%7Conichols%40vmware.com%7Cf5883189cfb94dc85e9f08d9bffe4d1c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921207357318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bPKIYiUgCKMKOS95o%2BnNT%2BslKKp8%2FUuwaO6mjxafLDw%3D&reserved=0

Source and binary distributions:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.7.RC1%2F&data=04%7C01%7Conichols%40vmware.com%7Cf5883189cfb94dc85e9f08d9bffe4d1c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921207357318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dHyDSmfxuPDTL0S3gJxd3WiO36DUuOlYxrrdZJgMFyU%3D&reserved=0

Maven staging repo:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1120&data=04%7C01%7Conichols%40vmware.com%7Cf5883189cfb94dc85e9f08d9bffe4d1c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921207357318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Jys9ODc%2BWiKVxSDOEWMetBxq%2Bk7OxOsxSV3jOGnyvIc%3D&reserved=0

GitHub:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.7.RC1&data=04%7C01%7Conichols%40vmware.com%7Cf5883189cfb94dc85e9f08d9bffe4d1c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921207357318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CiswFNQxN0Mtqd8%2BFjPUKZU36LDbXO6YtprC2gPsV5w%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.7.RC1&data=04%7C01%7Conichols%40vmware.com%7Cf5883189cfb94dc85e9f08d9bffe4d1c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921207357318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ggrDltymB6%2FnAXXvgYdgodeYyNQjvxSwy%2FwKQpe01ms%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.7.RC1&data=04%7C01%7Conichols%40vmware.com%7Cf5883189cfb94dc85e9f08d9bffe4d1c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921207357318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GZlTcoWNyzhDBTcCpzZjIZfUzdgC1JLYOKDgjXnPwCs%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.7.RC1&data=04%7C01%7Conichols%40vmware.com%7Cf5883189cfb94dc85e9f08d9bffe4d1c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921207357318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nVrI0InP9cai5b%2BRwwLocvmavTAewL6m44cRdWCKRW8%3D&reserved=0

Pipelines:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-main&data=04%7C01%7Conichols%40vmware.com%7Cf58

Re: [VOTE] Apache Geode 1.13.6.RC1

[Owen Nichols]

It's past the announced deadline and we have enough votes to close the vote.
 
Voting status
==
+1: 4 binding votes
* Nabarun Nag (PMC member)
* Jinmei Liao (PMC member)
* Dan Smith (PMC member)
* Alexander Murmann (PMC member)

+0: zero votes
 
-0: zero votes
 
-1: zero votes
 
The voting meets the requirements of at least 3 PMC members with +1 votes and 
has the required majority of +1 votes.
Apache Geode 1.13.6.RC1 has passed the vote and we will finalize the release 
shortly.
 
Thanks everyone for the great work!
 
-Owen

On 12/15/21, 2:53 PM, "Alexander Murmann"  wrote:

+1

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



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

Hello Geode Dev Community,

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

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

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

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

Release notes:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.6&data=04%7C01%7Conichols%40vmware.com%7Cdaa30f1539bc476f900a08d9c01da9f6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752055912490448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2iuKEPlVM83YbP9QBKGWp5%2Bng6483BfIQEGMXGB6dAw%3D&reserved=0

Source and binary distributions:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.6.RC1%2F&data=04%7C01%7Conichols%40vmware.com%7Cdaa30f1539bc476f900a08d9c01da9f6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752055912500399%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C3yQvIxZCf7JhzpDervxbWWRuFRxWT4cCPT2dR2HYUE%3D&reserved=0

Maven staging repo:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1121&data=04%7C01%7Conichols%40vmware.com%7Cdaa30f1539bc476f900a08d9c01da9f6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752055912500399%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=udYaFYM7f4CSEeLLjq3xDkfEbHN37Yh6tTWdLwfRxtc%3D&reserved=0

GitHub:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.6.RC1&data=04%7C01%7Conichols%40vmware.com%7Cdaa30f1539bc476f900a08d9c01da9f6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752055912500399%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AkeqIN9qgbR%2FO1FX0smm01NDGUUXOsbQzw%2FxNcUGocg%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.6.RC1&data=04%7C01%7Conichols%40vmware.com%7Cdaa30f1539bc476f900a08d9c01da9f6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752055912500399%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=iy6BWFgg%2BhAK3FV0MFXNE3ArzP8eBpK1j0qdUL2AKH4%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.6.RC1&data=04%7C01%7Conichols%40vmware.com%7Cdaa30f1539bc476f900a08d9c01da9f6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752055912500399%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5ZpqMgl43MqoRsaHRw1gIdOJXdkBTokOy7x4M9h3%2FGM%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.6.RC1&data=04%7C01%7Conichols%40vmware.com%7Cdaa30f1539bc476f900a08d9c01da9f6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752055912500399%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DmEYlqY%2F8Xkuy3l6mi7dwkGCG1ss7X7SwBZHJgKgLzI%3D&reserved=0

Pipelines:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-main&data=04%7C01%7Conichols%40vmware.com%7Cdaa30f1539bc476f900a08d9c01da9f6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752055912500399%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CuC4mv6MygXMw9IwNn5

[VOTE] Apache Geode 1.14.2.RC1

[Owen Nichols]

Hello Geode Dev Community,

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

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

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

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

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

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.14.2.RC1/

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

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

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

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

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

Regards
Owen Nichols

[VOTE] Apache Geode 1.12.7.RC1

[Owen Nichols]

Hello Geode Dev Community,

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

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

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

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

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

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.12.7.RC1/

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

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

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

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

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

Regards
Owen Nichols

[VOTE] Apache Geode 1.13.6.RC1

[Owen Nichols]

Hello Geode Dev Community,

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

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

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

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

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

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.13.6.RC1/

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

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

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

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

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

Regards
Owen Nichols

[ANNOUNCE] Apache Geode 1.12.6, 1.13.5, and 1.14.1

[Owen Nichols]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.12.6, 1.13.5, and 1.14.1

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

Geode 1.12.6, 1.13.5, and 1.14.1 bring Log4J 2.15.0 and several other fixes.
Users are encouraged to upgrade as soon as possible.
For the full list of changes please review the release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.6
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.13.5
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.14.1

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

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

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

Re: [VOTE] Apache Geode 1.14.1.RC2

[Owen Nichols]

We have enough votes to close the vote.
 
Voting status
==
+1: 4 binding votes
* Kirk Lund (PMC member)
* Jens Deppe (PMC member)
* Jianxia Chen (PMC member)
* Nabarun Nag (PMC member)

+0: zero votes
 
-0: zero votes
 
-1: zero votes
 
The voting meets the requirements of at least 3 PMC members with +1 votes and 
has the required majority of +1 votes.
Apache Geode 1.14.1.RC2 has passed the vote and we will finalize the release 
shortly.
 
Thanks everyone for the great work!
 
-Owen

On 12/10/21, 3:51 PM, "Nabarun Nag"  wrote:


+1 to 1.14.1.RC2


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

Regards
Nabarun Nag

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

Hello Geode Dev Community,

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

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

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

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

Release notes:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.1&data=04%7C01%7Conichols%40vmware.com%7C14fa6714bf7d412f45f108d9bc380a0b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747771145018858%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eSRSXqlJI8QpNjcKlDRuY2fTLKtScAOSzu%2FrYthODWA%3D&reserved=0

Source and binary distributions:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.14.1.RC2%2F&data=04%7C01%7Conichols%40vmware.com%7C14fa6714bf7d412f45f108d9bc380a0b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747771145018858%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rEjF01iFb9KYLL3sb0rorpECFqpTWlFn489rPbMVWAU%3D&reserved=0

Maven staging repo:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1118&data=04%7C01%7Conichols%40vmware.com%7C14fa6714bf7d412f45f108d9bc380a0b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747771145018858%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=p9FQ3fuY7M7nMqhdEweGnAu58tKCc30DXXC1UAseOlk%3D&reserved=0

GitHub:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.1.RC2&data=04%7C01%7Conichols%40vmware.com%7C14fa6714bf7d412f45f108d9bc380a0b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747771145018858%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rlx%2BoZWBYzXppkO9L4F6MQxMcjPVdVFntBaUtZc7pR0%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.1.RC2&data=04%7C01%7Conichols%40vmware.com%7C14fa6714bf7d412f45f108d9bc380a0b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747771145018858%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GYYaZh9cuTYLfc%2B26eVb%2FjkxLgaFZI%2FTv6S%2F0PzHGCE%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.1.RC2&data=04%7C01%7Conichols%40vmware.com%7C14fa6714bf7d412f45f108d9bc380a0b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747771145018858%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lArpRAwzlTMiRhAlrhAsC9QOfrC6ZRYVBK99s9EY1yA%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.1.RC2&data=04%7C01%7Conichols%40vmware.com%7C14fa6714bf7d412f45f108d9bc380a0b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747771145018858%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zuPEh7lKmrc1mVZq4erXODIuLj5jlHaiXqfvqXrV4yc%3D&reserved=0

Pipelines:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-main&data=04%7C01%7Conichols%40vmware.com%7C14fa6714bf7d412f45f108d9bc380a0b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747771145018858%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC

Re: [VOTE] Apache Geode 1.13.5.RC2

[Owen Nichols]

We have enough votes to close the vote.
 
Voting status
==
+1: 3 binding votes
* Kirk Lund (PMC member)
* Nabarun Nag (PMC member)
* Jens Deppe (PMC member)

+0: zero votes
 
-0: zero votes
 
-1: zero votes
 
The voting meets the requirements of at least 3 PMC members with +1 votes and 
has the required majority of +1 votes.
Apache Geode 1.13.5.RC2 has passed the vote and we will finalize the release 
shortly.
 
Thanks everyone for the great work!
 
-Owen

On 12/10/21, 3:17 PM, "Nabarun Nag"  wrote:

+1 to 1.13.5.RC2


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

Regards
Nabarun Nag


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

Hello Geode Dev Community,

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

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

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

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

Release notes:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.5&data=04%7C01%7Conichols%40vmware.com%7Cc204909c81f446c8a72608d9bc333657%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747750412327089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MujeyTnfvtMJHNOA6kgcAutFsjzBeRopPnd3%2BeZb7Ss%3D&reserved=0

Source and binary distributions:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.5.RC2%2F&data=04%7C01%7Conichols%40vmware.com%7Cc204909c81f446c8a72608d9bc333657%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747750412327089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xJC2eyuY%2Fh20zYaz1BwBHVj3NhYR4%2B2vvLfJQW9wYto%3D&reserved=0

Maven staging repo:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1117&data=04%7C01%7Conichols%40vmware.com%7Cc204909c81f446c8a72608d9bc333657%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747750412327089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=XAUIMWYmWm174HTxVoBOgGuaYoD20HhNkNvg5er5flI%3D&reserved=0

GitHub:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.5.RC2&data=04%7C01%7Conichols%40vmware.com%7Cc204909c81f446c8a72608d9bc333657%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747750412327089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LPYpUtiSNN3z%2F%2BGye9s2KvV4UOPtlaOfRRwTVy9P6t0%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.5.RC2&data=04%7C01%7Conichols%40vmware.com%7Cc204909c81f446c8a72608d9bc333657%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747750412327089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0HmoO70s%2BT1E%2FPTXzbo%2BuJXot55I03VGkObqm%2B90F9Y%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.5.RC2&data=04%7C01%7Conichols%40vmware.com%7Cc204909c81f446c8a72608d9bc333657%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747750412337045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sSz3ue0nkXyDoWEMy7xytE58kJjy3ZnNB%2FqrpyXx2fY%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.5.RC2&data=04%7C01%7Conichols%40vmware.com%7Cc204909c81f446c8a72608d9bc333657%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747750412337045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Bg2rxEGXVW2syiir%2FXdZZYelnwYpAC9p8Qvj2duT0hg%3D&reserved=0

Pipelines:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-main&data=04%7C01%7Conichols%40vmware.com%7Cc204909c81f446c8a72608d9bc333657%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747750412337045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%

Re: [VOTE] Apache Geode 1.12.6.RC2

[Owen Nichols]

We have enough votes to close the vote.
 
Voting status
==
+1: 3 binding votes
* Kirk Lund (PMC member)
* Nabarun Nag (PMC member)
* Jens Deppe (PMC member)

+0: zero votes
 
-0: zero votes
 
-1: zero votes
 
The voting meets the requirements of at least 3 PMC members with +1 votes and 
has the required majority of +1 votes.
Apache Geode 1.12.6.RC2 has passed the vote and we will finalize the release 
shortly.
 
Thanks everyone for the great work!
 
-Owen


On 12/10/21, 2:45 PM, "Jens Deppe"  wrote:

+1

Used gfsh to create a SSL-enabled cluster; ran various gfsh commands.

--Jens


From: Owen Nichols 
Date: Friday, December 10, 2021 at 2:09 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.6.RC2
Hello Geode Dev Community,

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

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

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

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

Release notes:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.6&data=04%7C01%7Conichols%40vmware.com%7Cfeb0aaf5c4e84f5dcf5208d9bc2ecead%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747731492432248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=igOEtvJjK0D3BmEhTpAjXznKl6s0geRXeOT1TYhCUQQ%3D&reserved=0

Source and binary distributions:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.6.RC2%2F&data=04%7C01%7Conichols%40vmware.com%7Cfeb0aaf5c4e84f5dcf5208d9bc2ecead%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747731492432248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dLnjlE8y2mJy5rBDhh4lia61n%2FIr4fcViCLs7ibyrYA%3D&reserved=0

Maven staging repo:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1119&data=04%7C01%7Conichols%40vmware.com%7Cfeb0aaf5c4e84f5dcf5208d9bc2ecead%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747731492432248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NpcBvKmga04Naqt3wCbULgDwTcjAUMqD%2Fvb4gKVi7pY%3D&reserved=0

GitHub:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.6.RC2&data=04%7C01%7Conichols%40vmware.com%7Cfeb0aaf5c4e84f5dcf5208d9bc2ecead%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747731492432248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qOR8OYQamOwatQIbcQQYmRpP1teQUx5SpBABF9wLhYc%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.6.RC2&data=04%7C01%7Conichols%40vmware.com%7Cfeb0aaf5c4e84f5dcf5208d9bc2ecead%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747731492432248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7Q63onsE7utA479Gpfciy47sfTWZh4i3AaX4d8LOHNo%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.6.RC2&data=04%7C01%7Conichols%40vmware.com%7Cfeb0aaf5c4e84f5dcf5208d9bc2ecead%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747731492432248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=P22ivKaeYZ6eHGa0QVcOCK8VSkdx2CUiTGq1Aa36lqo%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.6.RC2&data=04%7C01%7Conichols%40vmware.com%7Cfeb0aaf5c4e84f5dcf5208d9bc2ecead%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747731492432248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9qLI%2FBlVmKDU%2BEW%2Bk6yWDkh7uCK5F9%2Bi582ek%2Bv5UE8%3D&reserved=0

Pipelines:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-main&data=04%7C01%7Conichols%40vmware.com%7Cfeb0aaf5c4e84f5dcf5208d9bc2ecead%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637747731492432248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=iS6el67E5WM3lmdU94yAmA7eAOTcrnAfwMoyXsGKWmk%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2

[VOTE] Apache Geode 1.13.5.RC2

[Owen Nichols]

Hello Geode Dev Community,

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

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

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

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

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

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

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

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

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

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

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

Regards
Owen Nichols

[VOTE] Apache Geode 1.12.6.RC2

[Owen Nichols]

Hello Geode Dev Community,

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

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

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

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

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

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

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

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

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

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

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

Regards
Owen Nichols

[VOTE] Apache Geode 1.14.1.RC2

[Owen Nichols]

Hello Geode Dev Community,

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

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

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

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

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

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

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

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

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

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

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

Regards
Owen Nichols

Re: [DISCUSS] batch patch release voting

[Owen Nichols]

We already do “bulk/batch” release voting, as every vote covers several 
artifacts (geode, geode-native, geode-benchmarks, geode-examples).  I don’t 
interpret the ASF rules as setting any limit on the number of artifacts that 
can be approved in one vote.

It sounds like the rough consensus from this thread is to continue with 
separate votes per patch release, and just combine the announcement.  Thanks 
all for the input.



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

On December 2, 2021 at 4:27:05 PM PST, Udo Kohlmeyer  wrote:
I thought that was the case…

Then maybe every release has to be voted on, no bulk/batch allowed, as every 
release has to be verified separately.

Which, just means that bulk announcements is the only thing that makes sense…

From: Owen Nichols 
Date: Friday, December 3, 2021 at 10:39 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] batch patch release voting
I wonder if voting on patch versions makes sense.


Releasing (even patch releases) is an Act of the Apache Software Foundation, 
and as such there is a legal obligation to follow ASF voting rules for every 
release. Technically the purpose of the vote is for the Geode PMC to certify 
that the release meets ASF legal criteria (but there’s never such thing as too 
much testing, so we also hope reviewers will use the opportunity to think up 
creative new ways to test each release candidate)

---
Sent from Workspace ONE 
Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Conichols%40vmware.com%7C5b86a327271442fd31d808d9b5f3a01e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637740880245084944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jPrDfKScZu9TOw%2FtVqNPDQsVL1Y7gU1LrmcndKtYHWg%3D&reserved=0>

On December 2, 2021 at 3:25:03 PM PST, Udo Kohlmeyer  wrote:
I wonder if voting on patch versions makes sense. As we should never be 
breaking any existing features and essentially there should be sufficient 
testing on the fixes to confirm that they resolve the issues. There should also 
be no changes to APIs, as those changes should be included in a new minor.

I think a bulk announcement makes sense… So where possible we should/could 
adopt that approach.

But bulk vote for releases does not, as each patch version might contain 
different amount of fixes, for each minor. (some fixes might only be required 
in older/newer minor versions)

From: Owen Nichols 
Date: Friday, December 3, 2021 at 9:56 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] batch patch release voting
It doesn’t really make a lot of sense to release a fix in a 1.12 patch 
separately without later patches. Doing so would send the confusing message 
that users need to downgrade to get the fix (or if they upgrade they will lose 
it).

So, whether we vote separately or not, we should still probably wait to 
announce all together once all three are ready.


---
Sent from Workspace ONE 
Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Conichols%40vmware.com%7C5b86a327271442fd31d808d9b5f3a01e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637740880245084944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jPrDfKScZu9TOw%2FtVqNPDQsVL1Y7gU1LrmcndKtYHWg%3D&reserved=0>

On December 2, 2021 at 11:47:28 AM PST, Donal Evans  wrote:
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: [DISCUSS] batch patch release voting

[Owen Nichols]

I wonder if voting on patch versions makes sense.


Releasing (even patch releases) is an Act of the Apache Software Foundation, 
and as such there is a legal obligation to follow ASF voting rules for every 
release. Technically the purpose of the vote is for the Geode PMC to certify 
that the release meets ASF legal criteria (but there’s never such thing as too 
much testing, so we also hope reviewers will use the opportunity to think up 
creative new ways to test each release candidate)

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

On December 2, 2021 at 3:25:03 PM PST, Udo Kohlmeyer  wrote:
I wonder if voting on patch versions makes sense. As we should never be 
breaking any existing features and essentially there should be sufficient 
testing on the fixes to confirm that they resolve the issues. There should also 
be no changes to APIs, as those changes should be included in a new minor.

I think a bulk announcement makes sense… So where possible we should/could 
adopt that approach.

But bulk vote for releases does not, as each patch version might contain 
different amount of fixes, for each minor. (some fixes might only be required 
in older/newer minor versions)

From: Owen Nichols 
Date: Friday, December 3, 2021 at 9:56 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] batch patch release voting
It doesn’t really make a lot of sense to release a fix in a 1.12 patch 
separately without later patches. Doing so would send the confusing message 
that users need to downgrade to get the fix (or if they upgrade they will lose 
it).

So, whether we vote separately or not, we should still probably wait to 
announce all together once all three are ready.


---
Sent from Workspace ONE 
Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Conichols%40vmware.com%7C96315ce75fc440ed1d8f08d9b5eaf660%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637740843028651711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Yup%2BjajzF9eA5NBSgIREfNJ5PsQyspqfSrxhIkWyqGw%3D&reserved=0>

On December 2, 2021 at 11:47:28 AM PST, Donal Evans  wrote:
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: [DISCUSS] batch patch release voting

[Owen Nichols]

It doesn’t really make a lot of sense to release a fix in a 1.12 patch 
separately without later patches. Doing so would send the confusing message 
that users need to downgrade to get the fix (or if they upgrade they will lose 
it).

So, whether we vote separately or not, we should still probably wait to 
announce all together once all three are ready.


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

On December 2, 2021 at 11:47:28 AM PST, Donal Evans  wrote:
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?

[DISCUSS] batch patch release voting

[Owen Nichols]

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: API check error when adding a new method to a public interface

[Owen Nichols]

Adding a new method to a public interface breaks anyone else implementing that 
interface, for example Spring.

Adding a new method with a default implementation (except in the case where it 
is purely a composure of existing methods) isn't great either, you would 
probably have to throw Unsupported exception in the default implementation, 
which just pushes the mismatch from compile-time to runtime.  Default methods 
can also still be problematic if existing implementations of the interface 
happened to already have a method with the same name.

One option for adding new public methods would be to make a proposal for a new 
major version Geode 2.0.

Another option to consider is creating a new interface (rather than adding to 
existing interface).  Then change existing impl classes to implement both.

 -Owen

On 11/23/21, 10:33 AM, "Anilkumar Gingade"  wrote:

Alberto,

I don’t think the intention is to avoid, discourage adding a new 
method...As you have seen any changes to the API or adding a new API has 
implications on other parts of the product, it is good to validate/verify and 
address the dependency across the product and get everything working in 
accordance (without breaking any compatibility). If you have any requirement 
please propose through RFC and get an approval.

-Anil. 

On 11/23/21, 8:44 AM, "Alberto Gomez"  wrote:

Hi,

After the introduction of GEODE-9702 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-9702&data=04%7C01%7Conichols%40vmware.com%7C702629f1dee24c5f348a08d9aeafce3c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637732892374729426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eIIHIcdxkuNpUfHLVQEDW61XA5YaH7%2FZjTo8oURCkc0%3D&reserved=0),
 adding a new method to a public interface will make the 
api-check-test-openjdk11 fail even if a default implementation is provided.

My question is if the goal of this change is to forbid this type of 
changes in minor versions or if there is a process to follow in order for 
changes of this type to be added.

I wanted to propose (in an RFC) the addition of a new parameter to the 
create gateway sender command that would require adding a new method to the 
GatewaySender interface as well as to other public interfaces and I was 
wondering if this will be possible at all, and if so, how should I proceed with 
it.

Thanks,

Alberto

Re: @TestOnly or @VisibleForTesting

[Owen Nichols]

@VisibileForTesting is bad.  It does NOT tell you if the method SHOULD HAVE 
BEEN private, or package-private, or protected, so there is no way to 
reconstruct the originally-intended code if the annotation is ever removed.  It 
also prevents the exposed methods from being named in a way that clearly 
indicates that user code should never call them.

@TestOnly is good.  It tells you that for production, it is safe to remove the 
method entirely.  We might someday like automatically remove all @TestOnly 
methods when we ship official Geode releases -- not just to save bytes as Mark 
mentioned, but TO AVOID EXPOSING PRIVATE INTERALS (or worse, exposing the 
ability to manipulate and modify private internals!)


ANY use of @VisibileForTesting CAN be rewritten to use @TestOnly instead, for 
example:

  @VisibileForTesting
  public Foo getInternalStuff() {}

Could instead be:

  private Foo getInternalStuff() {}   

  @TestOnly
  public Foo getInternalStuffForTestOnly() {
return getInternalStuff();
  }


That said, I understand that *having tests* is more valuable than having 
perfect encapsulation, so if the extra 4 lines of code needed to do the right 
thing is a disincentive to writing tests...I'd rather have the tests...


On 11/5/21, 11:37 AM, "Kirk Lund"  wrote:

I'm ok with not using these annotations, but we still need to write *unit
tests* in addition to end-to-end *system tests*.

I started this thread primarily to standardize on how we use one or both
annotations. We shouldn't be using both arbitrarily without some sort of
guidelines.

If we want to actually stop using these annotations, then someone who feels
strongly about removing them should volunteer to submit a pull request that
*removes* all usages from the codebase. However, the purpose of these
annotations is to document some important information about the code for
better understanding by the developers working on it. So, please realize
that we will be losing this information. Also, removing the annotations
doesn't change the fact that we still need constructors and methods with
scopes that allow for testing.

Jinmei's description matches how I would want to use these annotations (if
we want to use both):

My understanding is @VisibileForTesting methods are used by the products,
> while @TestOnly methods are used only by the tests.
>
> In practice, I don’t like to add @TestOnly methods (although I like to
> mark those methods with this annotation if I found out a method is only
> used for testing for better identification), but I do find it useful to 
add
> @VisibleForTesting methods while making unit tests.
>

Dale's description represents a good usage of *@VisibleForTesting* for
chaining constructors to inject dependencies for unit testing:

Kirk and I often use @VisibleForTesting as part of a technique for making
> complex code more testable.
>
> Many classes have “hidden” dependencies that make that class hard to test.
> A useful technique is to add a constructor parameter to allow a test to
> inject a more controllable, more observable instance.
>
> But we don’t want to force every use of the existing constructor to have
> to create that instance. So we leave the old constructor’s signature as 
is,
> create a new constructor that accepts that new parameter, and make the old
> constructor call the new one.
>
> This new, intermediate constructor is called only by the old constructor
> and by tests. In order for tests to call it, we have to make it visible, 
so
> we mark it as @VisibleForTesting.
>

If a large constructor such as the one for *PartitionedRegion* constructs
its own dependencies using constructors new Dependency(...) and static
factories *Dependency.create*, then that prevents unit testing.

Untestable class:

*public UntestableClass() {*
*  // fetches its own dependencies*
*  dependency1 = new Dependency1();*

*  dependency2 = Dependency2.create(...);}*

Testable class:

*public TestableClass(Dependency1 dependency1, Dependency2 dependency2) {*
*  // all dependencies are passed in*
*  this.dependency1 = dependency1;*
*  this.dependency2 = dependency2;*
*}*

Now if you're trying to write unit tests for a class like
*PartitionedRegion*, the best technique is to use constructor chaining so
that the last constructor accepts all dependencies:

*public RefactoredClass() {*
*  this(new Dependency1(), Dependency2.create(...));*
*}*


*RefactoredClass(Dependency1 dependency1, Dependency2 dependency2) {*
*  // all dependencies are passed in*
*  ...*
*}*

Most of us have been applying *@VisibleForTesting* to the package-private
constructor that accepts all dependencies. Using the annotation doesn't
change the fact that we need to pass in the dependencies for unit

Re: @TestOnly or @VisibleForTesting

[Owen Nichols]

It would be really great if there were java tooling to actually compile 
separate production binaries and test binaries based on annotations like this, 
rather than having to ship methods that were only exposed for testing.

If such a preprocessor does exist, @TestOnly provides a stronger, unambiguous 
contract: any method with than annotation can be dropped for the production 
build.  However, @VisibleForTesting is weak, because it does not express what 
the correct lower visibility ought to be, so automation would be impossible.

If we decide to allow both, I agree that both annotations should never appear 
on the same entity, since the contracts are incompatible: @TestOnly must be 
used by tests only, while @VisibleForTesting by definition is also used in 
production.

It seems that @VisibleForTesting is a "lazy" shortcut -- instead of adding that 
annotation, you could instead create a delegating method annotated with 
@TestOnly, at the cost of 4 "extra" lines of code.

On 11/4/21, 3:30 PM, "Eric Zoerner"  wrote:

My opinion is that @VisibleForTesting is a code smell and either indicates 
that there is refactoring needed or there are tests that are unnecessary. If 
there is functionality in a private method that needs to be tested 
independently, then that code should be extracted and placed in a separate 
class that has a wider visibility that can be tested on its own.

The same could probably be said for @TestOnly unless there are actually 
static analysis tools that need it for some reason.

From: Kirk Lund 
Date: Thursday, November 4, 2021 at 15:13
To: dev@geode.apache.org 
Subject: Re: @TestOnly or @VisibleForTesting
As everyone thinks about how we want to use these annotations, please keep
this in mind that both *@VisibleForTesting* and *@TestOnly* can be used on
Types (Class/Interface/Enum), Constructors, Methods and Fields. (not just
Methods)

On Thu, Nov 4, 2021 at 3:09 PM Kirk Lund  wrote:

> Hey all,
>
> We're introducing a mess to the codebase. It's a small problem, but
> several small problems become a big problem and one of my missions is to
> clean up and improve the codebase.
>
> I recently started seeing lots of pull requests with usage of @TestOnly.
> Sometimes it's used instead of @VisibleForTesting, while sometimes I see
> both annotations added to the same method.
>
> Before we start using @TestOnly, I think we need some guidelines for when
> to use @TestOnly versus @VisibleForTesting. Or if we're going to replace
> @VisibleForTesting with @TestOnly, then we either need a PR for the
> replacement or, at a minimum, deprecation annotation and javadocs added to
> VisibleForTesting.java.
>
> The annotations appear similar but the javadocs describe slightly
> different meanings for them...
>
> *@VisibleForTesting* was created in Geode several years ago to mean that
> the method is either only for testing or the visibility of it was widened
> (example: a private method might be widened to be package-private,
> protected or public). The method might be used by product code, but it 
also
> has widened scope specifically to allow tests to call it. The javadocs 
say:
>
> "Annotates a program element that exists, or is more widely visible than
> otherwise necessary, only for use in test code.
>
> Introduced while mobbing with Michael Feathers. Name and javadoc borrowed
> from Guava and AssertJ (both are Apache License 2.0)."
>
> *@TestOnly* started appearing when we added org.jetbrains.annotations
> dependency earlier this year. It seems to indicate a method that is ONLY
> used for tests (never called by product). The javadocs say:
>
> "A member or type annotated with TestOnly claims that it should be used
> from testing code only.
>
> Apart from documentation purposes this annotation is intended to be used
> by static analysis tools to validate against element contract violations.
>
> This annotation means that the annotated element exposes internal data and
> breaks encapsulation of the containing class; the annotation won't prevent
> its use from production code, developers even won't see warnings if their
> IDE doesn't support the annotation. It's better to provide proper API 
which
> can be used in production as well as in tests."
>
> So... when do we use one over the other? I don't think both annotations
> should be on the same method. Also, some sort of guidelines are needed if
> we're going to start using @TestOnly.
>

[PSA] best way to push a tag

[Owen Nichols]

Preferred:
git push origin 

Thar be dragons:
git push --tags

[DISCUSS] Geode 1.14.0 retrospective

[Owen Nichols]

With Geode 1.14 now released, please reflect on what went well and what we 
could do differently next time.

I’ll start…

Went well: patch releases allowed us to continue delivering quarterly bugfixes 
while spacing out bigger changes.
Went well: "blocks-x.y.z" Jira label made it easy to track remaining work.

Next time: articulate a theme for 1.15 and keep focus on it, both before and 
after cutting the branch.
Next time: reduce backporting ceremony by treating "blocks-x.y.z" label as 
sufficient notice of intent to backport

Re: [jira] [Commented] (GEODE-6402) Create a DOAP file for the Apache Geode project

[Owen Nichols]

rat versions before 0.14 (not yet released, despite a fix for this bug being 
committed in May 2019) do not recognize the https variant of the Apache license 
url, so change line 10 to http://www.apache.org/licenses/LICENSE-2.0

On 9/1/21, 3:26 PM, "Dave Barnes"  wrote:

Why does this file, doap_Geode.rdf, fail the RAT license check? Looks valid
to me...

Excerpt from rat-report.txt:

Files with unapproved licenses:


  /Users/dbarnes/Repo/geode-site/website/content/doap_Geode.rdf


*


*

  Files with Apache License headers will be marked AL

  Binary files (which do not require any license headers) will be marked B

  Compressed archives will be marked A

  Notices, licenses etc. will be marked N

  AL/Users/dbarnes/Repo/geode-site/.asf.yaml

  AL/Users/dbarnes/Repo/geode-site/.travis.yml

  N /Users/dbarnes/Repo/geode-site/LICENSE

  N /Users/dbarnes/Repo/geode-site/NOTICE

  AL/Users/dbarnes/Repo/geode-site/README.md

  AL/Users/dbarnes/Repo/geode-site/build.gradle

  AL/Users/dbarnes/Repo/geode-site/docker/Dockerfile

  AL/Users/dbarnes/Repo/geode-site/gradlew

  AL/Users/dbarnes/Repo/geode-site/website/Rules

  AL/Users/dbarnes/Repo/geode-site/website/content/.htaccess

  AL
 /Users/dbarnes/Repo/geode-site/website/content/bootstrap/bootstrap.min.css

  AL/Users/dbarnes/Repo/geode-site/website/content/community/index.html

  AL/Users/dbarnes/Repo/geode-site/website/content/css/geode-site.css

 !? /Users/dbarnes/Repo/geode-site/website/content/doap_Geode.rdf
AL/Users/dbarnes/Repo/geode-site/website/content/docs/index.html

  B /Users/dbarnes/Repo/geode-site/website/content/favicon.ico

-- Forwarded message -
From: ASF GitHub Bot (Jira) 
Date: Wed, Sep 1, 2021 at 2:21 PM
Subject: [jira] [Commented] (GEODE-6402) Create a DOAP file for the Apache
Geode project
To: 



[

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-6402%3Fpage%3Dcom.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel%26focusedCommentId%3D17408388%23comment-17408388&data=04%7C01%7Conichols%40vmware.com%7Cadbf8a8cb96d4c3a4ee108d96d9786e4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637661319845016631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oW%2BySbHweWDbnNXret4PAJ0Ijo7zdQczdNK1zL1mAGk%3D&reserved=0
]

ASF GitHub Bot commented on GEODE-6402:
---

davebarnes97 merged pull request #10:
URL: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-site%2Fpull%2F10&data=04%7C01%7Conichols%40vmware.com%7Cadbf8a8cb96d4c3a4ee108d96d9786e4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637661319845016631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=T896DJhxpdpCcVD%2B41cPtm8cP%2FGRWuRyjhW0HuLX%2FkQ%3D&reserved=0





-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Create a DOAP file for the Apache Geode project
> ---
>
> Key: GEODE-6402
> URL: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-6402&data=04%7C01%7Conichols%40vmware.com%7Cadbf8a8cb96d4c3a4ee108d96d9786e4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637661319845016631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bXTUF%2BU5ilRN%2F0ZJ4T7BgP6YN%2BjaDMRK5dDT3AYKby0%3D&reserved=0
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>  Labels: pull-request-available
>
> An Apache project can (and should) have a DOAP ("Description Of A
Project") file that describes the project and provides some details. The
DOAP allows the project to be found via language and category searches,
provides release and repo information, etc.
> Here's a link to the Apache page that gets you started:
> 
[https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprojects.apache.org%2Fcreate.html&data=04%7C01%7Conichols%40vmware.com%7Cadbf8a8cb96d4c3a4ee108d96d9786e4%7Cb39138ca3

Re: Annual branch cleanup Aug 17

[Owen Nichols]

Sounds good @Jinmei, and thanks for point out the associated RFC for this 
communal branch.

It's past the announced deadline and I have run the following deletions to 
clean up the geode repo:

git push origin --delete GEM-3288-network-interfaces
git push origin --delete feature/GEODE-6316
git push origin --delete feature/GEODE-6770
git push origin --delete feature/GEODE-7277
git push origin --delete feature/vSphereTests
git push origin --delete feature/GEODE-7109
git push origin --delete feature/GEODE-8118
git push origin --delete feature/GEODE-6901
git push origin --delete mass-test-run
git push origin --delete wip/throw-FDE-instead
git push origin --delete feature/GEODE-8324
git push origin --delete feature/GEODE-8444
git push origin --delete GEODE-9064-JMX-filter-support_1.12-02
git push origin --delete feature/GEODE-8278-2

If you still have a local copy of one of these branches, please set its 
upstream to your personal fork to avoid accidentally pushing it back into the 
geode repo in the future.

Thanks again to everyone for using personal forks whenever possible.  The 
cleanup list this year was much shorter than last year.

-Owen

On 8/17/21, 8:54 AM, "Jinmei Liao"  wrote:

Please leave the feature branch “expireAuthentication”, The RFC is in: 
https://cwiki.apache.org/confluence/display/GEODE/On+Demand+Geode+Authentication+Expiration+and+Re-authentication

From: Owen Nichols 
Date: Sunday, August 1, 2021 at 1:01 AM
To: dev@geode.apache.org 
Subject: Annual branch cleanup Aug 17
Reminder to use your personal fork whenever possible.  If you do create a 
branch in the geode repo, please clean it up promptly.
An easy way to check is https://github.com/apache/geode/branches/yours

I propose to delete the branches listed below on August 17 at 3pm.  If 
there’s any branch you want to keep for reference, please push it to your own 
fork before then.
I will assume lazy consensus (no need to respond unless you disagree).

I will delete the following branches:
GEM-3288-network-interfaces
revert-6429-feature/GEODE-9220-set
feature/GEODE-6316
feature/GEODE-6770
feature/GEODE-7277
feature/vSphereTests
feature/GEODE-7109
feature/GEODE-8118
feature/GEODE-6901
mass-test-run
wip/throw-FDE-instead
feature/GEODE-8324
feature/GEODE-8444
feature/change-readme-ownership
feature/redis-memory-overhead
feature/redis-performance-testing
GEODE-9064-JMX-filter-support_1.12-02

I will delete the following branches and close their associated PR (please 
push to your own fork and make a new PR from there before Aug 17):
upthewaterspout-skip-checks
expireAuthentication
feature/GEODE-9191
feature/GEODE-8278-2

This branch has previously been approved by the community to remain in the 
geode repo and will NOT be deleted:
feature/GEODE-7665

Re: Proposal - unprotect develop branch of geode-native

[Owen Nichols]

For this situation in Geode repo, in addition to Squash, we also allow Rebase.  
This would allow you to put both commits in the same PR to pass checks, but 
still apply them to develop as separate commits.

On 8/17/21, 2:20 PM, "Blake Bender"  wrote:

Hello everyone,

Today I once again find myself between a rock and a hard place managing 
incoming PRs into the geode-native project.  We merged a PR that passed checkin 
gates, then broke in the main CI pipeline.  Additionally, our code formatter 
took an update yesterday, and now disagrees with some of the code that is 
already on the develop branch.  I submitted a PR to fix the formatting, but it 
now won't pass checkin gates because of the first break, and said first break 
can't be reverted because it won't pass checkin gates due to formatting.  I 
could maybe solve this problem by combining the two PRs, but then I'd pollute 
my Git history, which IMO is a bigger problem than either of these issues.

Sadly, this happens much more often than you'd think, and every time it 
does it takes days to untangle this knot we've tied ourselves in, when it 
should take seconds or minute of my time at most.  I would like to propose that 
we either unprotect develop on geode-native, and allow direct checkins for 
specific circumstances like reverting PRs or fixing things like this formatting 
issue.  It's crazy to keep wasting my time trying to work around something with 
such a simple solution at hand.

Thanks,

Blake

Re: Annual branch cleanup Aug 17

[Owen Nichols]

Sure, thanks for pointing this out. By any chance, is there an RFC or prior 
email thread for this shared project, in case others in the community are 
interested in contributing?

If this branch is not intended for the entire community, consider pushing it to 
your own fork and inviting specific collaborators.


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

On August 9, 2021 at 1:23:26 PM PDT, Dan Smith  wrote:
Would it be ok to leave the feature/redis-performance-testing branch for the 
time being? That is a shared branch that is being used by several people.

Thanks,
-Dan

From: Owen Nichols 
Sent: Sunday, August 1, 2021 1:01 AM
To: dev@geode.apache.org 
Subject: Annual branch cleanup Aug 17

Reminder to use your personal fork whenever possible.  If you do create a 
branch in the geode repo, please clean it up promptly.
An easy way to check is 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fbranches%2Fyours&data=04%7C01%7Conichols%40vmware.com%7C6d4ebb05741b489c1bdf08d95b738a8f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637641374067749825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xopNyZP9f%2FSce19oSSdNTeK95lH489bZT%2Fl6kJ7FIcY%3D&reserved=0

I propose to delete the branches listed below on August 17 at 3pm.  If there’s 
any branch you want to keep for reference, please push it to your own fork 
before then.
I will assume lazy consensus (no need to respond unless you disagree).

I will delete the following branches:
GEM-3288-network-interfaces
revert-6429-feature/GEODE-9220-set
feature/GEODE-6316
feature/GEODE-6770
feature/GEODE-7277
feature/vSphereTests
feature/GEODE-7109
feature/GEODE-8118
feature/GEODE-6901
mass-test-run
wip/throw-FDE-instead
feature/GEODE-8324
feature/GEODE-8444
feature/change-readme-ownership
feature/redis-memory-overhead
feature/redis-performance-testing
GEODE-9064-JMX-filter-support_1.12-02

I will delete the following branches and close their associated PR (please push 
to your own fork and make a new PR from there before Aug 17):
upthewaterspout-skip-checks
expireAuthentication
feature/GEODE-9191
feature/GEODE-8278-2

This branch has previously been approved by the community to remain in the 
geode repo and will NOT be deleted:
feature/GEODE-7665

Annual branch cleanup Aug 17

[Owen Nichols]

Reminder to use your personal fork whenever possible.  If you do create a 
branch in the geode repo, please clean it up promptly.
An easy way to check is https://github.com/apache/geode/branches/yours

I propose to delete the branches listed below on August 17 at 3pm.  If there’s 
any branch you want to keep for reference, please push it to your own fork 
before then.
I will assume lazy consensus (no need to respond unless you disagree).

I will delete the following branches:
GEM-3288-network-interfaces
revert-6429-feature/GEODE-9220-set
feature/GEODE-6316
feature/GEODE-6770
feature/GEODE-7277
feature/vSphereTests
feature/GEODE-7109
feature/GEODE-8118
feature/GEODE-6901
mass-test-run
wip/throw-FDE-instead
feature/GEODE-8324
feature/GEODE-8444
feature/change-readme-ownership
feature/redis-memory-overhead
feature/redis-performance-testing
GEODE-9064-JMX-filter-support_1.12-02

I will delete the following branches and close their associated PR (please push 
to your own fork and make a new PR from there before Aug 17):
upthewaterspout-skip-checks
expireAuthentication
feature/GEODE-9191
feature/GEODE-8278-2

This branch has previously been approved by the community to remain in the 
geode repo and will NOT be deleted:
feature/GEODE-7665

[ANNOUNCE] Apache Geode 1.12.3

[Owen Nichols]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.12.3.

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

While 1.13.3 is currently the latest release of Apache Geode, Geode 1.12.3
brings a subset of critical fixes for users not yet able to upgrade.

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

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

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

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

Re: [VOTE] Apache Geode 1.12.3.RC3

[Owen Nichols]

It's past the announced deadline and we have enough votes to close the vote.
 
Voting status
==
+1: 3 binding votes
* Nabarun Nag  (PMC member)
* Dave Barnes (PMC member)
* Dick Cavender (PMC member)
* Sean Goller

+0: zero votes
 
-0: zero votes
 
-1: zero votes
 
The voting meets the requirements of at least 3 PMC members with +1 votes and 
has the required majority of +1 votes.
Apache Geode 1.12.3.RC3 has passed the vote and we will finalize the release 
shortly.
 
Thanks everyone for the great work!
 
-Owen Nichols

On 6/30/21, 2:52 PM, "Dick Cavender"  wrote:

+1, built sources, reviewed gfsh version and NOTICE file. 

-Original Message-
From: Owen Nichols  
Sent: Friday, June 25, 2021 1:16 PM
To: dev@geode.apache.org
Subject: [VOTE] Apache Geode 1.12.3.RC3

Hello Geode Dev Community,

I'd like to propose a 1.12 patch release.

This is a release candidate for Apache Geode version 1.12.3.RC3.
Note: This is the first vote email due to a build issue with the first two 
RCs.
Thanks to all the community members for their contributions to this release!

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

Voting deadline:
3PM PDT Wed, June 30 2021.

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

Release notes:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.3&data=04%7C01%7Conichols%40vmware.com%7Cae47330712c94e9729a308d93c1167c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637606867726005832%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9w2PvEwx7eVAKkC8UHu1Fy42OfESD4x1rFDb8F3SnLg%3D&reserved=0

Source and binary distributions:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.3.RC3%2F&data=04%7C01%7Conichols%40vmware.com%7Cae47330712c94e9729a308d93c1167c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637606867726005832%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IjYGrhXng2%2FiMs5OKnEC2K%2BSiaPQAaGHQQkkAUamMb0%3D&reserved=0

Maven staging repo:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1084&data=04%7C01%7Conichols%40vmware.com%7Cae47330712c94e9729a308d93c1167c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637606867726005832%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gcjp2AHoCIfMq3r4%2BBEhoiZ4wg7qxdZ0a13uRgfftt0%3D&reserved=0

GitHub:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.3.RC3&data=04%7C01%7Conichols%40vmware.com%7Cae47330712c94e9729a308d93c1167c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637606867726015787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XThBJmzAAK3RowBQYakM42Bd33UrtsVKn2%2F%2BxiKa4PA%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.3.RC3&data=04%7C01%7Conichols%40vmware.com%7Cae47330712c94e9729a308d93c1167c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637606867726015787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pUcEgXS4gdSJMnRpbHNhErn%2FyUSf4r7km84hjvpqD8s%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.3.RC3&data=04%7C01%7Conichols%40vmware.com%7Cae47330712c94e9729a308d93c1167c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637606867726015787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HfSErdWDxFnhzHtkCEljndnJhQezCIjDIXQztOnuGo8%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.3.RC3&data=04%7C01%7Conichols%40vmware.com%7Cae47330712c94e9729a308d93c1167c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637606867726015787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mwc8Ke%2F2W5HBX%2B%2F9Y41PVgSmOpHplA3ACMMrUVnGU2w%3D&reserved=0

Pipelines:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-main&data=04%7C01%7Conichols%40vmware.com%7Cae47330712c94e9729a308d93c1167c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637606867726015787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi

Re: [DISCUSS] Backporting to support branches

[Owen Nichols]

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

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

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

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

Regards,
Nabarun

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

Hi,

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

For Developers:

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

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

For Release Manager:

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

Regards
Nabarun

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

[Owen Nichols]

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

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

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

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


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

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

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

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

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

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

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


Regards
Nabarun Nag



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

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

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

> On Oct 22, 2019, at 5:12 PM, Nabarun Nag  wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness 
> in the product is introduced. We can automate and go through fewer commits 
> faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or 
> other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what 
> is the history)
> GEODE-: 
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow 
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a 
> complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>

[VOTE] Apache Geode 1.12.3.RC3

[Owen Nichols]

Hello Geode Dev Community,

I'd like to propose a 1.12 patch release.

This is a release candidate for Apache Geode version 1.12.3.RC3.
Note: This is the first vote email due to a build issue with the first two RCs.
Thanks to all the community members for their contributions to this release!

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

Voting deadline:
3PM PDT Wed, June 30 2021.

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

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

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.12.3.RC3/

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

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

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

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

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

Regards
Owen Nichols

[ANNOUNCE] Apache Geode 1.13.3

[Owen Nichols]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.13.3.

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

Geode 1.13.3 includes a number of bug fixes, including a fix for an issue with
session state expiration.  For the full list of changes please review
the release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.13.3

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

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

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

Re: [VOTE] Apache Geode 1.13.3.RC2

[Owen Nichols]

It's past the announced deadline and we have enough votes to close the vote.
 
Voting status
==
+1: 3 binding votes
* Dave Barnes (PMC member)
* Robert Houghton (PMC member)
* Dick Cavender (PMC member)
 
+0: zero votes
 
-0: zero votes
 
-1: zero votes
 
The voting meets the requirements of at least 3 PMC members with +1 votes and 
has the required majority of +1 votes.
Apache Geode 1.13.3.RC2 has passed the vote and we will finalize the release 
shortly.
 
Thanks everyone for the great work!
 
-Owen Nichols

On 6/24/21, 3:31 PM, "Dick Cavender"  wrote:

+1 Built source distribution and reviewed LICENSE and NOTICE. 

-Original Message-
From: Owen Nichols  
Sent: Wednesday, June 23, 2021 11:56 AM
To: dev@geode.apache.org
Subject: [VOTE] Apache Geode 1.13.3.RC2

Hello Geode Dev Community,

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

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

Expedited voting deadline:
3PM PST Thu, June 24 2021.

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

Release notes:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.3&data=04%7C01%7Conichols%40vmware.com%7C695b1829c2774d329a6c08d9375fbee6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637601706626603108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ufYa8he4GMKs4UlO4Ka8gCGmAReqWRYDgtsxUic5BRY%3D&reserved=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.RC2%2F&data=04%7C01%7Conichols%40vmware.com%7C695b1829c2774d329a6c08d9375fbee6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637601706626603108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dnogTdTgxgSTWQD29KVGGt8AI%2F%2Fs2nnpetgwQ7TedbA%3D&reserved=0

Maven staging repo:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1086&data=04%7C01%7Conichols%40vmware.com%7C695b1829c2774d329a6c08d9375fbee6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637601706626603108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QAdyzwHt%2BvxRK2aPAp1OPTP4aMmyxUHd6V3cNe2Cni4%3D&reserved=0

GitHub:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.3.RC2&data=04%7C01%7Conichols%40vmware.com%7C695b1829c2774d329a6c08d9375fbee6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637601706626603108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DdeVfk855BxmZ7XsyoEf7%2FNpb%2BYbWtrLORkX6lk%2Bsto%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.3.RC2&data=04%7C01%7Conichols%40vmware.com%7C695b1829c2774d329a6c08d9375fbee6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637601706626613063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gIHcvDrLYWBRM4YCBgDVjy0qTC3F87Op%2B9TcedUjwsM%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.3.RC2&data=04%7C01%7Conichols%40vmware.com%7C695b1829c2774d329a6c08d9375fbee6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637601706626613063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WKS4YplBWuID%2Ba%2FGRWJWd57C2v91kOuwL33OG9cfV1g%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.3.RC2&data=04%7C01%7Conichols%40vmware.com%7C695b1829c2774d329a6c08d9375fbee6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637601706626613063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hMcjuQQrHIUt3WxoG4wHwrYs5E7lRaH5tF5ouibQjYI%3D&reserved=0

Pipelines:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-main&data=04%7C01%7Conichols%40vmware.com%7C695b1829c2774d329a6c08d9375fbee6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637601706626613063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Kf9%2Bye3F4e6%2FM%2FRsWOCskSIrdibfZgWFOrP%2BwR9Nv2U%3D&reserved=0

https://nam04.safeli

[VOTE] Apache Geode 1.13.3.RC2

[Owen Nichols]

Hello Geode Dev Community,

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

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

Expedited voting deadline:
3PM PST Thu, June 24 2021.

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

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

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

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

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

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

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

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

Regards
Owen Nichols

Re: [VOTE] Apache Geode 1.13.3.RC1

[Owen Nichols]

Thank you all for reviewing, unfortunately I need to withdraw this release 
candidate to revert one change that was accidentally merged a few weeks ago.  I 
will prepare an RC2 soon.

On 6/22/21, 9:17 AM, "Xiaojian Zhou"  wrote:

+1

On 6/21/21, 2:23 PM, "Nabarun Nag"  wrote:

+1 based on the following:

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

Regards,
Nabarun



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

Hello Geode Dev Community,

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

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

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

Voting deadline:
3PM PDT Tue, June 22 2021.

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

Release notes:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.3&data=04%7C01%7Conichols%40vmware.com%7C45ff66d82be640adf28808d935994929%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599754743141773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bZ14WTFaAiUMliW4xaf6%2Fjx4bsidAVK%2BBD8caTUwFUc%3D&reserved=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%2F&data=04%7C01%7Conichols%40vmware.com%7C45ff66d82be640adf28808d935994929%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599754743151728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9r4XOplHhXyUxynZJc96FaKt42C7ADkn%2BwiQFH%2FoMgE%3D&reserved=0

Maven staging repo:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1085&data=04%7C01%7Conichols%40vmware.com%7C45ff66d82be640adf28808d935994929%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599754743151728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hYnpxulEpzwxLAt2DEOz1DnyhEhZwje3qJ9b%2FcD9T4w%3D&reserved=0

GitHub:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.3.RC1&data=04%7C01%7Conichols%40vmware.com%7C45ff66d82be640adf28808d935994929%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599754743151728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UFSsduHDdLz0OXC6ECWIGCmMZFkG1BKxNLJllxcnBZg%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.3.RC1&data=04%7C01%7Conichols%40vmware.com%7C45ff66d82be640adf28808d935994929%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599754743151728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Nr9Ed7BayW2Myzu5OXhyi4UHkC4f1WhR7zaO1YT3zIY%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.3.RC1&data=04%7C01%7Conichols%40vmware.com%7C45ff66d82be640adf28808d935994929%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599754743151728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BaqMIX0sf4fCLRaFyzGaTy1Xic3xHIqiqfM4z1VaIoc%3D&reserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.3.RC1&data=04%7C01%7Conichols%40vmware.com%7C45ff66d82be640adf28808d935994929%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599754743151728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EMwj0AChmnEJX%2FdFDYNUgyczv8zkXeQViSuTYSOncSY%3D&reserved=0

Pipelines:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-main&data=04%7C01%7Conichols%40vmware

[VOTE] Apache Geode 1.13.3.RC1

[Owen Nichols]

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://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.13.3

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.13.3.RC1/

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

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

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

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

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

Regards
Owen Nichols

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

[Owen Nichols]

@Naba, two places to find recent flaky failures are:
* Latest mass-test report[1]
* Recently-sighted "CI Failure" Jira tickets[2]

[1] 
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/create-mass-test-run-report/builds/19
[2] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20GEODE%20AND%20summary%20~%20%22CI%20Failure%22%20ORDER%20BY%20updated%20DESC

On 6/10/21, 9:50 AM, "Nabarun Nag"  wrote:

Hi all,


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

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


Regards
Nabarun Nag

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

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

I just filed PR #6602 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6602&data=04%7C01%7Conichols%40vmware.com%7C11c07f7f9a6d4bb1304408d92c2fc9ea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637589406033359496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZvEa3p0O0DXBZEd8u9l8vwsr%2Bhb3FgzycgVxR%2FT08gs%3D&reserved=0>
 to change
stress-new-test from required to non-required. Please review!

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

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

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

[Owen Nichols]

Summarizing this thread so far:

In favor of making stress-new non-required:
Kirk
Mark
Myself

In favor of making all PR checks non-required:
Jake

In favor of hashing out a more nuanced balance between making it possible (but 
not too easy) to ignore stress-new failures:
Donal
Dale

Maybe that's rough concensus in terms of which option to recommend, but hardly 
a thread I would feel comfortable citing as evidence that the community is on 
board with striking down a longstanding protection that was enacted through a 
[VOTE]. 

On 6/9/21, 2:11 PM, "Anthony Baker"  wrote:

If we have consensus, no need to VOTE.

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

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

[Owen Nichols]

Ok, I'm on board with changing stress-new-test from a required PR check to 
non-required.  It's simple, codeowners still have the final say, and it neatly 
avoids the whole topic of overrides.  Time to take a [VOTE]?

On 6/9/21, 11:42 AM, "Mark Hanson"  wrote:

I am agreeing with Kirk's original desire to remote stress-new-test as a 
requirement. All others would remain.

Thanks,
Mark

    On 6/9/21, 11:39 AM, "Owen Nichols"  wrote:

The concern of holding the discussion via PR comments, rather than the 
dev list, is just that many people will be excluded.  In the past the Geode 
community has viewed overrides as highly exceptional, and perhaps indicative of 
a larger problem, so I feel that any override situation is of interest to the 
entire community.  But at minimum, as long as there's a public recorder of 
decision *somewhere* that can be cited, the individual performing the override 
can prove that they are acting with concensus.

Marks seems to be proposing something that goes far beyond that, 
essentially arguing that since we now have codeowners, we don't need gating PR 
checks at all, so there would be nothing to override.

On 6/9/21, 11:22 AM, "Dale Emery"  wrote:

Here’s the kind of scenario I’m imagining:

  *   Code owners and other reviewers review the PR in the usual 
way (either before or after the tests finish).
  *   Stress new test fails, perhaps multiple times.
  *   The committer investigates and, upon concluding that the 
failed tests are not related to the change, requests an override from the code 
owners.
  *   Code owners review the failures and the committer’s 
justification, and decide whether to override the failures.

In this scenario, the extra burden on code owners arises only at 
the committer’s request.

Dale

From: Owen Nichols 
Date: Wednesday, June 9, 2021 at 11:15 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement 
from PRs
This would substantially increase the burden on codeowners, because 
now in addition to looking at the code itself, they would have to wait for any 
running PR checks to complete, as well as remember to come back and look at the 
PR after any subsequent commits to make sure the checks are still passing.

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

I think that process is a bit much. PRs are already a 
challenge. What do people think about code owners being the gate. We can accept 
by custom that there should be no stress-new-test failures. If there is a 
failure, a code owner can request a change or decide to let it go. I think that 
is sufficient all things considered.

Thanks,
    Mark

On 6/9/21, 10:43 AM, "Owen Nichols"  wrote:

I feel that a traditional [DISCUSS] and [VOTE] on the dev 
list would be sufficient and proper to grant approval for an override.  Any PR 
already needs approval from 1 codeowner per area to merge, so codeowners 
already have a little more say because they hold veto power over the PR.

In terms of "practicalities of how this would actually 
work":
Step 1: start a [DISCUSS] thread explaining the problem and 
why you think an override is justified
Step 2: if there is concensus, [VOTE]
Step 3: Myself (or whoever performs the override) must cite 
a link to the vote thread


On 6/9/21, 10:16 AM, "Dale Emery"  wrote:

I too like #1 best for now… assuming it’s possible to 
give code owners this ability.

Coincidentally, about option #3, II was reading the git 
release notes just now, and noticed there’s a new “trailers” feature. It gives 
git the ability to parse “key: value” pairs at the end of a commit message. We 
could potentially (with a sufficiently current version of git) use that to 
exclude a test from a PR stress test run.

And, yeah, option #2 brings back the @FlakyTest 
annotation that we worked so hard to eliminate.

As Mark said, none of this fixes the underlying 
problem, which I’d frame as: We have too many tests whose results we don’t 
trust.

Dale

From: Kirk Lund 
Date: Wednesday, June 9, 2021 at 9:59 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Remove stress-new-test-openjdk11 
requirement from PRs
I do like the suggestions offered up by Dale and would 
encourage (or even
plead) with my fellow contributors to consider these:

 

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

[Owen Nichols]

The concern of holding the discussion via PR comments, rather than the dev 
list, is just that many people will be excluded.  In the past the Geode 
community has viewed overrides as highly exceptional, and perhaps indicative of 
a larger problem, so I feel that any override situation is of interest to the 
entire community.  But at minimum, as long as there's a public recorder of 
decision *somewhere* that can be cited, the individual performing the override 
can prove that they are acting with concensus.

Marks seems to be proposing something that goes far beyond that, essentially 
arguing that since we now have codeowners, we don't need gating PR checks at 
all, so there would be nothing to override.

On 6/9/21, 11:22 AM, "Dale Emery"  wrote:

Here’s the kind of scenario I’m imagining:

  *   Code owners and other reviewers review the PR in the usual way 
(either before or after the tests finish).
  *   Stress new test fails, perhaps multiple times.
  *   The committer investigates and, upon concluding that the failed tests 
are not related to the change, requests an override from the code owners.
  *   Code owners review the failures and the committer’s justification, 
and decide whether to override the failures.

In this scenario, the extra burden on code owners arises only at the 
committer’s request.

Dale

    From: Owen Nichols 
Date: Wednesday, June 9, 2021 at 11:15 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs
This would substantially increase the burden on codeowners, because now in 
addition to looking at the code itself, they would have to wait for any running 
PR checks to complete, as well as remember to come back and look at the PR 
after any subsequent commits to make sure the checks are still passing.

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

I think that process is a bit much. PRs are already a challenge. What 
do people think about code owners being the gate. We can accept by custom that 
there should be no stress-new-test failures. If there is a failure, a code 
owner can request a change or decide to let it go. I think that is sufficient 
all things considered.

Thanks,
Mark

    On 6/9/21, 10:43 AM, "Owen Nichols"  wrote:

I feel that a traditional [DISCUSS] and [VOTE] on the dev list 
would be sufficient and proper to grant approval for an override.  Any PR 
already needs approval from 1 codeowner per area to merge, so codeowners 
already have a little more say because they hold veto power over the PR.

In terms of "practicalities of how this would actually work":
Step 1: start a [DISCUSS] thread explaining the problem and why you 
think an override is justified
Step 2: if there is concensus, [VOTE]
Step 3: Myself (or whoever performs the override) must cite a link 
to the vote thread


On 6/9/21, 10:16 AM, "Dale Emery"  wrote:

I too like #1 best for now… assuming it’s possible to give code 
owners this ability.

Coincidentally, about option #3, II was reading the git release 
notes just now, and noticed there’s a new “trailers” feature. It gives git the 
ability to parse “key: value” pairs at the end of a commit message. We could 
potentially (with a sufficiently current version of git) use that to exclude a 
test from a PR stress test run.

And, yeah, option #2 brings back the @FlakyTest annotation that 
we worked so hard to eliminate.

As Mark said, none of this fixes the underlying problem, which 
I’d frame as: We have too many tests whose results we don’t trust.

Dale

From: Kirk Lund 
Date: Wednesday, June 9, 2021 at 9:59 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Remove stress-new-test-openjdk11 
requirement from PRs
I do like the suggestions offered up by Dale and would 
encourage (or even
plead) with my fellow contributors to consider these:

  *   Allow code owners to override the block, if they can be 
convinced the
> override is justified.
>   *   Exclude troublesome tests from stress test runs, either 
via
> annotations or via an `assumeThat(…)` that can detect that 
it’s running as
> a stress test. Whatever the mechanism for excluding, it would 
be in the
> code, and therefore subject to code owner review. (This, too, 
feels overly
> broad to me, as it would exclude the test from all stress 
test runs.)
>   *   A way to exclude a specific test method from running in 
the stress
> tests for a specific PR or commit. I don’t have any ideas for 
how to

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

[Owen Nichols]

This would substantially increase the burden on codeowners, because now in 
addition to looking at the code itself, they would have to wait for any running 
PR checks to complete, as well as remember to come back and look at the PR 
after any subsequent commits to make sure the checks are still passing.

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

I think that process is a bit much. PRs are already a challenge. What do 
people think about code owners being the gate. We can accept by custom that 
there should be no stress-new-test failures. If there is a failure, a code 
owner can request a change or decide to let it go. I think that is sufficient 
all things considered.

Thanks,
Mark

On 6/9/21, 10:43 AM, "Owen Nichols"  wrote:

I feel that a traditional [DISCUSS] and [VOTE] on the dev list would be 
sufficient and proper to grant approval for an override.  Any PR already needs 
approval from 1 codeowner per area to merge, so codeowners already have a 
little more say because they hold veto power over the PR.

In terms of "practicalities of how this would actually work":
Step 1: start a [DISCUSS] thread explaining the problem and why you 
think an override is justified
Step 2: if there is concensus, [VOTE]
Step 3: Myself (or whoever performs the override) must cite a link to 
the vote thread


On 6/9/21, 10:16 AM, "Dale Emery"  wrote:

I too like #1 best for now… assuming it’s possible to give code 
owners this ability.

Coincidentally, about option #3, II was reading the git release 
notes just now, and noticed there’s a new “trailers” feature. It gives git the 
ability to parse “key: value” pairs at the end of a commit message. We could 
potentially (with a sufficiently current version of git) use that to exclude a 
test from a PR stress test run.

And, yeah, option #2 brings back the @FlakyTest annotation that we 
worked so hard to eliminate.

As Mark said, none of this fixes the underlying problem, which I’d 
frame as: We have too many tests whose results we don’t trust.

Dale

From: Kirk Lund 
Date: Wednesday, June 9, 2021 at 9:59 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement 
from PRs
I do like the suggestions offered up by Dale and would encourage 
(or even
plead) with my fellow contributors to consider these:

  *   Allow code owners to override the block, if they can be 
convinced the
> override is justified.
>   *   Exclude troublesome tests from stress test runs, either via
> annotations or via an `assumeThat(…)` that can detect that it’s 
running as
> a stress test. Whatever the mechanism for excluding, it would be 
in the
> code, and therefore subject to code owner review. (This, too, 
feels overly
> broad to me, as it would exclude the test from all stress test 
runs.)
>   *   A way to exclude a specific test method from running in the 
stress
> tests for a specific PR or commit. I don’t have any ideas for how 
to
> declare such an exclusion, but if it could be done via a file it 
would be
> subject to code owner review.


1) Allow code owners to override the block, if they can be 
convinced the
override is justified.

After all, if we don't trust our code owners...

2-3) Use a custom annotation to exclude the test method or test 
class only
from stress-new-test.

At first I really liked this idea, but then we end up with growing a
collection of flaky tests that are excluded in some way from
stress-new-test that still occasionally fail in distributedTest.

#1 really sounds like the best option to me. I believe that leaving 
our
stress-new-test process as-is will only discourage everyone from 
fixing one
or two flaky tests in a large dunit test. However, I also believe 
that if
we give code owners the authority to override stress-new-test, then 
we
need to encourage them not to override this too often.

On Tue, Jun 8, 2021 at 11:11 AM Dale Emery  
wrote:

> Maybe we can find a way to relax the requirement, or to allow 
addressing
> specific situations like the tangle you find yourself in.
>
> Removing the requirement altogether feels overly broad. I fear it 
would
> allow us to quietly disregard all intermittent test failures, and 
I think
> we already quietly (or even actively) disregard way too many 
kinds of
> failures.
>
> I would prefer some w

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

[Owen Nichols]

I feel that a traditional [DISCUSS] and [VOTE] on the dev list would be 
sufficient and proper to grant approval for an override.  Any PR already needs 
approval from 1 codeowner per area to merge, so codeowners already have a 
little more say because they hold veto power over the PR.

In terms of "practicalities of how this would actually work":
Step 1: start a [DISCUSS] thread explaining the problem and why you think an 
override is justified
Step 2: if there is concensus, [VOTE]
Step 3: Myself (or whoever performs the override) must cite a link to the vote 
thread


On 6/9/21, 10:16 AM, "Dale Emery"  wrote:

I too like #1 best for now… assuming it’s possible to give code owners this 
ability.

Coincidentally, about option #3, II was reading the git release notes just 
now, and noticed there’s a new “trailers” feature. It gives git the ability to 
parse “key: value” pairs at the end of a commit message. We could potentially 
(with a sufficiently current version of git) use that to exclude a test from a 
PR stress test run.

And, yeah, option #2 brings back the @FlakyTest annotation that we worked 
so hard to eliminate.

As Mark said, none of this fixes the underlying problem, which I’d frame 
as: We have too many tests whose results we don’t trust.

Dale

From: Kirk Lund 
Date: Wednesday, June 9, 2021 at 9:59 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs
I do like the suggestions offered up by Dale and would encourage (or even
plead) with my fellow contributors to consider these:

  *   Allow code owners to override the block, if they can be convinced the
> override is justified.
>   *   Exclude troublesome tests from stress test runs, either via
> annotations or via an `assumeThat(…)` that can detect that it’s running as
> a stress test. Whatever the mechanism for excluding, it would be in the
> code, and therefore subject to code owner review. (This, too, feels overly
> broad to me, as it would exclude the test from all stress test runs.)
>   *   A way to exclude a specific test method from running in the stress
> tests for a specific PR or commit. I don’t have any ideas for how to
> declare such an exclusion, but if it could be done via a file it would be
> subject to code owner review.


1) Allow code owners to override the block, if they can be convinced the
override is justified.

After all, if we don't trust our code owners...

2-3) Use a custom annotation to exclude the test method or test class only
from stress-new-test.

At first I really liked this idea, but then we end up with growing a
collection of flaky tests that are excluded in some way from
stress-new-test that still occasionally fail in distributedTest.

#1 really sounds like the best option to me. I believe that leaving our
stress-new-test process as-is will only discourage everyone from fixing one
or two flaky tests in a large dunit test. However, I also believe that if
we give code owners the authority to override stress-new-test, then we
need to encourage them not to override this too often.

On Tue, Jun 8, 2021 at 11:11 AM Dale Emery  wrote:

> Maybe we can find a way to relax the requirement, or to allow addressing
> specific situations like the tangle you find yourself in.
>
> Removing the requirement altogether feels overly broad. I fear it would
> allow us to quietly disregard all intermittent test failures, and I think
> we already quietly (or even actively) disregard way too many kinds of
> failures.
>
> I would prefer some way to explicitly disregard only the specific test
> failures that prevent us from merging, and only with some amount of
> explicit justification.
>
> I’m not sure what that would look like. Some half-baked possibilities:
>
>   *   Allow code owners to override the block, if they can be convinced
> the override is justified.
>   *   Exclude troublesome tests from stress test runs, either via
> annotations or via an `assumeThat(…)` that can detect that it’s running as
> a stress test. Whatever the mechanism for excluding, it would be in the
> code, and therefore subject to code owner review. (This, too, feels overly
> broad to me, as it would exclude the test from all stress test runs.)
>   *   A way to exclude a specific test method from running in the stress
> tests for a specific PR or commit. I don’t have any ideas for how to
> declare such an exclusion, but if it could be done via a file it would be
> subject to code owner review.
>
> Dale
>
> From: Kirk Lund 
> Date: Tuesday, June 8, 2021 at 9:33 AM
> To: dev@geode.apache.org 
> Subject: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs
> Our requirement for stress-new-test-openjdk11 to pass before allowin

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

[Owen Nichols]

Thanks Kirk for tackling some of our flakiest tests!  I agree, we don't want to 
discourage anyone interested in paying down tech debt.

The Geode community has spoken clearly against bypassing or weakening required 
PR checks, so relaxing requirements in general might be a tough sell, but I'm 
curious what you had in mind.

It might be easier to try to get consensus on the dev list to approve a 
one-time exception, when a solid argument can be made that all reasonable 
alternatives have been exhausted (e.g. splitting up the tests or PR, 
re-triggering several times, running with increased timeout, etc) and the risk 
is low (e.g. test-only fixes or reverts).

On 6/8/21, 9:33 AM, "Kirk Lund"  wrote:

Our requirement for stress-new-test-openjdk11 to pass before allowing merge
doesn't really work as intended for fixing distributed tests that contain
multiple flaky test methods. In fact, I think it causes contributors to
avoid tackling flaky tests.

I've been working on GEODE-9103: CI Failure:
PutAllClientServerDistributedTest.testPutAllReturnsExceptions FAILED


 and was able to fix it.

However, stress-new-test-openjdk11 then continued to fail for other flaky
tests in PutAllClientServerDistributedTest. I managed to fix GEODE-9296 and
GEODE-8528 as well. I also tried but have not been able to fix GEODE-9242
which remains flaky.

Unfortunately, I cannot merge any of my fixes for
PutAllClientServerDistributedTest unless every single flaky test in it is
fixed by my PR. I think this is undesirable because it would be better to
merge the fix for 3 flaky test methods than none.

UPDATE: After running my precheckin more times, I did get
stress-new-test-openjdk11 to pass once so I can merge, but that's more of a
loophole than anything because I didn't manage to fix GEODE-9242.

Despite having PR #6542 eventually pass, I would like to discuss removing
or relaxing our requirement that stress-new-test-openjdk11 must pass in
order to merge a PR...

PR #6542: GEODE-9103: Fix ServerConnectivityExceptions in
PutAllClientServerDistributedTest



Fixed in PR #6542:
* GEODE-9296: CI Failure: PutAllClientServerDistributedTest >
testPartialKeyInPRSingleHopWithRedundancy


* GEODE-9103: CI Failure:
PutAllClientServerDistributedTest.testPutAllReturnsExceptions FAILED


* GEODE-8528: PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop
fails due to missing disk store after server restart



Still flaky:
* GEODE-9242: CI failure in PutAllClientServerDistributedTest >
testEventIdOutOfOrderInPartitionRegionSingleHop

[FYI] PR checks

[Owen Nichols]

Concourse job names have been changed to lowercase for conformity[1].

If your PR shows required checks with a status of "Expected -- Waiting for 
status to be reported", please push another commit.

[1] https://concourse-ci.org/config-basics.html#schema.identifier

Re: Reminder to use draft mode

[Owen Nichols]

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

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

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

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

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

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

--Jens

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

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

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

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

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

Comments inline…

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

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

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

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


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

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

--Jens

Re: Reminder to use draft mode

[Owen Nichols]

A PR in "Draft" mode simply conveys that at least one more commit is coming 
before it will be "done".  Reviewers generously volunteer their time to look at 
your PR, and are welcome to look at it while in draft mode if they wish, but if 
they are quite busy, some may prefer to wait until the PR is plausibly 
code-complete before setting aside time to review it.

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

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

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

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

Comments inline…

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

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

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

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


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

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

--Jens

Reminder to use draft mode

[Owen Nichols]

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

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

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

This small step will help us respect one anothers’ time and focus.  Thanks.

[ANNOUNCE] Apache Geode 1.12.2

[Owen Nichols]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.12.2.

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

While 1.13.x is currently the latest release of Apache Geode, Geode 1.12.2
contains a number of dependency updates and bug fixes.

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

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

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

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

Re: [VOTE] Requiring final keyword on every parameter and local variable

[Owen Nichols]

Good point.  We're probably stuck on vanilla JDK8 for years more anyway.

Since this discussion seems to be mainly about personal viewing preference, I 
wonder if someone has written an IntellJ plugin that would simply render 
effectively-final variables as if they were preceded by the word "final" (for 
people that want to see finals everywhere), or a plugin to collapse unnecessary 
finals (for people that don't want to see them).

On 4/21/21, 4:36 PM, "John Blum"  wrote:

I wouldn't recommend Lombok for production code, primarily because it 
generates code. Generated code occasionally leads to unintended consequences or 
incompatibilities with newer Java versions.  Additionally, it requires as 
3rd-party dependency to gain these capabilities rather than being part of the 
Java language itself.  I'd rather Java include appropriate features for these 2 
concerns, i.e. val & var, much like Kotlin, to more succinctly express intent. 
Even though Java now has var, it is different than Kotlin's var.

I only use Lombok for testing and demoing purposes.

-j

From: Kirk Lund 
Sent: Wednesday, April 21, 2021 12:59 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and local 
variable

I'm interested in 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprojectlombok.org%2F&data=04%7C01%7Conichols%40vmware.com%7C12ad0c3d5634430f31f808d9051e4d78%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637546449987523132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CDaPpdPe819GBlhtLa00DNXSi7HC%2Bm0weDUq2oHyGuo%3D&reserved=0
 and I remember John Blum using
it on some projects. I would like to study it and do some perf testing on
it before supporting it for Geode though. In general, I don't like
generated code and it looks like at least some of the features involve
generated code -- that's the only potential downside for me.

-Kirk

On Mon, Apr 19, 2021 at 12:57 PM Owen Nichols  wrote:

> Any interest in adopting 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprojectlombok.org%2F&data=04%7C01%7Conichols%40vmware.com%7C12ad0c3d5634430f31f808d9051e4d78%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637546449987523132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CDaPpdPe819GBlhtLa00DNXSi7HC%2Bm0weDUq2oHyGuo%3D&reserved=0
 in Geode?  Lombok
> allow a more readable "val" vs "var" syntax instead of "final" vs "" which
> could make it easier to do the right thing without "increasing visual
> noise".
>
> On 4/19/21, 12:40 PM, "Dale Emery"  wrote:
>
> My test for whether enforce a guideline in a PR review is: Would I be
> willing to automate enforcing it in CI?
>
> I am -0 on this particular guideline.
>
> IntelliJ offers two competing inspections for Java coding style:
>
>   *   Local variable or parameter can be final
>   *   Unnecessary 'final' on local variable or parameter
>
> Both of these are (I think) disabled by default in IntelliJ. And
> neither satisfies my “I’d be willing to automate enforcing it” test.
>
> Dale
>
> From: Mark Hanson 
> Date: Monday, April 19, 2021 at 11:08 AM
> To: dev@geode.apache.org 
> Subject: Re: [VOTE] Requiring final keyword on every parameter and
> local variable
> Hi Jake,
>
> I agree with everyone's point about final being a useful, I just don't
> find it useful enough to do anything manually across the code base at this
> point.
>
> I believe first in foremost in no code warnings. Intellij warns about
> variables that can be final, so I make them final as it finds them. It is
> very rare that I am writing new code at this point. I have spent the last
> year bug fixing other people's code.  From my standpoint, original intent
> is largely moot. So, for me, the question is do I go through code that is
> not mine and mark it all as final (where appropriate)? Sure, in code that 
I
> touch. In code the rest of the codebase, I think there are bigger fish to
> fry before we get to final.
>
> It seems like the larger portion of the consensus is to recommend that
> variables are marked final (where appropriate) as we find them or create
> them.
> That seems like the going forward approach consensus.
>
> I will be blunt though. This seems nitpicky *compared* t

Re: [VOTE] Apache Geode 1.12.2.RC1

[Owen Nichols]

It's past the announced deadline and we have enough votes to close the vote.
 
Voting status
==
+1: 4 binding votes
* Donal Evans (PMC member)
* Dave Barnes (PMC member)
* John Blum (PMC member)
* Nabarun Nag (PMC member)

+0: zero votes
 
-0: zero votes
 
-1: zero votes

The voting meets the requirements of at least 3 PMC members with +1 votes and 
has the required majority of +1 votes.
Apache Geode 1.12.2 has passed the vote and I will finalize the release shortly.
 
Thanks everyone for the great work!
 
-Owen Nichols


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

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


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

Regards
Nabarun

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

-1

Potential rebalance issue during upgrade to 1.12.2RC1

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


Regards
Nabarun

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

+1

Spring Data for Apache Geode 1.12.2 built successfully.

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

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

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

> +1
>
> Confirmed that performance in multiple scenarios is on par with the
> previous 1.12 release.
> ________
> From: Owen Nichols 
> Sent: Wednesday, April 14, 2021 3:38 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1
>
> Hello Geode Dev Community,
>
> Geode’s support/1.12 has gathered a few more fixes since 1.12.1 was
> released two months ago.  I’d like to propose another patch release.
>
> This is a release candidate for Apache Geode version 1.12.2.RC1.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback (including the checks you
> performed).
>
> Voting deadline:
> 3PM PDT Mon, April 19 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.2.RC1
>
> Release notes:
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.2&data=04%7C01%7Conichols%40vmware.com%7Ce4f83fbdcd8c49d44f6d08d904e9a1a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637546223763866411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ojzJeE2qMXrKiUjwj%2F%2FYtzMP9nke5XGwd6eP03Iqw9c%3D&reserved=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%2F&data=04%7C01%7Conichols%40vmware.com%7Ce4f83fbdcd8c49d44f6d08d904e9a1a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637546223763866411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=D04VsWibIc1KjKXbluJm3dDUswCN4FHiuQcH7ywPZGE%3D&reserved=0
>
> Maven staging repo:
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1080&data=04%7C01%7Conichols%40vmware.com%7Ce4f83fbdcd8c49d44f6d08d904e9a1a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637546223763866411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Vfqh2NNofBsy4xMK4qGXm7lMQDgagZjB6nzaDcXWWhI%3D&reserved=0
>
> GitHub:
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Conichols%40vmware.com%7Ce4f83fbdcd8c49d44f6d08d904e9a1a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637546223763866411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FvkNXsULhyLrbo2HdTih1tdj59MBbLH2%2Fsz1i9GtTbQ%3D&reserved=0
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Conichols%40vmware.com%7Ce4f83fbdcd8c49d44f6d08d904e9a1a0%7Cb39138ca3c

Re: [VOTE] Requiring final keyword on every parameter and local variable

[Owen Nichols]

Any interest in adopting https://projectlombok.org in Geode?  Lombok allow a 
more readable "val" vs "var" syntax instead of "final" vs "" which could make 
it easier to do the right thing without "increasing visual noise".

On 4/19/21, 12:40 PM, "Dale Emery"  wrote:

My test for whether enforce a guideline in a PR review is: Would I be 
willing to automate enforcing it in CI?

I am -0 on this particular guideline.

IntelliJ offers two competing inspections for Java coding style:

  *   Local variable or parameter can be final
  *   Unnecessary 'final' on local variable or parameter

Both of these are (I think) disabled by default in IntelliJ. And neither 
satisfies my “I’d be willing to automate enforcing it” test.

Dale

From: Mark Hanson 
Date: Monday, April 19, 2021 at 11:08 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and local 
variable
Hi Jake,

I agree with everyone's point about final being a useful, I just don't find 
it useful enough to do anything manually across the code base at this point.

I believe first in foremost in no code warnings. Intellij warns about 
variables that can be final, so I make them final as it finds them. It is very 
rare that I am writing new code at this point. I have spent the last year bug 
fixing other people's code.  From my standpoint, original intent is largely 
moot. So, for me, the question is do I go through code that is not mine and 
mark it all as final (where appropriate)? Sure, in code that I touch. In code 
the rest of the codebase, I think there are bigger fish to fry before we get to 
final.

It seems like the larger portion of the consensus is to recommend that 
variables are marked final (where appropriate) as we find them or create them.
That seems like the going forward approach consensus.

I will be blunt though. This seems nitpicky *compared* to the number of 
code warnings there are and the fact that people are not actively fixing all of 
the warnings.
If we don't come to the same consensus about all warnings this seems like 
painting a rusted car, sure it makes it all look the same, but does very little 
for the underlying problems. Now to undermine my own argument a little, I think 
that especially in release blockers, we want to touch as little code as 
possible, so I am flexible there.

I would also like to agree with Udo about final really not being very good 
compared to Mutable and Immutable objects in other languages.

Thanks,
Mark


On 4/15/21, 7:49 PM, "Udo Kohlmeyer"  wrote:

@jake, you are correct, I did miss the LOCAL variable out of the 
subject. :face_palm:

Yes, adding "final" to LOCAL variables will be HUGELY beneficial in 
this regard. Have we seen any performance improvement after having refactored 
this method? Have you been able to measure any improvements?

--Udo

On 4/15/21, 1:19 PM, "Jacob Barrett"  wrote:



> On Apr 14, 2021, at 7:46 PM, Udo Kohlmeyer  
wrote:
> @Jake the idea of smaller methods is great and we should ALWAYS 
strive for that. But that argument is completely irrelevant in this discussion. 
As making method arguments final does not naturally guide a developer to 
creating smaller methods. Nor does a smaller method mean it can/will be jitted. 
Too many factors (to discuss here) are part of that decision, also it is not 
relevant in this discussion. But more on that topic read THIS.

The original subject is in regards to parameters and local 
variables.

Irrelevant is certainly an opinion you are welcome to have but let 
me challenge you. Goto DistributedCacheOperation._distribute().

First challenge, look at around line 333:
boolean reliableOp = isOperationReliable() && 
region.requiresReliabilityCheck();

Without scrolling do you see that variable used? Nope, because it 
is first used on line 439, ~100 lines away. Does it mutate between there, well 
I can search for all uses and find out or I could be nice to the next person 
and intend for it to never mutate by adding final. Intent communicated!

Second challenge, mark all the local variables in the method as 
final. Now make it compile without introducing more mutable variables. At the 
end of this journey you will have about a dozen unit testable methods and a 
_distribute method that goes from ~370 lines to  ~90 with no mutable local 
variables.

I argue it is relevant as good guardrail for writing good code. 
While we should ALWAYS strive for it we don’t. Every little nudge helps.


-Jake

[VOTE] Apache Geode 1.12.2.RC1

[Owen Nichols]

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://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.2

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.12.2.RC1/

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

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

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

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

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

Regards
Owen Nichols

Re: CODEWATCHERS file effects

[Owen Nichols]

Thanks Alberto for the detailed list.  I think I was able to find explanations 
for all, see below.

> https://github.com/apache/geode/pull/6177
# 
geode-core/src/main/java/org/apache/geode/cache/client/internal/QueueManagerImpl.java
#matches your rule:
# geode-core/**/org/apache/geode/cache/client/**
#however, support branch PR should not have triggered CODEWATCHERS, I will fix.

> https://github.com/apache/geode/pull/6156 
# 
geode-core/src/distributedTest/java/org/apache/geode/cache/client/internal/CacheServerSSLConnMaxThreadsDUnitTest.java
#matches your rule:
# geode-core/**/org/apache/geode/cache/client/**

> https://github.com/apache/geode/pull/6153
# geode-wan/build.gradle
#matches your rule:
# geode-wan/**
#note that in CODEOWNERS, this would not have matched, because gradle files are 
remapped by a later rule

> https://github.com/apache/geode/pull/6151
# 
geode-core/src/main/java/org/apache/geode/cache/client/internal/QueueManagerImpl.java
#matches your rule:
# geode-core/**/org/apache/geode/cache/client/**

> https://github.com/apache/geode/pull/6075
# 
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/BaseCommand.java
#matches your rule:
# geode-core/**/org/apache/geode/internal/cache/tier/**

> https://github.com/apache/geode/pull/6116
#you are listed as a reviewer because you approved this PR.  You were never 
requested via CODEWATCHERS.

   
 ____
From: Owen Nichols 
Sent: Wednesday, March 24, 2021 2:30 AM
To: dev@geode.apache.org 
Subject: Re: CODEWATCHERS file effects

Hi Alberto, is there a specific PR you feel you were added to in error?  I 
spot-checked #6179 and there was one test change in geode-wan so that one seems 
correct.

I am looking for a solution to avoid adding watchers to draft PRs until 
they are taken out of draft mode, but it's non-trivial so I don't have an ETA 
yet.

On 3/23/21, 12:08 PM, "Alberto Gomez"  wrote:

Hi,

I have recently added myself to the CODEWATCHERS file to be assigned as 
reviewer to PRs touching certain areas of the code but seems that I am being 
added to many more PRs that what I intended, even to Draft PRs.

Is anybody else experiencing the same?

Thanks,

Alberto

Re: CODEWATCHERS file effects

[Owen Nichols]

Hi Alberto, is there a specific PR you feel you were added to in error?  I 
spot-checked #6179 and there was one test change in geode-wan so that one seems 
correct.  

I am looking for a solution to avoid adding watchers to draft PRs until they 
are taken out of draft mode, but it's non-trivial so I don't have an ETA yet.

On 3/23/21, 12:08 PM, "Alberto Gomez"  wrote:

Hi,

I have recently added myself to the CODEWATCHERS file to be assigned as 
reviewer to PRs touching certain areas of the code but seems that I am being 
added to many more PRs that what I intended, even to Draft PRs.

Is anybody else experiencing the same?

Thanks,

Alberto

Re: [DISCUSS] Cutting a Geode 1.14.0 release branch

[Owen Nichols]

Weeks since support/1.14 cut:  5
Changes backported this week:  7
Blockers we are still waiting on:  8

As of today I am no longer serving as Geode 1.14 Release Manager.  Please 
volunteer if you would like to take over.

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

Weeks since support/1.14 cut:  4
Blockers backported this week:  9
Blockers we are still waiting on:  9

If there's anything else we should be waiting on, please make a proposal to 
add it to the blocker board sooner rather than later (even if you're still 
investigating...fix doesn't have to be fully ready yet, but do please update in 
the ticket how it is progressing for anything taking "longer than a week")

    On 3/5/21, 6:02 PM, "Owen Nichols"  wrote:

It's been three weeks since support/1.14 was cut.  This week, backports 
for 12 blockers arrived on support/1.14.  Great job!

As of now, the blocker board [1] shows that we are waiting on 9 
blockers.  Once this list reaches zero, I can prepare RC1.

[1] 
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12336052

On 2/26/21, 9:09 AM, "Owen Nichols"  wrote:

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

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

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

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

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

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

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


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

Sounds good.

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

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

Thanks,
Owen Nichols
1.14.0 Release Manager

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

Hi everyone,

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

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

Re: CODEOWNERS vs CODEWATCHERS

[Owen Nichols]

Apache+GitHub only allows committers to be added as reviewers, so unfortunately 
only Geode committers can be added to either CODEOWNERS or CODEWATCHERS at this 
time.

Contributors interested in following changes to any file, directory, or subtree 
may wish to try GitHub's ".atom" suffixing to generate a live feed [1], for 
example to watch geode-wan add this url to your favorite feed reader [2].

If you can think of another way to notify non-committers I'd be willing to 
consider it.  For example, maybe CODEWATCHERS could tag them in a comment if 
they haven't been previously tagged or something like that, let me know if that 
would be helpful.

[1] https://docs.github.com/en/rest/reference/activity#feeds
[2] https://github.com/apache/geode/commits/develop/geode-wan.atom

On 3/18/21, 3:57 PM, "Alberto Bustamante Reyes" 
 wrote:

Hi,

Is it possible to add contributors to the CODEWATCHERS file? Or is it 
strictly necessary to be a committer?

BR/

Alberto B.
________
De: Owen Nichols 
Enviado: viernes, 12 de marzo de 2021 23:38
Para: dev@geode.apache.org 
Asunto: CODEOWNERS vs CODEWATCHERS

The Geode community has certainly become closer now that CODEOWNERS 
automatically adds a lot of people to the reviewer list for new PRs, but you 
may still feel like you’re missing out on PRs outside your area of expertise.

If you are a committer and there are additional code areas you’d like to be 
automatically added as an optional reviewer (as opposed to a binding 
codeowner), you can now do that through CODEWATCHERS.  Same file format, same 
process (submit a PR to make any changes).

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

[Owen Nichols]

Thanks, this seems related to GEODE-9029 which was already proposed and 
approved, I assume this is follow-up.  Added to blocker board.

On 3/18/21, 12:00 PM, "Hale Bales"  wrote:

Hello,

 I am putting forward the proposal to backport GEODE-9032 (support 
SLOWLOG command) to support/1.14 branch,

What does GEODE-9032 do?

  *   It updates the docs to put slowlog in the list of 
supported commands
  *   It updates the test that checks if commands are supported 
or not

These changes are low-risk as they are limited entirely to the Geode’s 
Redis-compatibility subsystem and do not impact any other Geode code. This is 
an update to docs and a test.

Why do we need to backport these changes?

  *   These changes will allow us to support the commands 
necessary for DataDog to be compatible with Geode's API for Compatibility with 
Redis.

~ hale (they/them)