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

[Joris Melchior]

+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: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo

[Joris Melchior]

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: Fw: [DISCUSS] Rebase and Squash Options on Github develop

[Joris Melchior]

+1 for Naburan’s proposed options.

From: Nabarun Nag 
Date: Monday, June 28, 2021 at 4:06 PM
To: Owen Nichols , dev@geode.apache.org 

Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.

The options I am proposing to be kept in the PRs are:

  *   Squash and merge
  *   Rebase and merge

Regards,
Nabarun

From: Owen Nichols 
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag ; dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

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

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

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

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


---
Sent from Workspace ONE 
Boxer

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

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

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

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

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

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


Regards
Nabarun Nag



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

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

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

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

Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

[Joris Melchior]

Congratulations Kamilla!

Joris

From: Ernie Burghardt 
Date: Monday, April 19, 2021 at 5:22 PM
To: dev@geode.apache.org 
Subject: [ANNOUNCE] New Geode Committer - Kamilla Aslami
The Apache Geode Project Management Committee has invited Kamilla Aslami to 
join the Geode as a Committer and we are pleased to announce she has
accepted.

Please join me in welcoming Kamilla!

Best regards,
EB
On behalf of the Apache Geode PMC

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

[Joris Melchior]

+1 On this approach. If we could somehow have side project to implement this I 
think it would be really helpful. 

I also think it's less intimidating to contribute to for a lot of people.

Joris

On 2021-03-29, 2:55 PM, "John Blum"  wrote:

How hard is it to put the work like Protobuf in a separate repository 
(attached to Geode in some way)? I am not sure what the (Apache) procedure is.

We need stop baking everything into the "core" of Apache Geode.  Most 
things that are non-essential (meaning, they are not required for Geode to 
carry out its primary responsibility as a data store, also & e.g. Redis 
Adapter) should be an "extension" (add-on), enabled with a plugin.

I fear this work would get lost if removed completely.  How would new (or 
even existing members) know where to find this work if interested? Branches are 
not a good alternative. A separate repo would make the entire process (e.g. 
releases) easier, not unlike the Kafka connector, or even Spring Data for that 
matter.

$0.02
-j


From: Bruce Schuchardt 
Sent: Monday, March 29, 2021 11:41 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

That's true John, but the Protobuf i/f is using the same code as the REST 
server to serialize/deserialize JSON documents.  It isn't any better at it.

On 3/29/21, 10:33 AM, "John Blum"  wrote:

Correction! Although a different/separate issue, Geode's JSON document 
handling is incomplete at best. It does not properly handle all forms of JSON 
or types (e.g. Java 8 Data/Time types).

From: Bruce Schuchardt 
Sent: Thursday, March 25, 2021 8:01 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

I worked on the protobuf client/server interface as long as anyone else 
but still fail to see the value in keeping it in anything but a branch unless 
someone is going to pick it up soon and complete it.

As Dan pointed out, we already have a good interface for storing Json 
documents and we never got beyond that as cache values with the protobuf i/f.  
People want to store data in Geode in a way that works with queries, delta 
propagation and other advanced features.  That was, and remains, the main 
problem for this interface.  Without that it's not even as good as the current 
REST interface.

On 3/24/21, 5:06 PM, "Jens Deppe"  wrote:

I was very excited when the protobuf support became available as it 
allowed for the fairly quick development of a Go client. 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-clientdata=04%7C01%7Cjmelchior%40vmware.com%7C410b3aeac8db41d1fc7708d8f2e441db%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637526409462649787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZGgWQi9xgyn5015sCK2ftsGsiADITYa57j7%2BpnE36f4%3Dreserved=0).
 As Udo already mentioned, removing this functionality reduces our potential 
exposure to new use cases and language bindings. Just because it isn't 'feature 
complete' doesn't mean it isn't useful to someone. In fact, just today, 
somebody reached out regarding the Go binding.

When considering various popular libraries/frameworks, they all 
have multiple bindings. Some of those are core to the library, but many are 
maintained separately. Having a well-defined protocol for Geode is the first 
step in making that possible.

--Jens

On 3/24/21, 1:11 PM, "Dan Smith"  wrote:

I also worked on the protobuf interface for a little while, 
although not for as long as some of the other folks commenting. I'm ok with 
removing it. I do see some value in leaving stalled/incomplete projects around 
as bait for future developers to pick up - that seems to have worked for redis 
;) But if it is a maintenance burden lets drop it from develop. Someone can 
always pick it up from the history.

If I recall correctly, one of the big incomplete parts of the 
project is that we hadn't figured out how to serialize user objects efficiently 
with this protocol. The default was to convert PDX objects to JSON. That was 
about as efficient as the existing REST protocol, which also uses json.

-Dan

From: Mike Martell 
Sent: Tuesday, March 23, 2021 4:53 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf 
client/server interface

As the only remaining member on the CSharpDriver team, I too 
have an attachment to Protobuf. It’s purely technical, however, not emotional. 
I was truly excited about the prospects of a self-describing 

Re: [ANNOUNCE] New Geode Committer - Matt Reddington

[Joris Melchior]

Welcome Matt!

On 2021-03-23, 1:56 PM, "Ernie Burghardt"  wrote:

The Apache Geode Project Management Committee has invited Matt Reddington 
to join the Geode as a Committer and we are pleased to announce he has
accepted.

Please join me in welcoming Mat!

Best regards,
EB
On behalf of the Apache Geode PMC

Re: PROPOSAL: Backport GEODE-9044 - Introduce RedisKey as key object for RedisData entries

[Joris Melchior]

+1

On 2021-03-19, 10:35 AM, "Jens Deppe"  wrote:

This work builds on GEODE-9023 which added sharding support to the 
compatible with Redis region.

This change cleans up data structures and will allow for easier, future 
rolling upgrades and data migrations if necessary.

Thanks
--Jens

Re: [Proposal] Backport GEODE-9045 to support/1.14

[Joris Melchior]

+1 

On 2021-03-17, 2:43 PM, "Hale Bales"  wrote:

Hello,

 I am putting forward the proposal to backport GEODE-9045 (Rename Redis 
properties and error messages) to support/1.14 branch,

What does GEODE-9045 do?

  *   It renames the redis-port property to 
compatible-with-redis-port
  *   It renames the redis-bind-address property to 
compatible-with-redis-bind-address
  *   It renames the redis-password property to 
compatible-with-redis-password
  *   It rewords error messages to remove usages of Redis, and 
changing them to something
  along the lines of Compatible with Redis

These changes are low-risk as they are limited entirely to the Geode’s 
Redis-compatibility subsystem and do not impact any other Geode code. This is 
simply a rename of properties and does not change any behavior.

Why do we need to backport these changes?

  *   These changes will make us compliant with Redis's 
copyright, which does not allow us to claim that we are Redis. This prevents us 
from having any customer-facing places that say Redis, or Geode Redis.

~ hale (they/them)

[DISCUSS] - RFC make key and trust stores reload automatically upon change

[Joris Melchior]

Hi Geode developers,

I have published an RFC for making the reloading of certs and trust automatic 
in Geode. The RFC can be found on our Wiki: 
https://cwiki.apache.org/confluence/display/GEODE/Make+key+and+trust+stores+reload+automatically+upon+change

Please provide feedback by Thursday February 18, 2021.

Thanks,

Joris Melchior

Re: [DISCUSS] CODEOWNERS and .asf.yml

[Joris Melchior]

I’ll give this an informal +1 then.

Joris

From: Robert Houghton 
Date: Thursday, January 14, 2021 at 4:40 PM
To: dev@geode.apache.org 
Subject: [DISCUSS] CODEOWNERS and .asf.yml
Hello fellow Geode developers.

The CODEOWNERS file has been merged to Geode develop for a few days now,
and we are starting to see automatic reviewers being added to code changes.
My thought is that we'll give this a week or so, to make sure that we like
the behavior we are seeing, and then to add the .asf.yml change that will
make the review of one owner mandatory for PR merge.

I don't think this needs a formal vote. But please do let me know what you
think.

-Robert Houghton

Re: [VOTE] Apache Geode 1.13.1.RC2

[Joris Melchior]

+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%7Cjmelchior%40vmware.com%7Cd12447e32fea45ab511d08d88a5d886f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637411481617089640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kwhPhoB9csEKCtT5%2BiB4tM0W%2FEjMAgg%2B9QUdyxxD1Ds%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%7Cjmelchior%40vmware.com%7Cd12447e32fea45ab511d08d88a5d886f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637411481617099635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7DOP%2BPwGWZViByzuzRajqXb1mdvOVPftdIPHZVzS7Y4%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1071data=04%7C01%7Cjmelchior%40vmware.com%7Cd12447e32fea45ab511d08d88a5d886f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637411481617099635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=dRfzb986Lp2UUFASx0G3rPKimNK%2FL7eXPV7ZQHc%2BjiY%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%7Cjmelchior%40vmware.com%7Cd12447e32fea45ab511d08d88a5d886f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637411481617099635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=O3KzrTpHdw8UQ91c3D%2BckcRdaYfomqb46PQXyptVfT0%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%7Cjmelchior%40vmware.com%7Cd12447e32fea45ab511d08d88a5d886f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637411481617099635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nP61Hjf1y%2BByvdcu1VVC6f%2FanHAGMigsOp8Nj2aaSYE%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%7Cjmelchior%40vmware.com%7Cd12447e32fea45ab511d08d88a5d886f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637411481617099635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=T4aqYUyzN%2B4hoOz9Nicn9jMDuYeCtbSJdzHDDWc%2FHXU%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%7Cjmelchior%40vmware.com%7Cd12447e32fea45ab511d08d88a5d886f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637411481617099635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=QDp01snTrC%2F8M5oqAx%2F4fXLuNtVEIQnRlfZfIAFF7zA%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%7Cjmelchior%40vmware.com%7Cd12447e32fea45ab511d08d88a5d886f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637411481617109627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=78Da9UEBmLmeqCKOsgNdYRqVj7H%2BwekGaf3%2FWZLNCA8%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%7Cjmelchior%40vmware.com%7Cd12447e32fea45ab511d08d88a5d886f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637411481617109627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=s12A0kEeZiMgPWCi5eRUXio4Ov44b6ilc77BmwLjBvc%3Dreserved=0

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

Re: Apache Geode 1.13.1 patch proposal

[Joris Melchior]

+1

From: Dick Cavender 
Date: Thursday, November 12, 2020 at 2:01 PM
To: dev@geode.apache.org 
Subject: Apache Geode 1.13.1 patch proposal
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: [PROPOSAL] Backport fix for GEODE-8620 to 1.13.1

[Joris Melchior]

+1

From: Donal Evans 
Date: Wednesday, October 21, 2020 at 12:00 PM
To: dev@geode.apache.org 
Subject: [PROPOSAL] Backport fix for GEODE-8620 to 1.13.1
Hi Geode dev,

I would like to backport the fix for 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8620data=04%7C01%7Cjmelchior%40vmware.com%7C59104257e7d346cd291f08d875da76a5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637388928459906084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=alM8ABmKV3xtQqfKnJPzT113isvPbGr%2B7Mh3g11QwM4%3Dreserved=0
 to the 1.13.1 branch. This bug causes incorrect redundancy levels to be 
reported for regions in which not all buckets have been created when using the 
Restore/StatusRedundancy features introduced in 1.13.0. The fix is minimal and 
has passed all tests run against the develop pipeline.

Thanks,
Donal

Re: [PROPOSAL] backport fix for GEODE-8574 to 1.13.1

[Joris Melchior]

+1

On 2020-10-08, 10:51 AM, "Jinmei Liao"  wrote:

I would like to include the fix for GEODE-8574 to 1.13.1, it would greatly 
help the Geode on k8s experience.

Thanks!

Jinmei

Re: [PROPOSAL] Backport GEODE-6008 to support 1.12

[Joris Melchior]

+1

On 2020-09-29, 6:09 PM, "Xiaojian Zhou"  wrote:

Hi,

GEODE-6008 changed “java.lang.IllegalStateException: NioSslEngine has been 
closed” to IOException, which enabled DirectChannel to handle it and retry the 
connection in the case that the connection is closed.

This fix is important and no risk to backport to support/1.12. Please vote 
for it.

Regards
Xiaojian Zhou

Re: [DISCUSS] One more 1.13 change

[Joris Melchior]

+1

On 2020-09-28, 3: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%2F5566data=02%7C01%7Cjmelchior%40vmware.com%7Cff464688426a4c9a7e6808d863e3b333%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637369176923816350sdata=mPB6w8RD0e44sLYEgcJCoP%2Fu%2BPepilHevImzjmjfkmA%3Dreserved=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%3D4data=02%7C01%7Cjmelchior%40vmware.com%7Cff464688426a4c9a7e6808d863e3b333%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637369176923816350sdata=IBtTHJOQigbGaDdCWnWogLjjZsHFgEzNDzde5CW7TDQ%3Dreserved=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: [PROPOSAL] Backport usability improvements to support 1.13 branch

[Joris Melchior]

+1

On 2020-09-23, 7:23 PM, "Jason Huynh"  wrote:

Hello,

I’d like to merge the pull request: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5524data=02%7C01%7Cjmelchior%40vmware.com%7Cf627e716175e47d617c408d86017a1be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637365001914345788sdata=Tbd%2FUTlqEmiEiq%2BlCo2IGsGeNA7GO40XlowwRV9Bq9Y%3Dreserved=0
 into a support 1.13 branch.  The commits are focused on a few usability 
improvements for Geode that were thought to have made it into 1.13 but actually 
did not make it.

What this pull request back ports:

  *   GEODE-8203: Logging to std out along with to the regular log file
  *   GEODE-8283: Rest API for disk store creation
  *   GEODE-8200: Fix for Rebalance API stuck “IN_PROGRESS” state forever 
and GEODE-8200: Enhance GfshRule
  *   GEODE-8241: Locator observers locator-wait-time
  *   GEODE-8078: Log and report error at the correct place


The PR pipeline is failing due to Redis tests (that I don’t think are on 
1.13).  Everything else appears to be passing.

Thanks,
-Jason

Re: [PROPOSAL] Backport GEODE-8432 to 1.13

[Joris Melchior]

+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] Postpone Geode 1.14

[Joris Melchior]

+1

On 2020-07-28, 7:34 PM, "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: [VOTE] change Default branch for geode-examples to 'develop'

[Joris Melchior]

+1

On 2020-07-10, 12:39 AM, "Owen Nichols"  wrote:

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%7Cjmelchior%40vmware.com%7C458c4abf934b43480f2308d8248b403a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637299527784977071sdata=7CRcXQYAkbVtQ5CMFZgKZCMtfyqHw2UxkNPA4KwSl8k%3Dreserved=0

Re: geode docker question

[Joris Melchior]

You might also want to look at docker compose so that locator and server can 
run in separate containers.

On 2020-07-08, 12:18 AM, "Mark Hanson"  wrote:

Here is a command that actually runs.. 

You need to be in the Geode directory, the run the command below to start 
everything.  
docker run -it -v $(pwd):/apache-geode  openjdk:8 sh -c 
"apache-geode/bin/gfsh -e 'start locator --name=Locator1' -e  'start server 
--name=Server1'" -c ""

Thanks,
Mark
On 7/7/20, 10:42 AM, "Mark Hanson"  wrote:

Hi Barry,

Are you looking for something like this?

docker run -it -v $(pwd):/apache_geode  openjdk:8 sh -c 
"apache-geode/bin/gfsh -e "start locator --name=Locator1" -e  "start server 
--name=Server1" 
^ shared location   
^ not sure this path is right but you get the idea.

Thanks,
Mark

On 7/7/20, 10:29 AM, "Barry Barrios"  wrote:

Do you have Apache Geode examples using docker? Is there a way to 
run a
docker container that automatically creates locator and server by
specifying some parameters without typing them in the gfsh shell 
prompt?
Also, same for deploying jars, is there a way to automatically 
deploy jars
when running docker? I was browsing through your apache geode 
examples
github repo to see if there were examples but didn't find what I was
looking for.

Best,
Barry

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

[Joris Melchior]

+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: Client Usage of RMI

[Joris Melchior]

Pulse communicates to the locator over jmx/rmi as well.

From: Kirk Lund 
Sent: June 19, 2020 14:24
To: dev@geode.apache.org 
Subject: Re: Client Usage of RMI

The only use of RMI in Geode that I'm aware of is:

1) GFSH to Locator communication over jmx/rmi
2) Communication from the main JUnit JVM to DUnit JVM for dunit tests

In theory, a User could connect to the Locator over jmx/rmi from any JVM
using JDK JMX code. This could include deploying a Function (that uses JMX)
to a Server or executing JMX code directly within a Geode Java Client.

On Fri, Jun 19, 2020 at 11:17 AM Jacob Barrett  wrote:

> All,
>
> Related to the conversation about certificate based authentication, how
> much of the client side would invoke any RMI requests? I am trying to gauge
> the impact of not having RMI as an option for client applications wishing
> to use certificate based authentication.
>
> -Jake
>
>

Re: Refactor to Restore Redundancy Command for 1.13?

[Joris Melchior]

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
>
> 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-8029 to support/1.12 and support/1.13

[Joris Melchior]

+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

[Joris Melchior]

I lean towards forks as well. I understand Naba's concerns but for most of the 
work we do, forks are a straightforward way to work on contributions to Geode. 
It's easy to give people rights on your fork if you work with multiple 
contributors.

Joris

From: Ernie Burghardt 
Sent: June 2, 2020 22:17
To: dev@geode.apache.org 
Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches

I'm a fan of features on forks!  It's fairly simple to make forks accessible to 
other folks.
I know this isn't a vote, but I'm a +1 for the concept...

EB

On 6/2/20, 3:42 PM, "Jacob Barrett"  wrote:

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

[Joris Melchior]

+1

From: Bruce Schuchardt 
Sent: May 27, 2020 16:35
To: dev@geode.apache.org 
Subject: [PROPOASAL] backport GEODE-8144

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%7Cjmelchior%40vmware.com%7C9bfb066e00084476b4df08d8027d7d39%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637262085285945188sdata=wjue8o5303%2FgfCWHRSsDTNRj8uJGshhi1XTTtUM59Ps%3Dreserved=0
 fixes the failing test
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5131data=02%7C01%7Cjmelchior%40vmware.com%7C9bfb066e00084476b4df08d8027d7d39%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637262085285945188sdata=kKtob9T0vSphqUgKIKZ4XCAKDMDlC9HXnFX3wKIDXNE%3Dreserved=0
 is the original PR

both have been merged to develop

Re: [PROPOSAL] Bring GEODE-8100 to support branches

[Joris Melchior]

More documentation is good!

+1

From: Jinmei Liao 
Sent: May 19, 2020 14:26
To: geode 
Subject: [PROPOSAL] Bring GEODE-8100 to support branches

This is to update documentation to better explain the Cluster management
service and various geode/system properties that control the behavior of
it. It also provides more usage examples in the documentation. There is no
product code change in this, but tt would be helpful to the users who would
like to understand Cluster management service more.

--
Cheers

Jinmei

Re: [PROPOSAL] bring GEODE-8131 PR to support branches

[Joris Melchior]

+1

From: Bruce Schuchardt 
Sent: May 19, 2020 11:53
To: dev@geode.apache.org 
Subject: [PROPOSAL] bring GEODE-8131 PR to support branches

While investigating a distributed hang we discovered that the alerting system 
was blocking the logging of critical information that would have helped 
diagnose the issue.  This PR modifies the logging of this information to first 
log it at “info” level and then at “fatal” level so that in the future we get 
this critical information.



https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5132data=02%7C01%7Cjmelchior%40vmware.com%7C29600763f6124467324e08d7fc0ccf26%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637255004256824880sdata=Du7%2BDr8mmHqyA2p69Ij8tQkhswvfDW8%2F5tE4Fjw344U%3Dreserved=0

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

[Joris Melchior]

This seems like a good thing to have.

+1

From: Robert Houghton 
Sent: May 13, 2020 17:32
To: dev@geode.apache.org ; Mario Ivanac 

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

We have enabled this job on the develop and support 1.13 branches, and it
is going well. I would like this to be a blocking job for our pull
requests.

Are there any issues around this test that we want to address, or reasons
to *not* have it be a blocking job in the PR pipeline?

To seed the conversation, there is an issue I am working on with @Mario
Ivanac  regarding exemptions to the Gradle task.

I would like to have a [VOTE] by end of week on this.

Re: [PROPOSAL] Merge PR 5103 (GEODE-8083) to support/1.13

[Joris Melchior]

+1

From: Robert Houghton 
Sent: May 12, 2020 18:57
To: dev@geode.apache.org ; Dave Barnes (Pivotal) 

Subject: [PROPOSAL] Merge PR 5103 (GEODE-8083) to support/1.13

This is a squash of GEODE-8083 and 8087, to bring the Java  API comparison
jobs from Gradle and Concourse to the support branch. Currently runs
cleanly from my terminal, and has been green on develop for a week or so.

@Dave Barnes  , as release manager, what say you?

Re: Proposal to bring GEODE-8068 to support/1.13

[Joris Melchior]

+1

From: Patrick Johnson 
Sent: May 8, 2020 17:40
To: dev@geode.apache.org 
Subject: Proposal to bring GEODE-8068 to support/1.13

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: Discussion - Change Public API Before Initial Release

[Joris Melchior]

+1

From: Jacob Barrett 
Sent: May 8, 2020 21:26
To: dev@geode.apache.org 
Subject: Discussion - Change Public API Before Initial Release

Hey Ya’ll,

We have a new API going into 1.13 that has an inconsistency I want to address 
before we are stuck with it. The class SniSocketFactory should be renamed 
SniProxySocketFactory. The class in question produces objects of type 
SniProxySocket. An "SNI socket" isn’t a thing but an SNI proxy is a thing. The 
factory class that produces proxy socket factories (yes a meta factory) 
ProxySocketFactories uses the “ProxySocket” name as well. It fells very 
inconsistent with all the other classes that make up with API for 
SniSocketFactory to not have a proxy in it and be called SniProxySocketFactory.

To be very clear, this API has not made it out of development yet but is in the 
1.13 release branch. Can I get a few thumbs up to open an ticket and pick it 
into the 1.13 release branch before it goes out?

Thanks,
Jake

Re: [DISCUSS] etiquette around breaking the pipeline

[Joris Melchior]

Recent experience makes me lean towards quick revert as well. Takes the 
pressure off when trying to produce a fix and if done soon enough it is usually 
quite straightforward.

From: Owen Nichols 
Sent: April 29, 2020 7:06 PM
To: dev@geode.apache.org 
Subject: [DISCUSS] etiquette around breaking the pipeline

There are many ways a commit can break the Geode CI pipeline[1] despite our 
required PR checks, such as:
- merge a PR that failed some non-required PR checks
- merge a PR that last ran checks awhile ago and now interacts unexpectedly 
with other recent changes
- merge a PR that fails Windows tests
- merge a PR that fails Benchmarks tests

When a bad commit gets through for whatever reason, what should happen next?  
For example:
- bring it up on the dev list
- someone should revert the change as soon as possible, allowing the pipeline 
to remain green while the issue is addressed
- a reasonable amount of time should be allowed for someone to make a quick 
fix, otherwise revert.
- the pipeline should remain broken for as long as it takes to fix, as long as 
there is clear communication that someone is working on it
- everyone look the other way and hope it fixes itself

I’m sure there are other ideas as well.  A related question is *who* can or 
should revert a bad commit?  Only the person that merged the PR?  Only the 
original author of the PR?  The first person to notice the problem?

What is a reasonable amount of time for this to happen?  2 hours? 2 days? 2 
weeks? Does it depend whether the bad commit is also affecting PR checks for 
everyone else vs only depriving downstream consumers of new Geode -SNAPSHOTs?

Would you take offense if someone else reverted your commit?  Does is make a 
difference if your commit is exposing an existing issue (as opposed to 
introducing a new bug)?

Is there a perception that reverts create a lot of extra work? (they 
shouldn’t--just start your rework PR with a revert of the revert, then add 
additional commits that resolve the issue, so reviewers can easily see what was 
missing the first time)

This is a discussion thread, not a vote.  We trust committers to do what’s 
best.  Would embracing a “anyone can revert, no shame” revert-first-then-fix 
culture benefit our community, or is our current easygoing approach working 
just fine?

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-maindata=02%7C01%7Cjmelchior%40vmware.com%7C147db9dcc029489fb48a08d7ec91f5c1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637237983950472313sdata=iEWXjnfwt1tUx6s2ODrF5aAoaNuFAphKjIo0ozE0AXU%3Dreserved=0

Re: Reconfiguring our notifications and more

[Joris Melchior]

+1

From: Anthony Baker 
Sent: April 21, 2020 11:54 AM
To: dev@geode.apache.org 
Subject: Reconfiguring our notifications and more

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-20156data=02%7C01%7Cjmelchior%40vmware.com%7Ca5e44fed47f2456e567608d7e60c5394%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637230812959789133sdata=VsMatRt1Gh1byWNIvsOtrqaWkPmlSqujidVs%2Bi7wBMM%3Dreserved=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-Notificationsettingsforrepositoriesdata=02%7C01%7Cjmelchior%40vmware.com%7Ca5e44fed47f2456e567608d7e60c5394%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637230812959789133sdata=0vVUz%2B8HIx43SNK3TRruYYJe1SryPIfXWh31qaZF3AI%3Dreserved=0

Re: [PROPOSAL]: GEODE-7940 to support/1.12

[Joris Melchior]

Sounds like something we should include.

+1

On Fri, Apr 17, 2020 at 4:41 AM Ju@N  wrote:

> Hello devs,
>
> I'd like to propose bringing *GEODE-7940 [1]* to the *support/1.12* branch.
> The bug is not new, seems quite old actually, but still seems pretty
> critical as it can lead to data loss in WAN topologies.
> Long story short: when there are multiple parallel *gateway-senders*
> attached
> to the same region and the user decides to stop, detach and *destroy* one
> of the senders (the destroy part is what actually causes the problem), the
> rest of the senders attached will silently stop replicating events to the
> the remote clusters and all these events will be lost.
> The fix has been merged into develop through commit *bfbb398 [2]*.
> Best regards.
>
> [1]: https://issues.apache.org/jira/browse/GEODE-7940
> [2]:
>
> https://github.com/apache/geode/commit/bfbb398891c5d96fa3a5975365b29d71bd849ad6
>
> --
> Ju@N
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: Proposal to bring GEODE-7969 to support/1.12

[Joris Melchior]

+1

On Wed, Apr 8, 2020 at 12:21 PM Owen Nichols  wrote:

> Recently it’s been noticed that netty-all-4.1.42.Final.jar is getting
> flagged for “high" security vulnerability CVE-2019-20444 and CVE-2019-20445.
>
> Analysis shows that Geode does not use Netty in a manner that would expose
> this vulnerability.
>
> The risk of bringing GEODE-7969 is very low.  Netty is only imported for
> some I/O libraries in geode-redis, not used as a server.  GEODE-7969 has
> passed all PR checks on support/1.12, and the same version bump to
> 4.1.45.Final has been on develop since February via GEODE-7798.
>
> This fix is critical to avoid false positives in automated vulnerability
> scans.
>
> -Owen



-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [DISCUSS] Redundancy Gfsh Commands

[Joris Melchior]

+1

I like this idea and Kirk's suggestion to use the CompletableFuture as a
standard for asynchronous operations.

On Mon, Mar 30, 2020 at 2:47 PM Donal Evans  wrote:

> Hey everyone,
>
> An RFC for adding gfsh commands to allow users to restore redundancy to
> partitioned regions and to easily check the redundancy status of
> partitioned regions has been posted:
> https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands
> .
>
> Please review and comment on this RFC by Monday, 04/06/2020.
>
> Please also note that this RFC has been revised from an earlier draft
> version that some of you may have seen, so the content may have changed.
>
> Thanks,
> Donal
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [DISCUSS] Client side configuration for a SNI proxy

[Joris Melchior]

+1

On Mon, Mar 16, 2020 at 6:33 PM Dan Smith  wrote:

> Hi all,
>
> A new RFC is up for this feature
>
> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy
> .
>
>
> Please review and comment by this Friday, 3/20/2020.
>
> This hopefully addresses some of the concerns with the previous RFC for
> this feature. The new proposal is for a more general SocketFactory property
> that users can implement, along the lines of what Jake and Owen suggested.
>
> -Dan
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: Discussion on Deprecation

[Joris Melchior]

+1 on leaving testing of deprecated functionality in place

On Mon, Mar 16, 2020 at 11:50 AM Dan Smith  wrote:

> +1
>
> One point though - we do need to leave some tests that specifically test
> the deprecated method(s), since we still support the deprecated APIs until
> we remove them. Everything else should be converted.
>
> -Dan
>
> On Sun, Mar 15, 2020 at 6:41 PM Jacob Barrett  wrote:
>
> > Hey Team,
> >
> > When deprecating a symbol, like class or method, please included a
> > reference to the replacement in the java docs. Also please include an
> > example of converting from the old API to the new. I am finding many many
> > places in the source where deprecated code has no hints at all. As many
> of
> > us don’t take the effort to immediately convert old tests over to the new
> > APIs the context is lost when someone finally does get around to it. For
> > public APIs this is extremely important so that users know how to migrate
> > their code with as few roadblocks as possible.
> >
> > Here is an example of something that is much better than most of what I
> am
> > seeing.
> >
> > /**
> >  * @deprecated Replaced with something better and safer.
> >  * Replaced by {@link Bar}.
> >  */
> > @Deprecated
> > class Foo {
> >   /**
> >* Do something.
> >*
> >* @deprecated Replaced with something better.
> >* Replaced by {@link Bar#doSomethingBetter()}
> >*/
> >   @Deprecated
> >   public void doSomething() {}
> >
> >   /**
> >* Do something.
> >*
> >* @deprecated Implementation is not safe.
> >* Replaced with {@link Bar#doSomethingBetter()} and {@link
> > Bar#doSomethingElse()}.
> >* Migration example, replace:
> >* {@code
> >*   Foo foo = new Foo();
> >*   foo.doSomethingAndSomethingElse();
> >* }
> >* with:
> >* {@code
> >*   Bar bar = Bar();
> >*   bar.doSomethingBetter();
> >*   bar.doSomethingElse();
> >* }
> >*/
> >   @Deprecated
> >   public void doSomethingAndSomethingElse() {}
> > }
> >
> > class Bar {
> >   public void doSomethingBetter() {}
> >   public void doSomethingElse() {}
> > }
> >
> > -Jake
> >
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: Discussion on Deprecation

[Joris Melchior]

+1

I think we should make it a habit to convert all Geode code as part of the
pull request that introduces the deprecation so that this is not left as a
low priority item for some later point in time.
Something to look for when reviewing pull requests IMO.



On Sun, Mar 15, 2020 at 9:41 PM Jacob Barrett  wrote:

> Hey Team,
>
> When deprecating a symbol, like class or method, please included a
> reference to the replacement in the java docs. Also please include an
> example of converting from the old API to the new. I am finding many many
> places in the source where deprecated code has no hints at all. As many of
> us don’t take the effort to immediately convert old tests over to the new
> APIs the context is lost when someone finally does get around to it. For
> public APIs this is extremely important so that users know how to migrate
> their code with as few roadblocks as possible.
>
> Here is an example of something that is much better than most of what I am
> seeing.
>
> /**
>  * @deprecated Replaced with something better and safer.
>  * Replaced by {@link Bar}.
>  */
> @Deprecated
> class Foo {
>   /**
>* Do something.
>*
>* @deprecated Replaced with something better.
>* Replaced by {@link Bar#doSomethingBetter()}
>*/
>   @Deprecated
>   public void doSomething() {}
>
>   /**
>* Do something.
>*
>* @deprecated Implementation is not safe.
>* Replaced with {@link Bar#doSomethingBetter()} and {@link
> Bar#doSomethingElse()}.
>* Migration example, replace:
>* {@code
>*   Foo foo = new Foo();
>*   foo.doSomethingAndSomethingElse();
>* }
>* with:
>* {@code
>*   Bar bar = Bar();
>*   bar.doSomethingBetter();
>*   bar.doSomethingElse();
>* }
>*/
>   @Deprecated
>   public void doSomethingAndSomethingElse() {}
> }
>
> class Bar {
>   public void doSomethingBetter() {}
>   public void doSomethingElse() {}
> }
>
> -Jake
>
>

-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: RFC - Client side configuration for a SNI proxy

[Joris Melchior]

+1

On Fri, Mar 6, 2020 at 2:46 PM Udo Kohlmeyer  wrote:

> Hi there Bill,
>
> Whilst I commend your enthusiasm. Giving the community a weekend to
> review an RFC is less than optimal.
>
> Please extend you deadline until 13 March 2020. Which is more reasonable.
>
> --Udo
>
> On 3/6/20 11:04 AM, Bill Burcham wrote:
> > Please review the RFC for *Client side configuration for a SNI proxy*:
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy
> >
> > Please comment by Monday, March 9, 2020.
> >
> > Regards,
> > Bill and Ernie
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [PROPOSAL]: Include GEODE-7717 in Release 1.12.0

[Joris Melchior]

+1


On Fri, Feb 7, 2020 at 11:36 AM Jinmei Liao  wrote:

> Hi devs,
>
> I would like to include the fix for GEODE-7717[1] in release 1.12.0. The
> change modifies the json response structure of all of the "list" operations
> in cluster management rest service. Including it in this release, where
> most users are just starting to experiment with CMS rest service would be
> great.
>
> [1]: https://issues.apache.org/jira/browse/GEODE-7717
>
> https://github.com/apache/geode/commit/bda6bdf50c0a6a3e7cc39fb3ff654a0c26c86d94
>
> --
> Cheers
>
> Jinmei
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

[Joris Melchior]

Since the feedback has been to proceed with this proposal I will open a
JIRA ticket and start the work on this.

Thanks for the feedback on this.

Joris.

On Fri, Jan 3, 2020 at 1:11 PM Kirk Lund  wrote:

> I'm for un-deprecating it.
>
> On Fri, Jan 3, 2020 at 7:01 AM Joris Melchior 
> wrote:
>
> > Yes, the code indicates that the deprecation is related to the different
> > QueryService methods but then these methods end up using the IndexType
> > themselves which is the main reason I want to un-deprecate the ENUM
> itself.
> >
> > The changes to the QueryService interface in the proposal were suggested
> by
> > John to make the code show its intentions more clearly.
> >
> > On Thu, Jan 2, 2020 at 4:40 PM John Blum  wrote:
> >
> > > I thought I recall that the IndexType
> > > <
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > > >
> > > [1]
> > > was *deprecated* in favor of specific methods on the QueryService
> > > <
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html
> > > >
> > > interface
> > > [2] used to create Indexes of a specific type, e.g. like a Key Index
> > using
> > > QueryService.createKeyIndex(..)
> > > <
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html#createKeyIndex-java.lang.String-java.lang.String-java.lang.String-
> > > >
> > > [3]
> > > (or one of the "overloaded" variants), which is in contrast to the
> > generic
> > > createIndex(..)
> > > <
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html#createIndex-java.lang.String-org.apache.geode.cache.query.IndexType-java.lang.String-java.lang.String-java.lang.String-
> > > >
> > > method [4] that accepted the (now deprecated) IndexType Enum as an
> > > argument.
> > >
> > > However, I still feel that the IndexType Enum should NOT be deprecated,
> > > especially given that the Index.getType():IndexType
> > > <
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/Index.html#getType--
> > > >
> > > method [5] is quite useful to assess an Index (e.g. think
> > > Management/Monitoring tools or other analysis tools to ascertain the
> > > state/configuration of the system).
> > >
> > > -j
> > >
> > >
> > > [1]
> > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > > [2]
> > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html
> > > [3]
> > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html#createKeyIndex-java.lang.String-java.lang.String-java.lang.String-
> > > [4]
> > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html#createIndex-java.lang.String-org.apache.geode.cache.query.IndexType-java.lang.String-java.lang.String-java.lang.String-
> > > [5]
> > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/Index.html#getType--
> > >
> > >
> > > On Thu, Jan 2, 2020 at 1:26 PM Joris Melchior 
> > > wrote:
> > >
> > > > Hi Kirk,
> > > >
> > > > No, I've tried to figure that out but was unsuccessful in doing so.
> It
> > > > would be helpful if someone would be able to shed some light on that.
> > > >
> > > >
> > > > On Thu, Jan 2, 2020 at 1:34 PM Kirk Lund  wrote:
> > > >
> > > > > Hi Joris, I've read the proposal and reviewed the code some. It's
> not
> > > > clear
> > > > > to me why it was originally deprecated or what the intended new
> > > direction
> > > > > (instead of IndexType) was ever going to be. Do you know more about
> > why
> > > > it
> > > > > was deprecated or what the devs were going to replace it with?
> > > > >
> > > > > On Thu, Jan 2, 2020 at 6:31 AM Joris Melchior <
> jmelch...@pivotal.io>
> > > > > wrote:
> > > > >
> > &

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

[Joris Melchior]

Yes, the code indicates that the deprecation is related to the different
QueryService methods but then these methods end up using the IndexType
themselves which is the main reason I want to un-deprecate the ENUM itself.

The changes to the QueryService interface in the proposal were suggested by
John to make the code show its intentions more clearly.

On Thu, Jan 2, 2020 at 4:40 PM John Blum  wrote:

> I thought I recall that the IndexType
> <
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> >
> [1]
> was *deprecated* in favor of specific methods on the QueryService
> <
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html
> >
> interface
> [2] used to create Indexes of a specific type, e.g. like a Key Index using
> QueryService.createKeyIndex(..)
> <
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html#createKeyIndex-java.lang.String-java.lang.String-java.lang.String-
> >
> [3]
> (or one of the "overloaded" variants), which is in contrast to the generic
> createIndex(..)
> <
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html#createIndex-java.lang.String-org.apache.geode.cache.query.IndexType-java.lang.String-java.lang.String-java.lang.String-
> >
> method [4] that accepted the (now deprecated) IndexType Enum as an
> argument.
>
> However, I still feel that the IndexType Enum should NOT be deprecated,
> especially given that the Index.getType():IndexType
> <
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/Index.html#getType--
> >
> method [5] is quite useful to assess an Index (e.g. think
> Management/Monitoring tools or other analysis tools to ascertain the
> state/configuration of the system).
>
> -j
>
>
> [1]
>
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> [2]
>
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html
> [3]
>
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html#createKeyIndex-java.lang.String-java.lang.String-java.lang.String-
> [4]
>
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/QueryService.html#createIndex-java.lang.String-org.apache.geode.cache.query.IndexType-java.lang.String-java.lang.String-java.lang.String-
> [5]
>
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/Index.html#getType--
>
>
> On Thu, Jan 2, 2020 at 1:26 PM Joris Melchior 
> wrote:
>
> > Hi Kirk,
> >
> > No, I've tried to figure that out but was unsuccessful in doing so. It
> > would be helpful if someone would be able to shed some light on that.
> >
> >
> > On Thu, Jan 2, 2020 at 1:34 PM Kirk Lund  wrote:
> >
> > > Hi Joris, I've read the proposal and reviewed the code some. It's not
> > clear
> > > to me why it was originally deprecated or what the intended new
> direction
> > > (instead of IndexType) was ever going to be. Do you know more about why
> > it
> > > was deprecated or what the devs were going to replace it with?
> > >
> > > On Thu, Jan 2, 2020 at 6:31 AM Joris Melchior 
> > > wrote:
> > >
> > > > Apart from Bruce's response (thanks!) it's been very quiet on this
> > item.
> > > >
> > > > I'll extend the response time to Jan 10.
> > > >
> > > > Details at
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477
> > > >
> > > > Thanks, Joris.
> > > >
> > > > On Wed, Dec 4, 2019 at 1:03 PM Bruce Schuchardt <
> > bschucha...@pivotal.io>
> > > > wrote:
> > > >
> > > > > This proposal seems reasonable to me
> > > > >
> > > > > On 12/3/19 10:19 AM, Joris Melchior wrote:
> > > > > > Ah, that makes sense. I will update!
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 3, 2019 at 12:41 PM Alexander Murmann <
> > > amurm...@pivotal.io
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Joris, the "to be reviewed by" field is for a target date by
> which
> > > to
> > > > > wrap
> > > > > >> up the discussion. Do you mind updating the field and letting
> the
> > > > > mailing
>

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

[Joris Melchior]

Hi Kirk,

No, I've tried to figure that out but was unsuccessful in doing so. It
would be helpful if someone would be able to shed some light on that.


On Thu, Jan 2, 2020 at 1:34 PM Kirk Lund  wrote:

> Hi Joris, I've read the proposal and reviewed the code some. It's not clear
> to me why it was originally deprecated or what the intended new direction
> (instead of IndexType) was ever going to be. Do you know more about why it
> was deprecated or what the devs were going to replace it with?
>
> On Thu, Jan 2, 2020 at 6:31 AM Joris Melchior 
> wrote:
>
> > Apart from Bruce's response (thanks!) it's been very quiet on this item.
> >
> > I'll extend the response time to Jan 10.
> >
> > Details at
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477
> >
> > Thanks, Joris.
> >
> > On Wed, Dec 4, 2019 at 1:03 PM Bruce Schuchardt 
> > wrote:
> >
> > > This proposal seems reasonable to me
> > >
> > > On 12/3/19 10:19 AM, Joris Melchior wrote:
> > > > Ah, that makes sense. I will update!
> > > >
> > > >
> > > > On Tue, Dec 3, 2019 at 12:41 PM Alexander Murmann <
> amurm...@pivotal.io
> > >
> > > > wrote:
> > > >
> > > >> Joris, the "to be reviewed by" field is for a target date by which
> to
> > > wrap
> > > >> up the discussion. Do you mind updating the field and letting the
> > > mailing
> > > >> list know what timeframe you envision?
> > > >>
> > > >> Thanks!
> > > >>
> > > >> On Mon, Dec 2, 2019 at 1:41 PM Joris Melchior  >
> > > >> wrote:
> > > >>
> > > >>> Hi All,
> > > >>>
> > > >>> Looking for feedback on the proposal to [un/de]deprecate the
> > IndexType
> > > >> ENUM
> > > >>> on Geode.
> > > >>>
> > > >>>
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477
> > > >>> Thanks, Joris.
> > > >>>
> > > >>> --
> > > >>> *Joris Melchior *
> > > >>> CF Engineering
> > > >>> Pivotal Toronto
> > > >>> 416 877 5427
> > > >>>
> > > >>> “Programs must be written for people to read, and only incidentally
> > for
> > > >>> machines to execute.” – *Hal Abelson*
> > > >>> <https://en.wikipedia.org/wiki/Hal_Abelson>
> > > >>>
> > > >
> > >
> >
> >
> > --
> > *Joris Melchior *
> > CF Engineering
> > Pivotal Toronto
> > 416 877 5427
> >
> > “Programs must be written for people to read, and only incidentally for
> > machines to execute.” – *Hal Abelson*
> > <https://en.wikipedia.org/wiki/Hal_Abelson>
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

[Joris Melchior]

Apart from Bruce's response (thanks!) it's been very quiet on this item.

I'll extend the response time to Jan 10.

Details at
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477

Thanks, Joris.

On Wed, Dec 4, 2019 at 1:03 PM Bruce Schuchardt 
wrote:

> This proposal seems reasonable to me
>
> On 12/3/19 10:19 AM, Joris Melchior wrote:
> > Ah, that makes sense. I will update!
> >
> >
> > On Tue, Dec 3, 2019 at 12:41 PM Alexander Murmann 
> > wrote:
> >
> >> Joris, the "to be reviewed by" field is for a target date by which to
> wrap
> >> up the discussion. Do you mind updating the field and letting the
> mailing
> >> list know what timeframe you envision?
> >>
> >> Thanks!
> >>
> >> On Mon, Dec 2, 2019 at 1:41 PM Joris Melchior 
> >> wrote:
> >>
> >>> Hi All,
> >>>
> >>> Looking for feedback on the proposal to [un/de]deprecate the IndexType
> >> ENUM
> >>> on Geode.
> >>>
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477
> >>> Thanks, Joris.
> >>>
> >>> --
> >>> *Joris Melchior *
> >>> CF Engineering
> >>> Pivotal Toronto
> >>> 416 877 5427
> >>>
> >>> “Programs must be written for people to read, and only incidentally for
> >>> machines to execute.” – *Hal Abelson*
> >>> <https://en.wikipedia.org/wiki/Hal_Abelson>
> >>>
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [DISCUSS] Replacing singleton PoolManager

[Joris Melchior]

+1

On Thu, Dec 5, 2019 at 7:40 PM Dan Smith  wrote:

> Hi,
>
> I wrote up a proposal for deprecating of the singleton PoolManager in favor
> of a ClientCache scoped service. Please review and comment on the below
> proposal.
>
> I think this should address the issues that Spring Data Geode and friends
> had trying to mock Pools and remove the need for those projects to try to
> inject mock Pools into a Geode singleton.
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Replace+singleton+PoolManager+with+ClientCache+scoped+service
>
> Thanks,
> -Dan
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

[Joris Melchior]

Ah, that makes sense. I will update!


On Tue, Dec 3, 2019 at 12:41 PM Alexander Murmann 
wrote:

> Joris, the "to be reviewed by" field is for a target date by which to wrap
> up the discussion. Do you mind updating the field and letting the mailing
> list know what timeframe you envision?
>
> Thanks!
>
> On Mon, Dec 2, 2019 at 1:41 PM Joris Melchior 
> wrote:
>
> > Hi All,
> >
> > Looking for feedback on the proposal to [un/de]deprecate the IndexType
> ENUM
> > on Geode.
> >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477
> >
> > Thanks, Joris.
> >
> > --
> > *Joris Melchior *
> > CF Engineering
> > Pivotal Toronto
> > 416 877 5427
> >
> > “Programs must be written for people to read, and only incidentally for
> > machines to execute.” – *Hal Abelson*
> > <https://en.wikipedia.org/wiki/Hal_Abelson>
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

[DISCUSSION] De/un-deprecate IndexType ENUM

[Joris Melchior]

Hi All,

Looking for feedback on the proposal to [un/de]deprecate the IndexType ENUM
on Geode.

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477

Thanks, Joris.

-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: Certificate Based Authorization

[Joris Melchior]

+1

On Mon, Dec 2, 2019 at 12:26 PM Jacob Barrett  wrote:

> +1
>
> > On Dec 2, 2019, at 6:47 AM, Jens Deppe  wrote:
> >
> > Hi Mario,
> >
> > Definitely sounds like a good idea! Feel free to write up a RFC proposal
> > with more details.
> >
> > Thanks
> > --Jens
> >
> > On Mon, Dec 2, 2019 at 1:30 AM Mario Kevo  wrote:
> >
> >> Hi,
> >>
> >>
> >>
> >> There is another potential functionality we would like to discuss and
> get
> >> some comments for. The idea is TLS certificate based authorization.
> >> Currently, if a user wants secure communication (TLS) + authorization,
> he
> >> needs to enable TLS and access control. The user also needs to handle
> both
> >> the certificates for TLS and the credentials for access control. The
> idea
> >> we have is to use both features: TLS and access control, but remove the
> >> need to handle the credentials (generating and securely storing the
> >> username and password). Instead of the credentials, the certificate
> subject
> >> DN would be used for authorization.
> >>
> >>
> >>
> >> This would of course be optional. We would leave the possibility to use
> >> these 2 features as they are right now, but would also provide a
> >> configuration option to use the features without the need for client
> >> credentials, utilizing the certificate information instead.
> >>
> >>
> >>
> >> For further clarity, here are the descriptions of how the options would
> >> work:
> >>
> >>
> >>
> >>  1.  Using TLS and access control as they work right now
> >> *   Certificates are prepared for TLS
> >> *   A SecurityManager is prepared for access control
> >> authentication/authorization. As part of this, a file (e.g.
> security.json)
> >> is prepared where we define the allowed usernames, passwords and
> >> authorization rights for each username
> >> *   The credentials are distributed towards clients. Here a user
> >> needs to consider secure distribution and periodical rotation of
> >> credentials.
> >>
> >> Once a client initiates a connection, we first get the TLS layer and
> >> certificate check, and right after that we perform the
> >> authentication/authorization of the user credentials.
> >>
> >>
> >>
> >>  1.  TLS certificate based authorization
> >> *   Certificates are prepared for TLS
> >> *   A SecurityManager is prepared for access control
> >> authentication/authorization. As part of this, a file (e.g.
> security.json)
> >> is prepared. In this case we don’t define the authorization rights
> based on
> >> usernames/passwords but based on certificate subject DNs.
> >> *   There is no more need to distribute or periodically rotate the
> >> credentials, since there would be none. Authorization would be based  on
> >> the subject DN fetched from the certificate used for that same
> connection
> >>
> >> Once a client initiates a connection, and when we get past the TLS
> layer,
> >> at the moment where geode expects the credentials from the client
> >> connection, we just take the certificate subject DN instead and provide
> it
> >> to the security manager for authorization.
> >>
> >>
> >>
> >> This wouldn’t lower the level of security (we can have TLS enabled
> without
> >> access control already), but would provide authentication without the
> >> hassle of username and password handling.
> >>
> >>
> >>
> >> This is the basic description of the idea. There would be more things to
> >> consider, like multi user authentication, but for now we would just
> like to
> >> get some initial feedback. If it is considered useful, we could get into
> >> the details.
> >>
> >>
> >> BR,
> >>
> >> Mario
> >>
> >>
>
>

-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: IndexType deprecation question

[Joris Melchior]

Okay, that is good feedback. I lean towards un-deprecating as well. Let me
write a draft proposal for some changes so everyone can chime in and
hopefully we'll have a workable target at the end of it.

Thanks, Joris.

On Mon, Dec 2, 2019 at 1:00 PM John Blum  wrote:

> My vote would be to UNDEPRECATE the IndexType in Apache Geode.  There are
> several codepaths in SDG that use the IndexType to make certain decisions.
>
> I also think having an Enum is much more flexible than having a method per
> Index type, particularly since you can use Enum values in switch
> statements.  I do like the createXyzIndex methods (e.g. createKeyIndex) for
> common OQL Indexes, however.  I do think the createIndex for
> FUNCTIONAL/RANGE OQL Indexes should be renamed (rather, the old method
> deprecated and a new method introduced, i.e. createRangeIndex or
> createFunctionalIndex).
>
> -j
>
>
> On Mon, Dec 2, 2019 at 9:44 AM Jason Huynh  wrote:
>
> > Hi Joris,
> >
> > Just some guesses and no actual answer from me here:
> >
> > The deprecation of the index type was before HASH indexes were created,
> and
> > my guess was due to the introduction of the "new at the time" query
> service
> > apis (the javadoc:@deprecated As of 6.6.1. Check {@link QueryService}
> for
> > changes.)
> >
> > The internals still use the IndexType as you have pointed out and maybe
> the
> > deprecation was more intended for the end user (since it's not an
> internal
> > type) and perhaps it was intended to have been moved internal at some
> > point?
> >
> > There is some weirdness with the index types and actually having multiple
> > implementations for the Functional type.  Under the covers we create a
> > memory-optimized version based on the indexed expression.
> >
> > Things have changed since deprecation, so maybe it should be
> > un/de-deprecated or an alternative solution can probably be thought up...
> >
> > -Jason
> >
> >
> > On Mon, Dec 2, 2019 at 9:13 AM Joris Melchior 
> > wrote:
> >
> > > Hi Jason,
> > >
> > > At this point it is not about creating but returning the Region with an
> > > indicator in the management API without using deprecated parts. Under
> the
> > > covers the QueryService java api still uses the IndexType ENUM and had
> > > assumed that an alternative would be provided when something is marked
> as
> > > deprecated.
> > >
> > > I can of course create a new ENUM to return but prefer not to take this
> > > step before ensuring that we don't have something in place already.
> > >
> > > I'm also wondering if the deprecation should have been limited to the
> > HASH
> > > type on the IndexType ENUM instead of deprecating the complete ENUM.
> > >
> > > Thanks, Joris.
> > >
> > > On Mon, Dec 2, 2019 at 12:05 PM Jason Huynh  wrote:
> > >
> > > > Hi Joris,
> > > >
> > > > How are you creating the index?  If using the QueryService java api,
> > > there
> > > > should be createKeyIndex() and createIndex() methods.  These methods
> > > should
> > > > create the primary key index and the functional index.
> > > >
> > > > I am not sure if there is an alternative in gfsh... it might still be
> > > using
> > > > the IndexType enum or something similar.
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Nov 29, 2019 at 12:18 PM Joris Melchior <
> jmelch...@pivotal.io>
> > > > wrote:
> > > >
> > > > > Thanks John.
> > > > >
> > > > > I'm trying to use it on the server side for the management API so
> > > > > unfortunately the Spring wrapper is not an option. Hopefully
> someone
> > > can
> > > > > provide some insight into the deprecation background once all the
> > > turkey
> > > > > and stuffing has been digested.
> > > > >
> > > > > On Fri, Nov 29, 2019 at 2:16 PM John Blum 
> wrote:
> > > > >
> > > > > > FYI... if you are using *Spring Data for Apache Geode* (SDG;
> > > > > > spring-data-geode), then there is an SDG Index enum type
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > > > > >
> > > > 

Re: IndexType deprecation question

[Joris Melchior]

Hi Jason,

At this point it is not about creating but returning the Region with an
indicator in the management API without using deprecated parts. Under the
covers the QueryService java api still uses the IndexType ENUM and had
assumed that an alternative would be provided when something is marked as
deprecated.

I can of course create a new ENUM to return but prefer not to take this
step before ensuring that we don't have something in place already.

I'm also wondering if the deprecation should have been limited to the HASH
type on the IndexType ENUM instead of deprecating the complete ENUM.

Thanks, Joris.

On Mon, Dec 2, 2019 at 12:05 PM Jason Huynh  wrote:

> Hi Joris,
>
> How are you creating the index?  If using the QueryService java api, there
> should be createKeyIndex() and createIndex() methods.  These methods should
> create the primary key index and the functional index.
>
> I am not sure if there is an alternative in gfsh... it might still be using
> the IndexType enum or something similar.
>
>
>
>
> On Fri, Nov 29, 2019 at 12:18 PM Joris Melchior 
> wrote:
>
> > Thanks John.
> >
> > I'm trying to use it on the server side for the management API so
> > unfortunately the Spring wrapper is not an option. Hopefully someone can
> > provide some insight into the deprecation background once all the turkey
> > and stuffing has been digested.
> >
> > On Fri, Nov 29, 2019 at 2:16 PM John Blum  wrote:
> >
> > > FYI... if you are using *Spring Data for Apache Geode* (SDG;
> > > spring-data-geode), then there is an SDG Index enum type
> > > <
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > >
> > > [1]
> > > wrapping the deprecated Apache Geode Index enum type
> > > <
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > > >
> > >  [2].
> > >
> > >
> > >
> > > [1]
> > >
> > >
> >
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> > > [2]
> > >
> > >
> >
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> > >
> > >
> > > On Fri, Nov 29, 2019 at 8:17 AM Joris Melchior 
> > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > I notice that the ENUM
> > > >
> > > > org.apache.geode.cache.query.IndexType has been deprecated but can't
> > > > find what to use instead of this ENUM if I wanted to use a
> > > > non-deprecated alternative.
> > > >
> > > > I understand that HASH indexes are no longer recommended but the
> other
> > > > types (PRIMARY_KEY, FUNCTIONAL) are still valid and I believe we
> > > > should be able to use them without using deprecated code.
> > > >
> > > > Can anyone tell me how this is accomplished?
> > > >
> > > > Thanks, Joris.
> > > >
> > > >
> > > > --
> > > > *Joris Melchior *
> > > > CF Engineering
> > > > Pivotal Toronto
> > > > 416 877 5427
> > > >
> > > > “Programs must be written for people to read, and only incidentally
> for
> > > > machines to execute.” – *Hal Abelson*
> > > > <https://en.wikipedia.org/wiki/Hal_Abelson>
> > > >
> > >
> > >
> > > --
> > > -John
> > > john.blum10101 (skype)
> > >
> >
> >
> > --
> > *Joris Melchior *
> > CF Engineering
> > Pivotal Toronto
> > 416 877 5427
> >
> > “Programs must be written for people to read, and only incidentally for
> > machines to execute.” – *Hal Abelson*
> > <https://en.wikipedia.org/wiki/Hal_Abelson>
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: IndexType deprecation question

[Joris Melchior]

Thanks John.

I'm trying to use it on the server side for the management API so
unfortunately the Spring wrapper is not an option. Hopefully someone can
provide some insight into the deprecation background once all the turkey
and stuffing has been digested.

On Fri, Nov 29, 2019 at 2:16 PM John Blum  wrote:

> FYI... if you are using *Spring Data for Apache Geode* (SDG;
> spring-data-geode), then there is an SDG Index enum type
> <
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> >
> [1]
> wrapping the deprecated Apache Geode Index enum type
> <
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
> >
>  [2].
>
>
>
> [1]
>
> https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/IndexType.html
> [2]
>
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/query/IndexType.html
>
>
> On Fri, Nov 29, 2019 at 8:17 AM Joris Melchior 
> wrote:
>
> > Hi All,
> >
> > I notice that the ENUM
> >
> > org.apache.geode.cache.query.IndexType has been deprecated but can't
> > find what to use instead of this ENUM if I wanted to use a
> > non-deprecated alternative.
> >
> > I understand that HASH indexes are no longer recommended but the other
> > types (PRIMARY_KEY, FUNCTIONAL) are still valid and I believe we
> > should be able to use them without using deprecated code.
> >
> > Can anyone tell me how this is accomplished?
> >
> > Thanks, Joris.
> >
> >
> > --
> > *Joris Melchior *
> > CF Engineering
> > Pivotal Toronto
> > 416 877 5427
> >
> > “Programs must be written for people to read, and only incidentally for
> > machines to execute.” – *Hal Abelson*
> > <https://en.wikipedia.org/wiki/Hal_Abelson>
> >
>
>
> --
> -John
> john.blum10101 (skype)
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

IndexType deprecation question

[Joris Melchior]

Hi All,

I notice that the ENUM

org.apache.geode.cache.query.IndexType has been deprecated but can't
find what to use instead of this ENUM if I wanted to use a
non-deprecated alternative.

I understand that HASH indexes are no longer recommended but the other
types (PRIMARY_KEY, FUNCTIONAL) are still valid and I believe we
should be able to use them without using deprecated code.

Can anyone tell me how this is accomplished?

Thanks, Joris.


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [DISCUSS/VOTE] Proposal to bring GEODE-7465 to release/1.11.0

[Joris Melchior]

+1

On Tue, Nov 26, 2019 at 2:41 PM Jason Huynh  wrote:

> +1
>
> On Tue, Nov 26, 2019 at 11:34 AM Anilkumar Gingade 
> wrote:
>
> > +1
> >
> > On Tue, Nov 26, 2019 at 11:32 AM Udo Kohlmeyer  wrote:
> >
> > > This is no-brainer
> > >
> > > *+1*
> > >
> > > On 11/26/19 11:27 AM, Owen Nichols wrote:
> > > > I would like to propose bringing “GEODE-7465: Set eventProcessor to
> > null
> > > in serial AEQ when it is stopped” into the 1.11 release (necessitating
> an
> > > RC4).
> > > >
> > > > Without the fix, a sequence of ordinary gfsh commands will leave the
> > WAN
> > > gateway in an unrecoverable hung state:
> > > > stop gateway-sender
> > > > start gateway-sender
> > > > The only recourse is to restart the server.
> > > >
> > > > This fix is critical because the distributed system fails to sync
> data
> > > between WAN sites as the user would expect.
> > > > This issue did exist in previous releases, but recent enhancements to
> > > WAN/AEQ such as AEQ-pause are increasing user interaction with
> > WAN-related
> > > gfsh commands.
> > > >
> > > > The fix is simple, low risk, tested, and has been on develop for 5
> > days:
> > > >
> > >
> >
> https://github.com/apache/geode/commit/e148cef9cb63eba283cf86bc490eb280023567ce
> > >
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module

[Joris Melchior]

+1

On Mon, Nov 18, 2019 at 6:22 PM Owen Nichols  wrote:

> +1
>
> > On Nov 18, 2019, at 3:00 PM, Nabarun Nag  wrote:
> >
> > +1
> >
> > On Mon, Nov 18, 2019 at 2:21 PM Udo Kohlmeyer  wrote:
> >
> >> Thank you for this Bill,
> >>
> >> I must admit that I'm starting to get a feeling of "scope creep" here..
> >> I understand that all efforts to "modularize" membership would require
> >> some form of peripheral decoupling.
> >>
> >> BUT
> >>
> >> I'm starting to get concerned that we are hitting a rabbit hole
> >> scenario. Maybe this is normal for an effort of this manner, BUT, I
> >> would like to urge that we start discussing/proposing other
> >> modulizations, like, Serialization and now TCP communications as real
> >> modules with own proposals and with their own merit.
> >>
> >> YES, I understand this is minimal touch modulizations, but I'm concerned
> >> that we are doing work under the incorrect banner. Just enough to
> >> complete one "piece of it", but possibly a rework, of the module because
> >> of the "good enough" approach we take.
> >>
> >> Maybe we are discovering that there is some pre-work that needed to have
> >> been completed before the whole membership modularization effort was
> >> started.. And maybe this is the time where we need to take a step back,
> >> look at this from a higher perspective and decide if membership is
> >> really still the priority here with serialization and transport
> >> (TCPServer) being a side-effect.
> >>
> >> For this reason alone I vote: *-0 *on this matter.. (it is only a little
> >> better than -1)
> >>
> >> --Udo
> >>
> >> On 11/18/19 1:48 PM, Bill Burcham wrote:
> >>> Dear Geode,
> >>>
> >>> In support of the Membership modularization efforts
> >>>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Move+membership+code+to+a+separate+gradle+sub-project
> >> ,
> >>> we would like to move the types in the
> >>> org.apache.geode.distributed.internal.tcpserver package (i.e. the
> >> TcpServer
> >>> class and related types) into a separate module in order to eliminate
> >>> dependencies on geode-core.
> >>>
> >>> The membership subsystem is dependent on this group of types, which in
> >> turn
> >>> are (were) highly-dependent on geode-core. We have been systematically
> >>> eliminating dependencies from these types to geode-core as part of
> >>> https://issues.apache.org/jira/browse/GEODE-7343 _TcpServer should not
> >>> depend on geode-core_ The final sub-task on that ticket puts TcpServer
> >> and
> >>> related types into its own separate module.
> >>>
> >>> The proposed module would be called "geode-tcp-server" and would
> contain
> >>> TcpServer and the other types in the
> >>> org.apache.geode.distributed.internal.tcpserver package.
> >>>
> >>> Your feedback is welcomed and appreciated.
> >>>
> >>> Your Friend,
> >>> Bill
> >>>
> >>
>
>

-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[Joris Melchior]

> >>>>> --Jens
> >>>>>
> >>>>> [1] -
> >>>>>
> >>>>
> >>>
> >>
> https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
> >>>>> [2] - http://tomcat.apache.org/whichversion.html
> >>>>> [3] - https://access.redhat.com/support/policy/updates/jboss_notes
> >>>>> [4] - https://en.wikipedia.org/wiki/IBM_WebSphere_Application_Server
> >>>>> [5] -
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://www.solstice.com/fwd/survival-guide-to-webspheres-and-weblogics-end-of-life
> >>>>>
> >>>>> On Fri, Nov 15, 2019 at 8:11 AM Charles Smith 
> >>>> wrote:
> >>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> The Geode HTTP Session Management Module for AppServers currently
> >>>> states:
> >>>>>> This approach is a generic solution, which is supported by any
> >>>> container
> >>>>>> that implements the Servlet 2.4 specification.
> >>>>>> I would like to suggest that this official support be bumped up to
> >>> the
> >>>>>> Servlet 3.0 specification.
> >>>>>>
> >>>>>> There are some important cookie security features missing in the
> >>>> ancient
> >>>>>> Servlet 2.4 spec, namely the secure and httpOnly flags. Bumping
> >>> support
> >>>>> to
> >>>>>> Servlet 3.0 would allow the Geode AppServer session module to
> >>>> inherently
> >>>>>> support these session cookie security features.
> >>>>>>
> >>>>>> I have logged the following Jira issue:
> >>>>>>
> >>>>>> https://issues.apache.org/jira/browse/GEODE-7438
> >>>>>>
> >>>>>> and submitted a pull request that provides the necessary support if
> >>> the
> >>>>>> Geode community agrees this is a good idea.
> >>>>>>
> >>>>>> And thank you for the excellent Apache Geode project!
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>> Charles Smith
> >>>>>>
> >>>>>> Developer/Analyst
> >>>>>>
> >>>>>> Web Architecture and Development
> >>>>>> MacEwan University
> >>>>>> smith...@macewan.ca
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> -John
> >>>> john.blum10101 (skype)
> >>>>
> >>>
> >>
> >>
> >> --
> >> -John
> >> john.blum10101 (skype)
> >>
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: Jira permission to assign myself

[Joris Melchior]

Thanks Dan!

On Fri, Nov 1, 2019 at 3:01 PM Dan Smith  wrote:

> Hi Joris,
>
> You now also have access.
>
> Thanks!
> -Dan
>
> On Fri, Nov 1, 2019 at 8:12 AM Joris Melchior 
> wrote:
>
> > Hi Dan,
> >
> > Can you provide me with the ability to assign tickets to myself as well?
> >
> > Username: joris.melchior
> >
> > Thanks, Joris.
> >
> > On Thu, Oct 31, 2019 at 2:19 PM Dan Smith  wrote:
> >
> > > Hi Szu-Yu Lo,
> > >
> > > You should have access now. Thanks for being interested in contributing
> > to
> > > Geode! If you haven't already, you might want to check out our How to
> > > Contribute
> > > <https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute>
> > > page.
> > >
> > > Thanks again!
> > > -Dan
> > >
> > > On Thu, Oct 31, 2019 at 11:13 AM Szu-Yu Lo 
> > wrote:
> > >
> > > > Hi Dan,
> > > >
> > > > My username is sylo.
> > > >
> > > > Thanks
> > > >
> > > > On Thu, Oct 31, 2019 at 2:12 PM Dan Smith  wrote:
> > > >
> > > > > Hi Szu-Yu Lo,
> > > > >
> > > > > What is your JIRA username? If you don't already have an account,
> you
> > > can
> > > > > create one.
> > > > >
> > > > > -Dan
> > > > >
> > > > > On Thu, Oct 31, 2019 at 10:09 AM Szu-Yu Lo  >
> > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am new to geode and would love to contributed  to geode. I am
> not
> > > > able
> > > > > to
> > > > > > assigned myself. It would be greatly appreciated, if I could have
> > > > > > permission to assign an issue to myself.
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Szu-Yu Lo
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > *Joris Melchior *
> > CF Engineering
> > Pivotal Toronto
> > 416 877 5427
> >
> > “Programs must be written for people to read, and only incidentally for
> > machines to execute.” – *Hal Abelson*
> > <https://en.wikipedia.org/wiki/Hal_Abelson>
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: Jira permission to assign myself

[Joris Melchior]

Hi Dan,

Can you provide me with the ability to assign tickets to myself as well?

Username: joris.melchior

Thanks, Joris.

On Thu, Oct 31, 2019 at 2:19 PM Dan Smith  wrote:

> Hi Szu-Yu Lo,
>
> You should have access now. Thanks for being interested in contributing to
> Geode! If you haven't already, you might want to check out our How to
> Contribute
> <https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute>
> page.
>
> Thanks again!
> -Dan
>
> On Thu, Oct 31, 2019 at 11:13 AM Szu-Yu Lo  wrote:
>
> > Hi Dan,
> >
> > My username is sylo.
> >
> > Thanks
> >
> > On Thu, Oct 31, 2019 at 2:12 PM Dan Smith  wrote:
> >
> > > Hi Szu-Yu Lo,
> > >
> > > What is your JIRA username? If you don't already have an account, you
> can
> > > create one.
> > >
> > > -Dan
> > >
> > > On Thu, Oct 31, 2019 at 10:09 AM Szu-Yu Lo 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > I am new to geode and would love to contributed  to geode. I am not
> > able
> > > to
> > > > assigned myself. It would be greatly appreciated, if I could have
> > > > permission to assign an issue to myself.
> > > >
> > > >
> > > > Regards,
> > > > Szu-Yu Lo
> > > >
> > >
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [DISCUSS] Tweak to branch protection rules

[Joris Melchior]

+1

On Wed, Oct 30, 2019 at 5:27 AM Ju@N  wrote:

> Question: this only applies for *approvals*, not for *refusals*, right?; I
> mean, the *merge pull request* button will remain blocked if there were
> some changes requested by reviewers and the author of the PR adds new
> commits (either addressing those requested changes or not)?.
> If the answer to the above is "yes", then +1.
>
> On Wed, Oct 30, 2019 at 1:44 AM Nabarun Nag  wrote:
>
> > +1
> >
> > On Tue, Oct 29, 2019 at 6:21 PM Darrel Schneider 
> > wrote:
> >
> > > +1
> > >
> > > On Tue, Oct 29, 2019 at 6:08 PM Owen Nichols 
> > wrote:
> > >
> > > > +1 …this has already bitten me a few times
> > > >
> > > > > On Oct 29, 2019, at 6:01 PM, Dan Smith  wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > It seems we've configured our branch protection rules such that
> > > pushing a
> > > > > change to a PR that has been approved invalidates the previous
> > > approval.
> > > > >
> > > > > I think we should turn this off - it looks like it's an optional
> > > feature.
> > > > > We should trust people to rerequest reviews if needed. Right now
> this
> > > is
> > > > > adding busywork for people to reapprove minor changes (Fixing merge
> > > > > conflicts, spotless, etc.)
> > > > >
> > > > > If you all agree I'll ask infra to uncheck "Dismiss stale pull
> > request
> > > > > approvals when new commits are pushed." in our branch protection
> > rules.
> > > > >
> > > > > -Dan
> > > >
> > > >
> > >
> >
>
>
> --
> Ju@N
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: Deprecate SystemFailure Class

[Joris Melchior]

+1.

On Mon, Oct 28, 2019 at 4:22 PM Robert Houghton 
wrote:

> +1.
>
> On Mon, Oct 28, 2019 at 12:11 PM Bill Burcham 
> wrote:
>
> > The SystemFailure class is a clearing house for detecting and attempting
> to
> > mitigate SystemFailure exceptions e.g. VirtualMachineError and
> > OutOfMemoryError.
> >
> > This class should not exist. SystemFailure exceptions should be allowed
> to
> > percolate up and cause the JVM to terminate as soon as possible with an
> > informative message in the log, if possible.
> >
> > Here is what the JVM spec has to say [1]:
> >
> > "A Java Virtual Machine implementation throws an object that is an
> instance
> > of a subclass of the class VirtualMethodError (sic) when an internal
> error
> > or resource limitation prevents it from implementing the semantics
> > described in this chapter. This specification cannot predict where
> internal
> > errors or resource limitations may be encountered and does not mandate
> > precisely when they can be reported."
> >
> > There's a typo in the spec there: it says "VirtualMethodError" when it
> > means "VirtualMachineError". Anyhoo, the upshot is: the JVM spec does not
> > apply after you've encountered a VirtualMachineError. As a result, there
> is
> > no reason to believe that subsequent processing will make things better
> > (than exiting immediately).
> >
> > The SystemFailure class should be deprecated so no new dependencies to it
> > are added. Existing dependencies on it, should be eliminated over time.
> >
> > Do you have any objections to deprecating the class and beginning
> > elimination of usage of it within Geode?
> >
> > Regards,
> > Bill
> >
> > [1]
> > https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
> > [2] oh and here's a ticket
> > https://issues.apache.org/jira/browse/GEODE-7369
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [DISCUSS] Blocking merge button in PR

[Joris Melchior]

+1 to the revised approach. I think requiring at least one review is
important. More eyes make for better code.

Cheers, Joris.

On Mon, Oct 21, 2019 at 8:11 AM Ju@N  wrote:

> +10 to Naba's proposal, it seems the right thing to do and will help us to
> prevent accidentally breaking *develop* while keeping focus on people
> instead of processes.
> I'd add, however, that the *Merge Pull Request* button should remain
> disabled until *all CIs have finished*, and only enable it once the *Build,
> Unit, Stress Tests and LGTM are green *(that is, force the committer to
> wait at least until all CIs are done)*. *I also agree in that that we
> should require *at least one* official approval.
> Cheers.
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: Token based authentication support added in Geode Develop

[Joris Melchior]

Yes, at the moment the we only support receiving a token provided in the
Authentication header field. We don't provide the standard endpoints for
token acquisition and refresh.

On Fri, Oct 4, 2019 at 4:14 PM John Blum  wrote:

> So application developer's will need to know to code their application
> client's to lookup the JWT token (from some store) and set HTTP request
> headers to send the token, or will this be handled automatically by a geode
> client?
>
> On Fri, Oct 4, 2019 at 11:37 AM Jinmei Liao  wrote:
>
> > yes, correct,  we are assuming the client will have the token available
> > somehow and send in the token in the authentication header. We are not
> > doing anything with actual token management.
> >
> > On Fri, Oct 4, 2019 at 11:34 AM Jens Deppe  wrote:
> >
> > > So, to be clear, we're providing the ability to recognize a HTTP
> > > authentication header containing 'Bearer '
> and
> > > then handing that to the Security Manager to do with as it pleases?
> > >
> > > We're not doing anything with actual token management? (i.e.
> generating,
> > > revoking, etc.).
> > >
> > > --Jens
> > >
> > > On Fri, Oct 4, 2019 at 10:59 AM Jinmei Liao  wrote:
> > >
> > > > Hi, all
> > > >
> > > > JWT token based authentication support is added to Geode develop
> > branch.
> > > > Currently only management v2 rest api can use this (we can add dev
> rest
> > > > there too if requested). In order to turn on token based auth for
> > > > management rest api, you will need to do these two things:
> > > > 1. start your locator with this property:
> > > >  *security-auth-token-enabled-components = all (or management)*
> > > > 2. implement your SecurityManager to authenticate the jwt token
> passed
> > > in.
> > > > The jwt token will be available in the properties using the key
> > > > "security-token".
> > > >
> > > > Let me know if you have any questions.
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
>
> --
> -John
> john.blum10101 (skype)
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [DISCUSS] RFC - Move membership code to a separate gradle sub-project

[Joris Melchior]

+1

On Thu, Sep 5, 2019 at 2:57 PM Darrel Schneider 
wrote:

> +1 I added some comments on the wiki
>
> On Thu, Sep 5, 2019 at 9:34 AM Kirk Lund  wrote:
>
> > *interfaces -> was supposed to be "implementations"
> >
> > On Thu, Sep 5, 2019 at 9:33 AM Kirk Lund  wrote:
> >
> > > +1 The planned subprojects look good. Thanks for clarifying the
> > > goals/anti-goals in the RPC, especially the anti-goal to not make it
> > > pluggable with different interfaces.
> > >
> > > On Thu, Sep 5, 2019 at 8:52 AM Aaron Lindsey 
> > wrote:
> > >
> > >> +1 — I'm happy to see us move toward better testability for the
> > membership
> > >> code!
> > >>
> > >> I also left my "+1" on the wiki page comments. I noticed that the
> > >> "Lightweight RFC Process" document states that we're supposed to have
> > >> discussions on the [DISCUSS] thread:
> > >>
> > >> In addition a [DISCUSS] email should be send to the dev mailing list.
> > >> > Discussion will take place in the email thread.
> > >> >
> > >>
> > >> Can we clarify how to have discussions on proposals? Personally, I
> don't
> > >> care either way as long as it's clear how the process is supposed to
> > work.
> > >>
> > >> - Aaron
> > >>
> > >>
> > >> On Wed, Sep 4, 2019 at 4:04 PM Bruce Schuchardt <
> bschucha...@pivotal.io
> > >
> > >> wrote:
> > >>
> > >> > Thanks to folks who put in review comments today.  We're shooting
> for
> > >> > closing this RFC this week.
> > >> >
> > >> >
> > >> > On 8/30/19 3:50 PM, Dan Smith wrote:
> > >> > > Hi all,
> > >> > >
> > >> > > We added the following RFC to the wiki about moving Geode's
> > membership
> > >> > > system to a separate gradle sub-project. Please review and comment
> > by
> > >> > > 9/6/2019.
> > >> > >
> > >> > > https://cwiki.apache.org/confluence/x/WRB4Bw
> > >> > >
> > >> > > Thanks!
> > >> > > -Dan
> > >> > >
> > >> >
> > >>
> > >
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: Use of Internal JDK API

[Joris Melchior]

Kudos! Enjoyed my first cleaned up build!

On Thu, Aug 22, 2019 at 12:46 PM Jacob Barrett  wrote:

> Hey Team,
>
> I just merged the fix for GEODE-130, an oldie but goodie, regarding all
> those annoying internal JDK API warnings when compiling. Please don’t be
> that person who puts more internal JDK API’s into the product. If you must
> please do it in the new geode-unsafe module. You will find that this module
> creates an API wrapping the internal JDK api’s so that geode-core and such
> can depend on “public” versions of these APIs and compile without warnings.
> The geode-unsafe module compiles with API warnings suppressed. Have fun
> compiling without all these warnings filling your screen.
>
> https://issues.apache.org/jira/browse/GEODE-130 <
> https://issues.apache.org/jira/browse/GEODE-130>
>
> -Jake
>
>
>

-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: edit permissions on wiki

[Joris Melchior]

Thanks, all good now!

On Fri, Aug 2, 2019 at 4:32 PM Kirk Lund  wrote:

> Oops. Try now.
>
> On Fri, Aug 2, 2019 at 12:52 PM Joris Melchior 
> wrote:
>
> > Don't seem to have edit permissions yet though ...
> >
> > On Fri, Aug 2, 2019 at 3:48 PM Joris Melchior 
> > wrote:
> >
> > > Thanks Kirk!
> > >
> > > On Fri, Aug 2, 2019 at 12:16 PM Kirk Lund  wrote:
> > >
> > >> You should have permission now. Thanks!
> > >>
> > >> On Fri, Aug 2, 2019 at 7:32 AM Joris Melchior 
> > >> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > Can someone provide me with edit permissions on the wiki?
> Specifically
> > >> the
> > >> > tree starting with this link
> > >> >
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
> > >> >
> > >> > My user name is 'joris.melchior'.
> > >> >
> > >> > Thanks,
> > >> >
> > >> > --
> > >> > *Joris Melchior *
> > >> > CF Engineering
> > >> > Pivotal Toronto
> > >> > 416 877 5427
> > >> >
> > >> > “Programs must be written for people to read, and only incidentally
> > for
> > >> > machines to execute.” – *Hal Abelson*
> > >> > <https://en.wikipedia.org/wiki/Hal_Abelson>
> > >> >
> > >>
> > >
> > >
> > > --
> > > *Joris Melchior *
> > > CF Engineering
> > > Pivotal Toronto
> > > 416 877 5427
> > >
> > > “Programs must be written for people to read, and only incidentally for
> > > machines to execute.” – *Hal Abelson*
> > > <https://en.wikipedia.org/wiki/Hal_Abelson>
> > >
> >
> >
> > --
> > *Joris Melchior *
> > CF Engineering
> > Pivotal Toronto
> > 416 877 5427
> >
> > “Programs must be written for people to read, and only incidentally for
> > machines to execute.” – *Hal Abelson*
> > <https://en.wikipedia.org/wiki/Hal_Abelson>
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: edit permissions on wiki

[Joris Melchior]

Don't seem to have edit permissions yet though ...

On Fri, Aug 2, 2019 at 3:48 PM Joris Melchior  wrote:

> Thanks Kirk!
>
> On Fri, Aug 2, 2019 at 12:16 PM Kirk Lund  wrote:
>
>> You should have permission now. Thanks!
>>
>> On Fri, Aug 2, 2019 at 7:32 AM Joris Melchior 
>> wrote:
>>
>> > Hi,
>> >
>> > Can someone provide me with edit permissions on the wiki? Specifically
>> the
>> > tree starting with this link
>> >
>> >
>> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
>> >
>> > My user name is 'joris.melchior'.
>> >
>> > Thanks,
>> >
>> > --
>> > *Joris Melchior *
>> > CF Engineering
>> > Pivotal Toronto
>> > 416 877 5427
>> >
>> > “Programs must be written for people to read, and only incidentally for
>> > machines to execute.” – *Hal Abelson*
>> > <https://en.wikipedia.org/wiki/Hal_Abelson>
>> >
>>
>
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> <https://en.wikipedia.org/wiki/Hal_Abelson>
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: edit permissions on wiki

[Joris Melchior]

Thanks Kirk!

On Fri, Aug 2, 2019 at 12:16 PM Kirk Lund  wrote:

> You should have permission now. Thanks!
>
> On Fri, Aug 2, 2019 at 7:32 AM Joris Melchior 
> wrote:
>
> > Hi,
> >
> > Can someone provide me with edit permissions on the wiki? Specifically
> the
> > tree starting with this link
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
> >
> > My user name is 'joris.melchior'.
> >
> > Thanks,
> >
> > --
> > *Joris Melchior *
> > CF Engineering
> > Pivotal Toronto
> > 416 877 5427
> >
> > “Programs must be written for people to read, and only incidentally for
> > machines to execute.” – *Hal Abelson*
> > <https://en.wikipedia.org/wiki/Hal_Abelson>
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

edit permissions on wiki

[Joris Melchior]

Hi,

Can someone provide me with edit permissions on the wiki? Specifically the
tree starting with this link
https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service

My user name is 'joris.melchior'.

Thanks,

-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: Proposal: For PR reviews and change requests can we have a 7 day turn around on re-reviews?

[Joris Melchior]

+1 on the assignee idea but understand Mark's concerns with inundating
certain people. Is there a way that we can manage the load for reviewers?

On Tue, Jul 9, 2019 at 2:17 PM Mark Hanson  wrote:

> In Github there is a request re-review option. I just learned more about
> that today.
> I think that people should probably be using that option to interact with
> reviewers.
> I do like the assignee idea. I worry that things might pile up on certain
> people,
> but that already kind of happening because certain people are doing more
> reviews.
>
> Thanks,
> Mark
>
>
> > On Jul 9, 2019, at 11:09 AM, Benjamin Ross  wrote:
> >
> > +1
> >
> > I think having an assignee would help set better expectations between
> > committer and reviewer.
> >
> > On Tue, Jul 9, 2019 at 11:05 AM Dan Smith  wrote:
> >
> >> +1
> >>
> >> What do you think about assigning someone to each PR to make sure it
> gets
> >> through the process? We don't currently seem to be using github's
> >> "assignee" field. Committers can make themselves the assignee, but for
> >> contributors we could assign a committer who will make sure the PR gets
> >> reviewed and merged in a timely fashion.
> >>
> >> -Dan
> >>
> >> On Tue, Jul 9, 2019 at 10:34 AM Mark Hanson  wrote:
> >>
> >>> Hi All,
> >>>
> >>> TL;DR
> >>>
> >>> Can we have a norm( preferred, but not required ) of providing feedback
> >>> within seven days of the last checkin to a PR?
> >>>
> >>> Long version
> >>>
> >>> I have just spent a bit of time reviewing PRs that have been open for a
> >>> while and sent some emails to reviewers of the ones that are open the
> >>> longest. In my humble opinion, it would be very nice if we could close
> >> out
> >>> some of the older PRs where the requester has made changes to, but
> >>> reviewers have not re-reviewed. An ideal norm would seem to be 7 days.
> >> One
> >>> might notice that I have a PR that I requested a change on, that I have
> >> not
> >>> provided feedback on, so I am in the same boat...
> >>>
> >>> Thoughts?
> >>>
> >>> Thanks,
> >>> Mark
> >>
>
>

-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: Proposal: For PR reviews and change requests can we have a 7 day turn around on re-reviews?

[Joris Melchior]

+1 I think it will help keep people engaged. It's no fun when your PR is
left to hang and might discourage infrequent/new contributors.

On Tue, Jul 9, 2019 at 1:34 PM Mark Hanson  wrote:

> Hi All,
>
> TL;DR
>
> Can we have a norm( preferred, but not required ) of providing feedback
> within seven days of the last checkin to a PR?
>
> Long version
>
> I have just spent a bit of time reviewing PRs that have been open for a
> while and sent some emails to reviewers of the ones that are open the
> longest. In my humble opinion, it would be very nice if we could close out
> some of the older PRs where the requester has made changes to, but
> reviewers have not re-reviewed. An ideal norm would seem to be 7 days. One
> might notice that I have a PR that I requested a change on, that I have not
> provided feedback on, so I am in the same boat...
>
> Thoughts?
>
> Thanks,
> Mark



-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: need access for commit

[Joris Melchior]

Hi Ashish,

The best way to start is look at the Wiki on How to Contribute
<https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute>.

Any questions you have beyond what you find in the Wiki you can always ask
here.

Cheers, Joris.

On Fri, Jun 14, 2019 at 9:48 PM aashish choudhary <
aashish.choudha...@gmail.com> wrote:

> Hi Team,
>
> I am interested to work on Geode development, bug fixes etc. Let me know
> the process for same.
>
>
> With Best Regards,
> Ashish
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>

Re: [DISCUSS] require reviews before merging a PR

[Joris Melchior]

Thanks Patrick. That's what we're doing currently so we'll continue to do
so :).

On Thu, Jun 6, 2019 at 12:40 PM Patrick Rhomberg 
wrote:

> >
> > I'm not sure it's possible to do this with the "reviewers" field - if
> > someone can figure out how to do this with the github IU, we can at least
> > try filing an ticket with apache infrastructure.
> >
>
> According to their docs [1], "collaborator with write access" is the GitHub
> required criteria to add reviewers.  So, yeah, you have to be a committer.
>
> If you're not a committer, you could always request in your PR comments for
> a committer to add some specific people, should you have any in mind.
>
> Imagination is Change.
> ~Patrick
>
> [1] https://help.github.com/en/articles/requesting-a-pull-request-review
>
> On Thu, Jun 6, 2019 at 9:26 AM Dan Smith  wrote:
>
> > >
> > > Would it be possible to allow people who do not have committer status
> to
> > > request reviewers on a pull request.
> >
> >
> > I'm not sure it's possible to do this with the "reviewers" field - if
> > someone can figure out how to do this with the github IU, we can at least
> > try filing an ticket with apache infrastructure.
> >
> > In the meantime, you can also just add a comment mentioning the people
> > you'd like to review the request. That works for requesting reviews from
> > non-committers as well.
> >
> > -Dan
> >
> > On Thu, Jun 6, 2019 at 9:05 AM Joris Melchior 
> > wrote:
> >
> > > Would it be possible to allow people who do not have committer status
> to
> > > request reviewers on a pull request. In some cases we may know who
> should
> > > take a look at it and in that case making it official by adding these
> > > people to the pull request would be good IMO.
> > >
> > > On Thu, Jun 6, 2019 at 10:26 AM Jens Deppe  wrote:
> > >
> > > > As reviewers we should also feel empowered to request additional
> > > reviewers
> > > > on a PR (perhaps beyond whomever the original submitter may already
> > have
> > > > requested).
> > > >
> > > > I think that, sometimes the complexity of a change prevents someone
> > from
> > > > commenting on just a portion of the change if they do not feel
> > > comfortable
> > > > understanding the scope of the whole change.
> > > >
> > > > Having said that though, once you have 'touched' a PR you should also
> > be
> > > > tracking the PR for additional commits or feedback until it is
> merged.
> > > >
> > > > --Jens
> > > >
> > > > On Wed, Jun 5, 2019 at 11:37 AM Alexander Murmann <
> amurm...@pivotal.io
> > >
> > > > wrote:
> > > >
> > > > > >
> > > > > > If we trust committers, why review at all? Just commit... and we
> > > might
> > > > > > catch a problem, we might not.
> > > > >
> > > > > Honestly that to me would be the ideal state. However, our test
> > > coverage
> > > > > and code quality is nowhere near to allow for that.
> > > > >
> > > > > What I was referring to is different though. I didn't say "trust
> them
> > > to
> > > > > write perfect code", but trust " to decide how much review they
> > require
> > > > to
> > > > > feel comfortable".  In some cases this might mean one review and in
> > > > others
> > > > > maybe two, three or even more and maybe even by very specific
> people.
> > > > >
> > > > > On Wed, Jun 5, 2019 at 11:31 AM Udo Kohlmeyer 
> > wrote:
> > > > >
> > > > > > Alexander, thank you for your response. And yes, change is
> > > > uncomfortable
> > > > > > and in some cases more reviewers would not have caught issues.
> BUT,
> > > > more
> > > > > > people would have seen the code, maybe become more familiar with
> > it,
> > > > > etc...
> > > > > >
> > > > > > I don't say don't trust committers, as I am one. But I also know
> > > that I
> > > > > > mistakes are made regardless of intent. If we trust committers,
> why
> > > > > > review at all? Just commit... and we might catch a problem, we
> > might
> > > > not.
> > > > > >
> > > > > >

Re: [DISCUSS] require reviews before merging a PR

[Joris Melchior]

 outside of the focus area. This will only promote a
> > > >> broader understanding of the project codebase. I also support the
> > notion
> > > >> of a pair/mobbing reviews, if a reviewer does not understand the
> > problem
> > > >> area enough to effectively review, OR where the solution is not
> > > apparent.
> > > >>
> > > >> --Udo
> > > >>
> > > >> On 6/4/19 16:49, Kirk Lund wrote:
> > > >>> I'm -1 for requiring N reviews before merging a commit.
> > > >>>
> > > >>> Overall, I support Lazy Consensus. If I post a PR that fixes the
> > > >> flakiness
> > > >>> in a test, the precheckin jobs prove it, and it sits there for 2
> > weeks
> > > >>> without reviews, then I favor merging it in at that point without
> any
> > > >>> reviews. I'm not going to chase people around or spam the dev list
> > over
> > > >> and
> > > >>> over asking for reviews. Nothing in the Apache Way says you have to
> > do
> > > >>> reviews before committing -- some projects prefer "commit then
> > review"
> > > >>> instead of "review then commit". You can always look at the code
> > > someone
> > > >>> changed and you can always change it further or revert it.
> > > >>>
> > > >>> I think if we don't trust our committers then we have a bigger
> > systemic
> > > >>> problem that becoming more strict about PR reviews isn not going to
> > > fix.
> > > >>>
> > > >>> Overall, I also favor pairing/mobbing over reviews. Without being
> > there
> > > >>> during the work, a reviewer lacks the context to understand why it
> > was
> > > >> done
> > > >>> the way it was done.
> > > >>>
> > > >>> If we cannot establish or maintain trust in committers, then I
> think
> > we
> > > >>> should remove committer status from everyone and start over as a
> > > project,
> > > >>> proposing and accepting one committer at a time.
> > > >>>
> > > >>> Instead of constraints on reviews, I would prefer to establish new
> > > >> criteria
> > > >>> for coding such as:
> > > >>> 1) all classes touched in a PR must have a unit test created if
> none
> > > >> exists
> > > >>> 2) all code touched in a PR must have unit test coverage (and
> > possibly
> > > >>> integration test coverage) specific to the changes
> > > >>> 3) all new classes must have full unit test coverage
> > > >>> 4) all code touched in a PR must follow clean code principles
> (which
> > > >> would
> > > >>> obviously need defining on the wiki)
> > > >>>
> > > >>> Then it becomes the responsibility of the author(s) and
> committer(s)
> > of
> > > >>> that PR to ensure that the code and the PR follows the project's
> > > criteria
> > > >>> for code quality and test coverage. It also becomes easier to
> measure
> > > the
> > > >>> PRs of a non-committer to determine if we think they would make a
> > good
> > > >>> committer (for example, do they adhere to clean code quality and
> unit
> > > >>> testing with mocks? -- along with any other criteria).
> > > >>>
> > > >>> On Thu, May 30, 2019 at 3:51 PM Owen Nichols 
> > > >> wrote:
> > > >>>> It seems common for Geode PRs to get merged with only a single
> green
> > > >>>> checkmark in GitHub.
> > > >>>>
> > > >>>> According to https://www.apache.org/foundation/voting.html we
> > should
> > > >> not
> > > >>>> be merging PRs with fewer than 3 green checkmarks.
> > > >>>>
> > > >>>> Consensus is a fundamental value in doing things The Apache Way.
> A
> > > >> single
> > > >>>> +1 is not consensus.  Since we’re currently discussing what it
> takes
> > > to
> > > >>>> become a committer and what standards a committer is expected to
> > > >> uphold, it
> > > >>>> seems like a good time to review this policy.
> > > >>>>
> > > >>>> GitHub can be configured to require N reviews before a commit can
> be
> > > >>>> merged.  Should we enable this feature?
> > > >>>>
> > > >>>> -Owen
> > > >>>> VOTES ON CODE MODIFICATION <
> > > >>>>
> > > >>
> > >
> https://www.apache.org/foundation/voting.html#votes-on-code-modification
> > >
> > > >>>> For code-modification votes, +1 votes are in favour of the
> proposal,
> > > but
> > > >>>> -1 votes are vetos <
> > > https://www.apache.org/foundation/voting.html#Veto>
> > > >>>> and kill the proposal dead until all vetoers withdraw their -1
> > votes.
> > > >>>>
> > > >>>> Unless a vote has been declared as using lazy consensus <
> > > >>>> https://www.apache.org/foundation/voting.html#LazyConsensus> ,
> > three
> > > +1
> > > >>>> votes are required for a code-modification proposal to pass.
> > > >>>>
> > > >>>> Whole numbers are recommended for this type of vote, as the
> opinion
> > > >> being
> > > >>>> expressed is Boolean: 'I approve/do not approve of this change.'
> > > >>>>
> > > >>>>
> > > >>>> CONSENSUS GAUGING THROUGH SILENCE <
> > > >>>> https://www.apache.org/foundation/voting.html#LazyConsensus>
> > > >>>> An alternative to voting that is sometimes used to measure the
> > > >>>> acceptability of something is the concept of lazy consensus <
> > > >>>> https://www.apache.org/foundation/glossary.html#LazyConsensus>.
> > > >>>>
> > > >>>> Lazy consensus is simply an announcement of 'silence gives
> assent.’
> > > When
> > > >>>> someone wants to determine the sense of the community this way, it
> > > >> might do
> > > >>>> so with a mail message such as:
> > > >>>> "The patch below fixes GEODE-12345; if no-one objects within three
> > > days,
> > > >>>> I'll assume lazy consensus and commit it."
> > > >>>>
> > > >>>> Lazy consensus cannot be used on projects that enforce a
> > > >>>> review-then-commit <
> > > >>>> https://www.apache.org/foundation/glossary.html#ReviewThenCommit>
> > > >> policy.
> > > >>>>
> > > >>>>
> > >
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>