[DISCUSS] Geode Redis Adapter

[Patrick Johnson]

I noticed that Geodes Redis Adapter needs some work, but doesn't seem to
have gotten much attention recently. In its current state, it is confusing
for users looking to run their Redis clients against Geode. What do you
think about moving it to a branch until we make it better?

Re: Adding GEODE-7412 to 1.11 release

[Patrick Johnson]

+1

> On Nov 8, 2019, at 10:56 AM, Udo Kohlmeyer  wrote:
> 
> Hi there Geode Dev,
> 
> I would like to request that we add 
> https://issues.apache.org/jira/browse/GEODE-7412 
>  to the 1.11 release.
> 
> This change is a build change that has crept in since 1.8. The issue that is 
> to be fixed is that the web archive, (geode-pulse) has since 1.8 been 
> uploaded as a jar file to maven central.
> 
> I would like to fix this by having the WAR artifact being pushed to maven 
> central again.
> 
> --Udo
> 

Permission to assign tickets in Jira

[Patrick Johnson]

Hi all,

Could someone grant me permission to assign tickets to myself in the Geode
Jira?

My Jira username is pjohnson.

-- 
Thanks,
Patrick Johnson

Re: Permission to assign tickets in Jira

[Patrick Johnson]

Thanks Dan!

> On Dec 3, 2019, at 4:11 PM, Dan Smith  wrote:
> 
> Done!
> 
> -Dan
> 
> On Tue, Dec 3, 2019 at 3:38 PM Patrick Johnson  wrote:
> 
>> Hi all,
>> 
>> Could someone grant me permission to assign tickets to myself in the Geode
>> Jira?
>> 
>> My Jira username is pjohnson.
>> 
>> --
>> Thanks,
>> Patrick Johnson
>> 

Re: New geode-gfsh module

[Patrick Johnson]

Our goal wasn’t to make gfsh standalone, but a couple people have asked about 
it already. It’s not currently planned as far as I know, though maybe it will 
be in the future.

> On Dec 6, 2019, at 10:00 AM, Jacob Barrett  wrote:
> 
> 
> 
>> On Dec 6, 2019, at 9:43 AM, Jens Deppe  wrote:
>> 
>> The geode-dependencies.jar now includes the *geode-gfsh.jar* (as well as
>> Spring still).
> 
> Should it??

Re: [VOTE] Inclusion of GEODE-7159 into 1.11

[Patrick Johnson]

+1

> On Dec 17, 2019, at 2:59 PM, Owen Nichols  wrote:
> 
> +1
> 
>> On Dec 17, 2019, at 2:58 PM, Udo Kohlmeyer  wrote:
>> 
>> Hi there Apache Devs.
>> 
>> I can we please vote on the inclusion of GEODE-7159. This issue is to fix an 
>> bug which assumes that all `Pool` objects are of type `PoolImpl` and 
>> immediately casts Pool -> PoolImpl. This issue is related to GEODE-7531, and 
>> is specific to the emergencyClose method.
>> 
>> In the case of testing with Mocks, the type casts fail, because the 
>> Pool-mocks are not of type PoolImpl. The simplest fix (for now) was to type 
>> check before the cast.
>> 
>> 
>> Regards
>> 
>> Udo
>> 
> 

Re: [VOTE] Inclusion of GEODE-7531 into 1.11

[Patrick Johnson]

+1

> On Dec 17, 2019, at 3:01 PM, Owen Nichols  wrote:
> 
> +1
> 
>> On Dec 17, 2019, at 2:57 PM, Udo Kohlmeyer  wrote:
>> 
>> Hi there Apache Devs.
>> 
>> I can we please vote on the inclusion of GEODE-7531. This issue is to fix an 
>> bug which assumes that all `Pool` objects are of type `PoolImpl` and 
>> immediately casts Pool -> PoolImpl.
>> 
>> In the case of testing with Mocks, the type casts fail, because the 
>> Pool-mocks are not of type PoolImpl. The simplest fix (for now) was to type 
>> check before the cast.
>> 
>> 
>> Regards
>> 
>> Udo
>> 
> 

Re: [Vote] Include GEODE-7752 into 1.12

[Patrick Johnson]

+1

On 2/5/20, 1:53 PM, "Udo Kohlmeyer"  wrote:

Hi there Geode dev,

I would like to request that GEODE-7752 
(7028f601680fee3f57cbdff63951128d7180ca13) gets included into 1.12.

This piece of code is a refactor of work done in GEODE-7715. This 
refactor specializes Builders and simplifies Builder behavior for better 
user experience.

--Udo

Re: [DISCUSSION] Bumping dependency versions for 1.12

[Patrick Johnson]

+1

On 2/11/20, 8:42 AM, "Udo Kohlmeyer"  wrote:

Hi there,

I wonder if this might be a little late in the game, but would we 
consider bumping some of the dependency versions for 1.12?

Off the top of my head, Spring from 5.2.1 to 5.2.3

--Udo

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

[Patrick Johnson]

+1

On 3/18/20, 11:50 AM, "Dan Smith"  wrote:

+1

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

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

Re: Reconfiguring our notifications and more

[Patrick Johnson]

+1

On Apr 21, 2020, at 8:55 AM, Robert Houghton 
mailto:rhough...@pivotal.io>> wrote:

+1

On Tue, Apr 21, 2020, 08:54 Anthony Baker 
mailto:aba...@pivotal.io>> wrote:

I’d like a quick round of feedback so we can stop the dev@ spamming [1].

ASF has implemented a cool way to give projects control of lots of things
[2].  In short, you provide a .asf.yml in each and every GitHub repo to
control lots of interesting things.  For us the most immediately relevant
are:

notifications:
 commits: comm...@geode.apache.org
 issues:  iss...@geode.apache.org
 pullrequests:  
notificati...@geode.apache.org
 jira_options: link label comment

I’d like to commit this to /develop and cherry-pick over to /master ASAP.
Later on we can explore the website and GitHub sections.  Let me know what
you think.

Anthony


[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FINFRA-20156&data=02%7C01%7Cjpatrick%40vmware.com%7C6fa53ba0ce4f40746e2c08d7e60c8a73%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637230813852989468&sdata=vw%2BlWbYy%2Fgtjtf7m%2FykruxqLYGB55QlZc%2F4Ou3Typr8%3D&reserved=0
[2]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FINFRA%2F.asf.yaml%2Bfeatures%2Bfor%2Bgit%2Brepositories%23id-.asf.yamlfeaturesforgitrepositories-Notificationsettingsforrepositories&data=02%7C01%7Cjpatrick%40vmware.com%7C6fa53ba0ce4f40746e2c08d7e60c8a73%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637230813852989468&sdata=S1QCL507a5bZ%2FOkkhGEU%2FhHM%2BY4wWiHBXVBPHCZb54s%3D&reserved=0

Proposal to bring GEODE-8068 to support/1.13

[Patrick Johnson]

I’d like to bring GEODE-8068 to support/1.13. This commit reverts two prior 
commits (GEODE-8033 and GEODE-8044). GEODE-8033 and GEODE-8044 introduced an 
experimental feature that is useless in its current state and has already been 
redesigned, so there is no reason for it to go out with 1.13.

Regards,
Patrick

Re: [Proposal] - RFC etiquette

[Patrick Johnson]

+1

> On Jul 9, 2020, at 1:18 PM, Udo Kohlmeyer  wrote:
> 
> 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

Request wiki access

[Patrick Johnson]

Hi,

Can someone grant me write access to the Apache Geode wiki? My user name is 
jpatrick, same as my email address.

Thanks,
Patrick Johnson

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

[Patrick Johnson]

+1

> On Aug 12, 2020, at 8:59 AM, Sarah Abbey  wrote:
> 
> 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: [VOTE] Apache Geode 1.13.0.RC1

[Patrick Johnson]

+1

What I did:

- Built from source
- Ran unit tests
- Built Spring Data Geode using 1.13
- Ran the Spring Data Geode unit tests using 1.13
- Ran the Spring Data Geode examples using 1.13


On Sep 8, 2020, at 5:02 PM, John Blum 
mailto:jb...@vmware.com>> wrote:

+1

Built Spring Data for Apache Geode (SDG) Ockham/2.4(2020-0-0) on Apache Geode 
1.13.0 (RC1), using the staging repository, successfully!

-John
SDG Lead



From: Apache mailto:aaronlind...@apache.org>>
Sent: Tuesday, September 8, 2020 4:07 PM
To: dev@geode.apache.org 
mailto:dev@geode.apache.org>>
Subject: Re: [VOTE] Apache Geode 1.13.0.RC1

+1 Looks good to me!

- Built from source and ran unit tests
- Used GFSH to create a locator and server and do some puts/gets
- Checked version in GFSH
- Built and ran all of the examples
- Verified SHAs and signatures

Aaron

On Sep 8, 2020, at 3:33 PM, Jens Deppe 
mailto:jde...@vmware.com>> wrote:

+1

Actions performed:

- Downloaded product .tgz bundle from maven co-ordinates
- Verified GemFireVersion.properties matched SHA for 1.13.0 build tag
- Started cluster with SSL enabled and ensured basic GFSH operations over HTTPS
- Connected GFSH v1.13.0 to newer cluster running v1.14.0

--Jens

On 9/7/20, 8:23 PM, "Dave Barnes" 
mailto:dbar...@apache.org>> 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.0&data=02%7C01%7Cjpatrick%40vmware.com%7C3b7535b1c0fa475a628d08d85453bad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352065881079210&sdata=0gnmQIbFeXbEKa3rTueloBiuPGxjWfFcoorX7n5%2FvmM%3D&reserved=0


  Source and binary distributions:

  
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.0.RC1%2F&data=02%7C01%7Cjpatrick%40vmware.com%7C3b7535b1c0fa475a628d08d85453bad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352065881079210&sdata=KtNhVJcgB4CxOXO%2FSlkGdXbeYcs3XTMAFMcfOG5CenM%3D&reserved=0


  Maven staging repo:

  
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1069&data=02%7C01%7Cjpatrick%40vmware.com%7C3b7535b1c0fa475a628d08d85453bad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352065881079210&sdata=FLUJ8Sh68ToIsKMwWI5VRhN1J6%2B6uGyySAbjtZSKYRY%3D&reserved=0


  GitHub:

  
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.0.RC1&data=02%7C01%7Cjpatrick%40vmware.com%7C3b7535b1c0fa475a628d08d85453bad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352065881079210&sdata=MWo79%2Bm%2Fn6iA5Aog49r%2B63g%2F95U0aDL4yJU4IgYM9F8%3D&reserved=0

  
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.0.RC1&data=02%7C01%7Cjpatrick%40vmware.com%7C3b7535b1c0fa475a628d08d85453bad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352065881079210&sdata=Ne%2FF%2BP9e4Qfwbbc7jEohApm37a2nwx45sXJPF1Av5Oc%3D&reserved=0

  
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.0.RC1&data=02%7C01%7Cjpatrick%40vmware.com%7C3b7535b1c0fa475a628d08d85453bad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352065881089205&sdata=XGXyFKGFFXwd2TCDZApiIlpAg1ah40gST4Thze0vEdE%3D&reserved=0

  
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.0.RC1&data=02%7C01%7Cjpatrick%40vmware.com%7C3b7535b1c0fa475a628d08d85453bad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352065881089205&sdata=5UKVGL9GRILQ%2BDreshfuesAoFNKNEqOeNpQvUucl4AY%3D&reserved=0


  Pipelines:

  
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-main&data=02%7C01%7Cjpatrick%40vmware.com%7C3b7535b1c0fa475a628d08d85453bad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352065881089205&sdata=yEpTPifuWYSt7gbUhUw%2B2IWbu3zGddao4gsRlqhFDzA%3D&reserved=0

  
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-rc&data=02%7C01%7Cjpatrick%40vmware.com%7C3b7535b1c0fa475a628d08d85453bad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637352065881089205&sdata=dFw3xRjsiXBRpAYvvd2DcV3p%2F1JlebokaPd7aRZMl4E%3D&reserved=0


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

Re: [DISCUSS] One more 1.13 change

[Patrick Johnson]

+1

> On Sep 28, 2020, at 12:21 PM, Dan Smith  wrote:
> 
> Hi,
> 
> I'd like to backport this change to support/1.13 as well
> 
> GEODE-8522: Switching exception log back to debug - 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5566&data=02%7C01%7Cjpatrick%40vmware.com%7Cb32ecd430b404e610fe708d863e3b4a5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637369176927680210&sdata=lgNl51lgbcV1LmuihEAhkw8mwxbfAbUqawqsEgwdNUA%3D&reserved=0
> 
> This cleans up some noise in our logs that customers might see.
> [https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Favatars3.githubusercontent.com%2Fu%2F47359%3Fs%3D400%26v%3D4&data=02%7C01%7Cjpatrick%40vmware.com%7Cb32ecd430b404e610fe708d863e3b4a5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637369176927680210&sdata=KNHUq8JyZOd5KSto0kgg6vJJNcZq3HLTN67uj2xzBg4%3D&reserved=0]
> GEODE-8522: Switching exception log back to debug (merge to 1.13) by 
> upthewaterspout · Pull Request #5566 · 
> apache/geode
> This log message happens during the course of normal startup of multiple 
> locators. We should not be logging a full stack trace during normal startup. 
> (cherry picked from commit 3df057c) Thank you f...
> github.com
> 

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Patrick Johnson]

It sounds like you intend to test which versions are compatible with each other 
and maintain a list the client can use to reject the setting of force-version 
when set to an incompatible version. If that’s the case, why not just have the 
handshake look at that list and automatically connect with any versions that it 
is known to be compatible with? Then you wouldn’t even have to set the 
property. 

> On Jan 22, 2021, at 11:05 AM, Alberto Gomez  wrote:
> 
> Hi Geode devs,
> 
> I have just published the following RFC in the Geode wiki: "Add option to 
> allow newer Geode clients to connect to older Geode servers"
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAdd%2Boption%2Bto%2Ballow%2Bnewer%2BGeode%2Bclients%2Bto%2Bconnect%2Bto%2Bolder%2BGeode%2Bservers&data=04%7C01%7Cjpatrick%40vmware.com%7C13575e2f7095498aaf0608d8bf08be8f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637469391602573044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fgNljW8GTiY3FfVSsnAIe943XHpnMRjLZKSDzmf5Fpk%3D&reserved=0
> 
> Could you please provide feedback by Tuesday, February 2nd, 2021?
> 
> Thanks,
> 
> Alberto G.
> 

Request Jira access

[Patrick Johnson]

Hello,

I'd like access to The Geode Jira. My Jira user name is yozaner1324.

Thank you,
Patrick Johnson

Re: [VOTE] Requiring final keyword on every parameter and local variable

[Patrick Johnson]

-1 for requiring final for all method parameters. While I have nothing against 
using final here, I don’t think it’s worth mandating and would be better left 
up to the individual and the specific circumstance.

On Apr 14, 2021, at 4:33 PM, Jason Huynh 
mailto:jhu...@vmware.com>> wrote:

Yeah, understood just an opinion about noise __  The clarity and precision part 
I'm debating a bit but  I also don't do code review or work in the actual code 
base as much as before so I'll go with a -0 vote for me and let everyone else 
that does see the code more often decide __

On 4/14/21, 4:28 PM, "Robert Houghton" 
mailto:rhough...@vmware.com>> wrote:

   Does this really "add noise" instead of "add clarity and precision" ?

   -Robert

   On 4/14/21, 4:25 PM, "Jason Huynh" 
mailto:jhu...@vmware.com>> wrote:

   Just to confirm for myself... final doesn't necessarily make object 
immutable.. the reference is immutable but if it refers to say a list, the list 
is still mutable.

   So if I see a final keyword, I should only expect the reference not to 
change, but it won't guarantee that the object isn't changing.

   I'm a -1 on forcing the issue because I believe we currently have too 
many "edge cases" where we can't stick a final on.  So we end up adding 
complexity in reading without the benefit guaranteeing anything...  I'd dislike 
seeing something like this make it partway and then get abandoned...

   Also are we only discussing local variables, class variables and method 
parameters?  Ignoring final on methods and classes?


   On 4/14/21, 2:18 PM, "Mark Hanson" 
mailto:hans...@vmware.com>> wrote:

   +1 To Kirk’s approach.
   -1 To final everywhere.

   I support Kirk’s approach of adding final where there is benefit. If 
we want to go further, we can have intellij find all of them and change them if 
we want. Final is not always a developer’s explicit statement. Sometimes 
something becomes final after the fact.

   If we manually touch any code, I would much rather we deal with the 
use of raw types than have final everywhere. This strikes me as a minor issue 
compared to the rampant use of raw types.

   E.g.
   RegionFactory regionFactory = 
getCache().createRegionFactory(RegionShortcut.PARTITION_REDUNDANT);
   Region region = regionFactory.create (“testRegion”);
   Region.put(int, String);`

   Thanks,
   Mark

   From: Bill Burcham 
mailto:bill.burc...@gmail.com>>
   Date: Wednesday, April 14, 2021 at 1:53 PM
   To: dev@geode.apache.org 
mailto:dev@geode.apache.org>>
   Subject: Re: [VOTE] Requiring final keyword on every parameter and 
local variable
   +1

   I am 100% for putting final everywhere it is possible to put it. 
Call this
   the "hard final" position.

   What I've been advocating for, intermittently, in PRs (for example, 
in PR
   #6310 
)
 is
   more of a "soft final" position which I can formulate as:

   The final keyword is valuable everywhere. When we encounter it in 
code, we
   assume that the author put it there intentionally to communicate 
that the
   variable will not change. Since the code compiled before our change, 
we
   know that the variable does not change (the compiler has proven it!) 
When
   modifying code, we do not remove the final keyword unless we have to 
(to
   get the code to compile).

   So that's the "soft final" position. But I'm all for Kirk's "hard 
final" if
   others agree. I just don't see any downside—only upside on this one.

   The final keyword is a vehicle, like types, for programmers to 
communicate
   their intentions. In both cases, the compiler can provide valuable
   validation. There is, unfortunately, some visual noise entailed 
(lots of
   occurrences of "final" in the code). But this makes non-final 
(mutable)
   variables much more apparent. Since they are (or should be) in the
   minority, this is an aid to maintainers. This becomes apparent in 
longer,
   more complex methods.

   On Wed, Apr 14, 2021 at 12:56 PM Kirk Lund 
mailto:kl...@apache.org>> wrote:

Our coding standard and our Design Decisions does NOT require using final
on parameters and local variables.

Please do NOT request that I add or keep final on parameters or local
variables unless the community votes and d

Re: Cleaning up the codebase - use curly braces everywhere

[Patrick Johnson]

+1. Also really like Naba's idea of incorporating this into spotless.

On May 27, 2021, at 10:46 AM, Raymond Ingles 
mailto:ring...@vmware.com>> wrote:

+1 Sounds like a good idea. Since always using curly braces is part of the 
style guide, fixing this makes sense.

The only possible additional step for 
large-but-automatically-generated-and-specifically-targeted PRs like this is 
running the test suite with code coverage, making sure the updated code paths 
are actually exercised by the tests. I think this particular change is 
low-risk, but that might be a good check as humans aren't all that great at 
checking 3300 instances of anything. And if there *are* gaps, it'll point to 
some good tests to write.

On 5/27/21, 1:22 PM, "Donal Evans" 
mailto:doev...@vmware.com>> wrote:

   Hi Geode dev,

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

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

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

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

   Donal

   [1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FCode%2BStyle%2BGuide&data=04%7C01%7Cjpatrick%40vmware.com%7C1a3fbc078ac94bca8b0608d921375879%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637577343862113013%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wGDiVSNZl%2FzRDPxG01ta60jwsHh%2BzLvRlsdQFAy0a1s%3D&reserved=0
   [2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6523&data=04%7C01%7Cjpatrick%40vmware.com%7C1a3fbc078ac94bca8b0608d921375879%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637577343862113013%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ae%2B9ssxeIZ5jdXqVLZXuzBgNy%2FxU4OAVlSwg8LuPyt8%3D&reserved=0

Re: [DISCUSS] - Creation of new Apache Geode Github repo for Gradle Plugin

[Patrick Johnson]

I think that's a great idea. Having the plugin in a separate repo will also 
make the plugin more easily testable than if it were in buildSrc. +1

From: Udo Kohlmeyer 
Sent: Tuesday, July 20, 2021 6:55:04 PM
To: geode 
Subject: [DISCUSS] - Creation of new Apache Geode Github repo for Gradle Plugin

Hi there Apache Dev.

As part of Geode-8705, there has been some work done on creating a gradle 
plugin that will generate module.xml files that are consumed by JBoss Modules, 
based on the gradle build files.

This plugin is intended to be not only used by the Geode project but also for 
customers/users that would like to deploy code/apps into Geode but also for 
developers wanting to write Geode extensions, like Lucene, Memcache, Redis, 
etc….

In order to better make this plugin available (eventually) to the end-consumer, 
I request a new Apache Github for this plugin.

Thoughts?

--Udo

Re: August Community Meeting

[Patrick Johnson]

+1 works for me.

> On Jul 29, 2021, at 11:00 AM, Alexander Murmann  wrote:
> 
> Hi Geode community,
> 
> Next week's August 4th is the first Wednesday in August. Usually that would 
> be the day that we have our community meeting. Many of our community members 
> work on Apache Geode as part of their work at VMware. The majority of those 
> folks will be unavailable next week.
> 
> Does it work for everyone if we push back a week?
> I also wonder if anyone would be opposed to moving the meeting from 
> Wednesdays to Thursdays.
> 
> So if everyone is fine with the proposals above, our next meeting would be on 
> Thursday, August 12th.
> 
> Please let me know if this will work!

Re: @TestOnly or @VisibleForTesting

[Patrick Johnson]

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

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

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

[Patrick Johnson]

+1 for cutting. My team has nothing we intend to put out in 1.15.

From: Anilkumar Gingade 
Sent: Friday, January 21, 2022 9:00:09 AM
To: dev@geode.apache.org 
Subject: Re: Proposal: Cutting 1.15 Release branch Tuesday, 25 January

>  and remaining work is on processing release-blocker bugs.
Is there estimation on when this will be done?

> will allow new work to proceed
Before taking on new work; release work/issues should be prioritized; unless 
there are resources available to get the work started (apart from working on 
release issues).

If the release blocker issues are down to 1 or 2; and there is a good 
understanding on when these will be fixed/merged then it will be good idea to 
cut a release branch.

-Anil


On 1/20/22, 5:43 PM, "Udo Kohlmeyer"  wrote:

+1 on cutting a release on 25 Jan 2022…

I implore all community members, that if you have a feature that has not 
met the 25 Jan 2022 deadline, to not try and add it post the deadline. This 
will help in the final stabilization phase of the release.

--Udo

From: Raymond Ingles 
Date: Friday, January 21, 2022 at 9:18 AM
To: dev@geode.apache.org 
Subject: Proposal: Cutting 1.15 Release branch Tuesday, 25 January
Hello Geode Dev Community,

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

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

[PROPOSAL] RFC for migrating from springfox to springdoc

[Patrick Johnson]

Hello devs!

Please review this RFC: 
https://cwiki.apache.org/confluence/display/GEODE/Migration+from+springfox+to+springdoc
 on migrating from springfox to springdoc for our swagger needs and provide any 
feedback you have.

Review period until Friday, May 13th.

—Patrick Johnson

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

[Patrick Johnson]

+1 for getting rid of CODEOWNERS.

> On Jun 29, 2022, at 9:33 AM, Anthony Baker  wrote:
> 
> ⚠ External Email
> 
> I realize that this is a thread hijack, but hopefully a useful one. I’ve seen 
> several requests for timely reviews in recent months. I think that the 
> CODEOWNERS goals were important and laudable—directing review requests to 
> those most suited to provide oversight—but the implementation has been 
> problematic. The size, complexity, and interconnectedness of the code base 
> meant that many pull requests tagged not just one expert but just about EVERY 
> expert in the community. This is rather inefficient, to say the least.
> 
> I propose that we revert CODEOWNERS and return to the review-then-commit 
> model requiring at least one +1 vote from a committer. I see Owen has already 
> created a PR [1] for this change.
> 
> Thoughts?
> 
> Anthony
> 
> [1] 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7820&data=05%7C01%7Cjpatrick%40vmware.com%7Cef39bb9a4e794fba73cd08da59ed3d9a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172911084617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PRAvK0HR0cU5Tg59KVD%2BIjnq8PAsaKfjX8%2BG%2FHeDnAw%3D&reserved=0
> 
> 
>> On Jun 28, 2022, at 5:43 AM, Mario Ivanac  wrote:
>> 
>> ⚠ External Email
>> 
>> Hi,
>> 
>> The following PRs:
>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7323&data=05%7C01%7Cjpatrick%40vmware.com%7Cef39bb9a4e794fba73cd08da59ed3d9a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172911084617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Tvz9IRs642RD89jY41htcIxuwsm1i4e90BJdmsLBYnI%3D&reserved=0
>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7749&data=05%7C01%7Cjpatrick%40vmware.com%7Cef39bb9a4e794fba73cd08da59ed3d9a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172911084617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nv2NsBKWaTDZhe%2BAfiQfM5JslaQDl48Fbk0OrscDWbQ%3D&reserved=0
>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7664&data=05%7C01%7Cjpatrick%40vmware.com%7Cef39bb9a4e794fba73cd08da59ed3d9a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921172911084617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k9d8Mxjv3llSWWcyL06xjQYDV%2FTXbh393Yk2%2F8%2BOyWU%3D&reserved=0
>> 
>> are waiting for review for some time.
>> 
>> 
>> Could code owners review these PRs?
>> 
>> Thanks,
>> Mario
>> 
>> 
>> 
>> ⚠ External Email: This email originated from outside of the organization. Do 
>> not click links or open attachments unless you recognize the sender.
>