+1
-Original Message-
From: Owen Nichols
Sent: Thursday, July 9, 2020 9:39 PM
To: dev@geode.apache.org
Subject: [VOTE] change Default branch for geode-examples to 'develop'
A fresh checkout of geode and all but one geode- repos checks
out develop as the Default branch.
The lone except
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
Even for smaller changes that only need a PR (not a whole RFC) it's a good
habit to include some detail about the use cases. Both reviewers and future
committers benefit from thoughtful commit messages and PR descriptions that
mention *why*, not just *what* was changed.
On 7/9/20, 6:15 PM
+1
"Adding a section" (Udo's language) for Use Cases is a positive way of
encouraging RFC authors to provide that material, without saying it's an
iron-clad requirement. Exactly the right way to do it. Commenters can
request more detail when they review it.
On Thu, Jul 9, 2020 at 4:31 PM Donal Ev
Udo,
You're right, and I agree wholeheartedly with your proposal to give RFCs enough
time and enough context for proper review by as many people as possible. Sorry
if that didn't come across in my original reply.
From: Udo Kohlmeyer
Sent: Thursday, July 9, 2020
Donal,
You have very valid points. All of which only pertain to the “HOW” or “IF” an
RFC should be written. This being a completely different problem to what I’m
proposing. I’m willing to comment on any proposal that were to address these
issues. :)
This proposal is largely aimed at, if there
+1
From: Patrick Johnson
Sent: Thursday, July 9, 2020 1:31 PM
To: dev@geode.apache.org
Subject: Re: [Proposal] - RFC etiquette
+1
> On Jul 9, 2020, at 1:18 PM, Udo Kohlmeyer wrote:
>
> Hi there Geode Dev's
>
> I would like to propose the following changes to th
While I definitely approve of these proposals in principle (especially the "Use
Cases" section, which could really help facilitate discussions around other
potential solutions/approaches to a problem), the fact that the RFC process is
still entirely voluntary on the part of the contributor(s) wh
+1
> On Jul 9, 2020, at 1:18 PM, Udo Kohlmeyer wrote:
>
> Hi there Geode Dev's
>
> I would like to propose the following changes to the RFC process that we have
> in place at the moment.
>
> 1. All submitted RFC’s will provide a minimum 2 week review period. This is
> to allow the communit
Hi there Geode Dev's
I would like to propose the following changes to the RFC process that we have
in place at the moment.
1. All submitted RFC’s will provide a minimum 2 week review period. This is
to allow the community to review the RFC in a reasonable timeframe. If we rush
things, we wi
Thanks, Bruce.
On Thu, Jul 9, 2020 at 10:32 AM Bruce Schuchardt wrote:
> Since I had 3 +1’s I merged the change to support/1.13
>
> From: Bruce Schuchardt
> Date: Thursday, July 9, 2020 at 8:00 AM
> To: "dev@geode.apache.org"
> Subject: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
>
Since I had 3 +1’s I merged the change to support/1.13
From: Bruce Schuchardt
Date: Thursday, July 9, 2020 at 8:00 AM
To: "dev@geode.apache.org"
Subject: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
There are reports that SSL performance is off on the support/1.13 branch with
respect
+1
De: Donal Evans
Enviado: jueves, 9 de julio de 2020 17:50
Para: dev@geode.apache.org
Asunto: Re: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
+1
From: Bruce Schuchardt
Sent: Thursday, July 9, 2020 8:00 AM
To: dev@geo
+1
From: Bruce Schuchardt
Sent: Thursday, July 9, 2020 8:00 AM
To: dev@geode.apache.org
Subject: [PROPOSAL] backport fix for GEODE-8020 to support/1.13
There are reports that SSL performance is off on the support/1.13 branch with
respect to the support/1.12 bran
While it's really late in the branch lifecycle and we should have shipped a
month ago, performance degradations are a no-go
+!
On Thu, Jul 9, 2020 at 8:00 AM Bruce Schuchardt wrote:
> There are reports that SSL performance is off on the support/1.13 branch
> with respect to the support/1.12 bra
There are reports that SSL performance is off on the support/1.13 branch with
respect to the support/1.12 branch, but performance on develop okay. The only
communications changes in develop that aren’t in 1.13 are those that fixed this
long-standing bug, so I’d like to backport it to the 1.13
Hi Alexander,
Yes, sure. I am extending the deadline for comments to next Thursday, July the
16th.
Cheers,
Alberto G.
From: Alexander Murmann
Sent: Thursday, July 9, 2020 1:42 AM
To: dev@geode.apache.org
Subject: Re: [DISCUSS] RFC - Avoid the queueing of dropp
Hi Eric,
I agree that the only case in which the memory issue may occur is when all
gateway senders instances are stopped. And that is what the solution proposed
in the RFC is targeted at, and also that is why the stop gateway sender command
is intended to be updated to fix the issue.
Note tha
18 matches
Mail list logo
