[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #904 was SUCCESSFUL (with 2378 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #904 was successful.
---
Scheduled
2380 tests in total.

https://build.spring.io/browse/SGF-NAG-904/





--
This message is automatically generated by Atlassian Bamboo

Better support for JSON gfsh results

[Jens Deppe]

Hi All,

I'm working on removing our dependency on geode-json (org.json) in favor of
Jackson. Initially this work has revolved around refactoring the internal
results from gfsh commands (nothing that is user-visible).

I'm now looking at the various gfsh 'data' commands (get, put, query and
locate) and would very much like them to produce more meaningful, (actual
JSON), structured results.

For example, a get on a region containing a simple 'User' object produces
this output.

Result  : true
Key Class   : java.lang.String
Key : jondoe
Value Class :
org.apache.geode.management.internal.cli.commands.GetCommandIntegrationTest.User

This is not very helpful and only really shows that the value, for the
given key, actually exists.

Querying a PDX object is more informative:

Result  : true
Key Class   : java.lang.String
Key : jondoe
Value Class : org.apache.geode.pdx.internal.PdxInstanceImpl

username | hashcode
 | 
jondoe   | 38de41a9

This brings me to the actual question. Although our Java API is backwards
compatible, the gfsh output has never been considered an 'API' in terms of
the structure of it's output text. However, I do want to ask that if we
start making changes to these commands, to produce actual JSON results,
will that cause anyone any pain?

Thoughts / comments?

--Jens

Re: [RESULT][VOTE] Apache Geode 1.6.0.RC1

[Anthony Baker]

Reminder on release voting requirements [1]:

- Must have 3 binding (PMC) +1 votes
- Must have a majority of +1 votes

In this case Galen, Dan, Swapnil, and myself are members of the Geode PMC.  All 
votes are "binding".

Anthony

[1] https://www.apache.org/foundation/voting.html 



> On May 1, 2018, at 3:07 PM, Mike Stolz  wrote:
> 
> This vote passes with three +1 votes and one +0 and zero -1 votes.
> 
> Summary:
> Anthony Baker +1
> Galen O'Sullivan +0
> Dan Smith +1
> Swapnil Bawaskar +1

[RESULT][VOTE] Apache Geode 1.6.0.RC1

[Mike Stolz]

This vote passes with three +1 votes and one +0 and zero -1 votes.

Summary:
Anthony Baker +1
Galen O'Sullivan +0
Dan Smith +1
Swapnil Bawaskar +1

Re: [VOTE] Apache Geode 1.6.0 RC1

[Dan Smith]

+1

Ran geode-release-check, looks good to me.

-Dan

On Tue, May 1, 2018 at 11:55 AM, Anthony Baker  wrote:

> Ok, thanks Galen.  AFAICT, the KEYS file being referred to is this one:
> https://dist.apache.org/repos/dist/release/geode/KEYS <
> https://dist.apache.org/repos/dist/release/geode/KEYS>.  Other Apache
> projects like Flink, Beam, Impala, or Kafka don’t version control their
> KEYS file.
>
> @PMC - we need more reviews and votes to complete this release in a timely
> manner.  Please check it out.
>
> Anthony
>
>
> > On May 1, 2018, at 11:42 AM, Galen O'Sullivan 
> wrote:
> >
> > Thanks for the clarification, Anthony. The release signing page you
> linked does say this:
> >
> > > Since the KEYS may be needed to check signatures for archived
> releases, it is important that all keys that have ever been used to sign
> releases are retained in the file. Entries should only be added (as
> described above), not removed.
> >
> > > Your public key should be exported and the result appended to the
> appropriate KEYS file(s).
> >
> > I think we should get Mike's key added to both the develop and release
> branches. I would prefer if it was present in the release tag (it could be
> confusing for someone checking release history).
> >
> > But I guess it shouldn't be too much of a problem if the key isn't in
> KEYS on the release. It won't affect the binary.
> >
> > I'll change to a +0.
> >
> > Galen
> >
> > On 5/1/18 10:15 AM, Anthony Baker wrote:
> >> Galen,
> >>
> >> Given the above information what are your thoughts?
> >>
> >> Anthony
> >>
> >>
> >>> On Apr 30, 2018, at 3:01 PM, Anthony Baker  wrote:
> >>>
> >>> Please review the ASF policy on signing releases [1].  I think these
> points are pertinent:
> >>>
> >>> - The release manager signs the release.  That provides the
> verification that the release binaries were in fact created by the release
> manager and have not been modified.  Multiple signatures are not required
> or even possible sometimes.
> >>>
> >>> - The KEYS file in git[2] is a convenience for keeping [3] up to
> date.  In fact, the KEYS file is a secondary check for a fingerprint at
> id.apache.org (see [4] for how ASF checks signatures on releases).
> >>>
> >>> To me I don’t see a strict necessity to include the KEYS file commit
> in the release tag.  It’s on the release branch and it will be merged to
> /develop.
> >>>
> >>> $.02,
> >>> Anthony
> >>>
> >>> [1] http://apache.org/dev/release-signing.html
> >>> [2] https://github.com/apache/geode/blob/develop/KEYS
> >>> [3] https://dist.apache.org/repos/dist/release/geode/KEYS
> >>> [4] https://mirror-vm.apache.org/~henkp/checker/faq.html
> >>>
>  On Apr 30, 2018, at 10:31 AM, Galen O'Sullivan 
> wrote:
> 
>  -1
> 
>  I don't see Mike's key in the KEYS file on either rel/v1.6.0.RC1 (
> 5ce726bd7b4f8d2648fd011a807a1bcc624ddfa5) or on develop.
> 
>  It seems odd to me to add a new key and use it to sign the release
> without using an already-existing key to sign the release as well. If
> someone's trying to verify a source tag, there isn't a chain of signatures
> with the last signer of the release signing a commit with the addition of
> the next new key.
> 
>  Galen
> >
>
>

Re: [VOTE] Apache Geode 1.6.0 RC1

[Anthony Baker]

Ok, thanks Galen.  AFAICT, the KEYS file being referred to is this one:  
https://dist.apache.org/repos/dist/release/geode/KEYS 
.  Other Apache projects 
like Flink, Beam, Impala, or Kafka don’t version control their KEYS file.

@PMC - we need more reviews and votes to complete this release in a timely 
manner.  Please check it out.

Anthony


> On May 1, 2018, at 11:42 AM, Galen O'Sullivan  wrote:
> 
> Thanks for the clarification, Anthony. The release signing page you linked 
> does say this:
> 
> > Since the KEYS may be needed to check signatures for archived releases, it 
> > is important that all keys that have ever been used to sign releases are 
> > retained in the file. Entries should only be added (as described above), 
> > not removed.
> 
> > Your public key should be exported and the result appended to the 
> > appropriate KEYS file(s).
> 
> I think we should get Mike's key added to both the develop and release 
> branches. I would prefer if it was present in the release tag (it could be 
> confusing for someone checking release history).
> 
> But I guess it shouldn't be too much of a problem if the key isn't in KEYS on 
> the release. It won't affect the binary.
> 
> I'll change to a +0.
> 
> Galen
> 
> On 5/1/18 10:15 AM, Anthony Baker wrote:
>> Galen,
>> 
>> Given the above information what are your thoughts?
>> 
>> Anthony
>> 
>> 
>>> On Apr 30, 2018, at 3:01 PM, Anthony Baker  wrote:
>>> 
>>> Please review the ASF policy on signing releases [1].  I think these points 
>>> are pertinent:
>>> 
>>> - The release manager signs the release.  That provides the verification 
>>> that the release binaries were in fact created by the release manager and 
>>> have not been modified.  Multiple signatures are not required or even 
>>> possible sometimes.
>>> 
>>> - The KEYS file in git[2] is a convenience for keeping [3] up to date.  In 
>>> fact, the KEYS file is a secondary check for a fingerprint at id.apache.org 
>>> (see [4] for how ASF checks signatures on releases).
>>> 
>>> To me I don’t see a strict necessity to include the KEYS file commit in the 
>>> release tag.  It’s on the release branch and it will be merged to /develop.
>>> 
>>> $.02,
>>> Anthony
>>> 
>>> [1] http://apache.org/dev/release-signing.html
>>> [2] https://github.com/apache/geode/blob/develop/KEYS
>>> [3] https://dist.apache.org/repos/dist/release/geode/KEYS
>>> [4] https://mirror-vm.apache.org/~henkp/checker/faq.html
>>> 
 On Apr 30, 2018, at 10:31 AM, Galen O'Sullivan  
 wrote:
 
 -1
 
 I don't see Mike's key in the KEYS file on either rel/v1.6.0.RC1 
 (5ce726bd7b4f8d2648fd011a807a1bcc624ddfa5) or on develop.
 
 It seems odd to me to add a new key and use it to sign the release without 
 using an already-existing key to sign the release as well. If someone's 
 trying to verify a source tag, there isn't a chain of signatures with the 
 last signer of the release signing a commit with the addition of the next 
 new key.
 
 Galen
> 

Re: [VOTE] Apache Geode 1.6.0 RC1

[Galen O'Sullivan]

Thanks for the clarification, Anthony. The release signing page you 
linked does say this:


> Since the KEYS may be needed to check signatures for archived 
releases, it is important that all keys that have ever been used to sign 
releases are retained in the file. Entries should only be added (as 
described above), not removed.


> Your public key should be exported and the result appended to the 
appropriate KEYS file(s).


I think we should get Mike's key added to both the develop and release 
branches. I would prefer if it was present in the release tag (it could 
be confusing for someone checking release history).


But I guess it shouldn't be too much of a problem if the key isn't in 
KEYS on the release. It won't affect the binary.


I'll change to a +0.

Galen

On 5/1/18 10:15 AM, Anthony Baker wrote:

Galen,

Given the above information what are your thoughts?

Anthony



On Apr 30, 2018, at 3:01 PM, Anthony Baker  wrote:

Please review the ASF policy on signing releases [1].  I think these points are 
pertinent:

- The release manager signs the release.  That provides the verification that 
the release binaries were in fact created by the release manager and have not 
been modified.  Multiple signatures are not required or even possible sometimes.

- The KEYS file in git[2] is a convenience for keeping [3] up to date.  In 
fact, the KEYS file is a secondary check for a fingerprint at id.apache.org 
(see [4] for how ASF checks signatures on releases).

To me I don’t see a strict necessity to include the KEYS file commit in the 
release tag.  It’s on the release branch and it will be merged to /develop.

$.02,
Anthony

[1] http://apache.org/dev/release-signing.html
[2] https://github.com/apache/geode/blob/develop/KEYS
[3] https://dist.apache.org/repos/dist/release/geode/KEYS
[4] https://mirror-vm.apache.org/~henkp/checker/faq.html


On Apr 30, 2018, at 10:31 AM, Galen O'Sullivan  wrote:

-1

I don't see Mike's key in the KEYS file on either rel/v1.6.0.RC1 
(5ce726bd7b4f8d2648fd011a807a1bcc624ddfa5) or on develop.

It seems odd to me to add a new key and use it to sign the release without 
using an already-existing key to sign the release as well. If someone's trying 
to verify a source tag, there isn't a chain of signatures with the last signer 
of the release signing a commit with the addition of the next new key.

Galen

Re: [VOTE] Apache Geode 1.6.0 RC1

[Anthony Baker]

Galen, 

Given the above information what are your thoughts?

Anthony


> On Apr 30, 2018, at 3:01 PM, Anthony Baker  wrote:
> 
> Please review the ASF policy on signing releases [1].  I think these points 
> are pertinent:
> 
> - The release manager signs the release.  That provides the verification that 
> the release binaries were in fact created by the release manager and have not 
> been modified.  Multiple signatures are not required or even possible 
> sometimes.
> 
> - The KEYS file in git[2] is a convenience for keeping [3] up to date.  In 
> fact, the KEYS file is a secondary check for a fingerprint at id.apache.org 
> (see [4] for how ASF checks signatures on releases).
> 
> To me I don’t see a strict necessity to include the KEYS file commit in the 
> release tag.  It’s on the release branch and it will be merged to /develop.
> 
> $.02,
> Anthony
> 
> [1] http://apache.org/dev/release-signing.html
> [2] https://github.com/apache/geode/blob/develop/KEYS
> [3] https://dist.apache.org/repos/dist/release/geode/KEYS
> [4] https://mirror-vm.apache.org/~henkp/checker/faq.html
> 
>> On Apr 30, 2018, at 10:31 AM, Galen O'Sullivan  wrote:
>> 
>> -1
>> 
>> I don't see Mike's key in the KEYS file on either rel/v1.6.0.RC1 
>> (5ce726bd7b4f8d2648fd011a807a1bcc624ddfa5) or on develop.
>> 
>> It seems odd to me to add a new key and use it to sign the release without 
>> using an already-existing key to sign the release as well. If someone's 
>> trying to verify a source tag, there isn't a chain of signatures with the 
>> last signer of the release signing a commit with the addition of the next 
>> new key.
>> 
>> Galen
> 

ApacheCon North America 2018 schedule is now live.

[Rich Bowen]

Dear Apache Enthusiast,

We are pleased to announce our schedule for ApacheCon North America 
2018. ApacheCon will be held September 23-27 at the Montreal Marriott 
Chateau Champlain in Montreal, Canada.


Registration is open! The early bird rate of $575 lasts until July 21, 
at which time it goes up to $800. And the room block at the Marriott 
($225 CAD per night, including wifi) closes on August 24th.


We will be featuring more than 100 sessions on Apache projects. The 
schedule is now online at https://apachecon.com/acna18/


The schedule includes full tracks of content from Cloudstack[1], 
Tomcat[2], and our GeoSpatial community[3].


We will have 4 keynote speakers, two of whom are Apache members, and two 
from the wider community.


On Tuesday, Apache member and former board member Cliff Schmidt will be 
speaking about how Amplio uses technology to educate and improve the 
quality of life of people living in very difficult parts of the 
world[4]. And Apache Fineract VP Myrle Krantz will speak about how Open 
Source banking is helping the global fight against poverty[5].


Then, on Wednesday, we’ll hear from Bridget Kromhout, Principal Cloud 
Developer Advocate from Microsoft, about the really hard problem in 
software - the people[6]. And Euan McLeod, ‎VP VIPER at ‎Comcast will 
show us the many ways that Apache software delivers your favorite shows 
to your living room[7].


ApacheCon will also feature old favorites like the Lightning Talks, the 
Hackathon (running the duration of the event), PGP key signing, and lots 
of hallway-track time to get to know your project community better.


Follow us on Twitter, @ApacheCon, and join the disc...@apachecon.com 
mailing list (send email to discuss-subscr...@apachecon.com) to stay up 
to date with developments. And if your company wants to sponsor this 
event, get in touch at h...@apachecon.com for opportunities that are 
still available.


See you in Montreal!

Rich Bowen
VP Conferences, The Apache Software Foundation
h...@apachecon.com
@ApacheCon

[1] http://cloudstackcollab.org/
[2] http://tomcat.apache.org/conference.html
[3] http://apachecon.dukecon.org/acna/2018/#/schedule?search=geospatial
[4] 
http://apachecon.dukecon.org/acna/2018/#/scheduledEvent/df977fd305a31b903
[5] 
http://apachecon.dukecon.org/acna/2018/#/scheduledEvent/22c6c30412a3828d6
[6] 
http://apachecon.dukecon.org/acna/2018/#/scheduledEvent/fbbb2384fa91ebc6b
[7] 
http://apachecon.dukecon.org/acna/2018/#/scheduledEvent/88d50c3613852c2de