Re: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo
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 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: > > > Persona
[VOTE] Apache Geode 1.15.0.RC1
Hello Geode Dev Community, This is a release candidate for Apache Geode version 1.15.0.RC1. Thank you to all community members for your contributions to this release over the past 490 days! Please do a review and give your feedback, including the checks you performed. Voting deadline: 3PM PST Wed, June 22 2022. Please note that we are voting upon the source tag: rel/v1.15.0.RC1 Release notes: https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.15.0 Source and binary distributions: https://dist.apache.org/repos/dist/dev/geode/1.15.0.RC1/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachegeode-1138 GitHub: https://github.com/apache/geode/tree/rel/v1.15.0.RC1 https://github.com/apache/geode-examples/tree/rel/v1.15.0.RC1 https://github.com/apache/geode-native/tree/rel/v1.15.0.RC1 https://github.com/apache/geode-benchmarks/tree/rel/v1.15.0.RC1 Pipelines: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-15-main https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-15-rc Geode's KEYS file containing PGP keys we use to sign the release: https://github.com/apache/geode/blob/develop/KEYS Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=https://dist.apache.org/repos/dist/dev/geode/1.15.0.RC1 -PgeodeRepositoryUrl=https://repository.apache.org/content/repositories/orgapachegeode-1138 build runAll Regards -Owen Nichols 1.15.0 Geode Release Manager
Re: [VOTE] Apache Geode 1.15.0.RC1
+1 Verified that performance across a variety of workloads is on par with previous releases. From: Owen Nichols Sent: Friday, June 17, 2022 9:22 AM To: dev@geode.apache.org Subject: [VOTE] Apache Geode 1.15.0.RC1 ⚠ External Email Hello Geode Dev Community, This is a release candidate for Apache Geode version 1.15.0.RC1. Thank you to all community members for your contributions to this release over the past 490 days! Please do a review and give your feedback, including the checks you performed. Voting deadline: 3PM PST Wed, June 22 2022. Please note that we are voting upon the source tag: rel/v1.15.0.RC1 Release notes: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.15.0&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1Jh2qL5j5uLqpcT7UsH%2BAxSd9SAbTvtbJAloOvt95Nc%3D&reserved=0 Source and binary distributions: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.15.0.RC1%2F&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hg5QXyPY9tGEXVHeMXOkjICIZn7p4sM%2BVx3yAFLUKYQ%3D&reserved=0 Maven staging repo: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1138&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Dqp5pW5UFWg4P%2Fl0j1rnq1YjhGVyiuHuNdymAQuBDmU%3D&reserved=0 GitHub: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.15.0.RC1&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pA2U7tRLdfcQvJfE1Jkkcs5PPOj9EzcUDugPFmg1WPs%3D&reserved=0 https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.15.0.RC1&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A9jlDbACLA7dckkqgEI2yKb1zy7gVUMBP6S4%2FA959Io%3D&reserved=0 https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.15.0.RC1&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ds5BxaLZ%2BdCJtzgdUdG%2FYZORZB2vPE2bplcGNgKwfqA%3D&reserved=0 https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.15.0.RC1&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6dS5Avqw%2BrJsov0%2Bjh%2Bj0jo%2F7EWUK1Ia9kjPVj3nPb8%3D&reserved=0 Pipelines: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-15-main&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9EaCLqQg6Q1RwsjxI3459rnl9DwS19xtDxQvmNpamoE%3D&reserved=0 https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-15-rc&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aB4MDvwtxzE%2FIYW1uy77CAbKzgaLqNjy4NWb32z0bMQ%3D&reserved=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%2FKEYS&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507
Re: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo
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 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.
Re: [VOTE] Apache Geode 1.15.0.RC1
+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.0&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1Jh2qL5j5uLqpcT7UsH%2BAxSd9SAbTvtbJAloOvt95Nc%3D&reserved=0 > > Source and binary distributions: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.15.0.RC1%2F&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hg5QXyPY9tGEXVHeMXOkjICIZn7p4sM%2BVx3yAFLUKYQ%3D&reserved=0 > > Maven staging repo: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1138&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Dqp5pW5UFWg4P%2Fl0j1rnq1YjhGVyiuHuNdymAQuBDmU%3D&reserved=0 > > GitHub: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.15.0.RC1&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pA2U7tRLdfcQvJfE1Jkkcs5PPOj9EzcUDugPFmg1WPs%3D&reserved=0 > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.15.0.RC1&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A9jlDbACLA7dckkqgEI2yKb1zy7gVUMBP6S4%2FA959Io%3D&reserved=0 > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.15.0.RC1&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ds5BxaLZ%2BdCJtzgdUdG%2FYZORZB2vPE2bplcGNgKwfqA%3D&reserved=0 > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.15.0.RC1&data=05%7C01%7Cdoevans%40vmware.com%7Cf13795dd8e85426d373108da507da954%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63791079797735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6dS5Avqw%2B
