Re: Updating geode-native-build docker image

[Anthony Baker]

Done!

> On Aug 27, 2019, at 10:20 AM, Ivan Godwin  wrote:
> 
> Anthony,
> 
> I would like access to the geode docker account. My docker username is
> igodwin.
> 
> Ivan
> 
> On Wed, Aug 7, 2019 at 3:54 PM Anthony Baker  wrote:
> 
>> Committers can request access to the geode docker account to push new
>> images.  Note that any geode source or binaries in these images should
>> *only* include releases that have been voted on and approved by the PMC
>> (e.g. v1.9.0, v1.8.0, …).
>> 
>> Can you send me your docker username?
>> 
>> Anthony
>> 
>> 
>>> On Aug 7, 2019, at 3:47 PM, Michael Oleske  wrote:
>>> 
>>> Hi Geode Devs!
>>> 
>>> Geode Native merged https://github.com/apache/geode-native/pull/509 this
>>> morning since our docker image was using an old Geode version.  What is
>> the
>>> proper way to update docker hub (
>>> https://hub.docker.com/r/apachegeode/geode-native-build) with the new
>>> image?  Is that something committers should be able to do?  Or is there
>> an
>>> automated build that updates docker hub?
>>> 
>>> Thanks!
>>> -michael
>> 
>> 

Re: [VOTE] Apache Geode 1.9.1 RC1

[John Blum]

+1

On Wed, Aug 28, 2019 at 2:51 PM Dan Smith  wrote:

> I missed this vote email as well - if we reopen the vote I'll cast one. I
> don't really have much context on why we want a 1.9.1 but I'm happy to
> double check the bits.
>
> One comment on this RC - I noticed that we bumped the ordinal in
> Version.java - is that what we actually want to do? That implies a new
> version of our communications protocol, which 1.10 will have to understand.
> Did we actually change the communication protocol in this release?
>
> -Dan
>
> On Wed, Aug 28, 2019 at 2:42 PM Kirk Lund  wrote:
>
> > SBDG 1.2 is currently in RC and cannot be changed to depend on Geode
> 1.10.
> > It must depend on Geode 1.9 or 1.9.1.
> >
> > So if we want to provide the logging fixes for SBDG 1.2 then we must
> > release Geode 1.9.1.
> >
> > Let's open a new vote for releasing Geode 1.9.1.
> >
> > On Wed, Aug 28, 2019 at 1:37 PM Owen Nichols 
> wrote:
> >
> > > It's past the announced deadline and the vote has failed to due to lack
> > of
> > > quorum.
> > >
> > > Voting status
> > > ==
> > > +1: zero votes
> > >
> > > +0: zero votes
> > >
> > > -0: zero votes
> > >
> > > -1: zero votes
> > >
> > > The voting does not meet the requirements <
> > > https://www.apache.org/foundation/voting.html> of at least 3 PMC
> members
> > > with +1 votes and a majority of +1 votes.
> > >
> > > The matter of what to do next is referred back to the original DISCUSS
> > > thread that proposed 1.9.1.
> > >
> > > -Owen & Kirk
> > >
> > > > On Aug 22, 2019, at 6:10 PM, Owen Nichols 
> wrote:
> > > >
> > > > Hello Geode dev community,
> > > >
> > > > This is a release candidate for Apache Geode, version 1.9.1.RC1.
> > > > Thanks to all the community members for their contributions to this
> > > release!
> > > >
> > > > Please do a review and give your feedback. The deadline is 3PM PST
> Tue,
> > > August 27 2019.
> > > > Release notes can be found at:
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> > > <
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> > >
> > >
> > > >
> > > > Please note that we are voting on the source tag: rel/v1.9.1.RC1
> > > >
> > > > Apache Geode:
> > > > https://github.com/apache/geode/tree/rel/v1.9.1.RC1 <
> > > https://github.com/apache/geode/tree/rel/v1.9.1.RC1>
> > > > Apache Geode examples:
> > > > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1 <
> > > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1>
> > > > Apache Geode native:
> > > > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1 <
> > > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1>
> > > >
> > > > Source and binary files:
> > > > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/ <
> > > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/>
> > > >
> > > > Maven staging repo:
> > > >
> https://repository.apache.org/content/repositories/orgapachegeode-1055
> > <
> > > https://repository.apache.org/content/repositories/orgapachegeode-1055
> >
> > > >
> > > > Geode's KEYS file containing PGP keys we use to sign the release:
> > > > https://github.com/apache/geode/blob/develop/KEYS <
> > > https://github.com/apache/geode/blob/develop/KEYS>
> > > >
> > > > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
> > > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1 <
> > > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1>
> > > -PgeodeRepositoryUrl=
> > > https://repository.apache.org/content/repositories/orgapachegeode-1055
> <
> > > https://repository.apache.org/content/repositories/orgapachegeode-1055
> >
> > > build runAll
> > > >
> > > > Regards
> > > > Owen Nichols & Kirk Lund
> > > >
> > >
> > >
> >
>


-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[John Blum]

+1 Yes!

SBDG needs the Apache Geode 1.9.1 release with the Logging changes if you
want to see Apache Geode on *Spring Initializer*.  The Logging issues are
impeding the presence of Apache Geode on *Initializer* at start.spring.io.


On Wed, Aug 28, 2019 at 4:48 PM Anthony Baker  wrote:

> I think it makes sense to do a 1.9.1 release for the same reasons that we
> proposed it originally.  It looks like we all missed the VOTE thread (it
> was on my // todo list).In the past when we’ve had insufficient votes,
> we've extended the deadline and asked for help reviewing the release.
>
> Anthony
>
>
> > On Aug 28, 2019, at 1:38 PM, Owen Nichols  wrote:
> >
> > The VOTE for 1.9.1.RC1 failed due to lack of quorum, so re-opening this
> thread to continue the discussion.
> >
> > Is there still a need for a 1.9 patch release (especially given that
> 1.10.0.RC1 is expected later this week)?
> >
> > If so, perhaps we should back up a step or two and first:
> > 1) come to rough consensus that 1.9.1 is still desired (and what should
> be in it)
> > 2) ensure that we have Geode PMC support for this release
> > 3) go through the formal process of voting each cherry-pick in the patch
> release
> >
> > This could result in a recommendation to re-vote on RC1, a
> recommendation to produce a new RC2, a recommendation to pull the plug (or
> no recommendation).
> >
> > As a failsafe, I hereby invoke lazy consensus: In the event that no
> explicit decision to move forward with 1.9.1 is reached by 3pm PDT Wed Sep
> 4, I will dismantle the current 1.9.1 branch, pipeline and nexus staging
> repo and remove 1.9.1 from the release notes wiki.
> >
> > -Owen
> >
> >
> >> On Aug 18, 2019, at 7:52 AM, Anthony Baker  wrote:
> >>
> >> Yep. Get a release manager, identify and cherry pick all the changes,
> then do the release.
> >>
> >> Anthony
> >>
> >>> On Aug 16, 2019, at 4:21 PM, Kirk Lund  wrote:
> >>>
> >>> Does anyone know what the next step is? Do we need a release manager to
> >>> proceed?
> >>>
>  On Tue, Aug 13, 2019 at 1:57 PM John Blum  wrote:
> 
>  Sorry, corrections below...
> 
> > On Tue, Aug 13, 2019 at 1:54 PM John Blum  wrote:
> >
> > Stated slightly a different way...
> >
> > If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly,
> then
> > it would *defy* the dependency on Apache Geode pulled in by SDG
> Moore/2.2
> > (which is and can only be Geode 1.9 *at this point*) for which SBDG
> is
> > also based, along with Spring Boot 2.2, which pulls in SD Moore/2.2
> and
> > therefore Geode 1.9, *indirectly (i.e. transitively)*, as well.  As
> such,
> > the stars would not align and it would cause issues (or unexpected
> > surprises, possibly conflicts) for users of Spring Boot when also
> using
> > SBDG.  *With**out* SBDG, users of Spring Boot would get Geode 1.9
> due to
> > the SD Moore/2.2 dependency, but with SBDG on the classpath, it would
> > suddenly (possibly) change the Geode version to 1.10.  That is
>  definitively
> > bad.
> >
> > Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9.
> >
> > SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not
> > available) which will pull in the latest version of Geode at that
> time
> > (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3
> reaches RC
> > status.
> >
> > Cheers,
> > John
> >
> >
> >
> >
> >> On Tue, Aug 13, 2019 at 1:45 PM John Blum  wrote:
> >>
> >> For clarification...
> >>
> >> 1. SBDG 1.1 is the "*current*" development line (on
> >> <
> 
> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
> >
> >> master
> >> <
> 
> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
> >
>  [1]);
> >> SBDG 1.2 is *not* yet in development.
> >> 2. SBDG 1.1 is at RC1
> >>  >
>  [2].
> >> 3. SBDG 1.1 is based on Spring Boot 2.1
> >> <
> 
> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8
> >
>  [3]
> >> and Spring Data (Geode) Lovelace
> >> <
> 
> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12
> >
>  [4]
> >> (or SDG 2.1
> >> <
> 
> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10
> >
>  [5]);
> >> This is not arbitrary because all the stars (bits, transitive
> dependency
> >> versions) must "align" as defined by what Spring Boot 2.1 declares,
> and
> >> Spring Boot 2.1 is based on
> >> <
> 
> https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169
> >
>  [6]
> >> Spring Data Lovelace/2.1.
> >> 

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Anthony Baker]

I think it makes sense to do a 1.9.1 release for the same reasons that we 
proposed it originally.  It looks like we all missed the VOTE thread (it was on 
my // todo list).In the past when we’ve had insufficient votes, we've 
extended the deadline and asked for help reviewing the release.

Anthony


> On Aug 28, 2019, at 1:38 PM, Owen Nichols  wrote:
> 
> The VOTE for 1.9.1.RC1 failed due to lack of quorum, so re-opening this 
> thread to continue the discussion.
> 
> Is there still a need for a 1.9 patch release (especially given that 
> 1.10.0.RC1 is expected later this week)?
> 
> If so, perhaps we should back up a step or two and first:
> 1) come to rough consensus that 1.9.1 is still desired (and what should be in 
> it)
> 2) ensure that we have Geode PMC support for this release
> 3) go through the formal process of voting each cherry-pick in the patch 
> release
> 
> This could result in a recommendation to re-vote on RC1, a recommendation to 
> produce a new RC2, a recommendation to pull the plug (or no recommendation).
> 
> As a failsafe, I hereby invoke lazy consensus: In the event that no explicit 
> decision to move forward with 1.9.1 is reached by 3pm PDT Wed Sep 4, I will 
> dismantle the current 1.9.1 branch, pipeline and nexus staging repo and 
> remove 1.9.1 from the release notes wiki.
> 
> -Owen
> 
> 
>> On Aug 18, 2019, at 7:52 AM, Anthony Baker  wrote:
>> 
>> Yep. Get a release manager, identify and cherry pick all the changes, then 
>> do the release. 
>> 
>> Anthony
>> 
>>> On Aug 16, 2019, at 4:21 PM, Kirk Lund  wrote:
>>> 
>>> Does anyone know what the next step is? Do we need a release manager to
>>> proceed?
>>> 
 On Tue, Aug 13, 2019 at 1:57 PM John Blum  wrote:
 
 Sorry, corrections below...
 
> On Tue, Aug 13, 2019 at 1:54 PM John Blum  wrote:
> 
> Stated slightly a different way...
> 
> If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly, then
> it would *defy* the dependency on Apache Geode pulled in by SDG Moore/2.2
> (which is and can only be Geode 1.9 *at this point*) for which SBDG is
> also based, along with Spring Boot 2.2, which pulls in SD Moore/2.2 and
> therefore Geode 1.9, *indirectly (i.e. transitively)*, as well.  As such,
> the stars would not align and it would cause issues (or unexpected
> surprises, possibly conflicts) for users of Spring Boot when also using
> SBDG.  *With**out* SBDG, users of Spring Boot would get Geode 1.9 due to
> the SD Moore/2.2 dependency, but with SBDG on the classpath, it would
> suddenly (possibly) change the Geode version to 1.10.  That is
 definitively
> bad.
> 
> Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9.
> 
> SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not
> available) which will pull in the latest version of Geode at that time
> (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3 reaches RC
> status.
> 
> Cheers,
> John
> 
> 
> 
> 
>> On Tue, Aug 13, 2019 at 1:45 PM John Blum  wrote:
>> 
>> For clarification...
>> 
>> 1. SBDG 1.1 is the "*current*" development line (on
>> <
 https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
> 
>> master
>> <
 https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17>
 [1]);
>> SBDG 1.2 is *not* yet in development.
>> 2. SBDG 1.1 is at RC1
>> 
 [2].
>> 3. SBDG 1.1 is based on Spring Boot 2.1
>> <
 https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8>
 [3]
>> and Spring Data (Geode) Lovelace
>> <
 https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12>
 [4]
>> (or SDG 2.1
>> <
 https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10>
 [5]);
>> This is not arbitrary because all the stars (bits, transitive dependency
>> versions) must "align" as defined by what Spring Boot 2.1 declares, and
>> Spring Boot 2.1 is based on
>> <
 https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169>
 [6]
>> Spring Data Lovelace/2.1.
>> 4. Spring Data Geode (SDG) Lovelace/2.1 is based on
>> <
 https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25>
 [7]
>> Apache Geode 1.6.
>> 5. All SDG Lovelace/2.1.x versions will always be based on the latest
>> Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of time.
>> This ship has sailed.
>> 
>> 
>> 
>> 6. SBDG 1.2, when it reaches development (soon),will be based on Spring
>> Boot 2.2
>> <
 

Re: [DISCUSS] Improvements on client function execution API

[Dan Smith]

Sorry for the slow response, I've been trying to decide what I think is the
right approach here.

For (1) - conceptually, I don't have a problem with having both blocking
and non blocking methods on Execution. So adding blocking versions of
execute() with a timeout seems ok. But I do think if we add them we need to
implement them on both the client and the server to behave the same way.
That shouldn't be too hard on the server since execute(timeout) can just
call getResult(timeout) internally.

For (2) - Although I think the original authors of this API probably did
intend for execute() to be non-blocking, the fact is that it does block on
the client and most users are probably calling execute from a client. So I
do agree we probably shouldn't change the behavior at this point. Perhaps
we can just clearly document the current behavior of execute() as part of
adding these new methods. Going forward we can add new methods to Execution
that are clearly non-blocking (submit?, invoke?) and implement them
consistently on *both* the client in the server, but that doesn't have to
be in the scope of this proposal.

-Dan

On Fri, Aug 23, 2019 at 4:28 AM Alberto Gomez 
wrote:

> Hi Jake,
>
> Please, see my answers below.
>
> On 22/8/19 21:16, Jacob Barrett wrote:
> >
> >> On Aug 21, 2019, at 8:49 AM, Alberto Gomez 
> wrote:
> >> 2. Timeout in ResultCollector::getResult() and Execution::execute()
> blocking
> >>
> >> Regarding the timeout in the ResultCollector::getResult() method
> problem and the blocking/non-blocking confusion for Execution::execute()
> two alternatives are considered:
> >>
> >> a) Remove the possibility of setting a timeout on the
> ResultCollector::getResult() method on the client side as with the current
> client implementation it is useless. This could be done by removing the
> method with the timeout parameter from the public API.
> >>
> >> It would be advisable to make explicit in the documentation that the
> getResult() method does not wait for results to arrive as that should have
> already been done in the Execution::execute() invocation.
> >>
> >> This alternative is very simple and would keep things pretty much as
> they are today.
> > To be honest I think approach would go against what a user “thinks” is
> going on. Given that there hasn’t been a timeout on execute I assumed it
> was asynchronous and that the getResult blocked until timeout or results
> arrived. Typically these two calls were done back to back.
>
> You are right if you look at the Java client. But if you look at the
> native clients, the timeout is there, both in the C++ and the C# cases
> which would indicate that it is a blocking call.
>
> See
>
> https://geode.apache.org/releases/latest/cppdocs/a00725.html#aa918a5e193745950e12ca4feb9c5d776
> and
>
> https://geode.apache.org/releases/latest/dotnetdocs/a00882.html#ae0a814049482ca424f89c13ab1099c3d
> >
> >> b) Transform the Execution::execute() method on the client side into a
> non-blocking method.
> >>
> >> This alternative is more complex and requires changes in all the
> clients. Apart from that it has implications on the public client API it
> requires moving the exceptions offered currently by the
> Execution::execute() method to the ResultCollector::getResult() and new
> threads will have to be managed.
> > I think this is more in line with what users expect is going on based on
> the current API, I know I have. If were are going to make any change I
> think this is the one. I don’t think the behavior change is a problem since
> it's what is expected to be happening anyway.
> >
> >> An outline of a possible implementation for option b) would be:
> >>
> >>   *   Instead of invoking the ServerRegionProxy::executeFunction()
> directly as it is done today, create a Future that invokes this method and
> returns the resultCollector passed as parameter.
> > Do you really think we need to introduce Futures here into the API? I
> feel like the ResultCollector acts as the Future. I don’t think any change
> needs to be made to the API in this regard. The ResultCollector
> implementation would just simply block as implied by the api for the
> timeout period. I would change the method to have units though and
> deprecate the method without units.
>
> I did not mean to introduce Futures in the API. My idea was to use Java
> Futures internally so that the ResultCollector returned by the
> getResult() method would wrap the Java Future with the ResultCollector
> that would actually hold the result.
>
> An alternative would be to leave the logic of blocking to each
> implementation ResultCollector. In the case of the
> DefaultResultCollector, we could use a CountDownLatch that would be
> decremented when endResults() is called and that would make getResult()
> block by using CountDown.await(...).
>
> The advantage of using Futures internally is that the blocking logic
> would not have to be implemented on every ResultCollector implementation.
>
> >
> > -Jake
> >
> >
> - Alberto
>

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Mark Hanson]

+1 for log4j changes etc.

Mark

Re: [VOTE] Apache Geode 1.9.1 RC1

[Dan Smith]

I missed this vote email as well - if we reopen the vote I'll cast one. I
don't really have much context on why we want a 1.9.1 but I'm happy to
double check the bits.

One comment on this RC - I noticed that we bumped the ordinal in
Version.java - is that what we actually want to do? That implies a new
version of our communications protocol, which 1.10 will have to understand.
Did we actually change the communication protocol in this release?

-Dan

On Wed, Aug 28, 2019 at 2:42 PM Kirk Lund  wrote:

> SBDG 1.2 is currently in RC and cannot be changed to depend on Geode 1.10.
> It must depend on Geode 1.9 or 1.9.1.
>
> So if we want to provide the logging fixes for SBDG 1.2 then we must
> release Geode 1.9.1.
>
> Let's open a new vote for releasing Geode 1.9.1.
>
> On Wed, Aug 28, 2019 at 1:37 PM Owen Nichols  wrote:
>
> > It's past the announced deadline and the vote has failed to due to lack
> of
> > quorum.
> >
> > Voting status
> > ==
> > +1: zero votes
> >
> > +0: zero votes
> >
> > -0: zero votes
> >
> > -1: zero votes
> >
> > The voting does not meet the requirements <
> > https://www.apache.org/foundation/voting.html> of at least 3 PMC members
> > with +1 votes and a majority of +1 votes.
> >
> > The matter of what to do next is referred back to the original DISCUSS
> > thread that proposed 1.9.1.
> >
> > -Owen & Kirk
> >
> > > On Aug 22, 2019, at 6:10 PM, Owen Nichols  wrote:
> > >
> > > Hello Geode dev community,
> > >
> > > This is a release candidate for Apache Geode, version 1.9.1.RC1.
> > > Thanks to all the community members for their contributions to this
> > release!
> > >
> > > Please do a review and give your feedback. The deadline is 3PM PST Tue,
> > August 27 2019.
> > > Release notes can be found at:
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> > <
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> >
> >
> > >
> > > Please note that we are voting on the source tag: rel/v1.9.1.RC1
> > >
> > > Apache Geode:
> > > https://github.com/apache/geode/tree/rel/v1.9.1.RC1 <
> > https://github.com/apache/geode/tree/rel/v1.9.1.RC1>
> > > Apache Geode examples:
> > > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1 <
> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1>
> > > Apache Geode native:
> > > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1 <
> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1>
> > >
> > > Source and binary files:
> > > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/ <
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/>
> > >
> > > Maven staging repo:
> > > https://repository.apache.org/content/repositories/orgapachegeode-1055
> <
> > https://repository.apache.org/content/repositories/orgapachegeode-1055>
> > >
> > > Geode's KEYS file containing PGP keys we use to sign the release:
> > > https://github.com/apache/geode/blob/develop/KEYS <
> > https://github.com/apache/geode/blob/develop/KEYS>
> > >
> > > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1 <
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1>
> > -PgeodeRepositoryUrl=
> > https://repository.apache.org/content/repositories/orgapachegeode-1055 <
> > https://repository.apache.org/content/repositories/orgapachegeode-1055>
> > build runAll
> > >
> > > Regards
> > > Owen Nichols & Kirk Lund
> > >
> >
> >
>

Re: [DISCUSS] Pulling the current proposed 1.10 release until we can agree on develop being stable

[Ryan McMahon]

+1 to continuing with the release branch we have.

I don't think that anybody is aiming to cause instability on the develop
branch.  We are all designing, writing code, refactoring, and writing
exhaustive tests to the best of our ability to ensure high quality.  We
have to accept that there will sometimes be unforeseen consequences; that
is the reality of working on a complex enterprise product.  I think that it
is unfortunate on this particular release we have seen as many critical
issues as we have, but I do not think there is anything fundamentally wrong
with our workflow.  I think if anything, cutting the release early and
allowing ample time to identify issues is a very good thing.  Yes, in
theory the develop branch should be releasable at any given moment, but in
reality there is sometimes a feedback delay where issues arise after some
time.  I think our current process of cutting a branch and cherry-picking
fixes for issues found allows us to deal with this delayed feedback.

The issues here to me are more around the delayed feedback time (issues
found by very rare race conditions that don't arise often) and a lack of
existing test coverage for many of our features.  I do believe that
everyone who has been committing refactored or new code is doing their due
diligence to write tests, but it is not always easy to identify where test
coverage gaps exist.  We will of course continue to fill those gaps as we
find them.  Do you have other ideas on how to make develop more stable?
Again, I personally feel people are doing their best to write new tests and
review code - to me this is not a process problem (more like a tech
debt/ease of refactoring problem) but I'm definitely open to discussion.

Ryan

Re: [VOTE] Apache Geode 1.9.1 RC1

[Udo Kohlmeyer]

+1 for a re-vote

On 8/28/19 2:42 PM, Kirk Lund wrote:

SBDG 1.2 is currently in RC and cannot be changed to depend on Geode 1.10.
It must depend on Geode 1.9 or 1.9.1.

So if we want to provide the logging fixes for SBDG 1.2 then we must
release Geode 1.9.1.

Let's open a new vote for releasing Geode 1.9.1.

On Wed, Aug 28, 2019 at 1:37 PM Owen Nichols  wrote:


It's past the announced deadline and the vote has failed to due to lack of
quorum.

Voting status
==
+1: zero votes

+0: zero votes

-0: zero votes

-1: zero votes

The voting does not meet the requirements <
https://www.apache.org/foundation/voting.html> of at least 3 PMC members
with +1 votes and a majority of +1 votes.

The matter of what to do next is referred back to the original DISCUSS
thread that proposed 1.9.1.

-Owen & Kirk


On Aug 22, 2019, at 6:10 PM, Owen Nichols  wrote:

Hello Geode dev community,

This is a release candidate for Apache Geode, version 1.9.1.RC1.
Thanks to all the community members for their contributions to this

release!

Please do a review and give your feedback. The deadline is 3PM PST Tue,

August 27 2019.

Release notes can be found at:

https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
<
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1>


Please note that we are voting on the source tag: rel/v1.9.1.RC1

Apache Geode:
https://github.com/apache/geode/tree/rel/v1.9.1.RC1 <

https://github.com/apache/geode/tree/rel/v1.9.1.RC1>

Apache Geode examples:
https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1 <

https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1>

Apache Geode native:
https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1 <

https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1>

Source and binary files:
https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/ <

https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/>

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachegeode-1055 <

https://repository.apache.org/content/repositories/orgapachegeode-1055>

Geode's KEYS file containing PGP keys we use to sign the release:
https://github.com/apache/geode/blob/develop/KEYS <

https://github.com/apache/geode/blob/develop/KEYS>

PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=

https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1 <
https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1>
-PgeodeRepositoryUrl=
https://repository.apache.org/content/repositories/orgapachegeode-1055 <
https://repository.apache.org/content/repositories/orgapachegeode-1055>
build runAll

Regards
Owen Nichols & Kirk Lund

Re: [VOTE] Apache Geode 1.9.1 RC1

[Kirk Lund]

SBDG 1.2 is currently in RC and cannot be changed to depend on Geode 1.10.
It must depend on Geode 1.9 or 1.9.1.

So if we want to provide the logging fixes for SBDG 1.2 then we must
release Geode 1.9.1.

Let's open a new vote for releasing Geode 1.9.1.

On Wed, Aug 28, 2019 at 1:37 PM Owen Nichols  wrote:

> It's past the announced deadline and the vote has failed to due to lack of
> quorum.
>
> Voting status
> ==
> +1: zero votes
>
> +0: zero votes
>
> -0: zero votes
>
> -1: zero votes
>
> The voting does not meet the requirements <
> https://www.apache.org/foundation/voting.html> of at least 3 PMC members
> with +1 votes and a majority of +1 votes.
>
> The matter of what to do next is referred back to the original DISCUSS
> thread that proposed 1.9.1.
>
> -Owen & Kirk
>
> > On Aug 22, 2019, at 6:10 PM, Owen Nichols  wrote:
> >
> > Hello Geode dev community,
> >
> > This is a release candidate for Apache Geode, version 1.9.1.RC1.
> > Thanks to all the community members for their contributions to this
> release!
> >
> > Please do a review and give your feedback. The deadline is 3PM PST Tue,
> August 27 2019.
> > Release notes can be found at:
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> <
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1>
>
> >
> > Please note that we are voting on the source tag: rel/v1.9.1.RC1
> >
> > Apache Geode:
> > https://github.com/apache/geode/tree/rel/v1.9.1.RC1 <
> https://github.com/apache/geode/tree/rel/v1.9.1.RC1>
> > Apache Geode examples:
> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1 <
> https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1>
> > Apache Geode native:
> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1 <
> https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1>
> >
> > Source and binary files:
> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/ <
> https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/>
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1055 <
> https://repository.apache.org/content/repositories/orgapachegeode-1055>
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS <
> https://github.com/apache/geode/blob/develop/KEYS>
> >
> > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1 <
> https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1>
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1055 <
> https://repository.apache.org/content/repositories/orgapachegeode-1055>
> build runAll
> >
> > Regards
> > Owen Nichols & Kirk Lund
> >
>
>

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Kirk Lund]

Let's reopen the vote!

On Wed, Aug 28, 2019 at 1:49 PM Kirk Lund  wrote:

> Do folks actually want a 1.9.1 release?
>
> On Wed, Aug 28, 2019 at 1:38 PM Owen Nichols  wrote:
>
>> The VOTE for 1.9.1.RC1 failed due to lack of quorum, so re-opening this
>> thread to continue the discussion.
>>
>> Is there still a need for a 1.9 patch release (especially given that
>> 1.10.0.RC1 is expected later this week)?
>>
>> If so, perhaps we should back up a step or two and first:
>> 1) come to rough consensus that 1.9.1 is still desired (and what should
>> be in it)
>> 2) ensure that we have Geode PMC support for this release
>> 3) go through the formal process of voting each cherry-pick in the patch
>> release
>>
>> This could result in a recommendation to re-vote on RC1, a recommendation
>> to produce a new RC2, a recommendation to pull the plug (or no
>> recommendation).
>>
>> As a failsafe, I hereby invoke lazy consensus: In the event that no
>> explicit decision to move forward with 1.9.1 is reached by 3pm PDT Wed Sep
>> 4, I will dismantle the current 1.9.1 branch, pipeline and nexus staging
>> repo and remove 1.9.1 from the release notes wiki.
>>
>> -Owen
>>
>>
>> > On Aug 18, 2019, at 7:52 AM, Anthony Baker  wrote:
>> >
>> > Yep. Get a release manager, identify and cherry pick all the changes,
>> then do the release.
>> >
>> > Anthony
>> >
>> >> On Aug 16, 2019, at 4:21 PM, Kirk Lund  wrote:
>> >>
>> >> Does anyone know what the next step is? Do we need a release manager to
>> >> proceed?
>> >>
>> >>> On Tue, Aug 13, 2019 at 1:57 PM John Blum  wrote:
>> >>>
>> >>> Sorry, corrections below...
>> >>>
>>  On Tue, Aug 13, 2019 at 1:54 PM John Blum  wrote:
>> 
>>  Stated slightly a different way...
>> 
>>  If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly,
>> then
>>  it would *defy* the dependency on Apache Geode pulled in by SDG
>> Moore/2.2
>>  (which is and can only be Geode 1.9 *at this point*) for which SBDG
>> is
>>  also based, along with Spring Boot 2.2, which pulls in SD Moore/2.2
>> and
>>  therefore Geode 1.9, *indirectly (i.e. transitively)*, as well.  As
>> such,
>>  the stars would not align and it would cause issues (or unexpected
>>  surprises, possibly conflicts) for users of Spring Boot when also
>> using
>>  SBDG.  *With**out* SBDG, users of Spring Boot would get Geode 1.9
>> due to
>>  the SD Moore/2.2 dependency, but with SBDG on the classpath, it would
>>  suddenly (possibly) change the Geode version to 1.10.  That is
>> >>> definitively
>>  bad.
>> 
>>  Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9.
>> 
>>  SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not
>>  available) which will pull in the latest version of Geode at that
>> time
>>  (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3
>> reaches RC
>>  status.
>> 
>>  Cheers,
>>  John
>> 
>> 
>> 
>> 
>> > On Tue, Aug 13, 2019 at 1:45 PM John Blum  wrote:
>> >
>> > For clarification...
>> >
>> > 1. SBDG 1.1 is the "*current*" development line (on
>> > <
>> >>>
>> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
>> 
>> > master
>> > <
>> >>>
>> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
>> >
>> >>> [1]);
>> > SBDG 1.2 is *not* yet in development.
>> > 2. SBDG 1.1 is at RC1
>> > > >
>> >>> [2].
>> > 3. SBDG 1.1 is based on Spring Boot 2.1
>> > <
>> >>>
>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8
>> >
>> >>> [3]
>> > and Spring Data (Geode) Lovelace
>> > <
>> >>>
>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12
>> >
>> >>> [4]
>> > (or SDG 2.1
>> > <
>> >>>
>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10
>> >
>> >>> [5]);
>> > This is not arbitrary because all the stars (bits, transitive
>> dependency
>> > versions) must "align" as defined by what Spring Boot 2.1 declares,
>> and
>> > Spring Boot 2.1 is based on
>> > <
>> >>>
>> https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169
>> >
>> >>> [6]
>> > Spring Data Lovelace/2.1.
>> > 4. Spring Data Geode (SDG) Lovelace/2.1 is based on
>> > <
>> >>>
>> https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25
>> >
>> >>> [7]
>> > Apache Geode 1.6.
>> > 5. All SDG Lovelace/2.1.x versions will always be based on the
>> latest
>> > Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of
>> time.
>> > This ship has sailed.
>> >
>> > 
>> >
>> > 6. SBDG 1.2, when it reaches 

Re: [DISCUSS] Pulling the current proposed 1.10 release until we can agree on develop being stable

[Udo Kohlmeyer]

Fundamentally I also don't have a problem with cherry-picking fixes to a 
potential release candidate. My concern is that the amount of fixes that 
were cherry-picked.


I also believe that "stabilizing" a release does have some 
cherry-picking, BUT the amount of stabilization that we have to apply 
has to be within reason and control.


I also understand that there are fixes that we want to include that are 
critical. BUT if it takes a month (from cutting to generating an RC) to 
get close to releasing, indicates that whatever is in develop is NOT 
stable. There were fixes that were included and the cause of the issues 
was "due to a recent commit SHA-- ". Which means most likely the 
rigor to review and test said bug/issue was not effectively tested.


Finding issues with maps that should have been concurrent maps and lead 
memory leaks are distressing. Now there we have code that has been 
refactored that we prefer not to release. If we don't want to release 
it, why is it in the main develop branch. Imo, only code THAT CAN BE 
RELEASED should ever make it to the main branch.


Maybe I am the problem here (again) Maybe it is I that is concerned 
with the quality that is being committed and then glossed over with, it 
is ok, we can fix any resulting issues coming from that.


If everybody is happy to release 1.10, then so be it... here is my +0.

But I don't think this approach of cutting a release branch and then 
effectively having to maintain to development branches and what commits 
are applied to the correct branches is in any way maintainable..


--Udo

On 8/27/19 11:56 AM, Bruce Schuchardt wrote:

+1 for going ahead with the current release/1.10

On 8/27/19 11:31 AM, Dan Smith wrote:

+1 to creating RC1 with the current release/1.10 branch this week.

I don't see a fundamental problem with cherry-picking some targeted and
tested fixes to release/1.10, based on our assessment of the risk to
customers vs. the risk of destabilizing the branch. I think 
release/1.10 is

in a good state, and we should go ahead with the release.

-Dan


On Tue, Aug 27, 2019 at 9:28 AM Bruce Schuchardt 


wrote:


The "develop" branch has a refactoring of membership code that should
not be included in 1.10.  I waited until the release branch was cut to
push these changes.

On 8/26/19 4:06 PM, Udo Kohlmeyer wrote:

Hi there Apache Geode devs,

It has been some weeks since the proposed 1.10 release was cut. We've
gone through a few cycles where we keep on submitting "please include
ticket GEODE-XXX" because it is critical and will break the system.
WHICH in reality tells me that current develop is broken and unstable.

I'm going to suggest that we abandon the current 1.10 release branch.
I cannot shake the feeling that our continuous cherry picking into a
branch will result in either the branch becoming unmaintainable, given
we have only select fixes in the branch OR we end up with a branch
that is more stable than our current development branch, which would
result in us having to rebase the develop branch onto the 1.10 branch.

I propose that once we see the pipeline is clean and green for a solid
we then again attempt to cut 1.10 branch.

We CANNOT continue adding to a branch in order to stabilize it.. It
just means the branch we cut from is unstable. If we cannot cut a
branch from develop without having to have weeks of stabilization
cycles, then our main branch is broken...

Either way, not a good spot to be in.

Thoughts?

--Udo

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Kirk Lund]

Do folks actually want a 1.9.1 release?

On Wed, Aug 28, 2019 at 1:38 PM Owen Nichols  wrote:

> The VOTE for 1.9.1.RC1 failed due to lack of quorum, so re-opening this
> thread to continue the discussion.
>
> Is there still a need for a 1.9 patch release (especially given that
> 1.10.0.RC1 is expected later this week)?
>
> If so, perhaps we should back up a step or two and first:
> 1) come to rough consensus that 1.9.1 is still desired (and what should be
> in it)
> 2) ensure that we have Geode PMC support for this release
> 3) go through the formal process of voting each cherry-pick in the patch
> release
>
> This could result in a recommendation to re-vote on RC1, a recommendation
> to produce a new RC2, a recommendation to pull the plug (or no
> recommendation).
>
> As a failsafe, I hereby invoke lazy consensus: In the event that no
> explicit decision to move forward with 1.9.1 is reached by 3pm PDT Wed Sep
> 4, I will dismantle the current 1.9.1 branch, pipeline and nexus staging
> repo and remove 1.9.1 from the release notes wiki.
>
> -Owen
>
>
> > On Aug 18, 2019, at 7:52 AM, Anthony Baker  wrote:
> >
> > Yep. Get a release manager, identify and cherry pick all the changes,
> then do the release.
> >
> > Anthony
> >
> >> On Aug 16, 2019, at 4:21 PM, Kirk Lund  wrote:
> >>
> >> Does anyone know what the next step is? Do we need a release manager to
> >> proceed?
> >>
> >>> On Tue, Aug 13, 2019 at 1:57 PM John Blum  wrote:
> >>>
> >>> Sorry, corrections below...
> >>>
>  On Tue, Aug 13, 2019 at 1:54 PM John Blum  wrote:
> 
>  Stated slightly a different way...
> 
>  If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly,
> then
>  it would *defy* the dependency on Apache Geode pulled in by SDG
> Moore/2.2
>  (which is and can only be Geode 1.9 *at this point*) for which SBDG is
>  also based, along with Spring Boot 2.2, which pulls in SD Moore/2.2
> and
>  therefore Geode 1.9, *indirectly (i.e. transitively)*, as well.  As
> such,
>  the stars would not align and it would cause issues (or unexpected
>  surprises, possibly conflicts) for users of Spring Boot when also
> using
>  SBDG.  *With**out* SBDG, users of Spring Boot would get Geode 1.9 due
> to
>  the SD Moore/2.2 dependency, but with SBDG on the classpath, it would
>  suddenly (possibly) change the Geode version to 1.10.  That is
> >>> definitively
>  bad.
> 
>  Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9.
> 
>  SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not
>  available) which will pull in the latest version of Geode at that time
>  (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3 reaches
> RC
>  status.
> 
>  Cheers,
>  John
> 
> 
> 
> 
> > On Tue, Aug 13, 2019 at 1:45 PM John Blum  wrote:
> >
> > For clarification...
> >
> > 1. SBDG 1.1 is the "*current*" development line (on
> > <
> >>>
> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
> 
> > master
> > <
> >>>
> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
> >
> >>> [1]);
> > SBDG 1.2 is *not* yet in development.
> > 2. SBDG 1.1 is at RC1
> > 
> >>> [2].
> > 3. SBDG 1.1 is based on Spring Boot 2.1
> > <
> >>>
> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8
> >
> >>> [3]
> > and Spring Data (Geode) Lovelace
> > <
> >>>
> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12
> >
> >>> [4]
> > (or SDG 2.1
> > <
> >>>
> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10
> >
> >>> [5]);
> > This is not arbitrary because all the stars (bits, transitive
> dependency
> > versions) must "align" as defined by what Spring Boot 2.1 declares,
> and
> > Spring Boot 2.1 is based on
> > <
> >>>
> https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169
> >
> >>> [6]
> > Spring Data Lovelace/2.1.
> > 4. Spring Data Geode (SDG) Lovelace/2.1 is based on
> > <
> >>>
> https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25
> >
> >>> [7]
> > Apache Geode 1.6.
> > 5. All SDG Lovelace/2.1.x versions will always be based on the latest
> > Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of
> time.
> > This ship has sailed.
> >
> > 
> >
> > 6. SBDG 1.2, when it reaches development (soon),will be based on
> Spring
> > Boot 2.2
> > <
> >>>
> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8
> >
> >>> [8],
> > Spring Data (Geode) Moore
> > <
> >>>
> 

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Owen Nichols]

The VOTE for 1.9.1.RC1 failed due to lack of quorum, so re-opening this thread 
to continue the discussion.

Is there still a need for a 1.9 patch release (especially given that 1.10.0.RC1 
is expected later this week)?

If so, perhaps we should back up a step or two and first:
1) come to rough consensus that 1.9.1 is still desired (and what should be in 
it)
2) ensure that we have Geode PMC support for this release
3) go through the formal process of voting each cherry-pick in the patch release

This could result in a recommendation to re-vote on RC1, a recommendation to 
produce a new RC2, a recommendation to pull the plug (or no recommendation).

As a failsafe, I hereby invoke lazy consensus: In the event that no explicit 
decision to move forward with 1.9.1 is reached by 3pm PDT Wed Sep 4, I will 
dismantle the current 1.9.1 branch, pipeline and nexus staging repo and remove 
1.9.1 from the release notes wiki.

-Owen


> On Aug 18, 2019, at 7:52 AM, Anthony Baker  wrote:
> 
> Yep. Get a release manager, identify and cherry pick all the changes, then do 
> the release. 
> 
> Anthony
> 
>> On Aug 16, 2019, at 4:21 PM, Kirk Lund  wrote:
>> 
>> Does anyone know what the next step is? Do we need a release manager to
>> proceed?
>> 
>>> On Tue, Aug 13, 2019 at 1:57 PM John Blum  wrote:
>>> 
>>> Sorry, corrections below...
>>> 
 On Tue, Aug 13, 2019 at 1:54 PM John Blum  wrote:
 
 Stated slightly a different way...
 
 If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly, then
 it would *defy* the dependency on Apache Geode pulled in by SDG Moore/2.2
 (which is and can only be Geode 1.9 *at this point*) for which SBDG is
 also based, along with Spring Boot 2.2, which pulls in SD Moore/2.2 and
 therefore Geode 1.9, *indirectly (i.e. transitively)*, as well.  As such,
 the stars would not align and it would cause issues (or unexpected
 surprises, possibly conflicts) for users of Spring Boot when also using
 SBDG.  *With**out* SBDG, users of Spring Boot would get Geode 1.9 due to
 the SD Moore/2.2 dependency, but with SBDG on the classpath, it would
 suddenly (possibly) change the Geode version to 1.10.  That is
>>> definitively
 bad.
 
 Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9.
 
 SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not
 available) which will pull in the latest version of Geode at that time
 (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3 reaches RC
 status.
 
 Cheers,
 John
 
 
 
 
> On Tue, Aug 13, 2019 at 1:45 PM John Blum  wrote:
> 
> For clarification...
> 
> 1. SBDG 1.1 is the "*current*" development line (on
> <
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
 
> master
> <
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17>
>>> [1]);
> SBDG 1.2 is *not* yet in development.
> 2. SBDG 1.1 is at RC1
> 
>>> [2].
> 3. SBDG 1.1 is based on Spring Boot 2.1
> <
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8>
>>> [3]
> and Spring Data (Geode) Lovelace
> <
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12>
>>> [4]
> (or SDG 2.1
> <
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10>
>>> [5]);
> This is not arbitrary because all the stars (bits, transitive dependency
> versions) must "align" as defined by what Spring Boot 2.1 declares, and
> Spring Boot 2.1 is based on
> <
>>> https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169>
>>> [6]
> Spring Data Lovelace/2.1.
> 4. Spring Data Geode (SDG) Lovelace/2.1 is based on
> <
>>> https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25>
>>> [7]
> Apache Geode 1.6.
> 5. All SDG Lovelace/2.1.x versions will always be based on the latest
> Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of time.
> This ship has sailed.
> 
> 
> 
> 6. SBDG 1.2, when it reaches development (soon),will be based on Spring
> Boot 2.2
> <
>>> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8>
>>> [8],
> Spring Data (Geode) Moore
> <
>>> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12>
>>> [9]
> (or SDG 2.2
> <
>>> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10>
>>> [10]);
> This is also not arbitrary because Spring Boot 2.2 declares a dependency
> on
> <
>>> 

Re: [VOTE] Apache Geode 1.9.1 RC1

[Owen Nichols]

It's past the announced deadline and the vote has failed to due to lack of 
quorum.

Voting status
==
+1: zero votes

+0: zero votes

-0: zero votes

-1: zero votes

The voting does not meet the requirements 
 of at least 3 PMC members with 
+1 votes and a majority of +1 votes.

The matter of what to do next is referred back to the original DISCUSS thread 
that proposed 1.9.1.

-Owen & Kirk

> On Aug 22, 2019, at 6:10 PM, Owen Nichols  wrote:
> 
> Hello Geode dev community,
> 
> This is a release candidate for Apache Geode, version 1.9.1.RC1.
> Thanks to all the community members for their contributions to this release!
> 
> Please do a review and give your feedback. The deadline is 3PM PST Tue, 
> August 27 2019.
> Release notes can be found at: 
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
>  
> 
>  
> 
> Please note that we are voting on the source tag: rel/v1.9.1.RC1
> 
> Apache Geode:
> https://github.com/apache/geode/tree/rel/v1.9.1.RC1 
>  
> Apache Geode examples:
> https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1 
>  
> Apache Geode native:
> https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1 
>  
> 
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/ 
>  
> 
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1055 
>  
> 
> Geode's KEYS file containing PGP keys we use to sign the release:
> https://github.com/apache/geode/blob/develop/KEYS 
>  
> 
> PS: Command to run geode-examples: ./gradlew 
> -PgeodeReleaseUrl=https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1 
>  
> -PgeodeRepositoryUrl=https://repository.apache.org/content/repositories/orgapachegeode-1055
>   
> build runAll
> 
> Regards
> Owen Nichols & Kirk Lund
> 

warning about confused code

[Bruce Schuchardt]

I've seen several instances in Geode code where someone has modified a 
class or interface to make an object Serializable in order to make 
distributed unit testing easier.


In all of these instances people have made a class implement 
DataSerializable, which extends Serializable.  This allowed them to pass 
these objects from one JVM to another in distributed tests:


   final RegionAttributes attr = new RegionAttributesFactory().create();

   vm.invoke(() -> { do something with attr });

That "invoke" is an RMI call that is going to java-serialize "attr".  
It's not going to use DataSerializable serialization and invoke 
toData/fromData methods.  RegionAttributesImpl has plenty of instance 
variables that aren't serializable when they're not null, so it's just 
by luck that this worked at all.


Instead of changing a Geode class like that you should create the 
attributes object in the target JVM:


   vm.invoke(() -> {

    RegionAttributes attr = new RegionAttributesFactory().create();

    do something with attr

   });

Use of java serialization with classes that are DataSerializable is an 
iffy practice.  Let's stop doing it.