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

[Dave Barnes]

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

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

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

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

[Alexander Murmann]

+1

On Mon, Aug 3, 2020 at 4:47 PM Jianxia Chen  wrote:

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

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

[Jianxia Chen]

+1

On Mon, Aug 3, 2020 at 4:13 PM Darrel Schneider  wrote:

> GEODE-6564 is a memory leak that has impacted users so it would be good to
> have it in 1.13. It has a simple, low risk, fix.
>

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

[Donal Evans]

+1

From: Darrel Schneider 
Sent: Monday, August 3, 2020 4:05 PM
To: dev@geode.apache.org 
Subject: [PROPOSAL] backport GEODE-6564 to support/1.13

GEODE-6564 is a memory leak that has impacted users so it would be good to have 
it in 1.13. It has a simple, low risk, fix.

[PROPOSAL] backport GEODE-6564 to support/1.13

[Darrel Schneider]

GEODE-6564 is a memory leak that has impacted users so it would be good to have 
it in 1.13. It has a simple, low risk, fix.

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

[Raymond Ingles]

+1

On 7/30/20, 3:21 AM, "Owen Nichols"  wrote:

Tags in the rel/ namespace should be created by the Geode release manager 
as part of an official Geode release only, yet we seem to have some extra ones 
somehow.
Further, I don't see any value in keeping RC tags forever long after the 
release is final.

Please vote +1 in favor of trimming the current list of 110 tags down to 20 
to make it nice and easy for newcomers (as well as the rest of us) to find and 
checkout a specific version of Geode; otherwise vote -1.  If the majority vote 
is +1 at 3PM PDT Fri Aug 7, I will proceed to archive and delete the 90 
unnecessary tags as detailed below.

I propose to KEEP only the following tags, corresponding to official Geode 
releases:

rel/v1.12.0
rel/v1.11.0
rel/v1.10.0
rel/v1.9.2
rel/v1.9.1
rel/v1.9.0
rel/v1.8.0
rel/v1.7.0
rel/v1.6.0
rel/v1.5.0
rel/v1.4.0
rel/v1.3.0
rel/v1.2.1
rel/v1.2.0
rel/v1.1.1
rel/v1.1.0
rel/v1.0.0-incubating
rel/v1.0.0-incubating.M3
rel/v1.0.0-incubating.M2
rel/v1.0.0-incubating.M1

I propose a one-time cleanup to DELETE all other tags, specifically:

develop/highwater
modules-pre-merge
rel/v1.0.0-incubating.M1.RC1
rel/v1.0.0-incubating.M1.RC2
rel/v1.0.0-incubating.M2.RC1
rel/v1.0.0-incubating.M2.RC2
rel/v1.0.0-incubating.M3.RC1
rel/v1.0.0-incubating.M3.RC2
rel/v1.0.0-incubating.M3.RC3
rel/v1.0.0-incubating.M3.RC4
rel/v1.0.0-incubating.M3.RC5
rel/v1.0.0-incubating.M3.RC6
rel/v1.0.0-incubating.M3.RC7
rel/v1.0.0-incubating.RC1
rel/v1.0.0-incubating.RC2
rel/v1.1.0.RC1
rel/v1.1.0.RC2
rel/v1.1.0manualrev-2017-02-16
rel/v1.1.0manualrev-2017-10-19
rel/v1.1.1.RC1
rel/v1.1.1.RC2
rel/v1.10.0.1
rel/v1.10.0.1.RC1
rel/v1.10.0.2
rel/v1.10.0.RC1
rel/v1.10.0.RC2
rel/v1.11.0.1
rel/v1.11.0.2
rel/v1.11.0.23755
rel/v1.11.0.23755_2
rel/v1.11.0.23755_3
rel/v1.11.0.3
rel/v1.11.0.4
rel/v1.11.0.5
rel/v1.11.0.6
rel/v1.11.0.7
rel/v1.11.0.7565
rel/v1.11.0.8
rel/v1.11.0.RC1
rel/v1.11.0.RC2
rel/v1.11.0.RC3
rel/v1.11.0.RC4
rel/v1.12.0.1
rel/v1.12.0.1234
rel/v1.12.0.2
rel/v1.12.0.23755
rel/v1.12.0.3
rel/v1.12.0.4
rel/v1.12.0.5
rel/v1.12.0.6
rel/v1.12.0.RC1
rel/v1.12.0.RC2
rel/v1.12.0.RC3
rel/v1.12.0.RC4
rel/v1.14.0.23755
rel/v1.2.0.RC1
rel/v1.2.0.RC2
rel/v1.2.1.RC1
rel/v1.2.1.RC2
rel/v1.2.1.RC3
rel/v1.2.1.RC4
rel/v1.2.1manualrev-2017-10-19
rel/v1.3.0.RC1
rel/v1.3.0.RC2
rel/v1.3.0.RC3
rel/v1.3.0.RC4
rel/v1.4.0.RC1
rel/v1.4.0.RC2
rel/v1.5.0.RC1
rel/v1.5.0.RC2
rel/v1.6.0.RC1
rel/v1.7.0.RC1
rel/v1.7.0.RC2
rel/v1.8.0.RC1
rel/v1.8.0.RC2
rel/v1.9.0.1
rel/v1.9.0.1.RC1
rel/v1.9.0.2
rel/v1.9.0.RC1
rel/v1.9.0.RC2
rel/v1.9.0.RC3
rel/v1.9.0.RC4
rel/v1.9.1-nordix
rel/v1.9.1.RC1
rel/v1.9.1.RC2
rel/v1.9.1.RC3
rel/v1.9.2.RC1
sga2-core
v1.1.0manualrev-2017-10-19
v9.0.0-beta.1

Re: Request wiki access

[Dan Smith]

Done. You should have access now.

From: Patrick Johnson 
Sent: Monday, August 3, 2020 1:37 PM
To: dev@geode.apache.org 
Subject: Request wiki access

Hi,

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

Thanks,
Patrick Johnson

Request wiki access

[Patrick Johnson]

Hi,

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

Thanks,
Patrick Johnson

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

[Mark Bretl]

I would vote for 1.13 since that is still up for release, however, I do not
see a need for 1.12 as it is not a critical issue.

--Mark

On Mon, Aug 3, 2020 at 9:00 AM Dave Barnes  wrote:

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

Re: [PROPOSAL] Postpone Geode 1.14

[Mark Hanson]

+1 to Michael's suggestion.

On 7/31/20, 5:38 PM, "Michael Oleske"  wrote:

Is there plans as a community to do a postmortem or retrospective around 
why the release is taking so long?  If there is an understanding of events that 
occurred to cause the long delay of Geode 1.13 to be released, that would help 
inform decisions if processes should change or if the release cadence should 
change (or both!)

-michael

From: Xiaojian Zhou 
Sent: Thursday, July 30, 2020 13:47
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Postpone Geode 1.14

+1

On 7/29/20, 1:35 PM, "Mark Bretl"  wrote:

+1

Should we need to drop a line to user@geode or is communicating on this
list enough once decided?

--Mark

On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior  
wrote:

> +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: [PROPOSAL] one-time cleanup of stray and obsolete tags in geode repo

[Anthony Baker]

+1 with the exception of sga2-core.  IIRC that is related to a code donation 
and should be preserved.  All other tags you’ve listed seem reasonable to 
remove.  I believe that tags in the rel/* are protected and will require an 
INFRA ticket.

Anthony


> On Jul 30, 2020, at 12:21 AM, Owen Nichols  wrote:
> 
> Tags in the rel/ namespace should be created by the Geode release manager as 
> part of an official Geode release only, yet we seem to have some extra ones 
> somehow.
> Further, I don't see any value in keeping RC tags forever long after the 
> release is final.
> 
> Please vote +1 in favor of trimming the current list of 110 tags down to 20 
> to make it nice and easy for newcomers (as well as the rest of us) to find 
> and checkout a specific version of Geode; otherwise vote -1.  If the majority 
> vote is +1 at 3PM PDT Fri Aug 7, I will proceed to archive and delete the 90 
> unnecessary tags as detailed below.
> 
> I propose to KEEP only the following tags, corresponding to official Geode 
> releases:
> 
> rel/v1.12.0
> rel/v1.11.0
> rel/v1.10.0
> rel/v1.9.2
> rel/v1.9.1
> rel/v1.9.0
> rel/v1.8.0
> rel/v1.7.0
> rel/v1.6.0
> rel/v1.5.0
> rel/v1.4.0
> rel/v1.3.0
> rel/v1.2.1
> rel/v1.2.0
> rel/v1.1.1
> rel/v1.1.0
> rel/v1.0.0-incubating
> rel/v1.0.0-incubating.M3
> rel/v1.0.0-incubating.M2
> rel/v1.0.0-incubating.M1
> 
> I propose a one-time cleanup to DELETE all other tags, specifically:
> 
> develop/highwater
> modules-pre-merge
> rel/v1.0.0-incubating.M1.RC1
> rel/v1.0.0-incubating.M1.RC2
> rel/v1.0.0-incubating.M2.RC1
> rel/v1.0.0-incubating.M2.RC2
> rel/v1.0.0-incubating.M3.RC1
> rel/v1.0.0-incubating.M3.RC2
> rel/v1.0.0-incubating.M3.RC3
> rel/v1.0.0-incubating.M3.RC4
> rel/v1.0.0-incubating.M3.RC5
> rel/v1.0.0-incubating.M3.RC6
> rel/v1.0.0-incubating.M3.RC7
> rel/v1.0.0-incubating.RC1
> rel/v1.0.0-incubating.RC2
> rel/v1.1.0.RC1
> rel/v1.1.0.RC2
> rel/v1.1.0manualrev-2017-02-16
> rel/v1.1.0manualrev-2017-10-19
> rel/v1.1.1.RC1
> rel/v1.1.1.RC2
> rel/v1.10.0.1
> rel/v1.10.0.1.RC1
> rel/v1.10.0.2
> rel/v1.10.0.RC1
> rel/v1.10.0.RC2
> rel/v1.11.0.1
> rel/v1.11.0.2
> rel/v1.11.0.23755
> rel/v1.11.0.23755_2
> rel/v1.11.0.23755_3
> rel/v1.11.0.3
> rel/v1.11.0.4
> rel/v1.11.0.5
> rel/v1.11.0.6
> rel/v1.11.0.7
> rel/v1.11.0.7565
> rel/v1.11.0.8
> rel/v1.11.0.RC1
> rel/v1.11.0.RC2
> rel/v1.11.0.RC3
> rel/v1.11.0.RC4
> rel/v1.12.0.1
> rel/v1.12.0.1234
> rel/v1.12.0.2
> rel/v1.12.0.23755
> rel/v1.12.0.3
> rel/v1.12.0.4
> rel/v1.12.0.5
> rel/v1.12.0.6
> rel/v1.12.0.RC1
> rel/v1.12.0.RC2
> rel/v1.12.0.RC3
> rel/v1.12.0.RC4
> rel/v1.14.0.23755
> rel/v1.2.0.RC1
> rel/v1.2.0.RC2
> rel/v1.2.1.RC1
> rel/v1.2.1.RC2
> rel/v1.2.1.RC3
> rel/v1.2.1.RC4
> rel/v1.2.1manualrev-2017-10-19
> rel/v1.3.0.RC1
> rel/v1.3.0.RC2
> rel/v1.3.0.RC3
> rel/v1.3.0.RC4
> rel/v1.4.0.RC1
> rel/v1.4.0.RC2
> rel/v1.5.0.RC1
> rel/v1.5.0.RC2
> rel/v1.6.0.RC1
> rel/v1.7.0.RC1
> rel/v1.7.0.RC2
> rel/v1.8.0.RC1
> rel/v1.8.0.RC2
> rel/v1.9.0.1
> rel/v1.9.0.1.RC1
> rel/v1.9.0.2
> rel/v1.9.0.RC1
> rel/v1.9.0.RC2
> rel/v1.9.0.RC3
> rel/v1.9.0.RC4
> rel/v1.9.1-nordix
> rel/v1.9.1.RC1
> rel/v1.9.1.RC2
> rel/v1.9.1.RC3
> rel/v1.9.2.RC1
> sga2-core
> v1.1.0manualrev-2017-10-19
> v9.0.0-beta.1

[DISCUSS] proposal for WAN support of an ingress proxy

[Bruce Schuchardt]

In some environments it’s expensive to provide all server machines with 
externally-resolvable hostnames.  We recently added support for “off platform” 
clients to access servers through an ingress 
proxy
  for this type of environment.  I’m proposing to do the same for inter-cluster 
(“WAN”) communications.

https://cwiki.apache.org/confluence/display/GEODE/WAN+Configuration+for+an+Ingress+Proxy

This improvement will allow one cluster to forward events to another cluster 
even though the other cluster’s machines do not have resolvable hostnames.  
Communications will go through a Proxy process hosted in the other cluster with 
a resolvable hostname.  The user-visible changes in this proposal are small, 
changing the “remote-locators” setting to allow for a new syntax.

I’m not proposing to implement a Proxy.  There are numerous Proxy products 
available that could fit into this scheme such as HAProxy, Envoy, and NGIX.

I will probably start with an SNI-based implementation and leverage work 
already done for client/server communications.

Please provide feedback by the end of 14 august.  Thanks!

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

[Dave Barnes]

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

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

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

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

[Mario Kevo]

+1

Šalje: Dave Barnes 
Poslano: 3. kolovoza 2020. 16:56
Prima: dev@geode.apache.org 
Predmet: Re: Proposal to backport GEODE-8395 (gfsh help banner) to support 
branches

+1


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

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

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

[Dave Barnes]

+1


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

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