Building docs with bookbinder

[Dave Barnes]

If anyone is building docs with bookbinder and is getting version mismatch
complaints, I found this very helpful. There’s a component named haml whose
default version doesn’t play nicely with middleman. Here’s the magic
Gemfile entry that fixes the issue:

source 'http://rubygems.org'
gem 'bookbindery'
gem 'haml', '>= 4.0.5', '< 6.0'

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

[Dave Barnes]

+1 to Anthony's suggestion.

On Wed, Jun 29, 2022 at 11:59 AM Joris Melchior
 wrote:

> +1 to Anthony’s suggestion.
>
> From: Anthony Baker 
> Date: Wednesday, June 29, 2022 at 12:34 PM
> To: dev@geode.apache.org 
> Subject: CODEOWNERS? (was Re: Pending PR reviews)
> ⚠ External Email
>
> I realize that this is a thread hijack, but hopefully a useful one. I’ve
> seen several requests for timely reviews in recent months. I think that the
> CODEOWNERS goals were important and laudable—directing review requests to
> those most suited to provide oversight—but the implementation has been
> problematic. The size, complexity, and interconnectedness of the code base
> meant that many pull requests tagged not just one expert but just about
> EVERY expert in the community. This is rather inefficient, to say the least.
>
> I propose that we revert CODEOWNERS and return to the review-then-commit
> model requiring at least one +1 vote from a committer. I see Owen has
> already created a PR [1] for this change.
>
> Thoughts?
>
> Anthony
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7820data=05%7C01%7Cjmelchior%40vmware.com%7C52c8574bba824aa8550908da59ed395e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172657046974%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=QLRDUSWYEQghr4uymf6ITo8ljqW93OicXeQMhCig9TU%3Dreserved=0
>
>
> > On Jun 28, 2022, at 5:43 AM, Mario Ivanac  wrote:
> >
> > ⚠ External Email
> >
> > Hi,
> >
> > The following PRs:
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7323data=05%7C01%7Cjmelchior%40vmware.com%7C52c8574bba824aa8550908da59ed395e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172657203211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=vOF5oEuamtm2SAteHVidt0z%2Fn2IwvmjhjHBYBDN%2BfYg%3Dreserved=0
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7749data=05%7C01%7Cjmelchior%40vmware.com%7C52c8574bba824aa8550908da59ed395e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172657203211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=5x%2Bb4zQndwuxCsIMZBbiIrClxKCH2FSQe%2FqxWoMTLAc%3Dreserved=0
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7664data=05%7C01%7Cjmelchior%40vmware.com%7C52c8574bba824aa8550908da59ed395e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172657203211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=RJwji25FKUPWNVuNkp7%2F9mkbtyNYa2bA84ymE9CxXE8%3Dreserved=0
> >
> > are waiting for review for some time.
> >
> >
> > Could code owners review these PRs?
> >
> > Thanks,
> > Mario
> >
> > 
> >
> > ⚠ External Email: This email originated from outside of the
> organization. Do not click links or open attachments unless you recognize
> the sender.
>

Re: [VOTE] Apache Geode 1.15.0.RC1

[Dave Barnes]

+1
Docs:
- Built and viewed the Geode User Guide using dev-tools docker-based
script, also manually-invoked bookbinder. Verified correct versioning.
- Viewed API docs & verified correct version in page headers.
- Built and viewed Native Client user guides for .NET framework and
C++ using manually-invoked bookbinder.
- Native client guides did not build for me on MacOS using the docker-based
script due to a version mismatch with my ruby environment. Not a
show-stopper.
- Did not test API doc builds for Native clients. Also not a show-stopper.



On Fri, Jun 17, 2022 at 2:35 PM Bill Burcham  wrote:

> +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://dist.apache.org/repos/dist/dev/geode/1.15.0.RC1/apache-geode-1.15.0-src.tgz.sha256
> matches checksum on
>
> https://dist.apache.org/repos/dist/dev/geode/1.15.0.RC1/apache-geode-1.15.0-src.tgz
>
> 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://github.com/apache/geode/tree/rel/v1.15.0.RC1
>
> https://github.com/apache/geode/commit/1869f2c06681bb73de727d2080d76c6215db9fb9
>
> 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.0data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=1Jh2qL5j5uLqpcT7UsH%2BAxSd9SAbTvtbJAloOvt95Nc%3Dreserved=0
> >
> > Source and binary distributions:
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.15.0.RC1%2Fdata=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=hg5QXyPY9tGEXVHeMXOkjICIZn7p4sM%2BVx3yAFLUKYQ%3Dreserved=0
> >
> > Maven staging repo:
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1138data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Dqp5pW5UFWg4P%2Fl0j1rnq1YjhGVyiuHuNdymAQuBDmU%3Dreserved=0
> >
> > GitHub:
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.15.0.RC1data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=pA2U7tRLdfcQvJfE1Jkkcs5PPOj9EzcUDugPFmg1WPs%3Dreserved=0
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.15.0.RC1data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=A9jlDbACLA7dckkqgEI2yKb1zy7gVUMBP6S4%2FA959Io%3Dreserved=0
> >
> >
> 

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

[Dave Barnes]

Good arguments on both sides, but not an overwhelming consensus.
I will leave things as they are. Thanks for everyone who contributed to the
discussion!

On Fri, Jun 17, 2022 at 6:37 AM Alberto Gomez 
wrote:

> Hi Dave,
>
> Supposing we move the documentation out of the geode code repo, if I
> download a certain release of Geode, how do I know which version of the
> documentation I must download which will be consistent with the code?
>
> Having both the docs and the code in the same repo makes the above
> question a no-brainer. But if code and documentation do not go hand by
> hand, how will we know?
>
> Alberto
> ____
> From: Dave Barnes 
> Sent: Wednesday, June 15, 2022 11:06 PM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo
>
> Adopting a policy that allows changes to doc sources after code freeze
> would address my primary complaint about the present system.
> Updating the User Guide at the time a user-visible code change is
> implemented is a helpful step toward keeping the docs up-to-date with the
> code, but is not sufficient.
> Above and beyond individual enhancements, the user guide addresses topics
> such as system configuration, upgrades, and the like. Such higher-level
> topics are often modified asynchronously from code releases, as are typo
> and format repairs. For such asynchronous updates, the fact that the doc
> sources are located in the source repo is of little consequence. In fact,
> separate repos would allow separate revision histories, an advantage to
> both.
> One more consideration is the possibility of breaking the monolithic user
> guide into smaller separate publications, such as an installation guide,
> system management/administration guide, developer's guide, advanced topics,
> etc. A change like this would be easier if it started from a docs-only
> repo.
> Did any of those thoughts change anyone's mind?
>
> On Wed, Jun 15, 2022 at 12:29 AM Owen Nichols  >
> wrote:
>
> > 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 constr

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

[Dave Barnes]

I think the committer list, like the PMC membership, is shared across all
the Geode-related sites. The geode-docs site would be added to this list.
>From the "Committers" link on Geode "Community" page (
https://geode.apache.org/community/):
Repositories managed by this Committee (from ASF Git mirrors
<https://git.apache.org/>):

   - geode: https://gitbox.apache.org/repos/asf/geode.git
   - geode-benchmarks:
   https://gitbox.apache.org/repos/asf/geode-benchmarks.git
   - geode-dotnet-core-client:
   https://gitbox.apache.org/repos/asf/geode-dotnet-core-client.git
   - geode-examples: https://gitbox.apache.org/repos/asf/geode-examples.git
   - geode-kafka-connector:
   https://gitbox.apache.org/repos/asf/geode-kafka-connector.git
   - geode-native: https://gitbox.apache.org/repos/asf/geode-native.git
   - geode-site: https://gitbox.apache.org/repos/asf/geode-site.git
   - geode-svn: https://svn.apache.org/repos/asf/geode/


On Thu, Jun 16, 2022 at 6:08 AM Joris Melchior 
wrote:

> I like this idea. I agree that changes to documentation are different from
> changes to code, and documentation should be able to move in a different
> cadence.
>
> Would committers to Geode and Geode-docs be the same after this proposed
> change?
>
> Joris Melchior
>
> From: Dave Barnes 
> Date: Tuesday, June 14, 2022 at 3:14 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%2Fgeodedata=05%7C01%7Cjmelchior%40vmware.com%7C54eb53d60ca94a1b157308da4e3a1593%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637908308627227614%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=2JRX3rpAptf1Sa0EmEPJnDu%2B3mS%2FsEB83M2warTTni4%3Dreserved=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 when critical last-minute doc changes
> are needed, but such changes are forbidden due to the code freeze.
>
> I have participated in the Geode project since its inception, and can
> confidently state that this conflict arises with nearly every Geode
> release. Setting up the docs in a separate repo would alleviate this
> regularly-recurring, counter-intuitive situation.
>
> Of note: The docs directories and toolset are almost entirely independent
> of directories and tools needed for code development and release, so
> removal of the doc sources from the Geode code repo should be painless for
> developers.
>
> Observations and opinions welcome...
>
> Dave Barnes
>
> 
>
> ⚠ External Email: This email originated from outside of the organization.
> Do not click links or open attachments unless you recognize the sender.
>

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

[Dave Barnes]

Adopting a policy that allows changes to doc sources after code freeze
would address my primary complaint about the present system.
Updating the User Guide at the time a user-visible code change is
implemented is a helpful step toward keeping the docs up-to-date with the
code, but is not sufficient.
Above and beyond individual enhancements, the user guide addresses topics
such as system configuration, upgrades, and the like. Such higher-level
topics are often modified asynchronously from code releases, as are typo
and format repairs. For such asynchronous updates, the fact that the doc
sources are located in the source repo is of little consequence. In fact,
separate repos would allow separate revision histories, an advantage to
both.
One more consideration is the possibility of breaking the monolithic user
guide into smaller separate publications, such as an installation guide,
system management/administration guide, developer's guide, advanced topics,
etc. A change like this would be easier if it started from a docs-only repo.
Did any of those thoughts change anyone's mind?

On Wed, Jun 15, 2022 at 12:29 AM Owen Nichols 
wrote:

> 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)

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

[Dave Barnes]

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%2Fgeodedata=05%7C01%7Cjblum%40vmware.com%7Cb6ae14ef841e416fb22208da4e3a2bb4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637908308999514633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=vWegMzha9uIc8JMMAYhgxU20V9beAoSbAFOK5aORAfc%3Dreserved=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 when critical last-minute doc changes
> are needed, but such changes are forbidden due to the code freeze.
>
> I have participated in the Geode project since its inception, and can
> confidently state that this conflict arises with nearly every Geode
> release. Setting up the docs in a separate repo would alleviate this
> regularly-recurring, counter-intuitive situation.
>
> Of note: The docs directories and toolset are almost entirely independent
> of directories and tools needed for code development and release, so
> removal of the doc sources from the Geode code repo should be painless for
> developers.
>
> Observations and opinions welcome...
>
> Dave Barnes
>
> 
>
> ⚠ External Email: This email originated from outside of the organization.
> Do not click links or open attachments unless you recognize the sender.
>

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

[Dave Barnes]

I'd like to move the doc sources for the Geode User Guide from the code
repo (https://github.com/apache/geode) 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 when critical last-minute doc changes
are needed, but such changes are forbidden due to the code freeze.

I have participated in the Geode project since its inception, and can
confidently state that this conflict arises with nearly every Geode
release. Setting up the docs in a separate repo would alleviate this
regularly-recurring, counter-intuitive situation.

Of note: The docs directories and toolset are almost entirely independent
of directories and tools needed for code development and release, so
removal of the doc sources from the Geode code repo should be painless for
developers.

Observations and opinions welcome...

Dave Barnes

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

[Dave Barnes]

I regularly contribute to the documentation, and I support this change.
Removal of the experimental Redis module would lighten the burden for those
who maintain the Geode documentation.

On Thu, Apr 14, 2022 at 10:39 PM Owen Nichols  wrote:

> 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<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben.balter.com%2F2016%2F07%2F21%2Fremoving-a-feature-is-a-feature%2Fdata=05%7C01%7Conichols%40vmware.com%7C446f816dd25e4b44826908da1e95e1f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637855926345514685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=rherU8SIujYGLQXkXgIUPCBUtHvMaSy71FQkIvvSWjc%3Dreserved=0>.
> Dependencies might need to be updated; flaky tests fixed and it brings
> cognitive overhead for us and our users. Unless someone else in the
> community steps up to take on the task of maintaining the geode-redis
> module, I propose to remove the code from our develop branch and give
> everyone more bandwidth to use elsewhere.
>
> Thank you all in advance for your thoughts
>

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

[Dave Barnes]

+1 Docs
Binary release contains correctly-versioned javadocs
Source release builds user guide correctly from command line and docker
script

On Thu, Mar 17, 2022 at 3:19 PM Dan Smith  wrote:

> +1
>
> Ran smoketest_rc.sh
>
> -Dan
> 
> From: Eric Shu 
> Sent: Tuesday, March 15, 2022 5:01 PM
> To: dev@geode.apache.org 
> Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.14.4.RC1
>
> +1
>
> Run end to end test cases against the build without seeing new issues.
> 
> From: Donal Evans 
> Sent: Tuesday, March 15, 2022 4:25 PM
> To: dev@geode.apache.org 
> Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.14.4.RC1
>
> +1
>
> Confirmed that performance across a variety of workloads is on par with
> previous releases.
> 
> From: Dick Cavender 
> Sent: Tuesday, March 15, 2022 3:41 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.14.4.RC1
>
> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.14.4.RC1.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Fri, March 18 2022
>
> Please note that we are voting upon the source tag:
> rel/v1.14.4.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.4data=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Wnl3egRmvIsJqBEkzuqU9VNnjpeCPW34oIrxOPCV47U%3Dreserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.14.4.RC1%2Fdata=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=PJlhXtl9kdDSnacv1Uy%2BJHQssKXloX%2FQLhWpDmWZLQs%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1137data=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=eVwkf1B9oKtq4MAnjNio0Le9oBf8GzHVisXLos%2BjyAU%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.4.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=gcQa%2FsRJZIsdHiJHLzfY5XgtkxUqgJC9ffnYdL2tzj4%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.4.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=sTmANacnskx5hcuqERsyS7W95Q2PHU1rI2jMRz4ASqI%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.4.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=xG5hvbe2hOSNnBnM%2FJf3Xhh2DnBBAVZY39JESt%2FEHr4%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.4.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=55zB3B7e8N0fKDXqX1JNB8aU5d4%2FGt3ENfZCBvZkrxU%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-maindata=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=59XUNNB1uPqbDMQrh%2BKyT1j%2Bd%2FAOkcJ3bDOI5RSriP8%3Dreserved=0
>
> 

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

[Dave Barnes]

+1 docs are good
- Binary distribution contains properly-versioned javadocs
- Built user guide from source distribution by manual entry and by scripted
docker utility


On Wed, Mar 9, 2022 at 9:22 AM Dan Smith  wrote:

> +1
>
>
>   *   Ran smoketest_rc -
> https://github.com/apache/geode/tree/develop/dev-tools/release-testing
>   *   verified concourse build passed
>   *   looked at artifacts
>
>
> 
> From: Donal Evans 
> Sent: Wednesday, March 9, 2022 9:04 AM
> To: dev@geode.apache.org 
> Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.9.RC1
>
> +1
>
> Confirmed that performance is on par with previous releases for a variety
> of workloads
> 
> From: Dick Cavender 
> Sent: Friday, March 4, 2022 2:05 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.9.RC1
>
> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.12.9.RC1.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Wed, March 9 2022.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.9.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.9data=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0monUNkMQZqfVmpXKenmzA%2FUVqvU8kyTXXhT8Np%2B8ks%3Dreserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.9.RC1%2Fdata=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=KkuUpKBZCUFqFBARZfpPRQpmjtXeBViamrXRnwJ16KE%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1131data=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Aj6poeSKodYfIUsOXr8WfpwZP2dPpnk%2FwXJnzAx3rmw%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.9.RC1data=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=VN1dbUf4jwKAgHLauuLf0dd0KJct5yT3tMHeVixcCQc%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.9.RC1data=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=mwQbdBPM4BZppjAyAbMCk%2FzCgtnbnQaDNW9KX%2FrRpz4%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.9.RC1data=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Fsjno%2Br8iszz70EQaF%2BTMQg%2BjrWXhV6W3uHLY8JYwK0%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.9.RC1data=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=vayn8jXJs%2FWIu6uAas0zRa%2B4H47PEf6dJpt6%2BRwYItw%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=rf9kmVC44tdj7hiHQoEAgyEa%2FLYjyKAG9s56mSGVQFs%3Dreserved=0
>
> 

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

[Dave Barnes]

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

[Dave Barnes]

+1 docs
binary distribution contains API docs with correct version header
source distribution provides working script for building & previewing user
guide

On Mon, Jan 24, 2022 at 9:06 AM Donal Evans  wrote:

> +1
>
> Confirmed that performance across a variety of workloads is on par with
> previous releases.
> 
> From: Dick Cavender 
> Sent: Friday, January 21, 2022 9:25 AM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.14.3.RC1
>
> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.14.3.RC1.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Tuesday, January 25 2022
>
> Please note that we are voting upon the source tag:
> rel/v1.14.3.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.3data=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=j5LpgLLJ5HyohirEoSu4f67c6FAx12prlfpb5zI2QZY%3Dreserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.14.3.RC1%2Fdata=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=1stKj1J2i115zjK%2Bcx4xvGsBoPwbRkB2%2F4BYS1AkOF8%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1128data=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Dv1xXcR7Ylo%2Fax9KKHU4i0Mv8SdwSDYXpiamP1912CE%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.3.RC1data=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=yFWl932ocYn6v9DvDlMFWGX9SDnLmBm6Inzsb7o346A%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.3.RC1data=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ocbN2bo9ud7O7zj0LyQmpPMlrJL%2Ba7J%2B%2FH6LAFrelMw%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.3.RC1data=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2BKfOx4amXgkERqAbgvtUBH0w9YawVAtcT8srTm2BXUQ%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.3.RC1data=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0mHfFYU13%2BVf%2Fni3STqLHqXYs%2Bkt92s42btwtdPoBE0%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-maindata=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=vz%2FDJ9IiVQJy1ssCjKXFvXdcODgGFdij8KpUk4If9K4%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-rcdata=04%7C01%7Cdoevans%40vmware.com%7C22e4716d6d62494a7f0008d9dd0306af%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637783827347507814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=t0ih5l%2FwiUirz4493xIMd1x8xA7GcXc4l2m3quOFQuE%3Dreserved=0
>
> Geode's KEYS file containing PGP keys we use to sign the 

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

[Dave Barnes]

+1 Checked docs:
source release:
- Built user guide with dev-tools script
- Verified that the latest version of log4j is correctly referenced in the
Logging section
binary release:
- verified that API docs have correct version header.


On Wed, Jan 19, 2022 at 4:50 PM Kirk Lund  wrote:

> +1 same as Naba
>
> On Wed, Jan 19, 2022 at 4:26 PM Nabarun Nag  wrote:
>
> > +1 based on the results of the pipeline tests.
> >
> > Regards
> > Nabarun Nag
> >
> > 
> > From: Dick Cavender 
> > Sent: Monday, January 17, 2022 11:20 AM
> > To: dev@geode.apache.org 
> > Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.7.RC1
> >
> > Hello Geode Dev Community,
> >
> > This is a release candidate for Apache Geode version 1.13.7.RC1.
> > Thanks to all the community members for their contributions to this
> > release!
> >
> > Please do a review and give your feedback, including the checks you
> > performed.
> >
> > Voting deadline:
> > 3PM PST Thursday, January 20 2022.
> >
> > Please note that we are voting upon the source tag:
> > rel/v1.13.7.RC1
> >
> > Release notes:
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.7data=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=V5yh9gXa39eKG7MY0uXruCe0qgODD3ef94YwMJcoKRw%3Dreserved=0
> >
> > Source and binary distributions:
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.7.RC1%2Fdata=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=NhGIBZQCPTvIdXFaxCTYqatC13cJkrjyx4AVgKk5698%3Dreserved=0
> >
> > Maven staging repo:
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1126data=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=rpF5i%2B1MUSkt%2FTU%2BKSv9d%2BjLiO3Vt8KPHXhSnMcBfhM%3Dreserved=0
> >
> > GitHub:
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.7.RC1data=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=cDmYAZN8vKLs5bRVmOPDGw6YshASiNiXX9I7PoxGZyc%3Dreserved=0
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.7.RC1data=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6WKvYUp52vm0qhBeNJKkAZYMiagI7hp1d7UIizTvAqw%3Dreserved=0
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.7.RC1data=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ZsDwPqv6gq%2B9z9g30M5xHAtT2e3T5AepXheqob2m8j0%3Dreserved=0
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.7.RC1data=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=hCAbePGsAZllyrXVhQoiuq%2BBANvLe%2BcpQQ0puQCeps0%3Dreserved=0
> >
> > Pipelines:
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-maindata=04%7C01%7Cnnag%40vmware.com%7Ca9dee05fec1f4851e8ca08d9d9ee6cea%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637780440337254741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=7C8JYijQu0VFpObgZj3GQDI%2FicP48lFcbn7Ji60%2FuXI%3Dreserved=0
> >
> >
> 

Re: [VOTE] Apache Geode 1.12.8.RC1

[Dave Barnes]

+1 from a docs standpoint.
In the source distribution, successfully built the user guide using the
dev-tools/docker/docs/preview-user-guide.sh script.
In the binary distribution, viewed the javadocs and verified correct
version headers.

On Mon, Jan 10, 2022 at 3:34 PM Dick Cavender  wrote:

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.12.8.RC1.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Thu, January 13 2022.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.8.RC1
>
> Release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.8
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/geode/1.12.8.RC1/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1124
>
> GitHub:
> https://github.com/apache/geode/tree/rel/v1.12.8.RC1
> https://github.com/apache/geode-examples/tree/rel/v1.12.8.RC1
> https://github.com/apache/geode-native/tree/rel/v1.12.8.RC1
> https://github.com/apache/geode-benchmarks/tree/rel/v1.12.8.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.8.RC1
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1124
> build runAll
>
> Regards
> Dick Cavender
>

Re: [VOTE] Apache Geode 1.12.5.RC1

[Dave Barnes]

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


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

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.12.5.RC4.
> Earlier RC1, RC2 and RC3 had issues.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Mon, October 25 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.5.RC4
>
> Release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.5
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/geode/1.12.5.RC4/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1113
>
> GitHub:
> https://github.com/apache/geode/tree/rel/v1.12.5.RC4
> https://github.com/apache/geode-examples/tree/rel/v1.12.5.RC4
> https://github.com/apache/geode-native/tree/rel/v1.12.5.RC4
> https://github.com/apache/geode-benchmarks/tree/rel/v1.12.5.RC4
>
> 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.5.RC4
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1113
> build runAll
>
> Regards
> Dick Cavender
>
>

Re: Requesting eligibility for JIRA ticket assignment

[Dave Barnes]

+1
Kaustubh's contribution was a good one.

On Thu, Sep 23, 2021 at 8:26 AM Kaustubh Maske Patil 
wrote:

> Hi,
> I recently made my first contribution to apache/geode on ticket GEODE-9619
> and would like to request eligibility for assignment to that ticket, and
> hopefully more in the future :)
>
> This is my GitHub profile https://github.com/nikochiko
>
> Thanks!
>
> Best,
> Kaustubh Maske Patil
>

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

[Dave Barnes]

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://issues.apache.org/jira/browse/GEODE-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408388#comment-17408388
]

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

davebarnes97 merged pull request #10:
URL: https://github.com/apache/geode-site/pull/10





-- 
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://issues.apache.org/jira/browse/GEODE-6402
> 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://projects.apache.org/create.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Odg: [VOTE] Apache Geode 1.14.0.RC2

[Dave Barnes]

+1 docs

   - Verified API docs
   - Built Geode User Guide using script, verified
   - Built Geode Native User Guides (C++, .NET) using script, verified


On Wed, Sep 1, 2021 at 12:51 AM Mario Kevo  wrote:

> +1
>
>
>   *   build from the source
>   *   run gfsh
>   *   run geode-examples
>
> 
> Šalje: Donal Evans 
> Poslano: 1. rujna 2021. 2:49
> Prima: dev@geode.apache.org 
> Predmet: Re: [VOTE] Apache Geode 1.14.0.RC2
>
> +1
>
> Validated that performance across a range of workloads is equivalent to
> previous releases
> 
> From: nabarun nag 
> Sent: Tuesday, August 31, 2021 5:36 PM
> To: dev@geode.apache.org 
> Subject: [VOTE] Apache Geode 1.14.0.RC2
>
> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.14.0.RC2.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline: Please note that this is an expedited voting process
> 3PM PST Thur, September 02 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.14.0.RC2
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.0data=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=cJWZ%2BgtEEKontEsDKm0y3YOvnVZ6cFeF5WzjVZF41f8%3Dreserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.14.0.RC2%2Fdata=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=seJKNwaisxT0g9tMJpsg2O9fZEpB3JONZTMlFTIU6D0%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1098data=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kZ6HTEZj0OdEM0ZgGm4TMcfwwvHAlvzfMWabn1549Cw%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3dZJbHhEYbKalCW7R9Zaqnm6Y4TRgIDCnW6%2BX1Gynrk%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=F0H7s%2Fid%2FM613DshfSFF88DJ8VF7rA1iTmX%2BM6OCZvM%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=syiMhfgtMnu0RRcOYJOHJV24UKfX1TO%2FEaIFxkqlL2Q%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Bt2rS4kMZPtLXST1VHUEBBUpBeRAJN%2FlzJTw%2Bxy6p6Q%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-maindata=04%7C01%7Cdoevans%40vmware.com%7Cf1388b1204f94c02180a08d96ce0a654%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534388597789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7MbP67Duzw7syMknmQyssHu8n42Q2aBblsUy1NlFc28%3Dreserved=0
>
> 

Re: Questions about conserve-sockets and WAN replication

[Dave Barnes]

Alberto,
As you point out, the recommendation to use `conserve-sockets=false` in WAN
configurations already appears in at least three places in the Geode User
Guide.
We can insert an additional mention into the guide -- did you have a
location in mind (sorry, this is an old thread and I don't recall whether
we already discussed this).

With regard to function execution ignoring the global setting, I suspect
that changing function behavior would break existing applications, so that
is probably not an option here.
Again, if you help me identify locations in the doc where you think we need
to insert a note regarding this behavior, we can do that.

Let's state these changes in one or two JIRA tickets for the docs
component. I'm happy to work with you on creating that ticket, but need
your help in identifying target locations in the guide.
Thanks,
Dave


On Thu, Aug 26, 2021 at 2:28 AM Alberto Gomez 
wrote:

> @Dave Barnes<mailto:dav...@vmware.com>, sorry for not having answered to
> your e-mail before.
>
> I am missing the following in the referred documentation:
>
>   *   State that conserve-sockets must be set to false for members that
> participate in a WAN deployment as it is stated in other parts of the
> documentation (see
> ./geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb
> ./geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb
> ./geode-docs/reference/topics/gemfire_properties.html.md.erb):
>   *   "To avoid hangs related to WAN messaging, always use the default
> setting of conserve-sockets=false for
> <%=vars.product_name%> members that participate in a WAN deployment."
>
> @dev@geode.apache.org<mailto:dev@geode.apache.org>, besides the above, I
> think the documentation is missing a very important piece of information
> that I have found in [1]:
> "even with conserve-sockets set to false, function executions do not use
> this setting and defaults to conserve-sockets=true behavior, regardless of
> the conserve-sockets setting. "
> and in [2]:
> "a Function Execution Processor does not honor the conserve-sockets
> setting so a shared P2P message reader is used in the remote server"
>
> I wonder if this should be stated in the Geode documentation or rather if
> function execution behavior should be changed to honor the conserve-sockets
> setting.
> Any thoughts on this?
>
> Best regards,
>
> Alberto
>
> [1]
> https://community.pivotal.io/s/article/GemFire-Function-Executions-and-conserve-sockets-behavior?language=en_US
> [2]
> https://medium.com/swlh/threads-used-in-apache-geode-function-execution-9dd707cf227c#bd8c
>
>
>   *
>
> 
> From: Dave Barnes 
> Sent: Wednesday, July 7, 2021 1:05 AM
> To: dev@geode.apache.org 
> Subject: Re: Questions about conserve-sockets and WAN replication
>
> Alberto,
> I recently updated some of the descriptions regarding conserve-sockets.
> Please check out this PR and see if it addresses any of your concerns.
> https://github.com/apache/geode/pull/6516
>
> On Tue, Jul 6, 2021 at 9:57 AM Alberto Gomez 
> wrote:
>
> > Hi,
> >
> > The Geode documentation states the following about conserve-sockets and
> > WAN deployments in [1]:
> >
> > "WAN deployments increase the messaging demands on a Geode system. To
> > avoid hangs related to WAN messaging, always set `conserve-sockets=false`
> > for Geode members that participate in a WAN deployment."
> >
> > Could anyone please provide some more detailed information about why and
> > where these hangs could happen? Is this a hard limitation or something to
> > be considered under certain circumstances?
> >
> > We have run into an unexpected situation which we wonder if it is related
> > to the documentation statement above:
> >
> > In a system like the following:
> >  - 2 WAN sites and 3 servers each
> >  - several partitioned regions with parallel senders
> >  - several replicated regions with serial senders
> >  - conserve-sockets set to true
> >
> > We have sometimes observed, when trying to stop a parallel gateway sender
> > while puts are being sent to both sites, that the thread stopping the
> > gateway sender in one of the members gets stuck waiting to receive a
> reply
> > from the other members (trying to get the size of the queue, see [2]). We
> > see also other threads stuck, some trying to get a lock held by the stuck
> > thread and others waiting in
> > ReplyProcessor21.waitForRepliesUninterruptibly() trying to put or get
> data
> > remotely (See [3] and [4]).
> > If we set conserve-sockets to false we do not expe

Re: [VOTE] Apache Geode 1.13.4.RC1

[Dave Barnes]

+1 docs
Built the user guide, by hand and with preview script.
Verified correct version string in javadocs.

On Wed, Jul 28, 2021 at 3:43 PM Donal Evans  wrote:

> +1
>
> Confirmed that performance across a variety of workloads is on par with
> previous releases.
> 
> From: Dick Cavender 
> Sent: Wednesday, July 28, 2021 2:49 PM
> To: dev@geode.apache.org 
> Subject: [VOTE] Apache Geode 1.13.4.RC1
>
> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.13.4.RC1.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Fri, July 30 2021
> *NOTE: THIS IS AN  ABBREVIATED 2 DAY VOTE *
>
> Please note that we are voting upon the source tag:
> rel/v1.13.4.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.4data=04%7C01%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682790133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=pZ6rcGwVcvkIZCtZpjPLAGQXXLQz606sc5eay7l6%2FNo%3Dreserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.4.RC1%2Fdata=04%7C01%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682790133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=tqdIEWvexyzD4KFpzvJrdXWMTZq%2FkgfE%2BhE2%2F6nm2yA%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1087data=04%7C01%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682790133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sIiSNWwjMGlgJLu004vHXzmZe9Ea%2FS5%2BC25rlsRNsiE%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.4.RC1data=04%7C01%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682790133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=gCEmjzi0idYaqcGPgj319JazeNYVPFyTMT12qTEYoEg%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.4.RC1data=04%7C01%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682800090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=u7JQrZFpvrnZkQuafC3YVOqkZLFJSXOGaTMPs9C8uAk%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.4.RC1data=04%7C01%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682800090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KdScjfvdSPhGeWZZKgI2qTFFnLBFCOLsVFXPQ1cgw7g%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.4.RC1data=04%7C01%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682800090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=l%2BC7Mdi5FK4%2FQJ6DpBHwED6Vg1x8atRm8u9Sgsuw4dk%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-maindata=04%7C01%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682800090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WTvSv4OSafEpuw1aSjRdsDV7dqxuzdjYlv3XCPA%2Fc7o%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-rcdata=04%7C01%7Cdoevans%40vmware.com%7C232cabf20f48420aeec508d9521191c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637631057682800090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kpSBlbt6fR1hnoERrNkdgzzQ%2BzwGBoNPy2V6lXA1hUs%3Dreserved=0
>
> Geode's KEYS file containing PGP keys we use to sign the release:
>
> 

Re: [VOTE] Apache Geode 1.12.4.RC1

[Dave Barnes]

+1 for geode docs
- Checked API docs (javadocs) for correct version in page headers
- Successfully ran user guide build script

+0 for geode-native docs
+0 for geode-examples
- For these last two, the build scripts are known to be broken, in the
first case due to a Bookbinder problem and in the second case due to a
versioning mismatch in the sessionState startup script. Both of these are
known to be fixed in later releases, so they should not be showstoppers for
this release candidate.

-

On Wed, Jul 21, 2021 at 4:35 PM Dick Cavender  wrote:

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.12.4.RC1.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> *3PM PST Mon, July 26 2021*
>
> Please note that we are voting upon the source tag:
> rel/v1.12.4.RC1
>
> Release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.4
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/geode/1.12.4.RC1/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1092
>
> GitHub:
> https://github.com/apache/geode/tree/rel/v1.12.4.RC1
> https://github.com/apache/geode-examples/tree/rel/v1.12.4.RC1
> https://github.com/apache/geode-native/tree/rel/v1.12.4.RC1
> https://github.com/apache/geode-benchmarks/tree/rel/v1.12.4.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.4.RC1
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1092
> build runAll
>
> Regards
> Dick Cavender
>

Re: Questions about conserve-sockets and WAN replication

[Dave Barnes]

Alberto,
I recently updated some of the descriptions regarding conserve-sockets.
Please check out this PR and see if it addresses any of your concerns.
https://github.com/apache/geode/pull/6516

On Tue, Jul 6, 2021 at 9:57 AM Alberto Gomez  wrote:

> Hi,
>
> The Geode documentation states the following about conserve-sockets and
> WAN deployments in [1]:
>
> "WAN deployments increase the messaging demands on a Geode system. To
> avoid hangs related to WAN messaging, always set `conserve-sockets=false`
> for Geode members that participate in a WAN deployment."
>
> Could anyone please provide some more detailed information about why and
> where these hangs could happen? Is this a hard limitation or something to
> be considered under certain circumstances?
>
> We have run into an unexpected situation which we wonder if it is related
> to the documentation statement above:
>
> In a system like the following:
>  - 2 WAN sites and 3 servers each
>  - several partitioned regions with parallel senders
>  - several replicated regions with serial senders
>  - conserve-sockets set to true
>
> We have sometimes observed, when trying to stop a parallel gateway sender
> while puts are being sent to both sites, that the thread stopping the
> gateway sender in one of the members gets stuck waiting to receive a reply
> from the other members (trying to get the size of the queue, see [2]). We
> see also other threads stuck, some trying to get a lock held by the stuck
> thread and others waiting in
> ReplyProcessor21.waitForRepliesUninterruptibly() trying to put or get data
> remotely (See [3] and [4]).
> If we set conserve-sockets to false we do not experience any hang.
>
> Could these stuck threads be related to what is stated in the
> documentation about WAN deployments and conserve-sockets set to true or
> should we rather think that it is an unrelated bug that needs to be solved?
>
> Thanks in advance for your help,
>
> Alberto
>
> [1]
> https://geode.apache.org/docs/guide/113/managing/monitor_tune/sockets_and_gateways.html
>
> [2]
> "ConcurrentParallelGatewaySenderEventProcessor Stopper Thread1" #1316
> daemon prio=10 os_prio=0 cpu=18.86ms elapsed=1544.80s
> tid=0x7f92bc1c2000 nid=0x2154 waiting on condition  [0x7f9179cd2000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method)
> - parking to wait for  <0x00031ca2be50> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.11
> /LockSupport.java:234)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(java.base@11.0.11
> /AbstractQueuedSynchronizer.java:1079)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base@11.0.11
> /AbstractQueuedSynchronizer.java:1369)
> at java.util.concurrent.CountDownLatch.await(java.base@11.0.11
> /CountDownLatch.java:278)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.partitioned.SizeMessage$SizeResponse.waitBucketSizes(SizeMessage.java:344)
> at
> org.apache.geode.internal.cache.PartitionedRegion.getSizeRemotely(PartitionedRegion.java:6758)
> at
> org.apache.geode.internal.cache.PartitionedRegion.entryCount(PartitionedRegion.java:6709)
> at
> org.apache.geode.internal.cache.PartitionedRegion.entryCount(PartitionedRegion.java:6691)
> at
> org.apache.geode.internal.cache.PartitionedRegion.getRegionSize(PartitionedRegion.java:6663)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.entryCount(LocalRegionDataView.java:99)
> at
> org.apache.geode.internal.cache.LocalRegion.entryCount(LocalRegion.java:2078)
> at
> org.apache.geode.internal.cache.LocalRegion.size(LocalRegion.java:8301)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.size(ParallelGatewaySenderQueue.java:1670)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.closeProcessor(AbstractGatewaySenderEventProcessor.java:1259)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.stopProcessing(AbstractGatewaySenderEventProcessor.java:1247)
> at
> 

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

[Dave Barnes]

+1
User Guide build scripts are broken, but this is a known bug and should not
delay the release.
A compiled 1.12 User Guide is available on the website, and a knowledgeable
user can build manually as a workaround.
I have back-ported the fix to 1.12 from 1.13, so in the event of a new
release candidate or new 1.12.x patch release, the problem will no longer
exist.

On Mon, Jun 28, 2021 at 11:00 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.
>
>
> 
> From: Owen Nichols 
> Sent: Friday, June 25, 2021 1:15 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.3.RC3
>
> Hello Geode Dev Community,
>
> I'd like to propose a 1.12 patch release.
>
> This is a release candidate for Apache Geode version 1.12.3.RC3.
> Note: This is the first vote email due to a build issue with the first two
> RCs.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PDT Wed, June 30 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.3.RC3
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=HS9vNQnqaQ61%2F6t6dS%2F5A8DxugClKwc%2BrJMXnaLVs7Q%3Dreserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.3.RC3%2Fdata=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=56Fa2%2BC%2Bv2uCLxa6iRchEynUS%2B6OZAspwmwXzsya4eM%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1084data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=iqjfSfVDYzuaj%2FzJs8YRLedEGBmI%2Fr4xTLFWMgRqzEg%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KLkcUfgn1ZkXB6OBwOVzkECUCd1xU7YZWd1mc%2FZAlIU%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=AQ8H4jHhSPm9f9evixDBNQJdJl0cWLOwGey8%2BkSf9Y0%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8IykbiM2prxCQ1tMM%2Ft15gryVmvc6jUFjegwplbBxGw%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.3.RC3data=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Gxw%2FT0BQPjiOmjlR8Sv4jwGj0wm8Z%2BSW4FUUnBQh8QE%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cnnag%40vmware.com%7Ce430c96afebf48ee4afa08d938160689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637602489520416316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=y6ln0WC5b%2BVKdgIOR6W%2BLTbI4IUhG0p0u1A8YiqhDdk%3Dreserved=0
>
> 

Re: [VOTE] Apache Geode 1.13.3.RC2

[Dave Barnes]

+1 user guide build script works as it should.

On Wed, Jun 23, 2021 at 4:45 PM Robert Houghton 
wrote:

> +1
> I like the build. I verified the output of the RC check jobs, and matched
> against the source SHA we are trying to publish.
>
>
> From: Owen Nichols 
> Date: Wednesday, June 23, 2021 at 11:56 AM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [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://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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.3.RC2data=04%7C01%7Crhoughton%40vmware.com%7C0292ff4088f3455ba36a08d9367889de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637600713602836651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=dfnMLCKjve7vyaMZJyE6aAe70FPU8NT04I05fePqJ9c%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.3.RC2data=04%7C01%7Crhoughton%40vmware.com%7C0292ff4088f3455ba36a08d9367889de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637600713602836651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=uKcpcjIrfEgr7Hfb5qVn28v3MdUNISbzRtENapC0Fak%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.3.RC2data=04%7C01%7Crhoughton%40vmware.com%7C0292ff4088f3455ba36a08d9367889de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637600713602836651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=dBthKohpFT%2BemN5pxQifpccj%2BdJmgdFgByiatSkOFw4%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.3.RC2data=04%7C01%7Crhoughton%40vmware.com%7C0292ff4088f3455ba36a08d9367889de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637600713602836651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=oHp%2B2QTu3r2P9WSjQxbvS3B8EStFpeidmciANXa9mcw%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-maindata=04%7C01%7Crhoughton%40vmware.com%7C0292ff4088f3455ba36a08d9367889de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637600713602836651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=UY%2FEWf7l8tfJW%2BU%2BbiD3a%2BqfnDijHIICWQ5MVa6Y6es%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-rcdata=04%7C01%7Crhoughton%40vmware.com%7C0292ff4088f3455ba36a08d9367889de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637600713602836651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=7Q%2Bj4ZF1zzc0syizXDJ5b1BdKjeAi1PXUnUcwfRnL9c%3Dreserved=0
>
> Geode's KEYS file containing PGP keys we use to sign the release:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2FKEYSdata=04%7C01%7Crhoughton%40vmware.com%7C0292ff4088f3455ba36a08d9367889de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637600713602836651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=nOBSS%2Fo3Ld5cZlUujvQ%2Fa8NmSifuUE6Jie1xOl1fCnc%3Dreserved=0
>
> 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: [NOTICE] Git web site publishing to be done via .asf.yaml only as of July 1st

[Dave Barnes]

We're on the green list -- we've been compliant since Oct 2019.

On Mon, May 31, 2021 at 8:08 AM Anthony Baker  wrote:

> I believe we will need to update the geode-site repo.
>
>
> Begin forwarded message:
>
> From: Daniel Gruno 
> Date: May 31, 2021 at 7:41:05 AM MDT
> To: Users 
> Subject: [NOTICE] Git web site publishing to be done via .asf.yaml only as
> of July 1st
> Reply-To: priv...@geode.apache.org
>
> TL;DR: if your project web site is kept in subversion, disregard this
> email please. If your project web site is using git, and you have not
> deployed it via .asf.yaml, you MUST switch before July 1st or risk your web
> site goes stale.
>
>
>
> Dear Apache projects,
> In order to simplify our web site publishing services and improve
> self-serve for projects and stability of deployments, we will be turning
> off the old 'gitwcsub' method of publishing git web sites. As of this
> moment, this involves 120 web sites. All web sites should switch to our
> self-serve method of publishing via the .asf.yaml meta-file. We aim to turn
> off gitwcsub around July 1st.
>
>
> ## How to publish via .asf.yaml:
> Publishing via .asf.yaml is described at:
> https://s.apache.org/asfyamlpublishing
> You can also see an example .asf.yaml with publishing and staging profiles
> for our own infra web site at:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Finfrastructure-website%2Fblob%2Fasf-site%2F.asf.yamldata=04%7C01%7Cbakera%40vmware.com%7C3c9e5ce4e2b04461fb5a08d92439bc68%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637580652653660482%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8rmWnJv6TUUJ1CnHboqk5bOhb0YrObQN3Kfq3JESq34%3Dreserved=0
>
> In short, one puts a file called .asf.yaml into the branch that needs to
> be published as the project's web site, with the following two-line
> content, in this case assuming the published branch is 'asf-site':
>
> publish:
>  whoami: asf-site
>
>
> It is important to note that the .asf.yaml file MUST be present at the
> root of the file system in the branch you wish to publish. The 'whoami'
> parameter acts as a guard, ensure that only the intended branch is used for
> publishing.
>
>
> ## Is my project affected by this?
> The quickest way to check if you need to switch to a .asf.yaml approach is
> to check out site source page at
> https://infra-reports.apache.org/site-source/ - if your site is listed in
> yellow, you will need to switch. This page will also tell you which branch
> you are currently publishing as your web site. This is (should be) the
> branch that you must add a .asf.yaml meta file to.
>
> The web site source list updates every hour. If your project site appears
> in green, you are already using .asf.yaml for publishing and do not need to
> make any changes.
>
>
> ## What happens if we miss the deadline?
> If you miss the deadline, don't fret. Your site will of course still
> remain online as is, but new updates will not appear till you create/edit
> the .asf.yaml and set up publishing.
>
>
> ## Who do we contact if we have questions?
> Please contact us at us...@infra.apache.org if you have any additional
> questions.
>
>
> With regards,
> Daniel on behalf of ASF Infra.
>

Apache Geode Board Report, May 2021

[Dave Barnes]

This is the final report as published to the Apache Board Agenda:

## 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:
Karen Miller notified the PMC on 7-April-2021 of her intent to resign from
the
position of PMC Chair. Karen has held the position since Dec 2018. The
community
solicited nominations and conducted an election.
A resolution has been submitted separately from this report naming
Dan Smith (upthewaterspout) as the new Apache Geode PMC Chair.

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

Community changes, past quarter:
- Donal Evans was added to the PMC on 2021-03-22
- Alberto Gomez was added as committer on 2021-02-17
- Kamilla Aslami was added as committer on 2021-04-19
- Matthew Reddington was added as committer on 2021-03-24
- Ray Ingles was added as committer on 2021-03-18
- Bruce Schuchardt resigned from the PMC on 2021-04-28;
  he remains a committer on the project.

## Project Activity:
Three releases of Apache Geode were issued during this reporting period.
Work areas included:
- Improvements to existing tests and addition of new ones
- Improvements to WAN replication
- Several bug fixes and improvements in the area of disaster recovery and
  restart

Recent releases:
- 1.13.2 was released on 2021-03-29.
- 1.12.1 was released on 2021-02-26.
- 1.12.2 was released on 2021-04-22.

## Community Health:
Initiatives during this period include:
- Implementation of CODEOWNERS and CODEWATCHERS lists to facilitate PR
reviews
- For the geode-native client, ongoing discussions regarding C++ version
support
and coding standards

These initiatives and the releases listed above are reflected in Apache
Geode repository activity:
- 308 issues opened in JIRA, past quarter (30% increase)
- 236 issues closed in JIRA, past quarter (6% increase)
- 691 commits in the past quarter (50% increase)
- 62 code contributors in the past quarter (10% increase)
- 488 PRs opened on GitHub, past quarter (29% increase)
- 478 PRs closed on GitHub, past quarter (28% increase)

PMC member Barry Ogelesby published [Transmitting Deltas Between Different
Apache Geode Distributed
Systems](
https://medium.com/@boglesby_2508/transmitting-deltas-between-different-apache-geode-distributed-systems-e46a3eae931
)
on 23-March-2021.

[DRAFT] Geode Board Report

[Dave Barnes]

This is a review draft of our report to the Apache Board on the Geode
project. Please send me your feedback by Monday, May 10.
In particular, let me know if I omitted any publications or community
outreach efforts.
Thanks,
Dave

## 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:
Karen Miller notified the PMC on 7-April-2021 of her intent to resign from
the
position of PMC Chair. Karen has held the position since Dec 2018. The
community
solicited nominations and conducted an election.
A resolution has been submitted separately from this report naming
Dan Smith (upthewaterspout) as the new Apache Geode PMC Chair.

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

Community changes, past quarter:
- Donal Evans was added to the PMC on 2021-03-22
- Alberto Gomez was added as committer on 2021-02-17
- Kamilla Aslami was added as committer on 2021-04-19
- Matthew Reddington was added as committer on 2021-03-24
- Ray Ingles was added as committer on 2021-03-18

## Project Activity:
Three releases of Apache Geode were issued during this reporting period.
Work areas included:
- Improvements to existing tests and addition of new ones
- Improvements to WAN replication
- Several bug fixes and improvements in the area of disaster recovery and
  restart

Recent releases:
- 1.13.2 was released on 2021-03-29.
- 1.12.1 was released on 2021-02-26.
- 1.12.2 was released on 2021-04-22.

## Community Health:
Initiatives during this period include:
- Implementation of CODEOWNERS and CODEWATCHERS lists to facilitate PR
reviews
- For the geode-native client, ongoing discussions regarding C++ version
support
and coding standards

These initiatives and the releases listed above are reflected in Apache
Geode repository activity:
- 308 issues opened in JIRA, past quarter (30% increase)
- 236 issues closed in JIRA, past quarter (6% increase)
- 691 commits in the past quarter (50% increase)
- 62 code contributors in the past quarter (10% increase)
- 488 PRs opened on GitHub, past quarter (29% increase)
- 478 PRs closed on GitHub, past quarter (28% increase)

PMC member Barry Ogelesby published [Transmitting Deltas Between Different
Apache Geode Distributed
Systems](
https://medium.com/@boglesby_2508/transmitting-deltas-between-different-apache-geode-distributed-systems-e46a3eae931
)
on 23-March-2021.

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

[Dave Barnes]

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

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

> +1
>
> Confirmed that performance in multiple scenarios is on par with the
> previous 1.12 release.
> 
> From: Owen Nichols 
> Sent: Wednesday, April 14, 2021 3:38 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1
>
> Hello Geode Dev Community,
>
> Geode’s support/1.12 has gathered a few more fixes since 1.12.1 was
> released two months ago.  I’d like to propose another patch release.
>
> This is a release candidate for Apache Geode version 1.12.2.RC1.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback (including the checks you
> performed).
>
> Voting deadline:
> 3PM PDT Mon, April 19 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.2.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.2data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=FrmRSQZPUtL3pciiAZ7LnGokKWITJgbl6N9KNdCBidQ%3Dreserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.2.RC1%2Fdata=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0dc%2FB9Hnf1wK4NpLXBUpy7v7H1xj9btZgsf1EjHW2IY%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1080data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=2T06JC%2BaRCVgViSmbwDqP6Z%2F6Y10zeIlOaTNpVwWkRA%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=VyruqqFrBFtwop5L9dPW%2BUI69D2ijqZS7rf1ZnHIloM%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=keT%2FsAuuqJ2jh1OAQgyAysVqNHqP%2BSJzlV%2F%2B6Yfjc9k%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=r8HofpAFHtOKoKaeDmZFQx3x%2FLViCem3fwB5Hd1Zjvs%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.2.RC1data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=fHlniSX58ttlHa1PegR5fY5y2ISh0hU8uPUH%2FQHsldg%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Ck4trXdfeLSrRB%2BZBU3gytEmfDHN3E52Dw6tYjKxeu0%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rcdata=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Fg7B1wfQN09lrTi%2FhvdtwdiPj8DCZjq5dD9YDjTU1FQ%3Dreserved=0
>
> Geode's KEYS file 

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

[Dave Barnes]

I STRONGLY AGREE with avoiding Jira ticket numbers in code comments.
In an open-source system, code comments function as user-visible
documentation (whether or not they're flagged for inclusion in the
Javadocs), so rather than resorting to a ticket number in place of an
explanation, provide the explanation.
Thanks Hale!

On Tue, Mar 30, 2021 at 4:16 PM Donal Evans  wrote:

> +1
>
> In theory, every commit is now associated with a GEODE jira ticket, so
> leaving a comment in the code when putting in a fix saying that it's for
> that ticket is redundant. Good commit names and messages would provide the
> broader context for changes, and regular comments that don't refer to a
> ticket at all can provide the fine-detail explanation that's sometimes
> needed to clarify code.
> 
> From: Hale Bales 
> Sent: Tuesday, March 30, 2021 2:24 PM
> To: dev@geode.apache.org 
> Subject: Deleting old references to ticket numbers and avoiding new ones
>
> Hi all,
>
> I have noticed in the past that there are a lot of ticket numbers in the
> code (along the lines of "fixes #") that reference tickets in a system that
> very few people still have access to. Since the average Geode developer
> does not have access to this system, having these in the code does not
> provide any value. I would like to propose that we remove all references to
> old ticket numbers when we come across them. If you happen to be one of the
> few people with access to this information, you could potentially remove
> the reference to the ticket number and add a note about the contents of
> that ticket. Finally, I would like to propose that we work to avoid this
> issue in the future (in case we every stop using Jira) by avoiding having
> just the Jira ticket number in a comment. Instead, we should provide both
> the ticket number and a short description of that ticket so that we can get
> all the necessary information from the comment.
>
> ~hale (they/them)
>

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

[Dave Barnes]

For the record, docs impact is negligible. Protobuf was never documented in
the User Guides, and mentions in the API docs will disappear when those are
re-built along with the software.

On Tue, Mar 23, 2021 at 11:55 AM Bruce Schuchardt  wrote:

> Yes, that's a Go client for Geode.  I have already contacted the author
> and he's okay with our removing support for it in Geode.
>
> On 3/23/21, 11:49 AM, "Mario Salazar de Torres"
>  wrote:
>
> Given this is on stall
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-clientdata=04%7C01%7Cbruces%40vmware.com%7C5b6bc29594c5409b52af08d8ee2c6df5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637521221887355590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8mJbnOgZHtUiwcQ66bKoaA%2BpoF91S67zrrdTXhQUtPs%3Dreserved=0
> I'd say +1 for removal
> [
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Favatars.githubusercontent.com%2Fu%2F194656%3Fs%3D400%26v%3D4data=04%7C01%7Cbruces%40vmware.com%7C5b6bc29594c5409b52af08d8ee2c6df5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637521221887355590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sQl%2FRtdZ%2BsH8QtdhlKl3ZAVKWNzG7zpW6lyrCCTNmWU%3Dreserved=0
> ]<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-clientdata=04%7C01%7Cbruces%40vmware.com%7C5b6bc29594c5409b52af08d8ee2c6df5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637521221887355590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8mJbnOgZHtUiwcQ66bKoaA%2BpoF91S67zrrdTXhQUtPs%3Dreserved=0
> >
> GitHub - gemfire/geode-go-client<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-clientdata=04%7C01%7Cbruces%40vmware.com%7C5b6bc29594c5409b52af08d8ee2c6df5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637521221887355590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8mJbnOgZHtUiwcQ66bKoaA%2BpoF91S67zrrdTXhQUtPs%3Dreserved=0
> >
> What is this? This is the beginning of a Go client for Apache Geode.It
> uses Geode's new protobuf-based client protocol to communicate with
> locators and servers.
> github.com
>
> 
> From: Alexander Murmann 
> Sent: Tuesday, March 23, 2021 7:46 PM
> To: dev@geode.apache.org 
> Subject: Re: [DISCUSS] removal of experimental Protobuf client/server
> interface
>
> +1 for removal
> 
> From: Mark Hanson 
> Sent: Tuesday, March 23, 2021 11:44
> To: dev@geode.apache.org 
> Subject: Re: [DISCUSS] removal of experimental Protobuf client/server
> interface
>
> +1 for removal.
>
> On 3/23/21, 8:46 AM, "Darrel Schneider"  wrote:
>
> I'm in favor of its removal. I was working on improving the geode
> thread monitor and found doing that on the protobuf code was much more
> complicated.
> 
> From: Bruce Schuchardt 
> Sent: Tuesday, March 23, 2021 8:16 AM
> To: dev@geode.apache.org 
> Subject: [DISCUSS] removal of experimental Protobuf client/server
> interface
>
> Hi folks,
>
> We’ve had an experimental client/server interface in Geode that
> no-one to my knowledge is using.  We’re testing it with every build and are
> having to make changes to it to keep it up to date with the rest of the
> project.  The last change of substance to the geode-protobuf sub-project,
> for instance, was in 2018 but that’s been followed by many incidental
> commits.
>
> GEM-8997<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8997data=04%7C01%7Cbruces%40vmware.com%7C5b6bc29594c5409b52af08d8ee2c6df5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637521221887355590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=rsMzoC4JXtz94TGCCwQLSvTs4A%2B1KBkepBkeDIcLSVY%3Dreserved=0>
> was opened to have the sub-projects for this interface removed.  I’ve
> prepared a pull request<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6168data=04%7C01%7Cbruces%40vmware.com%7C5b6bc29594c5409b52af08d8ee2c6df5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637521221887355590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2sptzH4HyG%2BBEF5RJDs08SRqx3K%2BoI4rwSMm7mpMXeU%3Dreserved=0>
> to remove it and would like to get consensus to move forward with that
> effort.
>
>
>

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

[Dave Barnes]

+1 docs:
- Binary distribution contains javadocs with correctly-versioned header
(1.13.2).
- Source distribution contains user guide sources that build successfully
and are correctly versioned.
(did not test geode-native source)


On Thu, Mar 11, 2021 at 1:45 PM Donal Evans  wrote:

> +1
>
> Confirmed that performance across a broad range of workloads is comparable
> to that seen in the 1.13.1 release.
> 
> From: Dick Cavender 
> Sent: Thursday, March 11, 2021 1:34 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.2.RC1
>
> Hello Geode Dev Community,
>
> It's been 4 months since the Apache Geode 1.13.1 release and there are a
> total 48 important fixes on support/1.13 that the community would benefit
> from. The recently released v1.12.1 has 33 <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fissues%2F%3Fjql%3Dproject%2520%253D%2520GEODE%2520AND%2520fixVersion%2520%253D%25201.12.1%2520and%2520fixVersion%2520%253D%25201.13.2data=04%7C01%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675471182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=H4bTz4M8EmkGGrFm7iy8zNaOxqnACXDrZ2h2ho3X46g%3Dreserved=0>
> fixes that are not released in 1.13. Based on this I propose release of an
> Apache Geode 1.13.2 based on the current support/1.13 branch. I'll
> volunteer to be the release manager for 1.13.2 and what follows is a
> release candidate for Apache Geode version 1.13.2.RC1.
>
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Tues, March 16, 2021
>
> Please note that we are voting upon the source tag:
> rel/v1.13.2.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.2data=04%7C01%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675471182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WXM3CGWfFZ4JJsIgGSZandkMpPFncY33mD4ELJyU7qc%3Dreserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.2.RC1%2Fdata=04%7C01%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675471182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vos%2B8SWMXWp4xHbLDKVTJbxXj%2Bobh89ET0oQhQzbOKY%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1079data=04%7C01%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675471182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=a1DG6HNCXMskDmR1blZWcNZzsRKwgOP1zZCknYLysbA%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675471182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=bSf8cZY7Bkon%2BB2navQDAG1vh0OqcpbBgI4Gm8%2BSDUk%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675481174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TSN%2FzxIfiCLq%2BzaWLYLgKJFeisywDMasb8PJZEUUJdM%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Cdoevans%40vmware.com%7C76efe2fb3abb4b07c72a08d8e4d571d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637510952675481174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=tq%2BeYgMptmxM%2FZ4BMznA2dxqcARrLimcGAhFJmayQ1Q%3Dreserved=0
>
> 

Re: [VOTE] Apache Geode 1.12.1.RC4

[Dave Barnes]

+1
Docs.
- Geode API docs header correctly updated to 1.12.1
- User guide build scripts generated correct 1.12.1 manual
- Native client user guides built correctly
- Native client api docs not tested -- they're generated by the full
software build, so I assume they're OK. We publish only the latest version
(1.13) on the Apache Geode website.

On Mon, Feb 22, 2021 at 10:23 AM Robert Houghton 
wrote:

> +1
>
> I verified the version.properties file contents to match the pipeline
> version that we've tested and verified.
> -Robert Houghton
>
>
> On 2/21/21, 12:08 PM, "Owen Nichols"  wrote:
>
> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.12.1.RC4.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Thu, February 25 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.1.RC4
>
> Release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.1
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/geode/1.12.1.RC4/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1075
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Crhoughton%40vmware.com%7Cf221b519b16b4ebf161008d8d6a46188%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637495348793363365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yBvhGM48yiWnZ0Gz3Q9mI%2B3J2ddoAoBGh4Oi3Jmo1Mw%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Crhoughton%40vmware.com%7Cf221b519b16b4ebf161008d8d6a46188%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637495348793363365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=92jZ7B2TeRyIUgcHSToUKC8sW%2Bh%2BRRt8sSTMTAKS%2Fj0%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Crhoughton%40vmware.com%7Cf221b519b16b4ebf161008d8d6a46188%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637495348793363365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=tJ7gap56xlCUH7vlWzebu1bss%2BTRmBJMBM6AYZOrqKg%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.1.RC4data=04%7C01%7Crhoughton%40vmware.com%7Cf221b519b16b4ebf161008d8d6a46188%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637495348793363365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=b1aVxqH8Kynl9BkHk3%2Fgxin5GDNaxuP684sAtqy3zD0%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Crhoughton%40vmware.com%7Cf221b519b16b4ebf161008d8d6a46188%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637495348793363365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=oeLPQLMuJYX3h%2FQTVex61x6s0jdaXywWJlWIgZU%2Ftzw%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rcdata=04%7C01%7Crhoughton%40vmware.com%7Cf221b519b16b4ebf161008d8d6a46188%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637495348793363365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fLNXbsgn%2BuX44vumuIMB2mluKjb5Uz7k9%2BemWLcQH70%3Dreserved=0
>
> Geode's KEYS file containing PGP keys we use to sign the release:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2FKEYSdata=04%7C01%7Crhoughton%40vmware.com%7Cf221b519b16b4ebf161008d8d6a46188%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637495348793363365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=X%2BGCSmUWwk8INBHRgBFq0biDO58gZMcVtZRagPptByo%3Dreserved=0
>
> Command to run geode-examples:
> ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.12.1.RC4
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1075
> build runAll
>
> Regards
> Owen Nichols
>
>

Re: Geode Quarterly Report DRAFT for your review

[Dave Barnes]

The numbers come from Apache - I'm not sure how they count 'em up. It was
our practice for the first years of opensourcehood to appoint people to
both roles, but that's no longer automatic.
 I'm going with 110 / 53 ~= 2. Not perfectly in tune, but close enough for
rock'n'roll.

On Mon, Feb 8, 2021 at 4:17 PM Mark Hanson  wrote:

> Hi Dave,
>
> Does the 110 committers number include PMC members? If so, that 2:1
> doesn't line up. It would be more like 1:1.
>
> Thanks,
> Mark
>
> On 2/8/21, 12:13 PM, "Dave Barnes"  wrote:
>
> Revised Committer-to-PMC ratio to 2:1 (thanks, Karen)
>
> On Mon, Feb 8, 2021 at 12:09 PM Dave Barnes 
> wrote:
>
> > Please respond by noon (PT) Tuesday. Thanks!
> >
> > ## Description:
> >
> > The mission of Apache Geode is the creation and maintenance of
> software
> > related
> >
> > to a data management platform that provides real-time, consistent
> access to
> >
> > data-intensive applications throughout widely distributed cloud
> > architectures.
> >
> >
> > ## Issues:
> >
> > There are no issues requiring board attention.
> >
> >
> > ## Membership Data:
> >
> > Apache Geode was founded 2016-11-15 (4 years ago)
> >
> > There are currently 110 committers and 53 PMC members in this
> project.
> >
> > The Committer-to-PMC ratio is roughly 7:4.
> >
> >
> > Community changes, past quarter:
> >
> > - No new PMC members. One member resigned due to retirement (but
> remains a
> > committer).
> >
> > - No new committers. Two candidates have been proposed and
> discussed, and
> > are in the voting process.
> >
> >
> > ## Project Activity:
> >
> > - Apache Geode v1.13.1 was released on 2020-11-18.
> >
> > - We're actively working on v1.14, which will contain many bug fixes.
> >
> > - PMC Member Barry Oglesby published two articles this quarter:
> >
> >   - ["Calculating Apache Geode GatewaySender Event Queue,
> Transmission
> > and Processing Times"](
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2Fswlh%2Fcalculating-apache-geode-gatewaysender-event-queue-transmission-and-p%2Fdata=04%7C01%7Chansonm%40vmware.com%7C3bf16ee091fc47b456ed08d8cc6df06f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637484119850376975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=obCBhMTpwpEzmcj239Ju5MCgld5eyMm3XoQpZ0m4zVU%3Dreserved=0
> >
> > rocessing-times-c39839bd45a7) in November, 2020.
> >
> >   - ["Calculating the Size of an Apache Geode GatewaySender Queue"](
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40boglesby_2508%2Fcalculating-the-size-of-an-apache-geode-gatewaysender-queue-7c41e2f6ba83data=04%7C01%7Chansonm%40vmware.com%7C3bf16ee091fc47b456ed08d8cc6df06f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637484119850376975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=6gANHVqIfSg0jv6dPRPk1FLhJ8aFm2lg1DSbyN89FRk%3Dreserved=0
> )
> > in January,\
> >
> >  2021.
> >
> >
> > ## Community Health:
> >
> > - 211 issues opened in JIRA, past quarter (-26%)
> >
> > - 203 issues closed in JIRA, past quarter (-15%)
> >
> > - 416 commits in the past quarter (-21% decrease)
> >
> > - 56 code contributors in the past quarter (-1%)
> >
> > - 322 PRs opened on GitHub, past quarter (-1%)
> >
> > - 321 PRs closed on GitHub, past quarter (-1%)
> >
>
>

Re: Geode Quarterly Report DRAFT for your review

[Dave Barnes]

Revised Committer-to-PMC ratio to 2:1 (thanks, Karen)

On Mon, Feb 8, 2021 at 12:09 PM Dave Barnes  wrote:

> Please respond by noon (PT) Tuesday. Thanks!
>
> ## Description:
>
> The mission of Apache Geode is the creation and maintenance of software
> related
>
> to a data management platform that provides real-time, consistent access to
>
> data-intensive applications throughout widely distributed cloud
> architectures.
>
>
> ## Issues:
>
> There are no issues requiring board attention.
>
>
> ## Membership Data:
>
> Apache Geode was founded 2016-11-15 (4 years ago)
>
> There are currently 110 committers and 53 PMC members in this project.
>
> The Committer-to-PMC ratio is roughly 7:4.
>
>
> Community changes, past quarter:
>
> - No new PMC members. One member resigned due to retirement (but remains a
> committer).
>
> - No new committers. Two candidates have been proposed and discussed, and
> are in the voting process.
>
>
> ## Project Activity:
>
> - Apache Geode v1.13.1 was released on 2020-11-18.
>
> - We're actively working on v1.14, which will contain many bug fixes.
>
> - PMC Member Barry Oglesby published two articles this quarter:
>
>   - ["Calculating Apache Geode GatewaySender Event Queue, Transmission
> and Processing Times"](
> https://medium.com/swlh/calculating-apache-geode-gatewaysender-event-queue-transmission-and-p\
>
> rocessing-times-c39839bd45a7) in November, 2020.
>
>   - ["Calculating the Size of an Apache Geode GatewaySender Queue"](
> https://medium.com/@boglesby_2508/calculating-the-size-of-an-apache-geode-gatewaysender-queue-7c41e2f6ba83)
> in January,\
>
>  2021.
>
>
> ## Community Health:
>
> - 211 issues opened in JIRA, past quarter (-26%)
>
> - 203 issues closed in JIRA, past quarter (-15%)
>
> - 416 commits in the past quarter (-21% decrease)
>
> - 56 code contributors in the past quarter (-1%)
>
> - 322 PRs opened on GitHub, past quarter (-1%)
>
> - 321 PRs closed on GitHub, past quarter (-1%)
>

Geode Quarterly Report DRAFT for your review

[Dave Barnes]

Please respond by noon (PT) Tuesday. Thanks!

## Description:

The mission of Apache Geode is the creation and maintenance of software
related

to a data management platform that provides real-time, consistent access to

data-intensive applications throughout widely distributed cloud
architectures.


## Issues:

There are no issues requiring board attention.


## Membership Data:

Apache Geode was founded 2016-11-15 (4 years ago)

There are currently 110 committers and 53 PMC members in this project.

The Committer-to-PMC ratio is roughly 7:4.


Community changes, past quarter:

- No new PMC members. One member resigned due to retirement (but remains a
committer).

- No new committers. Two candidates have been proposed and discussed, and
are in the voting process.


## Project Activity:

- Apache Geode v1.13.1 was released on 2020-11-18.

- We're actively working on v1.14, which will contain many bug fixes.

- PMC Member Barry Oglesby published two articles this quarter:

  - ["Calculating Apache Geode GatewaySender Event Queue, Transmission and
Processing Times"](
https://medium.com/swlh/calculating-apache-geode-gatewaysender-event-queue-transmission-and-p\

rocessing-times-c39839bd45a7) in November, 2020.

  - ["Calculating the Size of an Apache Geode GatewaySender Queue"](
https://medium.com/@boglesby_2508/calculating-the-size-of-an-apache-geode-gatewaysender-queue-7c41e2f6ba83)
in January,\

 2021.


## Community Health:

- 211 issues opened in JIRA, past quarter (-26%)

- 203 issues closed in JIRA, past quarter (-15%)

- 416 commits in the past quarter (-21% decrease)

- 56 code contributors in the past quarter (-1%)

- 322 PRs opened on GitHub, past quarter (-1%)

- 321 PRs closed on GitHub, past quarter (-1%)

Re: [VOTE] Apache Geode 1.13.1.RC2

[Dave Barnes]

+1

Docs review

   - Built user guides for geode and geode-native using the provided Docker
   scripts.
   - Opened the pre-built Geode javadocs in the binary distro.


Everything worked and looked as it should.

NOTE: The javadocs are branded "1.13.1" but the User Guides are still
"1.13". I regard this as correct -- there's no precedent I'm aware of for
Geode patch releases that would indicate otherwise.

On Tue, Nov 17, 2020 at 12:33 PM Nabarun Nag  wrote:

> +1
> Started gfsh, created cluster, create region, entry put and get, query
> execution.
> Build from source.
>
> Regards
> Nabarun Nag
>
> 
> From: Joris Melchior 
> Sent: Tuesday, November 17, 2020 12:25 PM
> To: dev@geode.apache.org 
> Subject: Re: [VOTE] Apache Geode 1.13.1.RC2
>
> +1
>
> Looks good to me. Did a build and gfsh test-drive.
>
> From: Dan Smith 
> Date: Monday, November 16, 2020 at 1:29 PM
> To: dev@geode.apache.org 
> Subject: Re: [VOTE] Apache Geode 1.13.1.RC2
> +1
>
> Looks good to me! I ran the geode-release-check against it, looked for
> binary artifacts, checked the pipeline.
>
> -Dan
> 
> From: Dick Cavender 
> Sent: Thursday, November 12, 2020 5:00 PM
> To: dev@geode.apache.org 
> Subject: [VOTE] Apache Geode 1.13.1.RC2
>
> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.13.1.RC2.
> Issues with creation of RC1 forced moving to RC2.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Tue, November 17 2020.
>
> Please note that we are voting upon the source tag:
> rel/v1.13.1.RC2
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.1data=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153729481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FpwSk4ZPaG4UbxnCceQupEqHmqK7%2BXXlxsgoTnlqsrs%3Dreserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.1.RC2%2Fdata=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153729481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=XYUPMs%2F%2FK6%2Bn7j9iEFtOoocBjMiOHimqrsA7fyhN2vY%3Dreserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1071data=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153729481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=W%2BmuOe9mXgOXqYsyJBklpU77zMKhKIHn98ov1K6j6Qc%3Dreserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.1.RC2data=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153729481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=75YEv2p7%2B5qeUPJ%2Fy%2FL0vDnGmD86D3yHo3XFo2NPxZ8%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.1.RC2data=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153729481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0eN4wZ0EFwoeAG7xBwLTE4OLtnxKhpXk5hA0ZYQb7%2BM%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.1.RC2data=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153739471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2F6NntnNnUpjb9wFBa6QSpo4WUd%2BWblX4nlYIeljkSX4%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.1.RC2data=04%7C01%7Cnnag%40vmware.com%7C0b2ca5e3ad4d441dc08108d88b36e365%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637412415153739471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=MH9EKYiC%2FGSJHkTrWoyo2qtUrr1UoF2VhzhjkWQyB%2Fw%3Dreserved=0
>
> Pipelines:
>
> 

Re: Apache Geode 1.13.1 patch proposal

[Dave Barnes]

I volunteer to update the Geode website, when the time arrives.

On Thu, Nov 12, 2020 at 2:43 PM Bruce Schuchardt  wrote:

> +1
>
> I'll have a couple of PRs that I'll want to backport next week.
>
> On 11/12/20, 11:01 AM, "Dick Cavender"  wrote:
>
> It's been two months since the 1.13.0 release and there have been 28
> important fixes on support/1.13 that the community would benefit from.
> Based on this I'd like to propose release of Apache Geode 1.13.1 based on
> the current support/1.13 branch. I'll volunteer to be the release manager
> for 1.13.1 so look forward to an RC1 soon.
>
> -Dick
>
>
>

Re: Short how-to on running a geode cluster in docker containers

[Dave Barnes]

Excellent work, Jens. Thanks!

On Wed, Nov 11, 2020 at 2:23 PM Jens Deppe  wrote:

> I recently had the need to run a geode cluster in docker containers and
> thought my findings and script might be useful. I’ve created a wiki page
> here:
> https://cwiki.apache.org/confluence/display/GEODE/Running+a+Geode+cluster+in+docker
>
> The reason for this was that I wanted to easily be able to use my geode
> build inside a geode/docker cluster for quick iteration. A secondary need
> was to be able to constrain the resources used by each member. Since docker
> allows CPU constraints I could simulate running on a ‘smaller’ system by
> just assigning a specific number of CPUs to each container.
>
> Please let me know if you have any questions.
>
> --Jens
>

Re: Please review and contribute: draft of Nov 2020 Apache board report

[Dave Barnes]

LGTM

On Tue, Nov 10, 2020 at 2:36 AM Alberto Gomez 
wrote:

> Hi Karen,
>
> According to the membership data I'd say the Committer-to-PMC ratio is
> closer to 2:1 than to 7:4.
>
> Alberto
> 
> From: Karen Miller 
> Sent: Monday, November 9, 2020 8:25 PM
> To: dev@geode.apache.org 
> Subject: Please review and contribute: draft of Nov 2020 Apache board
> report
>
> All, our board report is due in less than 48 hours.  I've included a
> first draft below.
> Please help correct my mistakes and let me know of blog posts and
> presentations
> that are not yet on the list.
>
> I think that we might also add to our Project Activity category mentions
> of the
> community's focus.  Would it be a good idea to add something like this?
>   - We're actively working on v1.13.1, which will contain many bug fixes.
>
> Since the report is due quite soon, please get corrections/additions
> to me before
> Tuesday Nov 10 (tomorrow) at 3pm Pacific time.
> Thanks.
> Karen Miller
> I work for VMware.
> This email is written in my capacity as Chair of the Apache Geode PMC.
>
> 
> ## Description:
> The mission of Apache Geode is the creation and maintenance of software
> related
> to a data management platform that provides real-time, consistent access to
> data-intensive applications throughout widely distributed cloud
> architectures.
>
> ## Issues:
> There are no issues requiring board attention.
>
> ## Membership Data:
> Apache Geode was founded 2016-11-15 (4 years ago)
> There are currently 110 committers and 54 PMC members in this project.
> The Committer-to-PMC ratio is roughly 7:4.
>
> Community changes, past quarter:
> - No new PMC members. Last addition was Alexander Murmann on 2020-03-26.
> - Sarah Abbey was added as committer on 2020-09-29
>
> ## Project Activity:
> - Apache Geode v1.13.0 was released on 2020-09-10.
> - 10 community members presented 8 talks at ApacheCon 2020. See
>   https://www.youtube.com/playlist?list=PLU2OcwpQkYCxKxd7dVETcwEtx5AEDIp1j
> for
>   a playlist that includes all 8 talks.
>
> ## Community Health:
> - 259 issues opened in JIRA, past quarter (-15% decrease)
> - 212 issues closed in JIRA, past quarter (-16% decrease)
> - 463 commits in the past quarter (-19% decrease)
> - 57 code contributors in the past quarter (-6% decrease)
> - 324 PRs opened on GitHub, past quarter (-16% decrease)
> - 325 PRs closed on GitHub, past quarter (-14% decrease)
>

Re: Utilizing GitHub .CODEOWNERS files

[Dave Barnes]

If 'docs' can be identified as a separate code area, then add my name to
the experimental owners' list.

On Fri, Oct 30, 2020 at 2:11 PM Owen Nichols  wrote:

> I'd be happy to volunteer as well
>
> On 10/30/20, 2:10 PM, "Dan Smith"  wrote:
>
> Hi Robert,
>
> Seems like a reasonable experiment. You can tag me if you like.
>
> Thanks,
> -Dan
> 
> From: Robert Houghton 
> Sent: Friday, October 30, 2020 1:52 PM
> To: dev@geode.apache.org 
> Subject: Utilizing GitHub .CODEOWNERS files
>
> Thanks to @udo and @nabarunnag the conversations and ideas around
> having
> better review processes and review quality.
>
> TL;DR - Adding GitHub CODEOWNERS[1] to geode-examples, eye toward
> adding to
> GEODE
>
> GitHub provides a mechanism of assigning code ownership to specific
> owners/committers based on file pattern-matching (similar to
> .gitignore).
> Owners are automatically added as reviewers to pull-requests against
> their
> described areas. This, coupled with our review requirements[2], could
> really help us get the right eyes on prospective code changes.
>
> I intend to add this file to the apache/geode-examples repository,
> tagging
> myself and a few volunteers to different code areas, and checking the
> results. If we like it, we can move on to doing the same to Geode.
>
> Will anyone volunteer to get code-reviews for geode-examples changes
> (that
> we won't merge) ?
>
> Thanks,
> -Robert Houghton
>
> [1]
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.github.com%2Fen%2Ffree-pro-team%40latest%2Fgithub%2Fcreating-cloning-and-archiving-repositories%2Fabout-code-ownersdata=04%7C01%7Conichols%40vmware.com%7C1404a0b2a4c54645dd4608d87d182e51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637396890095569226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Xtca2KkWOtMJCm0DVcBPyNlJUSB8STXe8BLoIOCSGao%3Dreserved=0
> [2]
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FINFRA%2Fgit%2B-%2B.asf.yaml%2Bfeatures%23git.asf.yamlfeatures-BranchProtectiondata=04%7C01%7Conichols%40vmware.com%7C1404a0b2a4c54645dd4608d87d182e51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637396890095569226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZF%2BC96kpEVwpG15RwLgYvlhdhMenI8y7LzoYumN9YJo%3Dreserved=0
>
>

Re: PR process and etiquette

[Dave Barnes]

Here's a common use case that we should address: A single PR may require
two reviews, one for code and another for docs, before it can be said to be
fully reviewed and ready to merge.
Points to consider:

   - Many PRs, especially those introducing new features or user-settable
   properties, include both code and docs. "Docs" includes updates to the user
   guide sources, but also code comments that are consumed by community
   developers and are included in the auto-generated API documentation.
   Parameter name choices, explanations, spelling and grammar need to be right.
   - Reviews of code and docs require different skills, so a good-quality
   PR review in such cases benefits from multiple reviewers, (at least) one
   for code, and (at least) one for docs.
   - [My key concern] Current protocol is 1 reviewer approval qualifies the
   PR for merging. I flag my doc reviews in such cases with a note to the
   submitter saying something like "Docs reviewed and approved; technical
   review still needed before merging". But a submitter who's eager to merge
   may just see green and go for it, without reading the caveat. I'm against
   enforcing a multiple-review requirement. What I would like to see is a
   status for partial approval, so I can register my approval without
   prematurely opening the door to a code merge.
   - Other considerations:
  - There are PRs that don't fit this two-part use case. Many PRs are
  code-only, with no doc component. Conversely, some PRs are
docs-only, with
  no code component.
  - PRs often are not recognized as falling into this two-part use
  case. Submitters of JIRA tickets may not know whether the solution to the
  problem they're reporting will affect docs. Submitter of the PR
addressing
  the JIRA ticket may not think to add the 'docs' component to the related
  JIRA ticket or to request a doc reviewer when creating the PR.


On Wed, Oct 28, 2020 at 8:41 AM Robert Houghton 
wrote:

> There are some pieces of Apache infrastructure we can control without
> needing tickets: Specifically
> required_pull_request_reviews:
> dismiss_stale_reviews: true
> require_code_owner_reviews: true
>
> I think these specific controls could go a long way towards helping keep
> our PR quality high, while reducing cognitive load for the reviewers.
>
> Full documentation here<
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-BranchProtection
> >
>
>
>
> From: Bruce Schuchardt 
> Date: Wednesday, October 28, 2020 at 8:10 AM
> To: dev@geode.apache.org 
> Subject: Re: PR process and etiquette
> -1
> While I often use the Draft option I don't see why we want to add even
> more rules about how we use github.  I think it's enough to put in a PR and
> then add reviewers when you're ready for comments.  Getting the stink-eye
> for putting up a non-Draft PR is just going to make it more difficult to
> attract and retain new contributors.
>
> On 10/27/20, 5:41 PM, "Udo Kohlmeyer"  wrote:
>
> Dear Apache Geode Devs,
> It is really great going through all the PRs that been submitted. As
> Josh Long is known to say: "I work for PRs".
> Whilst going through some of the PRs I do see that there are many PRs
> that have multiple commits against the PR.
> I know that the PR submission framework kicks off more testing than we
> do on our own local machines. It is extremely uncommon to submit a PR the
> first time and have all tests go green. Which h means we invariably iterate
> over commits to make the build go green.
> In this limbo time period, it is hard for any reviewer to know when
> the ticket is ready to be reviewed.
> I want to propose that when submitting a PR, it is initially submitted
> as a DRAFT PR. This way, all test can still be run and work can be done to
> make sure "green" is achieved. Once "green" status has been achieved, the
> draft can then be upgraded to a final PR by pressing the "Ready For Review"
> button. At this point all commits on the branch can then once again be
> squashed into a single commit.
> Now project committers will now know that the PR is in a state that it
> can be reviewed for completeness and functionality.
> In addition, it will help tremendously helpful if anyone submitting a
> PR monitors their PR for activity. If there is no activity for a few days,
> please feel free to ping the Apache Geode Dev community for review. If
> review is request, please prioritize some time to address the feedback, as
> reviewers spend time reviewing code and getting an understanding what the
> code is doing. If too much time goes by, between review and addressing the
> review comments, not only does the reviewer lose context, possibly
> requiring them to spend time again to understand what the code was/is
> supposed to do, but also possibly lose interest, as the ticket has now
> become cold or dropped down the list of PRs.
> There are currently 

Re: Clean C++ client metadata in timeouts

[Dave Barnes]

If a straight-up change solves a constant headache, as you suggest,
Alberto, and as Blake concurs, that sounds like the way to go.
Why introduce a new option or property if the user will always prefer one
behavior over the other? (And from a docs perspective, who needs another
optional property, anyway?)

On Thu, Sep 17, 2020 at 10:32 AM Blake Bender  wrote:

> Given that attempts to retrieve metadata after the C++ cache is closed are
> a constant headache for Geode Native development, I am generally in favor
> of anything that potentially reduces the number of times/places this
> happens.  If we've failed the handshake, it's very unlikely things will
> correct themselves without outside intervention, so this fix is probably
> goodness.  I'd go ahead and submit a PR when you think it's solid.
>
> Thanks,
>
> Blake
>
>
> On 9/17/20, 9:36 AM, "Dave Barnes"  wrote:
>
> Alberto,
> Are there cases in which one or two timeouts are followed by a
> successful
> retry? Or does one timeout *always* end with more timeouts and,
> ultimately,
> an IO error?
> If timeouts can sometimes be followed by successful retries, and
> re-trying
> is the current default behavior, then I agree that introducing a
> setting
> that effectively eliminates re-tries should be the developer's choice.
> In that case, I suggest that the option should not be a low-level
> choice of
> "handle the metadata in a way that eliminates retries" but should be
> higher
> level, like "when attempting to connect, try only once, instead of
> re-trying (the default behavior)."
> -Dave
>
> On Thu, Sep 17, 2020 at 7:42 AM Alberto Bustamante Reyes
>  wrote:
>
> > Hi geode-dev,
> >
> > I have a question about the c++ client.
> >
> > Some months ago we merged GEODE-8231 to solve a problem we observed
> > regarding the native client was trying to connect to stopped server.
> > GEODE-8231 solution consists on remove the client metadata when an
> "IO
> > error in handshake" exception is received. This fix solved most of
> our
> > problems, but it has been observed that sometimes when a server is
> stopped
> > the errors received in the client are not the same and this "IO
> error in
> > handshake" takes up to a minute to appear. So during that time, the
> client
> > is still trying to connect to the offline server.
> >
> > As the error received during that time is "timeout in handshake", we
> have
> > tested modyfing the solution of GEODE-8213 to make the client to
> remove the
> > metadata once a timeout error is received (here is a draft with the
> code:
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fpull%2F651data=02%7C01%7Cbblake%40vmware.com%7Cee9cfd61173047c7247808d85b27c3c8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637359573636742453sdata=FUhQIAalNs0PK4vFvgnVZPV55cLPykD2cvDRwgRrNj0%3Dreserved=0).
> With this change in
> > place, the behavior is ok.
> >
> >
> > But I would like to check your opinion about this check, because
> this will
> > cause that a single timeout will cause the removal of the client
> metadata,
> > which maybe its not the best solution. I thought about different
> > alternatives:
> >
> > - Wait until a given number of timeouts in a row have been received
> from
> > the same server to remove the metadata
> > - Make this "remove-metadata-after-timeout" something optional that
> could
> > be configured if needed
> >
> > As this will misalign the behavior of Java and C++ clients, making
> this an
> > optional configuration will be more appropriate, to keep the default
> c++
> > client behavior as the Java client.
> >
> > BR/
> >
> > Alberto B.
> >
>
>

Re: Clean C++ client metadata in timeouts

[Dave Barnes]

Alberto,
Are there cases in which one or two timeouts are followed by a successful
retry? Or does one timeout *always* end with more timeouts and, ultimately,
an IO error?
If timeouts can sometimes be followed by successful retries, and re-trying
is the current default behavior, then I agree that introducing a setting
that effectively eliminates re-tries should be the developer's choice.
In that case, I suggest that the option should not be a low-level choice of
"handle the metadata in a way that eliminates retries" but should be higher
level, like "when attempting to connect, try only once, instead of
re-trying (the default behavior)."
-Dave

On Thu, Sep 17, 2020 at 7:42 AM Alberto Bustamante Reyes
 wrote:

> Hi geode-dev,
>
> I have a question about the c++ client.
>
> Some months ago we merged GEODE-8231 to solve a problem we observed
> regarding the native client was trying to connect to stopped server.
> GEODE-8231 solution consists on remove the client metadata when an "IO
> error in handshake" exception is received. This fix solved most of our
> problems, but it has been observed that sometimes when a server is stopped
> the errors received in the client are not the same and this "IO error in
> handshake" takes up to a minute to appear. So during that time, the client
> is still trying to connect to the offline server.
>
> As the error received during that time is "timeout in handshake", we have
> tested modyfing the solution of GEODE-8213 to make the client to remove the
> metadata once a timeout error is received (here is a draft with the code:
> https://github.com/apache/geode-native/pull/651). With this change in
> place, the behavior is ok.
>
>
> But I would like to check your opinion about this check, because this will
> cause that a single timeout will cause the removal of the client metadata,
> which maybe its not the best solution. I thought about different
> alternatives:
>
> - Wait until a given number of timeouts in a row have been received from
> the same server to remove the metadata
> - Make this "remove-metadata-after-timeout" something optional that could
> be configured if needed
>
> As this will misalign the behavior of Java and C++ clients, making this an
> optional configuration will be more appropriate, to keep the default c++
> client behavior as the Java client.
>
> BR/
>
> Alberto B.
>

[ANNOUNCE] Apache Geode 1.13.0

[Dave Barnes]

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


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 contains some new gfsh commands and support for the Server Name
Indication (SNI) extension to TLS, as well as a number of improvements and
bug fixes.


Users are encouraged to upgrade to the latest release. For the full list of
changes please review the release notes:

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


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,

Dave Barnes on behalf of the Apache Geode team

Re: Geode 1.13 RC1 accepted

[Dave Barnes]

Good advice, Bruce. Thanks for the +1.

On Thu, Sep 10, 2020 at 9:53 AM Bruce Schuchardt  wrote:

> I missed the vote but am okay with it.  Maybe not start a 3-day vote on a
> holiday next time?
>
> On 9/9/20, 3:49 PM, "Dave Barnes"  wrote:
>
> It's past the announced deadline and we have closed the vote with a
> successful result.
>
> Voting status
> ==
> +1 10 votes (*=PMC member, 'binding' vote)
>
> Aaron Lindsey
>
> Dave Barnes*
>
> Jens Deppe*
>
> Jinmei Liao*
>
> John Blum*
>
> Mike Martell
>
> Nabarun Nag*
>
> Owen Nichols
>
> Patrick Johnson
>
> Sarah Abbey
>
>
> +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.RC1 has passed the vote. We will finalize the release
> shortly.
>
>
> Thanks everyone for the great work!
>
> -Dave
>
>

[DISCUSS] Someone to update 3rd-party libraries used by Geode

[Dave Barnes]

Hello Apache Geode Community,
We need a volunteer to update the 3rd-party libraries used by Geode. This
consists of going through the libraries we depend on and updating each to
the latest version that works with our code.
It would be nice to get this done within the next week or two so that we
have time to shake out issues before the next release.
Regards,
Dave Barnes on behalf of the Apache Geode Team

Geode 1.13 RC1 accepted

[Dave Barnes]

It's past the announced deadline and we have closed the vote with a
successful result.

Voting status
==
+1 10 votes (*=PMC member, 'binding' vote)

Aaron Lindsey

Dave Barnes*

Jens Deppe*

Jinmei Liao*

John Blum*

Mike Martell

Nabarun Nag*

Owen Nichols

Patrick Johnson

Sarah Abbey


+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.RC1 has passed the vote. We will finalize the release
shortly.


Thanks everyone for the great work!

-Dave

Re: [VOTE] Apache Geode 1.13.0.RC1

[Dave Barnes]

+1
- Built the Geode user guide from source
- Verified the Geode API docs in the binary distribution are correct
- Built the Geode Native user guides (.NET and C++) from source
- Built the Geode Native API docs from source

On Tue, Sep 8, 2020 at 2:05 PM Nabarun Nag  wrote:

> +1 Based on the following tasks
> Clean build
> Starting gfsh, executing queries.
> meld comparison of artifacts directories.
>
> 
> From: Jinmei Liao 
> Sent: Tuesday, September 8, 2020 11:16 AM
> To: dev@geode.apache.org 
> Subject: Re: [VOTE] Apache Geode 1.13.0.RC1
>
> +1
> Verified geode management rest urls are working as expected.
>
> On 9/8/20, 9:53 AM, "Owen Nichols"  wrote:
>
> +1
>
> I have reviewed test results for a battery of internal functional and
> performance tests, reviewed the LICENSE file for accuracy, looked at the
> logs for all checks in the rc pipeline, confirmed that artifact files are
> now named consistently as requested last time, confirmed gfsh and gfsh
> version --full output, reviewed the release notes in the wiki, reviewed
> that the fixed list in Jira is accurate, and checked that the RC1 tag shows
> as "Verified" in github.
>
> On 9/7/20, 8:23 PM, "Dave Barnes"  wrote:
>
> Hello Geode Dev Community,
>
>
> This is a release candidate for Apache Geode version 1.13.0.RC1.
>
> Thanks to all the community members for their contributions to
> this release!
>
>
> Please do a review and give your feedback, including the checks you
> performed.
>
>
> Voting deadline:
>
> 3PM PDT Wed, September 9, 2020.
>
>
> Please note that we are voting upon the source tag:
>
> rel/v1.13.0.RC1
>
>
> Release notes:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.0data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=rKGO6MdK93hSTJF%2F%2BN%2FIJ3Vd5vNeq1BQBRAGI77Ip4g%3Dreserved=0
>
>
> Source and binary distributions:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.0.RC1%2Fdata=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=x6vVgr6ceI0196EMCbmUq6WxAqixcSgARBhC0D1T%2BdM%3Dreserved=0
>
>
> Maven staging repo:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1069data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=fs1Mi7y3fEt7Bnfyl9KnJTKXWHTazsFdCmtUtUMS4Hs%3Dreserved=0
>
>
> GitHub:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=awSnw4fkDLxhVamoAM%2FsBSAGhaTi9KroI4Jlp5Lg8%2FE%3Dreserved=0
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=rK5NNxqocS0v1CakZ5xdNi7lq1IHz4UojJzx5AS7LVw%3Dreserved=0
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=rQG4MSWw%2FHxWAj4tdBLrE24Q1ukFa5ipI%2FWsDka9GaI%3Dreserved=0
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424618979sdata=9o7QtQAGg%2BSkjc5xNmxElJPJfFvJ1I8%2FvlErm1LMGc8%3Dreserved=0
>
>
> Pipelines:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-maindata=02%7C01%7Cnnag%40vmware.com%7C797084b8d89b4088fcd708d854236da1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351858424628973sdata=OR6viVpRZtN6rSz9qOH6xPwdYoUuaJDUCXp%2FIcd2ens%3Dreserved=0
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelin

[VOTE] Apache Geode 1.13.0.RC1

[Dave Barnes]

Hello Geode Dev Community,


This is a release candidate for Apache Geode version 1.13.0.RC1.

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


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


Voting deadline:

3PM PDT Wed, September 9, 2020.


Please note that we are voting upon the source tag:

rel/v1.13.0.RC1


Release notes:

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


Source and binary distributions:

https://dist.apache.org/repos/dist/dev/geode/1.13.0.RC1/


Maven staging repo:

https://repository.apache.org/content/repositories/orgapachegeode-1069


GitHub:

https://github.com/apache/geode/tree/rel/v1.13.0.RC1

https://github.com/apache/geode-examples/tree/rel/v1.13.0.RC1

https://github.com/apache/geode-native/tree/rel/v1.13.0.RC1

https://github.com/apache/geode-benchmarks/tree/rel/v1.13.0.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.0.RC1
-PgeodeRepositoryUrl=
https://repository.apache.org/content/repositories/orgapachegeode-1069
build runAll


Regards

Dave Barnes

Re: [PROPOSAL] Backport GEODE-8475 to 1.13

[Dave Barnes]

Yes, Gester - thanks.

> On Sep 2, 2020, at 3:04 PM, Owen Nichols  wrote:
> 
> +1, looking forward to getting this backported as soon as possible today!
> 
> On 9/2/20, 2:34 PM, "Eric Shu"  wrote:
> 
>+1
> 
>
>From: Dick Cavender 
>Sent: Wednesday, September 2, 2020 11:07 AM
>To: dev@geode.apache.org 
>Subject: RE: [PROPOSAL] Backport GEODE-8475 to 1.13
> 
>+1
> 
>-Original Message-
>From: Anilkumar Gingade 
>Sent: Wednesday, September 2, 2020 11:05 AM
>To: dev@geode.apache.org
>Subject: Re: [PROPOSAL] Backport GEODE-8475 to 1.13
> 
>+1 As it address a potential hang.
> 
>-Anil.
> 
> 
>On 9/2/20, 10:38 AM, "Xiaojian Zhou"  wrote:
> 
>Hi, All:
> 
>I want to backport my fix in GEODE-8475 to 1.13. It fixed a hang 
> caused by a potential deadlock.
> 
>This fix is quite safe, I have verified it by running all queue 
> related regression.
> 
>Regards
>Gester
> 
> 

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

[Dave Barnes]

OK Bruce, go for it.
Thanks for the fix.
Dave

On Tue, Sep 1, 2020 at 10:43 AM Sarah Abbey  wrote:

> +1
> 
> From: Donal Evans 
> Sent: Tuesday, September 1, 2020 1:38 PM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] port GEODE-8467 to support/1.13
>
> +1
> ________
> From: Dave Barnes 
> Sent: Tuesday, September 1, 2020 10:25 AM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] port GEODE-8467 to support/1.13
>
> > Assuming that it's passed applicable testing AND GETS AT LEAST 3 VOTES,
> let's do it.
>
> On Tue, Sep 1, 2020 at 10:24 AM Dave Barnes  wrote:
>
> > +1
> > GEODE-8467 addresses one of the few remaining 1.13 release blockers.
> > I see it's been approved and merged into the develop branch. Assuming
> that
> > it's passed applicable testing, let's do it.
> >
> > On Tue, Sep 1, 2020 at 7:37 AM Bruce Schuchardt 
> wrote:
> >
> >> I’d like to cherry-pick this change into support/1.13:
> >>
> >> There is a flaw in the code that handles a server being forced out of
> the
> >> cluster.  The flaw keeps the server from shutting down and leaves the
> >> server in a hung state.  The PR adds error handling to two methods, one
> in
> >> the Cache’s XML-generation method and the other in a Membership class to
> >> ensure that tear-down of the cache is performed.
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5490data=02%7C01%7Csabbey%40vmware.com%7Cbe14c93b2d4d43e31f7708d84e9dd689%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637345787113051903sdata=TsXIb6rNEAChlQPdDoGztVBayA70xlhGldyktCJwKW4%3Dreserved=0
> >>
> >>
>

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

[Dave Barnes]

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

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

> +1
> GEODE-8467 addresses one of the few remaining 1.13 release blockers.
> I see it's been approved and merged into the develop branch. Assuming that
> it's passed applicable testing, let's do it.
>
> On Tue, Sep 1, 2020 at 7:37 AM Bruce Schuchardt  wrote:
>
>> I’d like to cherry-pick this change into support/1.13:
>>
>> There is a flaw in the code that handles a server being forced out of the
>> cluster.  The flaw keeps the server from shutting down and leaves the
>> server in a hung state.  The PR adds error handling to two methods, one in
>> the Cache’s XML-generation method and the other in a Membership class to
>> ensure that tear-down of the cache is performed.
>>
>> https://github.com/apache/geode/pull/5490
>>
>>

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

[Dave Barnes]

+1
GEODE-8467 addresses one of the few remaining 1.13 release blockers.
I see it's been approved and merged into the develop branch. Assuming that
it's passed applicable testing, let's do it.

On Tue, Sep 1, 2020 at 7:37 AM Bruce Schuchardt  wrote:

> I’d like to cherry-pick this change into support/1.13:
>
> There is a flaw in the code that handles a server being forced out of the
> cluster.  The flaw keeps the server from shutting down and leaves the
> server in a hung state.  The PR adds error handling to two methods, one in
> the Cache’s XML-generation method and the other in a Membership class to
> ensure that tear-down of the cache is performed.
>
> https://github.com/apache/geode/pull/5490
>
>

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

[Dave Barnes]

Looks like more than enough approvals, Owen. Please port, as you proposed.
Thanks,
Dave

On Tue, Sep 1, 2020 at 7:45 AM Alexander Murmann 
wrote:

> +1
>
> On Tue, Sep 1, 2020 at 6:19 AM Sarah Abbey  wrote:
>
> > +1
> > 
> > From: Ju@N 
> > Sent: Tuesday, September 1, 2020 4:10 AM
> > To: dev@geode.apache.org 
> > Subject: Re: Proposal to bring GEODE-8456 (shiro upgrade) to support
> > branches
> >
> > +1
> >
> > On Tue, 1 Sep 2020 at 01:11, Donal Evans  wrote:
> >
> > > +1
> > >
> > > We still have outstanding release blockers for 1.13, so getting this
> fix
> > > in now just prevents extra work in the future without slowing us down
> > now.
> > > 
> > > From: Owen Nichols 
> > > Sent: Monday, August 31, 2020 4:19 PM
> > > To: dev@geode.apache.org 
> > > Subject: Proposal to bring GEODE-8456 (shiro upgrade) to support
> branches
> > >
> > > Recently shiro-1.5.3.jar is getting flagged for ‘high’ security
> > > vulnerability CVE-2020-13933.
> > >
> > > Analysis shows that Geode does not use Shiro in a manner that would
> > expose
> > > this vulnerability.
> > >
> > > The risk of bringing GEODE-8456 is low (difference between Shiro 1.5.3
> > and
> > > 1.6.0 is bugfix and dependency bump only).  GEODE-8456 has been on
> > develop
> > > for 6 days and passed all tests.
> > >
> > > This fix is critical to avoid false positives in automated
> vulnerability
> > > scans.  It would be nice to bring to support branches before 1.13.0 is
> > > released.
> > >
> > > Please vote “+1” to approve including this in 1.13.0.  If there are any
> > -1
> > > votes, I’ll wait until after 1.13.0 is done to propose this again.
> > >
> >
> >
> > --
> > Ju@N
> >
>

Re: [PROPOSAL] Backport GEODE-8432 to 1.13

[Dave Barnes]

Thanks for your contribution, Gester

On Thu, Aug 20, 2020 at 12:37 PM Joris Melchior 
wrote:

> +1
>
> On 2020-08-20, 12:08 PM, "Xiaojian Zhou"  wrote:
>
> It's using region path instead of getting the region. It should be no
> risk.
>
> On 8/19/20, 10:25 AM, "Xiaojian Zhou"  wrote:
>
> This problem also exists in 1.13.
>
>
>

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

[Dave Barnes]

+1 esp addition of "Affects Version/s".

On Mon, Aug 17, 2020 at 3:07 PM Kirk Lund  wrote:

> +1 if it's possible
>
> On Mon, Aug 17, 2020 at 12:04 PM Donal Evans  wrote:
>
> > Looking at the dialogue that opens when you attempt to create a new
> ticket
> > in the GEODE Jira[1], there are two fields included that aren't really
> > necessary and may cause confusion. The "Fix Version/s" field should
> > presumably not be filled out until the issue has actually been fixed,
> > rather than at the time of ticket creation. The "Sprint" field seems to
> no
> > longer serve any purpose at all that I can discern, having only been
> filled
> > in 13 tickets, the most recent of which was created in December 2018[2].
> > With the expansion of the community contributing to the Geode project,
> it's
> > important to provide a straightforward experience for people who are new
> to
> > the project and wish to file tickets, so the presence of these fields may
> > cause issues.
> >
> > I propose that these two fields be removed from the "Create Issue"
> > dialogue and that the "Affects Version/s" field be added, since that
> field
> > is far more important at time of ticket creation. There are currently
> 3851
> > bug tickets in the Jira with no "Affects Version/s" value entered at
> > all[3], which I suspect is in part due to that field not being an option
> in
> > the "Create Issue" dialogue, meaning you have to remember to go back
> after
> > creating the ticket and enter it. With Geode moving to a model of having
> > support branches and patch releases, properly capturing the versions
> > affected by a given issue becomes even more important.
> >
> > [1] https://i.imgur.com/oQ8CW87.png
> > [2]
> >
> https://issues.apache.org/jira/projects/GEODE/issues/GEODE-8433?filter=allissues=cf%5B12310921%5D+ASC%2C+created+DESC
> > [3]
> >
> https://issues.apache.org/jira/browse/GEODE-8433?jql=project%20%3D%20GEODE%20AND%20issuetype%20%3D%20Bug%20AND%20affectedVersion%20%3D%20EMPTY%20ORDER%20BY%20created%20DESC%2C%20affectedVersion%20ASC%2C%20cf%5B12310921%5D%20ASC
> >
>

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

[Dave Barnes]

I was waiting until you confirmed that the fix had successfully completed a 
test cycle on develop. 
I see Owen gave it the green light in that regard, so all is in order.
Thanks for this — at the beginning of the week, it was our last known blocker.
-Dave

> On Aug 13, 2020, at 5:08 PM, Mark Hanson  wrote:
> 
> I just cherry-picked the change in. Thanks!
> 
> On 8/13/20, 4:55 PM, "Dick Cavender"  wrote:
> 
>+1
> 
>-Original Message-
>From: Mark Hanson  
>Sent: Thursday, August 13, 2020 4:46 PM
>To: dev@geode.apache.org
>Subject: Re: [Proposal] Backport GEODE-8422 to support/1.13
> 
>Hi All, 
> 
>I can't remember for sure, but I think we need 3 approvals?
> 
>Thanks,
>Mark
> 
>On 8/13/20, 4:22 PM, "Owen Nichols"  wrote:
> 
>+1 from me.  Pipeline and all other testing I've seen suggests this 
> fix is good
> 
>On 8/12/20, 4:52 PM, "Jianxia Chen"  wrote:
> 
>+1
> 
>On Wed, Aug 12, 2020 at 4:41 PM Mark Hanson  
> wrote:
> 
>> Hi All,
>> 
>> We have found a case where tombstones were being cleared when the region
>> was not initialized. This was causing some test failures and potential
>> field failures. We would like to put this into support/1.13.
>> 
>> Thanks,
>> Mark
>> 
> 
> 
> 

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

[Dave Barnes]

Do I understand correctly that this fix, if validated, addresses the last
remaining release-blocker for 1.13?

On Wed, Aug 12, 2020 at 6:02 PM Mark Hanson  wrote:

> Not yet, we will need to wait for that to finish cleanly relative to this
> change. I guess I was just seeking to gain approval for priority of it once
> it does pass. (Maybe I am being a little over zealous).
>
> Thanks,
> Mark
>
> On 8/12/20, 5:52 PM, "Dave Barnes"  wrote:
>
> Has the version on the develop branch completed a test cycle?
>
> On Wed, Aug 12, 2020 at 4:52 PM Jianxia Chen 
> wrote:
>
> > +1
> >
> > On Wed, Aug 12, 2020 at 4:41 PM Mark Hanson 
> wrote:
> >
> > > Hi All,
> > >
> > > We have found a case where tombstones were being cleared when the
> region
> > > was not initialized. This was causing some test failures and
> potential
> > > field failures. We would like to put this into support/1.13.
> > >
> > > Thanks,
> > > Mark
> > >
> >
>
>

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

[Dave Barnes]

Has the version on the develop branch completed a test cycle?

On Wed, Aug 12, 2020 at 4:52 PM Jianxia Chen  wrote:

> +1
>
> On Wed, Aug 12, 2020 at 4:41 PM Mark Hanson  wrote:
>
> > Hi All,
> >
> > We have found a case where tombstones were being cleared when the region
> > was not initialized. This was causing some test failures and potential
> > field failures. We would like to put this into support/1.13.
> >
> > Thanks,
> > Mark
> >
>

Re: [PROPOSAL] Backport GEODE-8423 to support/1.13

[Dave Barnes]

OK, Sarah, you have the requisite 3 votes -- go ahead and back-port.
Thanks for your contribution!
-Dave

On Wed, Aug 12, 2020 at 9:24 AM Dan Smith  wrote:

> +1
>
> -Dan
>
> On Aug 12, 2020, at 8:59 AM, Sarah Abbey  sab...@vmware.com>> wrote:
>
> get
>
>

Re: [PROPOSAL] Backport GEODE-8423 to support/1.13

[Dave Barnes]

+1


On Wed, Aug 12, 2020 at 9:10 AM Darrel Schneider  wrote:

> +1
> 
> From: Sarah Abbey 
> Sent: Wednesday, August 12, 2020 8:59 AM
> To: dev@geode.apache.org 
> Subject: [PROPOSAL] Backport GEODE-8423 to support/1.13
>
> The documentation for the Redis API for Geode that will currently be
> published for 1.13 is not accurate and needs to be updated so potential
> users searching for information about Redis API for Geode will get accurate
> information.
>

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

[Dave Barnes]

Plenty of approvals. Go ahead and port, Anil. Thanks!

On Fri, Aug 7, 2020 at 11:08 AM Owen Nichols  wrote:

> +1 and please bring to support/1.12 as well
>
> On 8/7/20, 10:49 AM, "Jianxia Chen"  wrote:
>
> +1
>
> On Fri, Aug 7, 2020 at 10:35 AM Anilkumar Gingade  >
> wrote:
>
> > This causes a large object to be partially (corrupt data) stored in
> cache
> > instead of throwing an exception.
> >
> >
>
>

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

[Dave Barnes]

Go ahead and back-port, Darrel. Thanks for your contribution.

On Mon, Aug 3, 2020 at 4:51 PM Alexander Murmann 
wrote:

> +1
>
> On Mon, Aug 3, 2020 at 4:47 PM Jianxia Chen  wrote:
>
> > +1
> >
> > On Mon, Aug 3, 2020 at 4:13 PM Darrel Schneider 
> wrote:
> >
> > > GEODE-6564 is a memory leak that has impacted users so it would be good
> > to
> > > have it in 1.13. It has a simple, low risk, fix.
> > >
> >
>

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

[Dave Barnes]

Hard to believe this problem was still hanging around. Definitely
back-port, the sooner, the better.

On Mon, Aug 3, 2020 at 7:56 AM Dave Barnes  wrote:

> +1
>
>
> On Sun, Aug 2, 2020 at 7:07 AM Donal Evans  wrote:
>
>> +1
>>
>> Nice catch!
>>
>> Get Outlook for Android<https://aka.ms/ghei36>
>>
>> 
>> From: Jinmei Liao 
>> Sent: Saturday, August 1, 2020 11:09:45 PM
>> To: dev@geode.apache.org 
>> Subject: Re: Proposal to backport GEODE-8395 (gfsh help banner) to
>> support branches
>>
>> +1
>>
>> On Aug 1, 2020 10:30 PM, Owen Nichols  wrote:
>> This issue was present since Geode 1.0.  There is zero risk from this
>> fix, which is already on develop.  It is critical because Geode releases
>> are a legal Act of the Apache Foundation and should not misrepresent the
>> identity of the project.
>>
>> Here’s the issue:
>>
>> $ gfsh
>> _ __
>>/ _/ __/ __/ // /
>>   / /  __/ /___  /_  / _  /
>> / /__/ / /  _/ / // /
>> /__/_/  /__/_//_/1.12.0
>>
>> Monitor and Manage Apache Geode<-- right product name
>>
>> $gfsh --help
>> Pivotal GemFire(R) v1.12.0 Command Line Shell   <-- WRONG product name
>>
>> The “right” instance above was fixed 5 years ago.  GEODE-8395 fixes gfsh
>> to use the “right” code in both places.  Please vote +1 to backport this
>> fix to support/1.13 and support/1.12.
>>
>>
>>

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

[Dave Barnes]

+1


On Sun, Aug 2, 2020 at 7:07 AM Donal Evans  wrote:

> +1
>
> Nice catch!
>
> Get Outlook for Android
>
> 
> From: Jinmei Liao 
> Sent: Saturday, August 1, 2020 11:09:45 PM
> To: dev@geode.apache.org 
> Subject: Re: Proposal to backport GEODE-8395 (gfsh help banner) to support
> branches
>
> +1
>
> On Aug 1, 2020 10:30 PM, Owen Nichols  wrote:
> This issue was present since Geode 1.0.  There is zero risk from this fix,
> which is already on develop.  It is critical because Geode releases are a
> legal Act of the Apache Foundation and should not misrepresent the identity
> of the project.
>
> Here’s the issue:
>
> $ gfsh
> _ __
>/ _/ __/ __/ // /
>   / /  __/ /___  /_  / _  /
> / /__/ / /  _/ / // /
> /__/_/  /__/_//_/1.12.0
>
> Monitor and Manage Apache Geode<-- right product name
>
> $gfsh --help
> Pivotal GemFire(R) v1.12.0 Command Line Shell   <-- WRONG product name
>
> The “right” instance above was fixed 5 years ago.  GEODE-8395 fixes gfsh
> to use the “right” code in both places.  Please vote +1 to backport this
> fix to support/1.13 and support/1.12.
>
>
>

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

[Dave Barnes]

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

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

These unused files need to be identified and deleted.

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

[Dave Barnes]

+1

On Thu, Jul 30, 2020 at 8:45 AM Owen Nichols  wrote:

> Hi Donal, I can confirm that develop/highwater hasn't been updated in a
> year and is no longer in use by any pipelines (all pipelines use the last
> release tag as the benchmark baseline now).
>
> On 7/30/20, 5:48 AM, "Donal Evans"  wrote:
>
> I may be mistaken, but I think the develop/highwater tag was used by
> the geode-benchmarks project. Can we get confirmation that it's no longer
> in use?
>
> +1 conditional on that
>
> Get Outlook for Android<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36data=02%7C01%7Conichols%40vmware.com%7C9d3beabf432846c6345a08d83486d80f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637317101044141000sdata=oH94Mya2EVyjt%2Bt%2FenrrGdsFZHYxAp17Ft6fqCI5cYQ%3Dreserved=0
> >
>
> 
> From: Ju@N 
> Sent: Thursday, July 30, 2020 3:10:44 AM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] one-time cleanup of stray and obsolete tags in
> geode repo
>
> +1
>
> On Thu 30 Jul 2020 at 08:21, Owen Nichols  wrote:
>
> > Tags in the rel/ namespace should be created by the Geode release
> manager
> > as part of an official Geode release only, yet we seem to have some
> extra
> > ones somehow.
> > Further, I don't see any value in keeping RC tags forever long after
> the
> > release is final.
> >
> > Please vote +1 in favor of trimming the current list of 110 tags
> down to
> > 20 to make it nice and easy for newcomers (as well as the rest of
> us) to
> > find and checkout a specific version of Geode; otherwise vote -1.
> If the
> > majority vote is +1 at 3PM PDT Fri Aug 7, I will proceed to archive
> and
> > delete the 90 unnecessary tags as detailed below.
> >
> > I propose to KEEP only the following tags, corresponding to official
> Geode
> > releases:
> >
> > rel/v1.12.0
> > rel/v1.11.0
> > rel/v1.10.0
> > rel/v1.9.2
> > rel/v1.9.1
> > rel/v1.9.0
> > rel/v1.8.0
> > rel/v1.7.0
> > rel/v1.6.0
> > rel/v1.5.0
> > rel/v1.4.0
> > rel/v1.3.0
> > rel/v1.2.1
> > rel/v1.2.0
> > rel/v1.1.1
> > rel/v1.1.0
> > rel/v1.0.0-incubating
> > rel/v1.0.0-incubating.M3
> > rel/v1.0.0-incubating.M2
> > rel/v1.0.0-incubating.M1
> >
> > I propose a one-time cleanup to DELETE all other tags, specifically:
> >
> > develop/highwater
> > modules-pre-merge
> > rel/v1.0.0-incubating.M1.RC1
> > rel/v1.0.0-incubating.M1.RC2
> > rel/v1.0.0-incubating.M2.RC1
> > rel/v1.0.0-incubating.M2.RC2
> > rel/v1.0.0-incubating.M3.RC1
> > rel/v1.0.0-incubating.M3.RC2
> > rel/v1.0.0-incubating.M3.RC3
> > rel/v1.0.0-incubating.M3.RC4
> > rel/v1.0.0-incubating.M3.RC5
> > rel/v1.0.0-incubating.M3.RC6
> > rel/v1.0.0-incubating.M3.RC7
> > rel/v1.0.0-incubating.RC1
> > rel/v1.0.0-incubating.RC2
> > rel/v1.1.0.RC1
> > rel/v1.1.0.RC2
> > rel/v1.1.0manualrev-2017-02-16
> > rel/v1.1.0manualrev-2017-10-19
> > rel/v1.1.1.RC1
> > rel/v1.1.1.RC2
> > rel/v1.10.0.1
> > rel/v1.10.0.1.RC1
> > rel/v1.10.0.2
> > rel/v1.10.0.RC1
> > rel/v1.10.0.RC2
> > rel/v1.11.0.1
> > rel/v1.11.0.2
> > rel/v1.11.0.23755
> > rel/v1.11.0.23755_2
> > rel/v1.11.0.23755_3
> > rel/v1.11.0.3
> > rel/v1.11.0.4
> > rel/v1.11.0.5
> > rel/v1.11.0.6
> > rel/v1.11.0.7
> > rel/v1.11.0.7565
> > rel/v1.11.0.8
> > rel/v1.11.0.RC1
> > rel/v1.11.0.RC2
> > rel/v1.11.0.RC3
> > rel/v1.11.0.RC4
> > rel/v1.12.0.1
> > rel/v1.12.0.1234
> > rel/v1.12.0.2
> > rel/v1.12.0.23755
> > rel/v1.12.0.3
> > rel/v1.12.0.4
> > rel/v1.12.0.5
> > rel/v1.12.0.6
> > rel/v1.12.0.RC1
> > rel/v1.12.0.RC2
> > rel/v1.12.0.RC3
> > rel/v1.12.0.RC4
> > rel/v1.14.0.23755
> > rel/v1.2.0.RC1
> > rel/v1.2.0.RC2
> > rel/v1.2.1.RC1
> > rel/v1.2.1.RC2
> > rel/v1.2.1.RC3
> > rel/v1.2.1.RC4
> > rel/v1.2.1manualrev-2017-10-19
> > rel/v1.3.0.RC1
> > rel/v1.3.0.RC2
> > rel/v1.3.0.RC3
> > rel/v1.3.0.RC4
> > rel/v1.4.0.RC1
> > rel/v1.4.0.RC2
> > rel/v1.5.0.RC1
> > rel/v1.5.0.RC2
> > rel/v1.6.0.RC1
> > rel/v1.7.0.RC1
> > rel/v1.7.0.RC2
> > rel/v1.8.0.RC1
> > rel/v1.8.0.RC2
> > rel/v1.9.0.1
> > rel/v1.9.0.1.RC1
> > rel/v1.9.0.2
> > rel/v1.9.0.RC1
> > rel/v1.9.0.RC2
> > rel/v1.9.0.RC3
> > rel/v1.9.0.RC4
> > rel/v1.9.1-nordix
> > rel/v1.9.1.RC1
> > rel/v1.9.1.RC2
> > rel/v1.9.1.RC3
> > rel/v1.9.2.RC1
> > sga2-core
> > v1.1.0manualrev-2017-10-19
> > v9.0.0-beta.1
> >
> --
> Ju@N
>
>

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

[Dave Barnes]

+1
Thanks, Bruce.

On Wed, Jul 29, 2020 at 8:22 AM Jianxia Chen  wrote:

> +1
>
> On Wed, Jul 29, 2020 at 8:04 AM Bruce Schuchardt 
> wrote:
>
> > This concerns a hang during recovery from disk.  The problem was
> > introduced in 1.13.
> >
> > https://issues.apache.org/jira/browse/GEODE-8385
> >
> >
>

Re: [PROPOSAL] Postpone Geode 1.14

[Dave Barnes]

+1

On Tue, Jul 28, 2020 at 5:05 PM Donal Evans  wrote:

> +1
> 
> From: Owen Nichols 
> Sent: Tuesday, July 28, 2020 4:38 PM
> To: Alexander Murmann ; dev@geode.apache.org <
> dev@geode.apache.org>
> Subject: Re: [PROPOSAL] Postpone Geode 1.14
>
> +1
>
>
> ---
> Sent from Workspace ONE Boxer<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=02%7C01%7Cdoevans%40vmware.com%7Ccd4d1f981e344957f92a08d8334f6516%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637315763386093818sdata=Ydv6m8%2F2p6c342hpTp3HStbMDCqD3M4xJfFLjeMc1ZM%3Dreserved=0
> >
>
> On July 28, 2020 at 4:34:55 PM PDT, Alexander Murmann 
> wrote:
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut the 1.14
> release. The actual ship date for Geode 1.13 is important information for
> that conversation. Thus we cannot have that conversation before then.
>

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

[Dave Barnes]

OK, Eric, go ahead. Thanks for your contribution!
Dave

On Tue, Jul 28, 2020 at 5:15 PM Donal Evans  wrote:

> +1
> 
> From: Dick Cavender 
> Sent: Tuesday, July 28, 2020 4:53 PM
> To: dev@geode.apache.org 
> Subject: RE: [PROPOSAL] port GEODE-8323 changes to support/1.13 branch.
>
> +1
>
> -Original Message-
> From: Eric Shu 
> Sent: Tuesday, July 28, 2020 4:22 PM
> To: dev@geode.apache.org
> Subject: [PROPOSAL] port GEODE-8323 changes to support/1.13 branch.
>
> This is to address HARegionQueue GII events not properly removed issue,
> which could potentially resurrect a strayed event in client cache.
>
> Regards,
> Eric
>

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

[Dave Barnes]

Thanks, y'all.

On Wed, Jul 22, 2020 at 5:01 PM Dick Cavender  wrote:

> +1
>
> -Original Message-
> From: Owen Nichols 
> Sent: Wednesday, July 22, 2020 4:59 PM
> To: dev@geode.apache.org
> Subject: Re: [Proposal] Back-port doc fixes to support/1.13
>
>
>
>
> +1
>
> On July 22, 2020 at 3:43:16 PM PDT, Jinmei Liao  wrote:
> +1
>
> On Jul 22, 2020 3:39 PM, Dave Barnes  wrote:
> I propose back-porting the following doc updates to Geode support/1.13
> (and 1.12, while we're at it):
>
>
> - GEODE-2113: User Guide - p2p.HANDSHAKE_POOL_SIZE is obsolete, remove
> from docs (code fixed in 1.9.0, docs fixed in 1.14.0)
>
> - GEODE-7628: Block jmx mbean creation when no security manager is
> configured (docs) (code fixed in 1.12.0, docs fixed in 1.14.0)
>
> - GEODE-8308: Some formatting text visible in the docs (docs only, fixed in
> 1.14.0)
>
> - GEODE-8363: Label Micrometer docs as experimental (docs only, fixed in
> 1.14.0)
>
> - GEODE-8377: User Guide: GFSH GC command should be documented to use only
> in non-production environments (docs only, fixed in 1.14.0)
>

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

[Dave Barnes]

I propose back-porting the following doc updates to Geode support/1.13 (and
1.12, while we're at it):


- GEODE-2113: User Guide - p2p.HANDSHAKE_POOL_SIZE is obsolete, remove from
docs (code fixed in 1.9.0, docs fixed in 1.14.0)

- GEODE-7628: Block jmx mbean creation when no security manager is
configured (docs) (code fixed in 1.12.0, docs fixed in 1.14.0)

- GEODE-8308: Some formatting text visible in the docs (docs only, fixed in
1.14.0)

- GEODE-8363: Label Micrometer docs as experimental (docs only, fixed in
1.14.0)

- GEODE-8377: User Guide: GFSH GC command should be documented to use only
in non-production environments (docs only, fixed in 1.14.0)

Re: [PROPOSAL] Cherry pic GEODE-8331 to support branches

[Dave Barnes]

Please go ahead, Jinmei. Thanks for your contribution.

On Wed, Jul 22, 2020 at 3:11 PM Dick Cavender  wrote:

> +1
>
> -Original Message-
> From: Anilkumar Gingade 
> Sent: Wednesday, July 22, 2020 2:44 PM
> To: dev@geode.apache.org
> Subject: Re: [PROPOSAL] Cherry pic GEODE-8331 to support branches
>
> +1
> This will provide a consistent experience our end user from 1.10 release
> version.
>
> On 7/22/20, 2:23 PM, "Jinmei Liao"  wrote:
>
> I would like to propose to cherry pick GEODE-8331: allow GFSH to
> connect to other versions of cluster (#5375) to support branches up to
> 1.10. This would allow gfsh to connect to other versions of cluster and
> provide better error messages when command is not support by the connected
> cluster.
>
> Jinmei
>
>

Re: [VOTE] change Default branch for geode-examples to 'develop'

[Dave Barnes]

+1

> On Jul 9, 2020, at 10:04 PM, Dick Cavender  wrote:
> 
> +1
> 
> -Original Message-
> From: Owen Nichols  
> Sent: Thursday, July 9, 2020 9:39 PM
> To: dev@geode.apache.org
> Subject: [VOTE] change Default branch for geode-examples to 'develop'
> 
> A fresh checkout of geode and all but one geode- repos checks 
> out develop as the Default branch.
> 
> The lone exception is geode-examples.  Please vote +1 if you are in favor of 
> changing its Default branch to develop for consistency with the other repos 
> and other reasons as per recent discussion[1].
> 
> [1] 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fx%2Fthread.html%2Frfec15c0a7d5d6d57beed90868dbb53e3bfcaabca67589b28585556ee%40%253Cdev.geode.apache.org%253Edata=02%7C01%7Cdickc%40vmware.com%7C1a703cc22f784158523008d8248b4188%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637299527805384154sdata=9BABTC6ROp6h3hD7lsOkezesyc%2BuJFAFQB08BFL7O%2FE%3Dreserved=0

Re: [Proposal] - RFC etiquette

[Dave Barnes]

+1

"Adding a section" (Udo's language) for Use Cases is a positive way of
encouraging RFC authors to provide that material, without saying it's an
iron-clad requirement. Exactly the right way to do it. Commenters can
request more detail when they review it.

On Thu, Jul 9, 2020 at 4:31 PM Donal Evans  wrote:

> Udo,
>
> You're right, and I agree wholeheartedly with your proposal to give RFCs
> enough time and enough context for proper review by as many people as
> possible. Sorry if that didn't come across in my original reply.
> 
> From: Udo Kohlmeyer 
> Sent: Thursday, July 9, 2020 3:55 PM
> To: dev@geode.apache.org 
> Subject: Re: [Proposal] - RFC etiquette
>
> Donal,
>
> You have very valid points. All of which only pertain to the “HOW” or “IF”
> an RFC should be written. This being a completely different problem to what
> I’m proposing. I’m willing to comment on any proposal that were to address
> these issues. :)
>
> This proposal is largely aimed at, if there is an existing RFC, we don’t
> try and rush it through and provide more context to reviewers to better
> comment on use case, technical approach or overall soundness of the
> proposal. If we keep aiming RFC’s at specialized technical knowledge, we
> will definitely lose reviewers who have not looked at that code in a long
> time. If the use case(s) are at least described than we can have many
> reviewers who can comment on the feature or technical approach without
> being intimate with all the inner workings of the system.
>
> I believe this approach will help with an overall better understanding of
> the systems behavior.
>
> —Udo
> On Jul 9, 2020, 1:46 PM -0700, Donal Evans , wrote:
> While I definitely approve of these proposals in principle (especially the
> "Use Cases" section, which could really help facilitate discussions around
> other potential solutions/approaches to a problem), the fact that the RFC
> process is still entirely voluntary on the part of the contributor(s) who
> intend to add/modify features in Geode makes me slightly hesitant to add
> extra work/complexity to it. If someone feels like it's too much effort to
> write an RFC, they may decide to skip it and go straight to PR, which for
> large/complex change sets can lead to a lot of missing context for why a
> particular approach was taken and a greater chance of only one or two
> committers actually reviewing the changes in detail rather than the larger
> community being able to weigh in on an RFC.
>
> I feel that RFCs can be a very valuable process to help determine the best
> solution to complex problems, but if there is "too much" work involved in
> creating one and nothing compelling committers to write them, we may end up
> losing out on the value they provide. Perhaps the community could agree on
> some criteria for work that would *require* an RFC, related to the
> scope/breadth of the intended changes and how many different approaches
> there might be? This would have to go hand-in-hand with a commitment from
> the community to promptly and thoroughly review RFCs, though, otherwise
> people could end up being put to the trouble of writing a comprehensive RFC
> only to have barely any actual feedback.
> 
> From: Udo Kohlmeyer 
> Sent: Thursday, July 9, 2020 1:18 PM
> To: geode 
> Subject: [Proposal] - RFC etiquette
>
> Hi there Geode Dev's
>
> I would like to propose the following changes to the RFC process that we
> have in place at the moment.
>
> 1. All submitted RFC’s will provide a minimum 2 week review period. This
> is to allow the community to review the RFC in a reasonable timeframe. If
> we rush things, we will miss things. I’d rather have a little more time
> spent on the RFC review and getting the approach “correct” than rushing the
> RFC and then at a later point in time (either at PR review or worse
> production issue) find out that the approach was less than optimal.
> 2. Add a new section to the RFC. I would like to propose this section to
> be labelled “Use Cases”. In this section I would like all submitters to
> describe the use case that this RFC is to fulfill. This would include all
> possible combinations (success and failure) and expected outcomes of each.
>
> I hope with the additions to the RFC process and template we can better
> round out each RFC. Causing less delays later in the process and allowing
> all community members to actively participate in the review process
> regardless of technical skill level.
>
> Thoughts or comments?
>
> —Udo
>

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

[Dave Barnes]

Thanks, Bruce.

On Thu, Jul 9, 2020 at 10:32 AM Bruce Schuchardt  wrote:

> Since I had 3 +1’s I merged the change to support/1.13
>
> From: Bruce Schuchardt 
> Date: Thursday, July 9, 2020 at 8:00 AM
> To: "dev@geode.apache.org" 
> Subject: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
>
> There are reports that SSL performance is off on the support/1.13 branch
> with respect to the support/1.12 branch,  but performance on develop okay.
> The only communications changes in develop that aren’t in 1.13 are those
> that fixed this long-standing bug, so I’d like to backport it to the 1.13
> branch.
>
> https://github.com/apache/geode/pull/5048
>
> The error was in the cluster communications message-streamer class that
> created some extra objects during message transmission.  The fix is small
> and has been, at this point, through many test iterations.
>

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

[Dave Barnes]

Sounds like an improvement, Juan, and you’ve got the votes.
Go ahead and back port. 
Thanks,
Dave

> On Jul 3, 2020, at 9:08 AM, Joris Melchior  wrote:
> 
> +1
> 
> On 2020-07-03, 9:06 AM, "Ju@N"  > wrote:
> 
>Hello devs,
> 
>I'd like to propose bringing GEODE-8029 [1] to the support/1.12 and
>support/1.13 branches.
>No, you're not having deja vú (neither this is an error within the Matrix):
>a couple of weeks ago I've backported another fix for the same ticket to
>the mentioned branches and sent the proposal to the list with exactly the
>same subject, but it has proven to be problematic and introduced some
>regressions... sorry about that.
>The new fix uses a different approach, solves the original issue and
>doesn't introduce any new problems (feel free to have a look at the ticket
>for further details); it has been merged into develop already through
>commit fdc4401 [2]. As a side note, I've also created a new ticket
>(GEODE-8325 [3]) to improve the internal behavior and implement a long term
>solution to avoid the proliferation of unused drf files.
>Best regards.
> 
>[1]: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8029data=02%7C01%7Cjmelchior%40vmware.com%7Ced545d4bfe2f4c74855d08d81f51ef52%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637293784053573074sdata=7%2F%2BN0mPrBss1LooT7Fu605r%2BDhYGG3JnLslQlL0pNLs%3Dreserved=0
>  
> 
>[2]:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2Ffdc440131f0d562d97f2340d2e7ba5aacf935d62data=02%7C01%7Cjmelchior%40vmware.com%7Ced545d4bfe2f4c74855d08d81f51ef52%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637293784053573074sdata=z5ztkjZ9RBsD32hE5FL3W5J%2Bc6xZh7YUYHVpruNgpjs%3Dreserved=0
>  
> 
>[3]: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8325data=02%7C01%7Cjmelchior%40vmware.com%7Ced545d4bfe2f4c74855d08d81f51ef52%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637293784053573074sdata=gXIoTE2JXozzKTwVknNdpdvAovJyoG0nM01w3Nb%2FINc%3Dreserved=0
>  
> 
> 
> 
>-- 
>Ju@N

Re: Back-Port GEODE-8240 to 1.12, 1.13

[Dave Barnes]

Hey, Bill, you got the votes. Go ahead with the back-ports.
Thanks,
Dave

On Wed, Jul 1, 2020 at 10:54 AM Kirk Lund  wrote:

> +1
>
> On Wed, Jul 1, 2020 at 9:59 AM Dick Cavender  wrote:
>
> > +1
> >
> > -Original Message-
> > From: Bruce Schuchardt 
> > Sent: Wednesday, July 1, 2020 9:49 AM
> > To: dev@geode.apache.org
> > Subject: Re: Back-Port GEODE-8240 to 1.12, 1.13
> >
> > +1
> >
> > On 7/1/20, 9:43 AM, "Bill Burcham"  wrote:
> >
> > I'd like permission to back-port the fix for rolling upgrade bug
> > GEODE-8240
> > to support/1.12 and support/1.13
> >
> > -Bill
> >
> >
>

Re: [PROPOSAL] merge GEODE-8259 to support branches

[Dave Barnes]

OK, Gester, please merge.
Thanks,
Dave

On Wed, Jul 1, 2020 at 8:33 AM Bruce Schuchardt  wrote:

> +1
> I reviewed this PR and, as Gester said, it's low risk.  If it fixes a
> problem someone is having let's backport it.
>
> On 6/30/20, 3:51 PM, "Xiaojian Zhou"  wrote:
>
> Customer encountered a singlehop getAll failure due to
> SerializationException which is identified as socket error. The
> solution is
> to retry the getAll in this race condition (currently we did not
> retry).
>
>
> The fix is tested in both develop and support branches. The fix is
> conservative and very low risk.
>
>
>
> So it would be nice to bring to before 1.13.0 release.
>
>
>
> Regards
>
> Xiaojian Zhou
>
>

Re: [PROPOSAL] merge GEODE-8259 to support branches

[Dave Barnes]

...and there it is!

On Tue, Jun 30, 2020 at 4:10 PM Dave Barnes  wrote:

> Strange -- I received the two votes 9 minutes before I got the original
> message.
> I'm heading out for the day, so Gester, if you get that third vote, go
> ahead and merge.
> Cheers,
> Dave
>
> On Tue, Jun 30, 2020 at 3:58 PM Jinmei Liao  wrote:
>
>> +1
>> 
>> From: Owen Nichols 
>> Sent: Tuesday, June 30, 2020 3:56 PM
>> To: dev@geode.apache.org 
>> Subject: Re: [PROPOSAL] merge GEODE-8259 to support branches
>>
>> +1
>>
>> On 6/30/20, 3:51 PM, "Xiaojian Zhou"  wrote:
>>
>> Customer encountered a singlehop getAll failure due to
>> SerializationException which is identified as socket error. The
>> solution is
>> to retry the getAll in this race condition (currently we did not
>> retry).
>>
>>
>> The fix is tested in both develop and support branches. The fix is
>> conservative and very low risk.
>>
>>
>>
>> So it would be nice to bring to before 1.13.0 release.
>>
>>
>>
>> Regards
>>
>> Xiaojian Zhou
>>
>>

Re: [PROPOSAL] merge GEODE-8259 to support branches

[Dave Barnes]

Strange -- I received the two votes 9 minutes before I got the original
message.
I'm heading out for the day, so Gester, if you get that third vote, go
ahead and merge.
Cheers,
Dave

On Tue, Jun 30, 2020 at 3:58 PM Jinmei Liao  wrote:

> +1
> 
> From: Owen Nichols 
> Sent: Tuesday, June 30, 2020 3:56 PM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] merge GEODE-8259 to support branches
>
> +1
>
> On 6/30/20, 3:51 PM, "Xiaojian Zhou"  wrote:
>
> Customer encountered a singlehop getAll failure due to
> SerializationException which is identified as socket error. The
> solution is
> to retry the getAll in this race condition (currently we did not
> retry).
>
>
> The fix is tested in both develop and support branches. The fix is
> conservative and very low risk.
>
>
>
> So it would be nice to bring to before 1.13.0 release.
>
>
>
> Regards
>
> Xiaojian Zhou
>
>

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

[Dave Barnes]

Thanks for taking care of that, Owen.

On Tue, Jun 30, 2020 at 9:38 AM Owen Nichols  wrote:

> Backported to support/1.13 and support/1.12
>
> On 6/30/20, 9:37 AM, "Robert Houghton"  wrote:
>
> +1
>
> From: Dick Cavender 
> Date: Tuesday, June 30, 2020 at 9:14 AM
> To: dev@geode.apache.org 
> Subject: RE: Proposal to bring GEODE-8315 (shiro upgrade) to support
> branches
> +1
>
> -Original Message-
> From: Ju@N 
> Sent: Tuesday, June 30, 2020 9:12 AM
> To: dev@geode.apache.org
> Subject: Re: Proposal to bring GEODE-8315 (shiro upgrade) to support
> branches
>
> +1
>
> On Tue, 30 Jun 2020 at 17:03, Owen Nichols 
> wrote:
>
> > Recently shiro-1.5.2.jar is getting flagged for critical security
> > vulnerability CVE-2020-11989.
> >
> > Analysis shows that Geode does not use Shiro in a manner that would
> > expose this vulnerability.
> >
> > The risk of bringing GEODE-8315 is very low (difference between Shiro
> > 1.5.2 and 1.5.3 is bugfix only).  GEODE-8315 has been on develop for
> 2
> > days and passed the pipeline.
> >
> > This fix is critical to avoid false positives in automated
> > vulnerability scans, so it would be nice to bring before 1.13.0
> release.
> >
>
>
> --
> Ju@N
>
>

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

[Dave Barnes]

For completeness, GEODE-7519 was a typo, should have been GEODE-7518.

On Mon, Jun 29, 2020 at 10:44 AM Dave Barnes  wrote:

> That was quick - thanks, all. I'll proceed with the back-port of these 5
> fixes.
>
> On Mon, Jun 29, 2020 at 10:36 AM Donal Evans  wrote:
>
>> +1
>> 
>> From: Owen Nichols 
>> Sent: Monday, June 29, 2020 10:35 AM
>> To: dev@geode.apache.org 
>> Subject: Re: [Proposal] Back-port doc fixes to support/1.13
>>
>> +1
>>
>> On 6/29/20, 10:32 AM, "Jinmei Liao"  wrote:
>>
>> +1, yay to doc changes.
>> 
>> From: Dave Barnes 
>> Sent: Monday, June 29, 2020 10:30 AM
>> To: dev@geode.apache.org 
>> Subject: [Proposal] Back-port doc fixes to support/1.13
>>
>> These five doc changes correct doc bugs and format errors that have
>> caused
>> users pain. I propose that we back-port them to support/1.13:
>>
>> GEODE-8193: Broken link in statistics list
>>
>> GEODE-7956, GEODE-7519: Docs should mention dot as a valid region name
>> character
>>
>> GEODE-8304: Better highlight steps for building documentation
>>
>> GEODE-8237: Add note about 'alter region' and cluster conf service in
>> doc
>>
>>

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

[Dave Barnes]

That was quick - thanks, all. I'll proceed with the back-port of these 5
fixes.

On Mon, Jun 29, 2020 at 10:36 AM Donal Evans  wrote:

> +1
> 
> From: Owen Nichols 
> Sent: Monday, June 29, 2020 10:35 AM
> To: dev@geode.apache.org 
> Subject: Re: [Proposal] Back-port doc fixes to support/1.13
>
> +1
>
> On 6/29/20, 10:32 AM, "Jinmei Liao"  wrote:
>
> +1, yay to doc changes.
> ____
> From: Dave Barnes 
> Sent: Monday, June 29, 2020 10:30 AM
> To: dev@geode.apache.org 
> Subject: [Proposal] Back-port doc fixes to support/1.13
>
> These five doc changes correct doc bugs and format errors that have
> caused
> users pain. I propose that we back-port them to support/1.13:
>
> GEODE-8193: Broken link in statistics list
>
> GEODE-7956, GEODE-7519: Docs should mention dot as a valid region name
> character
>
> GEODE-8304: Better highlight steps for building documentation
>
> GEODE-8237: Add note about 'alter region' and cluster conf service in
> doc
>
>

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

[Dave Barnes]

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

GEODE-8193: Broken link in statistics list

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

GEODE-8304: Better highlight steps for building documentation

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

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

[Dave Barnes]

OK - you've got the votes, Mark, thanks for your contribution.
I'm persuaded by the positive arguments and assurances of low risk.

All: let's focus on getting to RC1. I'm not comfortable with "as this
release has drug on for so long, it might be just about time to reset
expectations". Let's clean up 1.13 and get it out the door.
Thanks,
Dave


On Fri, Jun 26, 2020 at 2:54 PM Owen Nichols  wrote:

> Thank Mark and Donal for detailing the risk and criticality of this
> change.  Since 1.13 is still waiting on a couple other issues, might as
> well take the opportunity to bring this in.  My vote is +1 now.
>
> On 6/26/20, 2:32 PM, "Donal Evans"  wrote:
>
> When restore-redundancy was first proposed, the question was asked
> whether a REST api would be part of that, and the answer was an emphatic
> "no" (largely due to the continuing "experimental" labeling on the REST
> API, as I recall).  So I reject that argument that this is about "including
> the entire feature"
> The "no" regarding the inclusion of a REST api was specifically
> referring to the inclusion of that api's design in the RFC for the restore
> redundancy feature, not whether a REST api for it should exist at all. From
> the RFC: "It is also not within the scope of this RFC to describe any REST
> API that may be created at a future point in time."[1]<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands%23RedundancyGfshCommands-Anti-Goalsdata=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3Dreserved=0>
> It was always intended to create a REST api for the restore redundancy
> feature, but it was outside of the scope of my knowledge at the time the
> RFC was created to describe it fully there, so the decision was to move
> forward with the "partial" RFC rather than get bogged down in fully
> describing every facet of the feature before beginning implementation.
>
> As for the risk associated with this last stage of the restore
> redundancy feature, as far as I can tell, it's very low. The core changes
> are already in the 1.13 release branch, and have been since mid May, with
> no issues found since then. The proposed changes to be backported to the
> 1.13 release branch merely expose the REST endpoints associated with those
> changes, and don't touch core Geode at all, as far as I'm aware.
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands%23RedundancyGfshCommands-Anti-Goalsdata=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3Dreserved=0
> 
> From: Owen Nichols 
> Sent: Friday, June 26, 2020 2:09 PM
> To: dev@geode.apache.org 
> Subject: Re: [Proposal] Add REST command for Restore Redundancy to
> 1.13 (GEODE-8095)
>
> When restore-redundancy was first proposed, the question was asked
> whether a REST api would be part of that, and the answer was an emphatic
> "no" (largely due to the continuing "experimental" labeling on the REST
> API, as I recall).  So I reject that argument that this is about "including
> the entire feature"
>
> Our "critical fixes rule" notes that our quarterly release cadence
> ensures that there is always an upcoming release vehicle for new features
> -- we will be cutting support/1.14 in just a few weeks on Aug 3.  Can you
> make the case that this feature is critical to release sooner?  As I
> understand it this feature is just an optimization -- existing code can
> already use the rebalance API to restore redundancy, it just might take a
> little longer.
>
> That said, all you need is three votes, so make your case.  Especially
> as we are already 8 weeks past the branch cut of support/1.13, and
> hopefully getting very close to an RC1, concern about risk weighs on my
> mind more than the merits.  What level of testing has this been through?
> Does it touch core code?  You may be able to get the votes just by
> demonstrating that the risk is very low.
>
> I'm a +0 for this based on the information presented so far.
>
> On 6/26/20, 11:50 AM, "Donal Evans"  wrote:
>
> +1
>
> Although normally features wouldn't really count as "critical
> fixes" that would warrant inclusion after the release branch has been cut,
> in this case, the internal API and gfsh commands for restore redundancy are
> already in the release, and it makes much more sense to include the entire
> feature in one release rather than having a semi-complete feature in 1.13
> and forcing the REST component to wait for a later release.
> 
> 

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

[Dave Barnes]

Looks good. Merge to 1.13 (if you haven't already).
-Dave

On Fri, Jun 26, 2020 at 10:05 AM Donal Evans  wrote:

> +1
> 
> From: Owen Nichols 
> Sent: Friday, June 26, 2020 9:59 AM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12
>
> +1
>
> On 6/26/20, 7:58 AM, "Ju@N"  wrote:
>
> +1
>
> On Fri, 26 Jun 2020 at 15:51, Bruce Schuchardt 
> wrote:
>
> > This small fix avoids a failure of one cluster to communicate with
> the
> > locators of another cluster, ensuring that a proper handshake for WAN
> > communications occurs.  Without the fix it’s possible that WAN
> connections
> > will not be formed and updates will not be transmitted between sites.
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5306data=02%7C01%7Cdoevans%40vmware.com%7Cf0fdfd0e9f3f4d1225c508d819f24b53%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637287875728618402sdata=ROQYORRw357JRmVBW3gCxRFoptOz%2F%2Fg6oEMoRN4vrhg%3Dreserved=0
> >
> >
>
> --
> Ju@N
>
>

Re: Fate of master branch

[Dave Barnes]

+1 if we can override git’s ‘master’ default and establish ‘develop’ in its 
place. Otherwise renaming to ‘main’ would solve the problem with the negative 
connotations.

NB: Mark, I think the 3-vote convention is just for back-ports to the 
release-branch. I don’t think of it as applying to a general discussion like 
this one.

> On Jun 26, 2020, at 9:42 AM, Anthony Baker  wrote:
> 
> By just do it, I assume you mean:
> 
> - Contact delete master where not needed
> - Rename master to main when needed
> - Contact INFRA to change the default branch
> - Update README and CI jobs as needed
> 
> Across *all* geode repos.
> 
> 
> Anthony
> 
> 
>> On Jun 26, 2020, at 9:38 AM, Mark Hanson  wrote:
>> 
>> +1 to delete. No good reason to keep it that I know of. I think I am the 
>> third +1 with no -1s so just do it.
>> 
>> Thanks,
>> Mark
>> 
>>> On Jun 26, 2020, at 9:13 AM, Alexander Murmann  wrote:
>>> 
>>> +1 to deleting. Given we tag everything properly on the other branches, I
>>> don't see the need for it either.
>>> 
>>> On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes
>>>  wrote:
>>> 
 +1 for deleting master branch. An also for updating the wiki page about
 branching that Alberto pointed out.
 
 De: Bruce Schuchardt 
 Enviado: viernes, 26 de junio de 2020 17:37
 Para: dev@geode.apache.org 
 Asunto: Re: Fate of master branch
 
 Let's just delete it.  I need to do that in my own repos as well.
 
 On 6/26/20, 8:05 AM, "Blake Bender"  wrote:
 
  Apologies if this has been addressed already and I missed it.  In
 keeping with other OSS projects, I believe it’s time we did something about
 removing the insensitive term master from Geode repositories.
 
  One choice a lot of projects appear to be going with is a simple
 rename from master • main.  In our own case, however, master isn’t really
 in use for anything vital.  We track releases with a tag and a branch to
 backport fixes to, and the develop branch is the “source of truth”
 latest-and-greatest version of the code.  We could thus simply delete
 master with no loss I’m aware of.  Any opinions?
 
  Thanks,
 
  Blake
 
 
 
>> 
> 

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

[Dave Barnes]

Thanks for taking care of this, Naba.

> On Jun 19, 2020, at 12:27 PM, Nabarun Nag  wrote:
> 
> Thank you all for the  votes needed for the backport. It has been backported 
> to support/1.13 branch
> 
> GEODE-8261: Added a null check for the proxyID. (#5251)
> 
> Regards
> Naba
> 
> 
> -Original Message-
> From: Jianxia Chen  
> Sent: Friday, June 19, 2020 12:22 PM
> To: dev@geode.apache.org
> Subject: Re: [VOTE] Backporting of GEODE-8261 to 1.13 release branch.
> 
> +1
> 
> On Fri, Jun 19, 2020 at 12:16 PM Nabarun Nag  wrote:
> 
>> Hi Geode devs,
>> 
>> Requesting vote to backport of GEODE-8261 to 1.13
>> 
>> Why?
>> This commit fixes an issue with servers throwing null pointer 
>> exceptions while a member is being shutdown and registering interest is in 
>> process.
>> 
>> SHA
>> 720a4caea2ddb22296aa3225fc5264d2096cdf20
>> 
>> 
>> Regards
>> Nabarun
>> 

Re: [PROPOSAL] back port fix for GEODE-8251 to support branches

[Dave Barnes]

OK to backport, Jinmei. Thanks for your contribution.
-Dave

(I saw a +1 vote from Owen in another email client, though it doesn’t seem to 
show up in this rendering of the thread. Thought I had successfully worked 
around the email issue. Hmmm…)

> On Jun 19, 2020, at 8:47 AM, Jianxia Chen  wrote:
> 
> +1
> 
> On Fri, Jun 19, 2020 at 8:46 AM Jinmei Liao  wrote:
> 
>> Need one more vote 
>> 
>> From: Bruce Schuchardt 
>> Sent: Thursday, June 18, 2020 3:43 PM
>> To: dev@geode.apache.org 
>> Subject: Re: [PROPOSAL] back port fix for GEODE-8251 to support branches
>> 
>> +1
>> 
>> On 6/18/20, 3:24 PM, "Jinmei Liao"  wrote:
>> 
>>The fix for this issue
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8251data=02%7C01%7Cjiliao%40vmware.com%7C76cb38f955c84ade5d9f08d813d91e9c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637281170530289424sdata=a8fdpKs4MUwr90bE0oOgobk5so840TJhK47%2FJFE0JDs%3Dreserved=0
>> is needed on support 1.13 branch in order for rolling upgrade to work from
>> 1.12 to 1.13.
>> 
>>Thanks!
>> 
>>Jinmei
>> 
>> 

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

[Dave Barnes]

Wow, +103! Sounds like an endorsement.

On Thu, Jun 18, 2020 at 12:44 PM Owen Nichols  wrote:

> +1
>
> On 6/18/20, 12:15 PM, "Dick Cavender"  wrote:
>
> +1
>
> -Original Message-
> From: Ernie Burghardt 
> Sent: Thursday, June 18, 2020 10:49 AM
> To: dev@geode.apache.org
> Subject: Re: [PROPOSAL] backport GEODE-8277 to support/1.13
>
> +100
>
> On 6/18/20, 10:46 AM, "Bruce Schuchardt"  wrote:
>
> Several keystores used by a test have expired, which will cause
> acceptance tests to fail in support/1.13.  I’d like to cherry-pick the new
> keystores into that branch.  The new keystores have a 5/2120 expiration
> date.
>
>
>

Re: [PROPOSAL] backport PR #5250 to support/1.13

[Dave Barnes]

Looks good, Bruce. Please backport.


On Tue, Jun 16, 2020 at 4:01 PM Owen Nichols  wrote:

> +1
>
> On 6/16/20, 3:54 PM, "Jianxia Chen"  wrote:
>
> +1
>
> On Tue, Jun 16, 2020 at 3:24 PM Bruce Schuchardt 
> wrote:
>
> > This PR has been merged to develop.  It fixes a problem with the
> previous
> > commit for GEODE-8144 that caused performance degradation when TLS is
> > enabled between servers.  I have run perf tests and verified that it
> fixes
> > the problem.
> >
> > It’s a small change that makes a big difference…
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5250data=02%7C01%7Conichols%40vmware.com%7Ce2ec5e282bb240a6406d08d812484504%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637279448892893348sdata=1qOm9MNcOb0JbWE8PTtLJEicYXbO8QglFaPk18VhRss%3Dreserved=0
> >
> >
>
>

Re: Refactor to Restore Redundancy Command for 1.13?

[Dave Barnes]

Thanks for clarifying, Mark. Let's wait for all the approvals and test
results before back-porting to 1.13.


On Tue, Jun 16, 2020 at 2:16 PM Mark Hanson  wrote:

> Hi Dave,
>
> So this PR is actually awaiting some reviews before it will be put on
> develop.
>
> Thanks,
> Mark
>
> On 6/16/20, 2:07 PM, "Dave Barnes"  wrote:
>
> If I understand correctly that the refactored version has already been
> checked in and tested on `develop`, then we have enough approvals to
> add
> this to 1.13.
> Go ahead, Mark.
>
> On Tue, Jun 16, 2020 at 8:45 AM Joris Melchior 
> wrote:
>
> > Yes, +1 on this change.
> >
> > Joris
> > 
> > From: Mark Hanson 
> > Sent: June 15, 2020 16:30
> > To: dev@geode.apache.org 
> > Subject: Re: Refactor to Restore Redundancy Command for 1.13?
> >
> > To be clear the code for 1.13 using the Restore Redundancy Command
> in GFSH
> > is fine as it stands. We are refactoring to add the REST API version.
> >
> > Are people still good with that?
> >
> > Thanks,
> > Mark
> >
> > On 6/15/20, 1:28 PM, "Kirk Lund"  wrote:
> >
> > +1 for getting the change into 1.13
> >
> > On Mon, Jun 15, 2020 at 1:25 PM Owen Nichols <
> onich...@vmware.com>
> > wrote:
> >
> > > +1 for getting it right the first time
> > >
> > >
> > > ---
> > > Sent from Workspace ONE Boxer<
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=02%7C01%7Chansonm%40vmware.com%7C774b45ee83db4e6a5a5a08d812394116%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637279384406586799sdata=vcdgVzwoT7OO7%2BJJC1s6U8VVO2lpg0rYFCLSMHR9Kq4%3Dreserved=0
> > >
> > >
> > > On June 15, 2020 at 1:23:59 PM PDT, Mark Hanson <
> hans...@vmware.com>
> > > wrote:
> > > Hi All,
> > >
> > > So we are working on refactoring the Restore Redundancy gfsh
> command
> > code
> > > and we have made a change to a class that is getting
> serialized. We
> > are
> > > curious if this is something we could maybe get into 1.13 (
> the first
> > > release of this command? Or should we just make our
> > > serialization/deserialization work for 2 versions?
> > >
> > > Thanks,
> > > Mark
> > >
> >
> >
>
>

Re: Refactor to Restore Redundancy Command for 1.13?

[Dave Barnes]

If I understand correctly that the refactored version has already been
checked in and tested on `develop`, then we have enough approvals to add
this to 1.13.
Go ahead, Mark.

On Tue, Jun 16, 2020 at 8:45 AM Joris Melchior  wrote:

> Yes, +1 on this change.
>
> Joris
> 
> From: Mark Hanson 
> Sent: June 15, 2020 16:30
> To: dev@geode.apache.org 
> Subject: Re: Refactor to Restore Redundancy Command for 1.13?
>
> To be clear the code for 1.13 using the Restore Redundancy Command in GFSH
> is fine as it stands. We are refactoring to add the REST API version.
>
> Are people still good with that?
>
> Thanks,
> Mark
>
> On 6/15/20, 1:28 PM, "Kirk Lund"  wrote:
>
> +1 for getting the change into 1.13
>
> On Mon, Jun 15, 2020 at 1:25 PM Owen Nichols 
> wrote:
>
> > +1 for getting it right the first time
> >
> >
> > ---
> > Sent from Workspace ONE Boxer<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=02%7C01%7Cjmelchior%40vmware.com%7C9d6cf31bdd97492b191808d8116ae982%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637278498191299129sdata=7pw0D4Xl2AYwFj%2BLn7apALTVw%2B5nZaVDP6Vkz0Nl4HU%3Dreserved=0
> >
> >
> > On June 15, 2020 at 1:23:59 PM PDT, Mark Hanson 
> > wrote:
> > Hi All,
> >
> > So we are working on refactoring the Restore Redundancy gfsh command
> code
> > and we have made a change to a class that is getting serialized. We
> are
> > curious if this is something we could maybe get into 1.13 ( the first
> > release of this command? Or should we just make our
> > serialization/deserialization work for 2 versions?
> >
> > Thanks,
> > Mark
> >
>
>

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

[Dave Barnes]

OK, Bruce -- merge away.
Thanks,
Dave

On Thu, Jun 11, 2020 at 12:47 PM Dick Cavender  wrote:

> +1
>
> -Original Message-
> From: Eric Shu 
> Sent: Thursday, June 11, 2020 11:33 AM
> To: dev@geode.apache.org
> Subject: Re: [PROPOSAL] backport GEODE-8238 to support/1.13
>
> +1
> 
> From: Owen Nichols 
> Sent: Thursday, June 11, 2020 10:58 AM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] backport GEODE-8238 to support/1.13
>
> +1
>
>
> ---
> Sent from Workspace ONE Boxer<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=02%7C01%7Cdickc%40vmware.com%7C449d3bc3f7fa465b8d7b08d80e36d985%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637274976024080508sdata=3hgzE2ImoJR8lePkXCM307ob%2FVB7m4dyEcbxLA75laI%3Dreserved=0
> >
>
> On June 11, 2020 at 10:52:19 AM PDT, Bruce Schuchardt 
> wrote:
> This ticket concerns loss of a message and a subsequent hang during
> shutdown.  The problem is also in support/1.13 and I'd like to backport to
> that branch.
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8238data=02%7C01%7Cdickc%40vmware.com%7C449d3bc3f7fa465b8d7b08d80e36d985%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637274976024080508sdata=cG2rc2X1YAmsqGZVumT%2F4JLUYIH5hjm8Y%2Fw8ADIa6oQ%3Dreserved=0
>
> It's a small change to fix a problem introduced in changes for GEODE-7727.
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-7727data=02%7C01%7Cdickc%40vmware.com%7C449d3bc3f7fa465b8d7b08d80e36d985%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637274976024085498sdata=xaYlc41o44RmSdwvko%2FuhBW6VtNvRgFXGAsRbU%2FY2YQ%3Dreserved=0
>
>

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

[Dave Barnes]

Looks like the community approves, Ju@n. Go ahead and merge.
Thanks,
Dave

On Wed, Jun 10, 2020 at 10:37 AM Joris Melchior 
wrote:

> +1
> 
> From: Ju@N 
> Sent: June 10, 2020 6:18
> To: dev@geode.apache.org 
> Subject: [PROPOSAL]: BackPort GEODE-8029 to support/1.12 and support/1.13
>
> Hello devs,
>
> I'd like to propose bringing GEODE-8029 [1] to the *support/1.12* and
> *support/1.13* branches.
> The fix has been merged into develop through commit
> bc0090dc93643fd4d09c79a4b0c29d883172b546 [2], and it's basically to make
> sure we delete unused drfs upon initialization to prevent the proliferation
> of unused records and files within the file system, which could cause
> members to fail during startup while recovering disk-stores.
> Best regards.
>
> [1]:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8029data=02%7C01%7Cjmelchior%40vmware.com%7C96432ff1699a4d2ed2a508d80d27a970%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637273811288277601sdata=kw1jFlsIIdlhh%2FTxW%2BcZD2BVmfQzGSCgoW1xyRdKE4E%3Dreserved=0
> [2:]
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2Fbc0090dc93643fd4d09c79a4b0c29d883172b546data=02%7C01%7Cjmelchior%40vmware.com%7C96432ff1699a4d2ed2a508d80d27a970%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637273811288277601sdata=R412kMw3EXKl6%2FOgKP3OEZDuJJs%2F3uRIT0AZljdlpDo%3Dreserved=0
>
> --
> Ju@N
>

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

[Dave Barnes]

Suppose I want to commit to another contributor's fork. How can they grant
me permission to do so? (This is a common predicament for me when I'm
reviewing doc PRs.)


On Wed, Jun 3, 2020 at 2:04 PM Xiaojian Zhou  wrote:

> We have discussed that when in Common team. The current solution worked
> perfectly.
>
> One person will merge the develop into feature/GEODE-7665 (which
> conceptually can be anyone. I did 2 times) every week. Now Naba is taking
> the responsibility to do the weekly merge. He did great!
>
> Fork will cause many other issues, it will still need a person to maintain
> it. I feel fork is only suitable for a work that will be finished within a
> week.
>
> Regards
> Gester
>
> On 6/2/20, 4:41 PM, "Nabarun Nag"  wrote:
>
> I don’t think it is right to make the open source Geode Community to
> work on my personal fork
>
> Regards
> Naba
>
>
> -Original Message-
> From: Mark Hanson 
> Sent: Tuesday, June 2, 2020 4:35 PM
> To: dev@geode.apache.org
> Subject: Re: [DISCUSSION] Stop using the Geode Repository for
> Feature/WIP Branches
>
> While I am not 100% sure, I understand your thoughts here, I am pretty
> sure I do. We have already done such work in a branch in a fork (Micrometer
> work). The only real gotcha was that there needed to be one person at least
> as a collaborator, in case of vacations and such.
>
> All of the things you have specified are possible within the confines
> of a fork.
>
> Thanks,
> Mark
>
> On 6/2/20, 4:29 PM, "Nabarun Nag"  wrote:
>
> - We are maintaining feature/GEODE-7665 which is the feature
> branch for PR clear work on which multiple developers are working on.
> - We are maintaining this in Geode repository.
> - All sub-tasks of GEODE-7665 are merged into this feature branch.
> - Anyone in the Geode community can work on any subtask
> - This is a long running, and a massive feature development which
> is manipulating core code on Apache Geode. Hence all work is pushed to the
> feature branch to keep develop isolated from a regression introduced in PR
> clear work.
> - We have previously used release flags for Lucene work which we
> found to be inefficient and unnecessary extra work.
>
> We vote that PR clear feature branch be maintained in the Geode
> Repository as this is a long running, massive effort involving everyone
> from the community.
>
> When the PR clear tasks are completed, the branch will be
> rigorously tested and then squash merged into develop and the feature
> branch will be deleted.
>
>
> Regards
> Naba
>
> -Original Message-
> From: Jacob Barrett 
> Sent: Tuesday, June 2, 2020 3:43 PM
> To: dev@geode.apache.org
> Subject: [DISCUSSION] Stop using the Geode Repository for
> Feature/WIP Branches
>
> I know this has been brought up multiple times without resolution.
> I want us resolve to ban the use of Geode repository for work in progress,
> feature branches, or any other branches that are not release or support
> branches. There is no reason given the nature of GitHub why you can’t fork
> the repository to contribute.
>
> * Work done on these branches results in the ASF bots updating the
> associated JIRAs and email blasting all of us with your work.
>
> * People don’t clean up these branches, which leads to a mess of
> branches on everyones clones and in the UI.
>
> * All your intermediate commits get synced to the repo, which
> bloats the repo for everyone else. Even your commits you rebase over and
> force push are left in the repo. When you delete your branch these commits
> are not removed. There is no way for us to prune unreferenced commits.
> Nobody else needs your commits outside of what was merged to a production
> branch.
>
> If anyone has a use case for working directly from Geode repo that
> can’t work from a fork please post it here so we can resolve.
>
> Thanks,
> Jake
>
>
>
>
>
>

Re: [PROPOASAL] backport GEODE-8144

[Dave Barnes]

I'm going to spend a release-manager +1 to put this proposal over the top.
Please merge this fix into support/1.13, Bruce.
Thanks,
Dave

On Thu, May 28, 2020 at 7:52 AM Udo Kohlmeyer  wrote:

> +1
> On May 27, 2020, 1:35 PM -0700, Bruce Schuchardt ,
> wrote:
> This ticket has two PRs. One passed all normal CI runs but then we hit a
> faulty test that failed on a Windows machine. There’s a new PR that fixes
> that test & has been merged.
>
> The PRs fixe endpoint verification problems in servers and locators.
> Without this fix it’s not possible to boot a locator/server with endpoint
> verification enabled.
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5164data=02%7C01%7Cudo%40vmware.com%7C0796e6c983d444e87feb08d8027d7ce8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637262085284295283sdata=sqhirE3DudI00gOpLHlGYTHG9T8GPNVaJK7GB6rSl%2Bc%3Dreserved=0
> fixes the failing test
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5131data=02%7C01%7Cudo%40vmware.com%7C0796e6c983d444e87feb08d8027d7ce8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637262085284305283sdata=BruRleV2p%2BRVg5mWBEt8LPWrCsMKUClogFX8VInanmc%3Dreserved=0
> is the original PR
>
> both have been merged to develop
>
>
>

Re: No more hardcoded region separators!

[Dave Barnes]

Excellent, Donal!
If you have not already done so, please consider documenting the practice
you're advocating in a place where all community contributors have a chance
of seeing it. Maybe
https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute?

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

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