Re: [PROPOSAL] bring GEODE-8091 to support branches

[Dave Barnes]

..and 1.12.


On Mon, May 11, 2020 at 6:09 PM Dave Barnes  wrote:

> OK, Jinmei. Three of those plus-ones is the magic minimum.
> Please add your change to 1.13.
> Dave
>
>
> On Mon, May 11, 2020 at 4:20 PM Donal Evans  wrote:
>
>> +1
>>
>> On Mon, May 11, 2020 at 4:11 PM Anilkumar Gingade 
>> wrote:
>>
>> > +1
>> >
>> > On Mon, May 11, 2020 at 4:10 PM Jinmei Liao  wrote:
>> >
>> > > https://issues.apache.org/jira/browse/GEODE-8091
>> > >
>> > > We've had users that were trying to use the
>> > > "--load-cluster-configuration-from-dir=true" when starting up a
>> locator
>> > > with a security manager and came across this failure on Geode1.12 and
>> > would
>> > > this to be fixed. Can I get a few +1s to port this back to the support
>> > > branches?
>> > >
>> > >
>> > > --
>> > > Cheers
>> > >
>> > > Jinmei
>> > >
>> >
>>
>

Re: [PROPOSAL] bring GEODE-8091 to support branches

[Dave Barnes]

OK, Jinmei. Three of those plus-ones is the magic minimum.
Please add your change to 1.13.
Dave


On Mon, May 11, 2020 at 4:20 PM Donal Evans  wrote:

> +1
>
> On Mon, May 11, 2020 at 4:11 PM Anilkumar Gingade 
> wrote:
>
> > +1
> >
> > On Mon, May 11, 2020 at 4:10 PM Jinmei Liao  wrote:
> >
> > > https://issues.apache.org/jira/browse/GEODE-8091
> > >
> > > We've had users that were trying to use the
> > > "--load-cluster-configuration-from-dir=true" when starting up a locator
> > > with a security manager and came across this failure on Geode1.12 and
> > would
> > > this to be fixed. Can I get a few +1s to port this back to the support
> > > branches?
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>

Re: [PROPOSAL] bring GEODE-8091 to support branches

[Donal Evans]

+1

On Mon, May 11, 2020 at 4:11 PM Anilkumar Gingade 
wrote:

> +1
>
> On Mon, May 11, 2020 at 4:10 PM Jinmei Liao  wrote:
>
> > https://issues.apache.org/jira/browse/GEODE-8091
> >
> > We've had users that were trying to use the
> > "--load-cluster-configuration-from-dir=true" when starting up a locator
> > with a security manager and came across this failure on Geode1.12 and
> would
> > this to be fixed. Can I get a few +1s to port this back to the support
> > branches?
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: [PROPOSAL] bring GEODE-8091 to support branches

[Anilkumar Gingade]

+1

On Mon, May 11, 2020 at 4:10 PM Jinmei Liao  wrote:

> https://issues.apache.org/jira/browse/GEODE-8091
>
> We've had users that were trying to use the
> "--load-cluster-configuration-from-dir=true" when starting up a locator
> with a security manager and came across this failure on Geode1.12 and would
> this to be fixed. Can I get a few +1s to port this back to the support
> branches?
>
>
> --
> Cheers
>
> Jinmei
>

Re: [PROPOSAL] bring GEODE-8091 to support branches

[Owen Nichols]

+1

> On May 11, 2020, at 4:09 PM, Jinmei Liao  wrote:
> 
> https://issues.apache.org/jira/browse/GEODE-8091
> 
> We've had users that were trying to use the
> "--load-cluster-configuration-from-dir=true" when starting up a locator
> with a security manager and came across this failure on Geode1.12 and would
> this to be fixed. Can I get a few +1s to port this back to the support
> branches?
> 
> 
> -- 
> Cheers
> 
> Jinmei

[PROPOSAL] bring GEODE-8091 to support branches

[Jinmei Liao]

https://issues.apache.org/jira/browse/GEODE-8091

We've had users that were trying to use the
"--load-cluster-configuration-from-dir=true" when starting up a locator
with a security manager and came across this failure on Geode1.12 and would
this to be fixed. Can I get a few +1s to port this back to the support
branches?


-- 
Cheers

Jinmei

Re: Discussion - Change Public API Before Initial Release

[Jacob Barrett]

For closure this has been cherry-picked into support/1.13. 

Thanks,
Jake


> On May 11, 2020, at 10:47 AM, Dave Barnes  wrote:
> 
> Plenty of votes, go ahead, Jake, and add this to the support/1.13 branch.
> 
> On Mon, May 11, 2020 at 8:36 AM Joris Melchior  wrote:
> 
>> +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: Our May 2020 report to the board

[Nabarun Nag]

Thank you Dave for putting together the report !! Thank you all for putting 
together those amazing blogs and all the Apache Geode contributors.

Regards
Naba



Get Outlook for iOS

From: Karen Miller 
Sent: Monday, May 11, 2020 2:30:35 PM
To: dev@geode.apache.org 
Subject: Our May 2020 report to the board

Apache Geode developers, please thank Dave Barnes for putting together
the May 2020 board report that I filed today.  Here is the contents of the
report:

## Description:
The mission of Apache Geode is the creation and maintenance of software
related to a data management platform that provides real-time, consistent
access to data-intensive applications throughout widely distributed cloud
architectures.

## Issues:
296 issues opened in JIRA, past quarter (-16% decrease) 226 issues closed in
JIRA, past quarter (-26% decrease)

Given the worldwide impact of the Covid-19 pandemic disruption to our
community's work routines, we feel these figures, though lower than those of
the previous reporting period, reveal an engaged and productive development
community.

## Membership Data:
Apache Geode was founded 2016-11-15 (3 years ago)
There are currently 109 committers and 54 PMC members in this project.
The Committer-to-PMC ratio is roughly 7:4.

Community changes, past quarter:
- Alexander Murmann was added to the PMC on 2020-03-26
- Joris Melchior was added to the PMC on 2020-03-22
- Mark Hanson was added to the PMC on 2020-03-26
- Joris Melchior was added as committer on 2020-03-19
- Mario Kevo was added as committer on 2020-03-23

## Project Activity:
- version 1.12.0 was released on 2020-03-31 This release included improvements
  to the management REST API, .NET and C++ native clients, client/server
  security, and error recovery.
- version 1.13 release is under way

## Community Health:
The Apache Geode dev and issues mailing lists both experienced upticks in
discussion traffic, up 15% and 44%, respectively, in Q1.

The number of JIRA tickets opened and closed remained robust, though down 16%
and 26%, respectively, from the previous quarter. Points of emphasis included
error recovery improvements, API extensions, and compatibility to accommodate
containers such as Kubernetes and BOSH.

In February, community member Jason Huynh posted an article entitled "Apache
Geode as a remote Gradle Build Cache"
(https://jasonhuynh.blogspot.com/2020/02/apache-geode-as-remote-gradle-build.html).
In March, Jason posted "Publishing Apache Geode Metrics to Wavefront"
(https://medium.com/@huynhja/
publishing-apache-geode-metrics-to-wavefront-6e9a6cf5992b) along with an
accompanying video (https://youtu.be/BDZh-FLkDTg).

Community member Juan Jose Ramos posted an article in March entitled "Geode
Distributed Sequences"
(https://medium.com/@jujoramos/geode-distributed-sequences-12626251d5e3), and
another in April, "The Command Region Pattern"
(https://medium.com/@jujoramos/the-command-region-pattern-14bc49594eca).

In April, community member Barry Oglesby published "Remove Unused PdxTypes
from an Apache Geode Distributed System"
(https://medium.com/@boglesby_2508/remove-unused-pdxtypes-from-an-apache-geode-distributed-system-5a4f0e199e34).

Our May 2020 report to the board

[Karen Miller]

Apache Geode developers, please thank Dave Barnes for putting together
the May 2020 board report that I filed today.  Here is the contents of the
report:

## Description:
The mission of Apache Geode is the creation and maintenance of software
related to a data management platform that provides real-time, consistent
access to data-intensive applications throughout widely distributed cloud
architectures.

## Issues:
296 issues opened in JIRA, past quarter (-16% decrease) 226 issues closed in
JIRA, past quarter (-26% decrease)

Given the worldwide impact of the Covid-19 pandemic disruption to our
community's work routines, we feel these figures, though lower than those of
the previous reporting period, reveal an engaged and productive development
community.

## Membership Data:
Apache Geode was founded 2016-11-15 (3 years ago)
There are currently 109 committers and 54 PMC members in this project.
The Committer-to-PMC ratio is roughly 7:4.

Community changes, past quarter:
- Alexander Murmann was added to the PMC on 2020-03-26
- Joris Melchior was added to the PMC on 2020-03-22
- Mark Hanson was added to the PMC on 2020-03-26
- Joris Melchior was added as committer on 2020-03-19
- Mario Kevo was added as committer on 2020-03-23

## Project Activity:
- version 1.12.0 was released on 2020-03-31 This release included improvements
  to the management REST API, .NET and C++ native clients, client/server
  security, and error recovery.
- version 1.13 release is under way

## Community Health:
The Apache Geode dev and issues mailing lists both experienced upticks in
discussion traffic, up 15% and 44%, respectively, in Q1.

The number of JIRA tickets opened and closed remained robust, though down 16%
and 26%, respectively, from the previous quarter. Points of emphasis included
error recovery improvements, API extensions, and compatibility to accommodate
containers such as Kubernetes and BOSH.

In February, community member Jason Huynh posted an article entitled "Apache
Geode as a remote Gradle Build Cache"
(https://jasonhuynh.blogspot.com/2020/02/apache-geode-as-remote-gradle-build.html).
In March, Jason posted "Publishing Apache Geode Metrics to Wavefront"
(https://medium.com/@huynhja/
publishing-apache-geode-metrics-to-wavefront-6e9a6cf5992b) along with an
accompanying video (https://youtu.be/BDZh-FLkDTg).

Community member Juan Jose Ramos posted an article in March entitled "Geode
Distributed Sequences"
(https://medium.com/@jujoramos/geode-distributed-sequences-12626251d5e3), and
another in April, "The Command Region Pattern"
(https://medium.com/@jujoramos/the-command-region-pattern-14bc49594eca).

In April, community member Barry Oglesby published "Remove Unused PdxTypes
from an Apache Geode Distributed System"
(https://medium.com/@boglesby_2508/remove-unused-pdxtypes-from-an-apache-geode-distributed-system-5a4f0e199e34).

Re: Proposal to bring GEODE-8016 to support branches

[Owen Nichols]

Thanks!  Change has been backported to 1.13 and 1.12.  Downstream projects can 
now use the new version selector syntax consistently across 1.12, 1.13, and 
1.14.  To recap, that means if you are a downstream project and you want the 
latest “nightly build” (formerly -SNAPSHOT) of Geode 1.12, 1.13, or 1.14 please 
use the maven repo url:

https://maven.apachegeode-ci.info/snapshots 


And change your geode- dependency version to a non-snapshot notation 
such as:

Gradle:
1.+ //latest 1.y.x
1.14.+//latest 1.14.x
1.13.+//latest 1.13.x
1.12.+//latest 1.12.x

Maven:
[1,2)  //latest 1.y.x
[1.14,1.15)//latest 1.14.x
[1.13,1.14)//latest 1.13.x
[1.12,1.13)//latest 1.12.x

> On May 11, 2020, at 10:49 AM, Dave Barnes  wrote:
> 
> Looks good, Owen. Go ahead and add this to 1.13.
> 
> On Mon, May 11, 2020 at 9:49 AM Robert Houghton 
> wrote:
> 
>> Yes please! +1
>> 
>> On Mon, May 11, 2020 at 2:46 AM Darrel Schneider 
>> wrote:
>> 
>>> +1
>>> 
>>> On Sun, May 10, 2020 at 10:05 PM Dick Cavender 
>>> wrote:
>>> 
 +1
 
 On Sat, May 9, 2020 at 6:42 PM Owen Nichols 
>> wrote:
 
> Last week develop was successfully migrated from publishing -SNAPSHOT
>>> to
> publishing -build.nnn, as discussed on the dev list.
> 
> I propose that we bring the same change to support/1.13 and
>>> support/1.12
> for consistency.  This will allow downstream projects to change over
>>> the
> new model “everywhere" rather than having to maintain support for
>> both
 ways
> and constantly try to remember which branches do it which way.
> 
> The specific changes to be cherry-picked from develop are a4c8b <
> 
 
>>> 
>> https://github.com/apache/geode/commit/a4c8b9ed8bbea584f798164fa5308d236e9b6048
> 
> and 39c52 <
> 
 
>>> 
>> https://github.com/apache/geode/commit/39c522e340196cb30d55d81d93c63028938cd782
> .
> I have prepared PR #5089 
>>> for
> support/1.13 and PR #5090 >> 
 for
> support/1.12 due to the version number differences on each branch.
 
>>> 
>> 

Re: Proposal to bring GEODE-8016 to support branches

[Dave Barnes]

Looks good, Owen. Go ahead and add this to 1.13.

On Mon, May 11, 2020 at 9:49 AM Robert Houghton 
wrote:

> Yes please! +1
>
> On Mon, May 11, 2020 at 2:46 AM Darrel Schneider 
> wrote:
>
> > +1
> >
> > On Sun, May 10, 2020 at 10:05 PM Dick Cavender 
> > wrote:
> >
> > > +1
> > >
> > > On Sat, May 9, 2020 at 6:42 PM Owen Nichols 
> wrote:
> > >
> > > > Last week develop was successfully migrated from publishing -SNAPSHOT
> > to
> > > > publishing -build.nnn, as discussed on the dev list.
> > > >
> > > > I propose that we bring the same change to support/1.13 and
> > support/1.12
> > > > for consistency.  This will allow downstream projects to change over
> > the
> > > > new model “everywhere" rather than having to maintain support for
> both
> > > ways
> > > > and constantly try to remember which branches do it which way.
> > > >
> > > > The specific changes to be cherry-picked from develop are a4c8b <
> > > >
> > >
> >
> https://github.com/apache/geode/commit/a4c8b9ed8bbea584f798164fa5308d236e9b6048
> > > >
> > > > and 39c52 <
> > > >
> > >
> >
> https://github.com/apache/geode/commit/39c522e340196cb30d55d81d93c63028938cd782
> > > >.
> > > > I have prepared PR #5089 
> > for
> > > > support/1.13 and PR #5090  >
> > > for
> > > > support/1.12 due to the version number differences on each branch.
> > >
> >
>

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

[Dave Barnes]

Go ahead, Patrick, and add this to 1.13.

On Mon, May 11, 2020 at 8:36 AM Joris Melchior  wrote:

> +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

[Dave Barnes]

Plenty of votes, go ahead, Jake, and add this to the support/1.13 branch.

On Mon, May 11, 2020 at 8:36 AM Joris Melchior  wrote:

> +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: Proposal to bring GEODE-8016 to support branches

[Robert Houghton]

Yes please! +1

On Mon, May 11, 2020 at 2:46 AM Darrel Schneider 
wrote:

> +1
>
> On Sun, May 10, 2020 at 10:05 PM Dick Cavender 
> wrote:
>
> > +1
> >
> > On Sat, May 9, 2020 at 6:42 PM Owen Nichols  wrote:
> >
> > > Last week develop was successfully migrated from publishing -SNAPSHOT
> to
> > > publishing -build.nnn, as discussed on the dev list.
> > >
> > > I propose that we bring the same change to support/1.13 and
> support/1.12
> > > for consistency.  This will allow downstream projects to change over
> the
> > > new model “everywhere" rather than having to maintain support for both
> > ways
> > > and constantly try to remember which branches do it which way.
> > >
> > > The specific changes to be cherry-picked from develop are a4c8b <
> > >
> >
> https://github.com/apache/geode/commit/a4c8b9ed8bbea584f798164fa5308d236e9b6048
> > >
> > > and 39c52 <
> > >
> >
> https://github.com/apache/geode/commit/39c522e340196cb30d55d81d93c63028938cd782
> > >.
> > > I have prepared PR #5089 
> for
> > > support/1.13 and PR #5090 
> > for
> > > support/1.12 due to the version number differences on each branch.
> >
>

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: Proposal to bring GEODE-8016 to support branches

[Darrel Schneider]

+1

On Sun, May 10, 2020 at 10:05 PM Dick Cavender  wrote:

> +1
>
> On Sat, May 9, 2020 at 6:42 PM Owen Nichols  wrote:
>
> > Last week develop was successfully migrated from publishing -SNAPSHOT to
> > publishing -build.nnn, as discussed on the dev list.
> >
> > I propose that we bring the same change to support/1.13 and support/1.12
> > for consistency.  This will allow downstream projects to change over the
> > new model “everywhere" rather than having to maintain support for both
> ways
> > and constantly try to remember which branches do it which way.
> >
> > The specific changes to be cherry-picked from develop are a4c8b <
> >
> https://github.com/apache/geode/commit/a4c8b9ed8bbea584f798164fa5308d236e9b6048
> >
> > and 39c52 <
> >
> https://github.com/apache/geode/commit/39c522e340196cb30d55d81d93c63028938cd782
> >.
> > I have prepared PR #5089  for
> > support/1.13 and PR #5090 
> for
> > support/1.12 due to the version number differences on each branch.
>