Re: [DISCUSS] Time to cut Geode 1.10.0?

[Owen Nichols]

There appears to be consensus that this is a critical fix.

The following commits have been brought into support/1.10.0 
 as the critical fix for 
GEODE-7051 :

git cherry-pick -x 413800bc16d05df689a2af5c30797f180aad6088 

git cherry-pick -x e1b61cdcaf38966bbb732b0b3db5223f2cc4f5e4 


GEODE-7051  has been marked 
as 'resolved in' 1.10.0.

-Owen

> On Aug 6, 2019, at 1:39 PM, Bruce Schuchardt  wrote:
> 
> +1
> 
> On 8/6/19 1:33 PM, Nabarun Nag wrote:
>> +1 on getting the Fix [Upgrade
>> log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
>> in the geode-core pom.] in.
>> 
>> 
>> Spring Data for Apache Geode has been removed from Spring Initializr
>> because of the issue with  log4j dependencies, also IntelliJ doesn't list
>> it as a NoSQL dependency. I would prefer that it is resolved in this
>> release and not wait for 3-4 months.
>> 
>> Regards
>> Naba
>> 
>> 
>> 
>> On Tue, Aug 6, 2019 at 1:00 PM Owen Nichols  wrote:
>> 
>>> Hi Kirk, thank you for bringing your concern.
>>> 
>>> Yes, release/1.10.0 was created last week <
>>> https://lists.apache.org/thread.html/4d4388ccab1170d94b8b6d204efe9197a4d3ddc2d25cbb6e6cecee0d@%3Cdev.geode.apache.org%3E>
>>> as planned.  Our current process <
>>> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E>
>>> dictates a time-based schedule to cut release branches.  Once cut, the
>>> “critical fixes” rule allows critical fixes to be brought to the release
>>> branch by proposal on the dev list.
>>> 
>>> Currently the 1.10.0 release pipeline <
>>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-main>
>>> is all green.  If there is consensus from the Geode community that this
>>> log4j change satisfies the “critical fixes” rule, Dick or I will be happy
>>> to bring it to the 1.10.0 release branch.
>>> 
>>> -Owen
>>> 
 On Aug 6, 2019, at 12:49 PM, Kirk Lund  wrote:
 
 Did we already cut the 1.10 branch?
 
 I'd like to find out if it's possible to get a change into 1.10: Upgrade
 log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
 in the geode-core pom.
 
 Getting this change into 1.10 will make things much easier for Spring
>>> Boot
 Data Geode. When using Geode with Spring Boot, log4j-core has to be
 manually excluded so that logback can be used instead. The change to
>>> log4j
 2.12.0 will also help as they have already have some dependency on 2.12.0
 (probably log4j-to-slf4j). I can find out more precise details if needed.
 
 On Wed, Jul 31, 2019 at 9:35 AM Dick Cavender  wrote:
 
> In preparation for cutting the release branch have we confirmed that
> Geode's LICENSE and NOTICE file been confirmed to accurately reflect
>>> what
> is being shipped for v1.10?
> 
> From Apache: http://www.apache.org/dev/licensing-howto.html
> *"*The LICENSE and NOTICE files must exactly represent the contents of
>>> the
> distribution they reside in."
> 
> Ideally this is kept up to date during development as the dependencies
> change or are added but this often is missed and needs to be reconciled
>>> on
> develop before we cut a release branch.
> 
> -Dick
> 
> 
> 
> 
> 
> On Tue, Jul 30, 2019 at 6:04 PM Owen Nichols 
>>> wrote:
>> From that email:
>> 
>> To make this work, it's important to be strict
>> about cutting the release branch on the set date and only allow
>>> critical
>> fixes after the release has been cut. Once we start compromising on
>>> this,
>> we go down a slippery slope that ultimately leads to not getting the
>> predictability benefits described here.
>> 
>> We are perilously close to the "slippery slope”:
>> * Geode 1.8.0 was announced on Dec 12 — almost 8 months ago
>> * Geode 1.9.0 was announced on Apr 25 — putting us about 5 weeks late
>> already on cutting the 1.10 branch
>> 
>> It seems like the community reaction to branching from the SHA
>>> initially
>> proposed is “woah, not quite yet”.
>> 
>> To get last-minute stuff in (or out) and get back on track, I propose
>> setting a strict CUT date for the 1.10 branch at 3PM PDT Thursday
>>> August
> 1.
>> -Owen
>> 
>> 
>>> On Jul 30, 2019, at 5:31 PM, Alexander Murmann 
>> wrote:
>>> Hi Karen,
>>> 
>>> Here is the previous discussion that was very positively received:
>>> 
>>> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
>>> However, JI

Re: [DISCUSS] Time to cut Geode 1.10.0?

[John Blum]

A couple of clarifications:


1.  First, and most importantly, Pivotal GemFire, specifically (Apache
Geode was never officially on *Spring Initializer*, actually) was removed
from *Spring Initializer* because *Spring Boot* *1.5.x* has finally
reached *End
of Life*.Pivotal GemFire existed as an "option" on *Spring Initializer*
only because *Spring Boot* *1.5.x* had (primarily) a *Starter
*
[1]
(and there was also an Example

[2]),
compliments of yours truly, ;-), roughly 4 years ago now.

It was *not* because of the *Log4j (core)* dependency.


2. Pivotal GemFire does not exist (as a Starter nor Example) in *Spring
Boot* (core) 2.0 and beyond (e.g. 2.1, 2.2, etc) today, primarily, because
of "licensing" and "legal" reasons.  There are other (technical) reasons
but legal & licensing pretty much trumps everything else.


3. Around the time *Spring Boot* 2.0 started up, Apache Geode had no (1.0)
GA version and had not yet graduated from Apache Incubator.  In short, we
cannot ship non-release, non-GA versions of dependencies with GA versions
of Boot, on *Initializer*.


4. Around this same time, most of the work I did in Boot for GemFire had 1)
already been rebased on Apache Geode and 2) started being migrated to what
you now know as the *Spring Boot for Apache Geode & Pivotal GemFire* (SBDG)
project on *GitHub*
 [3] (
*spring-boot-data-geode* repository).  So, it all depended on me at this
point to get back on *Initializer*.  SBDG needed to be an established
project (with users and few releases, etc).  Sorry for the delay.


5. Finally, yes, there is a problem
 [4]
between Apache Geode's Logging dependency/usage (specifically, on
org.apache.logging.log4j:log4j-core) and logging dependencies declared
by *Spring
Boot* when users declare a dependency on
org.springframework.boot:spring-boot-starter-logging (the "Starter" to
introduce logging into your *Spring Boot* application), which they often do
when building *Spring Boot* applications.

Essentially the problem is that the Log4j dependency versions declared by
Boot 2.2.x (Log4j 2.12

[5])
and used by Geode 1.9 (Log4j 2.11

[6])
do not line up, which causes issues when using the Log4j to SLF4J bridge
dependency (org.apache.logging.log4j:log4j-to-slf4j).  Most likely users
are using SLF4J in their applications and *Logback* as the logging
provider, and also wants all application dependencies (e.g. Geode) logging
to use the same logging configuration (hence the bridge).

I could explain the nuances of which version of all dependencies

[7]
that Spring Boot manages and when those dependencies are "updated" (e.g.
like moving from Log4j 2.11 to 2.12), but that is beyond the scope of this
already long email.



Anyway, sorry to derail the release email.  I just want to make sure we
understand this in no way holding up the *Spring Initializer* work being
done to include SBDG Starters on start.spring.io.  I have already taken the
necessary steps in SBDG to workaround #5.

However, I will say... *Kirk's* work is very important to us because it
makes it much easier and more consistent for users.  So, we highly support
this effort (i.e. the sooner the better).

I hope this helps.

Regards,
John



[1]
https://github.com/spring-projects/spring-boot/tree/1.5.x/spring-boot-starters/spring-boot-starter-data-gemfire
[2]
https://github.com/spring-projects/spring-boot/tree/1.5.x/spring-boot-samples/spring-boot-sample-data-gemfire
[3] https://github.com/spring-projects/spring-boot-data-geode
[4] https://github.com/spring-projects/spring-boot-data-geode/issues/42
[5]
https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L145
[6]
https://github.com/apache/geode/blob/rel/v1.9.0/boms/geode-all-bom/src/test/resources/expected-pom.xml#L461-L469
[7]
https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L37-L238


On Tue, Aug 6, 2019 at 2:21 PM Nabarun Nag  wrote:

> Hi,
>
> The commit mentioned in the earlier email has now been reverted on develop
> and release/1.10.0 branches.
> Thank you for your patience.
>
> Regards
> Nabarun Nag
>
>
> On Tue, Aug 6, 2019 at 2:13 PM Nabarun Nag  wrote:
>
> > Hi Geode Community,
> >
> > After some further analysis, few of the thr

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Nabarun Nag]

Hi,

The commit mentioned in the earlier email has now been reverted on develop
and release/1.10.0 branches.
Thank you for your patience.

Regards
Nabarun Nag


On Tue, Aug 6, 2019 at 2:13 PM Nabarun Nag  wrote:

> Hi Geode Community,
>
> After some further analysis, few of the threads are hanging in our
> application using the release branch. Here is an example stacktrace.
> *** Hung thread
>
> "vm_5_thr_5_client1_host1_21862" #457 daemon prio=5 os_prio=0 
> tid=0x7fc204009800 nid=0x69aa waiting on condition [0x7fc1de195000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>
>   - parking to wait for  <0xf10d8098> (a 
> java.util.concurrent.CountDownLatch$Sync)
>   at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
>
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
>   at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
>
>   at 
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
>
>   at 
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
>
>   at 
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
>
>   at 
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
>
>   at 
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
>
>   at 
> org.apache.geode.internal.cache.execute.FunctionStreamingResultCollector.waitForCacheOrFunctionException(FunctionStreamingResultCollector.java:439)
>
>   at 
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:90)
>
> We did some further investigation and we presume that it was introduced by
> the following commit.
> GEODE-6973: Use cachelistener to synchronize typeToId with IdToType r…
> (#3853)
>
> We are planning to revert this commit in the release branch as this is a
> necessary fix that needs to be in the release.
>
> Regards
> Nabarun Nag
>
>
>
> On Tue, Aug 6, 2019 at 1:39 PM Bruce Schuchardt 
> wrote:
>
>> +1
>>
>> On 8/6/19 1:33 PM, Nabarun Nag wrote:
>> > +1 on getting the Fix [Upgrade
>> > log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional
>> dependency
>> > in the geode-core pom.] in.
>> >
>> >
>> > Spring Data for Apache Geode has been removed from Spring Initializr
>> > because of the issue with  log4j dependencies, also IntelliJ doesn't
>> list
>> > it as a NoSQL dependency. I would prefer that it is resolved in this
>> > release and not wait for 3-4 months.
>> >
>> > Regards
>> > Naba
>> >
>> >
>> >
>> > On Tue, Aug 6, 2019 at 1:00 PM Owen Nichols 
>> wrote:
>> >
>> >> Hi Kirk, thank you for bringing your concern.
>> >>
>> >> Yes, release/1.10.0 was created last week <
>> >>
>> https://lists.apache.org/thread.html/4d4388ccab1170d94b8b6d204efe9197a4d3ddc2d25cbb6e6cecee0d@%3Cdev.geode.apache.org%3E
>> >
>> >> as planned.  Our current process <
>> >>
>> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
>> >
>> >> dictates a time-based schedule to cut release branches.  Once cut, the
>> >> “critical fixes” rule allows critical fixes to be brought to the
>> release
>> >> branch by proposal on the dev list.
>> >>
>> >> Currently the 1.10.0 release pipeline <
>> >>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-main
>> >
>> >> is all green.  If there is consensus from the Geode community that this
>> >> log4j change satisfies the “critical fixes” rule, Dick or I will be
>> happy
>> >> to bring it to the 1.10.0 release branch.
>> >>
>> >> -Owen
>> >>
>> >>> On Aug 6, 2019, at 12:49 PM, Kirk Lund  wrote:
>> >>>
>> >>> Did we already cut the 1.10 branch?
>> >>>
>> >>> I'd like to find out if it's possible to get a change into 1.10:
>> Upgrade
>> >>> log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional
>> dependency
>> >>> in the geode-core pom.
>> >>>
>> >>> Getting this change into 1.10 will make things much easier for Spring
>> >> Boot
>> >>> Data Geode. When using Geode with Spring Boot, log4j-core has to be
>> >>> manually excluded so that logback can be used instead. The change to
>> >> log4j
>> >>> 2.12.0 will also help as they have already have some dependency on
>> 2.12.0
>> >>> (probably log4j-to-slf4j). I can find out more precise details if
>> needed.
>> >>>
>> >>> On Wed, Jul 31, 2019 at 9:35 AM Dick Cavender 
>> wrote:
>> >>>
>>  In preparation for cutting the release branch have we confirmed that
>>  Geode's LICENSE and NOTICE file been confirmed to accurately refl

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Nabarun Nag]

Hi Geode Community,

After some further analysis, few of the threads are hanging in our
application using the release branch. Here is an example stacktrace.
*** Hung thread
"vm_5_thr_5_client1_host1_21862" #457 daemon prio=5 os_prio=0
tid=0x7fc204009800 nid=0x69aa waiting on condition
[0x7fc1de195000]
   java.lang.Thread.State: TIMED_WAITING (parking)
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  <0xf10d8098> (a
java.util.concurrent.CountDownLatch$Sync)
  at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
  at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
  at 
org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
  at 
org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
  at 
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
  at 
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
  at 
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
  at 
org.apache.geode.internal.cache.execute.FunctionStreamingResultCollector.waitForCacheOrFunctionException(FunctionStreamingResultCollector.java:439)
  at 
org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:90)

We did some further investigation and we presume that it was introduced by
the following commit.
GEODE-6973: Use cachelistener to synchronize typeToId with IdToType r…
(#3853)

We are planning to revert this commit in the release branch as this is a
necessary fix that needs to be in the release.

Regards
Nabarun Nag



On Tue, Aug 6, 2019 at 1:39 PM Bruce Schuchardt 
wrote:

> +1
>
> On 8/6/19 1:33 PM, Nabarun Nag wrote:
> > +1 on getting the Fix [Upgrade
> > log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
> > in the geode-core pom.] in.
> >
> >
> > Spring Data for Apache Geode has been removed from Spring Initializr
> > because of the issue with  log4j dependencies, also IntelliJ doesn't list
> > it as a NoSQL dependency. I would prefer that it is resolved in this
> > release and not wait for 3-4 months.
> >
> > Regards
> > Naba
> >
> >
> >
> > On Tue, Aug 6, 2019 at 1:00 PM Owen Nichols  wrote:
> >
> >> Hi Kirk, thank you for bringing your concern.
> >>
> >> Yes, release/1.10.0 was created last week <
> >>
> https://lists.apache.org/thread.html/4d4388ccab1170d94b8b6d204efe9197a4d3ddc2d25cbb6e6cecee0d@%3Cdev.geode.apache.org%3E
> >
> >> as planned.  Our current process <
> >>
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> >
> >> dictates a time-based schedule to cut release branches.  Once cut, the
> >> “critical fixes” rule allows critical fixes to be brought to the release
> >> branch by proposal on the dev list.
> >>
> >> Currently the 1.10.0 release pipeline <
> >>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-main
> >
> >> is all green.  If there is consensus from the Geode community that this
> >> log4j change satisfies the “critical fixes” rule, Dick or I will be
> happy
> >> to bring it to the 1.10.0 release branch.
> >>
> >> -Owen
> >>
> >>> On Aug 6, 2019, at 12:49 PM, Kirk Lund  wrote:
> >>>
> >>> Did we already cut the 1.10 branch?
> >>>
> >>> I'd like to find out if it's possible to get a change into 1.10:
> Upgrade
> >>> log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional
> dependency
> >>> in the geode-core pom.
> >>>
> >>> Getting this change into 1.10 will make things much easier for Spring
> >> Boot
> >>> Data Geode. When using Geode with Spring Boot, log4j-core has to be
> >>> manually excluded so that logback can be used instead. The change to
> >> log4j
> >>> 2.12.0 will also help as they have already have some dependency on
> 2.12.0
> >>> (probably log4j-to-slf4j). I can find out more precise details if
> needed.
> >>>
> >>> On Wed, Jul 31, 2019 at 9:35 AM Dick Cavender 
> wrote:
> >>>
>  In preparation for cutting the release branch have we confirmed that
>  Geode's LICENSE and NOTICE file been confirmed to accurately reflect
> >> what
>  is being shipped for v1.10?
> 
>   From Apache: http://www.apache.org/dev/licensing-howto.html
>  *"*The LICENSE and NOTICE files must exactly represent the contents of
> >> the
>  distribution they reside in."
> 
>  Ideally this is kept up to date during development as the dependencies
>  change or are added but this often is missed and needs to be
> reco

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Bruce Schuchardt]

+1

On 8/6/19 1:33 PM, Nabarun Nag wrote:

+1 on getting the Fix [Upgrade
log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
in the geode-core pom.] in.


Spring Data for Apache Geode has been removed from Spring Initializr
because of the issue with  log4j dependencies, also IntelliJ doesn't list
it as a NoSQL dependency. I would prefer that it is resolved in this
release and not wait for 3-4 months.

Regards
Naba



On Tue, Aug 6, 2019 at 1:00 PM Owen Nichols  wrote:


Hi Kirk, thank you for bringing your concern.

Yes, release/1.10.0 was created last week <
https://lists.apache.org/thread.html/4d4388ccab1170d94b8b6d204efe9197a4d3ddc2d25cbb6e6cecee0d@%3Cdev.geode.apache.org%3E>
as planned.  Our current process <
https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E>
dictates a time-based schedule to cut release branches.  Once cut, the
“critical fixes” rule allows critical fixes to be brought to the release
branch by proposal on the dev list.

Currently the 1.10.0 release pipeline <
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-main>
is all green.  If there is consensus from the Geode community that this
log4j change satisfies the “critical fixes” rule, Dick or I will be happy
to bring it to the 1.10.0 release branch.

-Owen


On Aug 6, 2019, at 12:49 PM, Kirk Lund  wrote:

Did we already cut the 1.10 branch?

I'd like to find out if it's possible to get a change into 1.10: Upgrade
log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
in the geode-core pom.

Getting this change into 1.10 will make things much easier for Spring

Boot

Data Geode. When using Geode with Spring Boot, log4j-core has to be
manually excluded so that logback can be used instead. The change to

log4j

2.12.0 will also help as they have already have some dependency on 2.12.0
(probably log4j-to-slf4j). I can find out more precise details if needed.

On Wed, Jul 31, 2019 at 9:35 AM Dick Cavender  wrote:


In preparation for cutting the release branch have we confirmed that
Geode's LICENSE and NOTICE file been confirmed to accurately reflect

what

is being shipped for v1.10?

 From Apache: http://www.apache.org/dev/licensing-howto.html
*"*The LICENSE and NOTICE files must exactly represent the contents of

the

distribution they reside in."

Ideally this is kept up to date during development as the dependencies
change or are added but this often is missed and needs to be reconciled

on

develop before we cut a release branch.

-Dick





On Tue, Jul 30, 2019 at 6:04 PM Owen Nichols 

wrote:

 From that email:

To make this work, it's important to be strict
about cutting the release branch on the set date and only allow

critical

fixes after the release has been cut. Once we start compromising on

this,

we go down a slippery slope that ultimately leads to not getting the
predictability benefits described here.

We are perilously close to the "slippery slope”:
* Geode 1.8.0 was announced on Dec 12 — almost 8 months ago
* Geode 1.9.0 was announced on Apr 25 — putting us about 5 weeks late
already on cutting the 1.10 branch

It seems like the community reaction to branching from the SHA

initially

proposed is “woah, not quite yet”.

To get last-minute stuff in (or out) and get back on track, I propose
setting a strict CUT date for the 1.10 branch at 3PM PDT Thursday

August

1.

-Owen



On Jul 30, 2019, at 5:31 PM, Alexander Murmann 

wrote:

Hi Karen,

Here is the previous discussion that was very positively received:


https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E

However, JIRA tells me that GEODE-7013 is already fixed. If we were to

go

with a SHA from this week, for which Jake also chimed in with plenty

of

reasons, this should be in the release.

On Tue, Jul 30, 2019 at 5:10 PM Karen Miller 

wrote:

Alexander, can you point me at the policy decision for the "critical

issue"

rule you mention? I always though it was up
to the release manager.

I want GEODE-7013 fixes in because it is the right thing to do.  Our

gfsh

help/hint wasn't working the way we say that it did.
With the fix, it does.  I want either the documentation to match the

code,

or I want the code to match the documentation.
The fix in GEODE-7013 changes the code to match the existing

documentation,

so we don't have to change the documentation
(which would have needed to be cherry-picked into our 1.10 release

branch).


On Tue, Jul 30, 2019 at 11:47 AM Owen Nichols 

wrote:

Our "critical issue” rule has the effect that the bar to commit to

develop

is “low”, but the bar to cherry-pick to support branch is “very

high”.

Contributors could plan around this disparity more easily if any of

the

following were true:
- releases were more frequent
- planned cut date of release branch was announced in advance

(rather

than

retroactively)
- 

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Nabarun Nag]

+1 on getting the Fix [Upgrade
log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
in the geode-core pom.] in.


Spring Data for Apache Geode has been removed from Spring Initializr
because of the issue with  log4j dependencies, also IntelliJ doesn't list
it as a NoSQL dependency. I would prefer that it is resolved in this
release and not wait for 3-4 months.

Regards
Naba



On Tue, Aug 6, 2019 at 1:00 PM Owen Nichols  wrote:

> Hi Kirk, thank you for bringing your concern.
>
> Yes, release/1.10.0 was created last week <
> https://lists.apache.org/thread.html/4d4388ccab1170d94b8b6d204efe9197a4d3ddc2d25cbb6e6cecee0d@%3Cdev.geode.apache.org%3E>
> as planned.  Our current process <
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E>
> dictates a time-based schedule to cut release branches.  Once cut, the
> “critical fixes” rule allows critical fixes to be brought to the release
> branch by proposal on the dev list.
>
> Currently the 1.10.0 release pipeline <
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-main>
> is all green.  If there is consensus from the Geode community that this
> log4j change satisfies the “critical fixes” rule, Dick or I will be happy
> to bring it to the 1.10.0 release branch.
>
> -Owen
>
> > On Aug 6, 2019, at 12:49 PM, Kirk Lund  wrote:
> >
> > Did we already cut the 1.10 branch?
> >
> > I'd like to find out if it's possible to get a change into 1.10: Upgrade
> > log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
> > in the geode-core pom.
> >
> > Getting this change into 1.10 will make things much easier for Spring
> Boot
> > Data Geode. When using Geode with Spring Boot, log4j-core has to be
> > manually excluded so that logback can be used instead. The change to
> log4j
> > 2.12.0 will also help as they have already have some dependency on 2.12.0
> > (probably log4j-to-slf4j). I can find out more precise details if needed.
> >
> > On Wed, Jul 31, 2019 at 9:35 AM Dick Cavender  wrote:
> >
> >> In preparation for cutting the release branch have we confirmed that
> >> Geode's LICENSE and NOTICE file been confirmed to accurately reflect
> what
> >> is being shipped for v1.10?
> >>
> >> From Apache: http://www.apache.org/dev/licensing-howto.html
> >> *"*The LICENSE and NOTICE files must exactly represent the contents of
> the
> >> distribution they reside in."
> >>
> >> Ideally this is kept up to date during development as the dependencies
> >> change or are added but this often is missed and needs to be reconciled
> on
> >> develop before we cut a release branch.
> >>
> >> -Dick
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Jul 30, 2019 at 6:04 PM Owen Nichols 
> wrote:
> >>
> >>> From that email:
> >>>
> >>> To make this work, it's important to be strict
> >>> about cutting the release branch on the set date and only allow
> critical
> >>> fixes after the release has been cut. Once we start compromising on
> this,
> >>> we go down a slippery slope that ultimately leads to not getting the
> >>> predictability benefits described here.
> >>>
> >>> We are perilously close to the "slippery slope”:
> >>> * Geode 1.8.0 was announced on Dec 12 — almost 8 months ago
> >>> * Geode 1.9.0 was announced on Apr 25 — putting us about 5 weeks late
> >>> already on cutting the 1.10 branch
> >>>
> >>> It seems like the community reaction to branching from the SHA
> initially
> >>> proposed is “woah, not quite yet”.
> >>>
> >>> To get last-minute stuff in (or out) and get back on track, I propose
> >>> setting a strict CUT date for the 1.10 branch at 3PM PDT Thursday
> August
> >> 1.
> >>>
> >>> -Owen
> >>>
> >>>
>  On Jul 30, 2019, at 5:31 PM, Alexander Murmann 
> >>> wrote:
> 
>  Hi Karen,
> 
>  Here is the previous discussion that was very positively received:
> 
> >>>
> >>
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> 
>  However, JIRA tells me that GEODE-7013 is already fixed. If we were to
> >> go
>  with a SHA from this week, for which Jake also chimed in with plenty
> of
>  reasons, this should be in the release.
> 
>  On Tue, Jul 30, 2019 at 5:10 PM Karen Miller 
> >> wrote:
> 
> > Alexander, can you point me at the policy decision for the "critical
> >>> issue"
> > rule you mention? I always though it was up
> > to the release manager.
> >
> > I want GEODE-7013 fixes in because it is the right thing to do.  Our
> >>> gfsh
> > help/hint wasn't working the way we say that it did.
> > With the fix, it does.  I want either the documentation to match the
> >>> code,
> > or I want the code to match the documentation.
> > The fix in GEODE-7013 changes the code to match the existing
> >>> documentation,
> > so we don't have to change the documentation
> > (which would have needed to be

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Owen Nichols]

Hi Kirk, thank you for bringing your concern.

Yes, release/1.10.0 was created last week 

 as planned.  Our current process 

 dictates a time-based schedule to cut release branches.  Once cut, the 
“critical fixes” rule allows critical fixes to be brought to the release branch 
by proposal on the dev list.

Currently the 1.10.0 release pipeline 

 is all green.  If there is consensus from the Geode community that this log4j 
change satisfies the “critical fixes” rule, Dick or I will be happy to bring it 
to the 1.10.0 release branch.

-Owen

> On Aug 6, 2019, at 12:49 PM, Kirk Lund  wrote:
> 
> Did we already cut the 1.10 branch?
> 
> I'd like to find out if it's possible to get a change into 1.10: Upgrade
> log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
> in the geode-core pom.
> 
> Getting this change into 1.10 will make things much easier for Spring Boot
> Data Geode. When using Geode with Spring Boot, log4j-core has to be
> manually excluded so that logback can be used instead. The change to log4j
> 2.12.0 will also help as they have already have some dependency on 2.12.0
> (probably log4j-to-slf4j). I can find out more precise details if needed.
> 
> On Wed, Jul 31, 2019 at 9:35 AM Dick Cavender  wrote:
> 
>> In preparation for cutting the release branch have we confirmed that
>> Geode's LICENSE and NOTICE file been confirmed to accurately reflect what
>> is being shipped for v1.10?
>> 
>> From Apache: http://www.apache.org/dev/licensing-howto.html
>> *"*The LICENSE and NOTICE files must exactly represent the contents of the
>> distribution they reside in."
>> 
>> Ideally this is kept up to date during development as the dependencies
>> change or are added but this often is missed and needs to be reconciled on
>> develop before we cut a release branch.
>> 
>> -Dick
>> 
>> 
>> 
>> 
>> 
>> On Tue, Jul 30, 2019 at 6:04 PM Owen Nichols  wrote:
>> 
>>> From that email:
>>> 
>>> To make this work, it's important to be strict
>>> about cutting the release branch on the set date and only allow critical
>>> fixes after the release has been cut. Once we start compromising on this,
>>> we go down a slippery slope that ultimately leads to not getting the
>>> predictability benefits described here.
>>> 
>>> We are perilously close to the "slippery slope”:
>>> * Geode 1.8.0 was announced on Dec 12 — almost 8 months ago
>>> * Geode 1.9.0 was announced on Apr 25 — putting us about 5 weeks late
>>> already on cutting the 1.10 branch
>>> 
>>> It seems like the community reaction to branching from the SHA initially
>>> proposed is “woah, not quite yet”.
>>> 
>>> To get last-minute stuff in (or out) and get back on track, I propose
>>> setting a strict CUT date for the 1.10 branch at 3PM PDT Thursday August
>> 1.
>>> 
>>> -Owen
>>> 
>>> 
 On Jul 30, 2019, at 5:31 PM, Alexander Murmann 
>>> wrote:
 
 Hi Karen,
 
 Here is the previous discussion that was very positively received:
 
>>> 
>> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
 
 However, JIRA tells me that GEODE-7013 is already fixed. If we were to
>> go
 with a SHA from this week, for which Jake also chimed in with plenty of
 reasons, this should be in the release.
 
 On Tue, Jul 30, 2019 at 5:10 PM Karen Miller 
>> wrote:
 
> Alexander, can you point me at the policy decision for the "critical
>>> issue"
> rule you mention? I always though it was up
> to the release manager.
> 
> I want GEODE-7013 fixes in because it is the right thing to do.  Our
>>> gfsh
> help/hint wasn't working the way we say that it did.
> With the fix, it does.  I want either the documentation to match the
>>> code,
> or I want the code to match the documentation.
> The fix in GEODE-7013 changes the code to match the existing
>>> documentation,
> so we don't have to change the documentation
> (which would have needed to be cherry-picked into our 1.10 release
>>> branch).
> 
> 
> On Tue, Jul 30, 2019 at 11:47 AM Owen Nichols 
>>> wrote:
> 
>> Our "critical issue” rule has the effect that the bar to commit to
> develop
>> is “low”, but the bar to cherry-pick to support branch is “very
>> high”.
>> 
>> Contributors could plan around this disparity more easily if any of
>> the
>> following were true:
>> - releases were more frequent
>> - planned cut date of release branch was announced in advance (rather
> than
>> retroactively)
>> - a process existed for making exceptions to the “critical issue”
>> rule
>> 

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Kirk Lund]

Did we already cut the 1.10 branch?

I'd like to find out if it's possible to get a change into 1.10: Upgrade
log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
in the geode-core pom.

Getting this change into 1.10 will make things much easier for Spring Boot
Data Geode. When using Geode with Spring Boot, log4j-core has to be
manually excluded so that logback can be used instead. The change to log4j
2.12.0 will also help as they have already have some dependency on 2.12.0
(probably log4j-to-slf4j). I can find out more precise details if needed.

On Wed, Jul 31, 2019 at 9:35 AM Dick Cavender  wrote:

> In preparation for cutting the release branch have we confirmed that
> Geode's LICENSE and NOTICE file been confirmed to accurately reflect what
> is being shipped for v1.10?
>
> From Apache: http://www.apache.org/dev/licensing-howto.html
> *"*The LICENSE and NOTICE files must exactly represent the contents of the
> distribution they reside in."
>
> Ideally this is kept up to date during development as the dependencies
> change or are added but this often is missed and needs to be reconciled on
> develop before we cut a release branch.
>
> -Dick
>
>
>
>
>
> On Tue, Jul 30, 2019 at 6:04 PM Owen Nichols  wrote:
>
> > From that email:
> >
> > To make this work, it's important to be strict
> > about cutting the release branch on the set date and only allow critical
> > fixes after the release has been cut. Once we start compromising on this,
> > we go down a slippery slope that ultimately leads to not getting the
> > predictability benefits described here.
> >
> > We are perilously close to the "slippery slope”:
> > * Geode 1.8.0 was announced on Dec 12 — almost 8 months ago
> > * Geode 1.9.0 was announced on Apr 25 — putting us about 5 weeks late
> > already on cutting the 1.10 branch
> >
> > It seems like the community reaction to branching from the SHA initially
> > proposed is “woah, not quite yet”.
> >
> > To get last-minute stuff in (or out) and get back on track, I propose
> > setting a strict CUT date for the 1.10 branch at 3PM PDT Thursday August
> 1.
> >
> > -Owen
> >
> >
> > > On Jul 30, 2019, at 5:31 PM, Alexander Murmann 
> > wrote:
> > >
> > > Hi Karen,
> > >
> > > Here is the previous discussion that was very positively received:
> > >
> >
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> > >
> > > However, JIRA tells me that GEODE-7013 is already fixed. If we were to
> go
> > > with a SHA from this week, for which Jake also chimed in with plenty of
> > > reasons, this should be in the release.
> > >
> > > On Tue, Jul 30, 2019 at 5:10 PM Karen Miller 
> wrote:
> > >
> > >> Alexander, can you point me at the policy decision for the "critical
> > issue"
> > >> rule you mention? I always though it was up
> > >> to the release manager.
> > >>
> > >> I want GEODE-7013 fixes in because it is the right thing to do.  Our
> > gfsh
> > >> help/hint wasn't working the way we say that it did.
> > >> With the fix, it does.  I want either the documentation to match the
> > code,
> > >> or I want the code to match the documentation.
> > >> The fix in GEODE-7013 changes the code to match the existing
> > documentation,
> > >> so we don't have to change the documentation
> > >> (which would have needed to be cherry-picked into our 1.10 release
> > branch).
> > >>
> > >>
> > >> On Tue, Jul 30, 2019 at 11:47 AM Owen Nichols 
> > wrote:
> > >>
> > >>> Our "critical issue” rule has the effect that the bar to commit to
> > >> develop
> > >>> is “low”, but the bar to cherry-pick to support branch is “very
> high”.
> > >>>
> > >>> Contributors could plan around this disparity more easily if any of
> the
> > >>> following were true:
> > >>> - releases were more frequent
> > >>> - planned cut date of release branch was announced in advance (rather
> > >> than
> > >>> retroactively)
> > >>> - a process existed for making exceptions to the “critical issue”
> rule
> > >>>
> > >>> I agree that the proposed SHA looks like a relatively stable
> > branchpoint
> > >>> (coming near the end of a nice period of solid green in the
> pipeline),
> > >> and
> > >>> I acknowledge that fair warning was given a week ago that a branch
> was
> > >>> “coming soon”, but I wonder if there is anything we can do to make
> the
> > >>> rules for what gets in a release and what doesn’t feel a little less
> > >>> arbitrary?
> > >>>
> > >>> -Owen
> > >>>
> > >>>
> >  On Jul 30, 2019, at 11:16 AM, Alexander Murmann <
> amurm...@apache.org>
> > >>> wrote:
> > 
> >  Dick, thank you for stepping up!
> > 
> >  I think it's great to cut the branch sooner rather than later. There
> >  already is GEODE-7012 which introduces a distributed deadlock during
> >  startup. That seems like a critical issue to fix. That should be
> able
> > >> to
> >  happen after we cut the branch though.
> > 
> >  Karen, I wonder if that could be m

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Dick Cavender]

In preparation for cutting the release branch have we confirmed that
Geode's LICENSE and NOTICE file been confirmed to accurately reflect what
is being shipped for v1.10?

>From Apache: http://www.apache.org/dev/licensing-howto.html
*"*The LICENSE and NOTICE files must exactly represent the contents of the
distribution they reside in."

Ideally this is kept up to date during development as the dependencies
change or are added but this often is missed and needs to be reconciled on
develop before we cut a release branch.

-Dick





On Tue, Jul 30, 2019 at 6:04 PM Owen Nichols  wrote:

> From that email:
>
> To make this work, it's important to be strict
> about cutting the release branch on the set date and only allow critical
> fixes after the release has been cut. Once we start compromising on this,
> we go down a slippery slope that ultimately leads to not getting the
> predictability benefits described here.
>
> We are perilously close to the "slippery slope”:
> * Geode 1.8.0 was announced on Dec 12 — almost 8 months ago
> * Geode 1.9.0 was announced on Apr 25 — putting us about 5 weeks late
> already on cutting the 1.10 branch
>
> It seems like the community reaction to branching from the SHA initially
> proposed is “woah, not quite yet”.
>
> To get last-minute stuff in (or out) and get back on track, I propose
> setting a strict CUT date for the 1.10 branch at 3PM PDT Thursday August 1.
>
> -Owen
>
>
> > On Jul 30, 2019, at 5:31 PM, Alexander Murmann 
> wrote:
> >
> > Hi Karen,
> >
> > Here is the previous discussion that was very positively received:
> >
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> >
> > However, JIRA tells me that GEODE-7013 is already fixed. If we were to go
> > with a SHA from this week, for which Jake also chimed in with plenty of
> > reasons, this should be in the release.
> >
> > On Tue, Jul 30, 2019 at 5:10 PM Karen Miller  wrote:
> >
> >> Alexander, can you point me at the policy decision for the "critical
> issue"
> >> rule you mention? I always though it was up
> >> to the release manager.
> >>
> >> I want GEODE-7013 fixes in because it is the right thing to do.  Our
> gfsh
> >> help/hint wasn't working the way we say that it did.
> >> With the fix, it does.  I want either the documentation to match the
> code,
> >> or I want the code to match the documentation.
> >> The fix in GEODE-7013 changes the code to match the existing
> documentation,
> >> so we don't have to change the documentation
> >> (which would have needed to be cherry-picked into our 1.10 release
> branch).
> >>
> >>
> >> On Tue, Jul 30, 2019 at 11:47 AM Owen Nichols 
> wrote:
> >>
> >>> Our "critical issue” rule has the effect that the bar to commit to
> >> develop
> >>> is “low”, but the bar to cherry-pick to support branch is “very high”.
> >>>
> >>> Contributors could plan around this disparity more easily if any of the
> >>> following were true:
> >>> - releases were more frequent
> >>> - planned cut date of release branch was announced in advance (rather
> >> than
> >>> retroactively)
> >>> - a process existed for making exceptions to the “critical issue” rule
> >>>
> >>> I agree that the proposed SHA looks like a relatively stable
> branchpoint
> >>> (coming near the end of a nice period of solid green in the pipeline),
> >> and
> >>> I acknowledge that fair warning was given a week ago that a branch was
> >>> “coming soon”, but I wonder if there is anything we can do to make the
> >>> rules for what gets in a release and what doesn’t feel a little less
> >>> arbitrary?
> >>>
> >>> -Owen
> >>>
> >>>
>  On Jul 30, 2019, at 11:16 AM, Alexander Murmann 
> >>> wrote:
> 
>  Dick, thank you for stepping up!
> 
>  I think it's great to cut the branch sooner rather than later. There
>  already is GEODE-7012 which introduces a distributed deadlock during
>  startup. That seems like a critical issue to fix. That should be able
> >> to
>  happen after we cut the branch though.
> 
>  Karen, I wonder if that could be merged after the branch got cut, but
> >>> also
>  wonder if that fits our "critical issue" rule for being merged after
> >> the
>  branch has been cut or hold up the release. This has been broken since
> >> a
>  very long time. Thoughts?
> 
>  On Tue, Jul 30, 2019 at 10:51 AM Karen Miller 
> >>> wrote:
> 
> > I'd like to see the changes from
> > https://issues.apache.org/jira/browse/GEODE-7013 included in the
> >> Geode
> > 1.10
> > release. GEODE-7013's changes restore gfsh help/hint behavior that
> was
> >>> lost
> > during a refactor in the earliest
> > releases of Geode.  The commit occurred after SHA1
> > dc6890107a2651d8ba1450e8db8a1c39d712fdc7.
> > Thanks.  Karen
> >
> >
> > On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender 
> >>> wrote:
> >
> >> I'll take on the Release Manager role for Geode 1.10 with

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Owen Nichols]

From that email:

To make this work, it's important to be strict
about cutting the release branch on the set date and only allow critical
fixes after the release has been cut. Once we start compromising on this,
we go down a slippery slope that ultimately leads to not getting the
predictability benefits described here.

We are perilously close to the "slippery slope”:
* Geode 1.8.0 was announced on Dec 12 — almost 8 months ago
* Geode 1.9.0 was announced on Apr 25 — putting us about 5 weeks late already 
on cutting the 1.10 branch 

It seems like the community reaction to branching from the SHA initially 
proposed is “woah, not quite yet”.  

To get last-minute stuff in (or out) and get back on track, I propose setting a 
strict CUT date for the 1.10 branch at 3PM PDT Thursday August 1.

-Owen


> On Jul 30, 2019, at 5:31 PM, Alexander Murmann  wrote:
> 
> Hi Karen,
> 
> Here is the previous discussion that was very positively received:
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> 
> However, JIRA tells me that GEODE-7013 is already fixed. If we were to go
> with a SHA from this week, for which Jake also chimed in with plenty of
> reasons, this should be in the release.
> 
> On Tue, Jul 30, 2019 at 5:10 PM Karen Miller  wrote:
> 
>> Alexander, can you point me at the policy decision for the "critical issue"
>> rule you mention? I always though it was up
>> to the release manager.
>> 
>> I want GEODE-7013 fixes in because it is the right thing to do.  Our gfsh
>> help/hint wasn't working the way we say that it did.
>> With the fix, it does.  I want either the documentation to match the code,
>> or I want the code to match the documentation.
>> The fix in GEODE-7013 changes the code to match the existing documentation,
>> so we don't have to change the documentation
>> (which would have needed to be cherry-picked into our 1.10 release branch).
>> 
>> 
>> On Tue, Jul 30, 2019 at 11:47 AM Owen Nichols  wrote:
>> 
>>> Our "critical issue” rule has the effect that the bar to commit to
>> develop
>>> is “low”, but the bar to cherry-pick to support branch is “very high”.
>>> 
>>> Contributors could plan around this disparity more easily if any of the
>>> following were true:
>>> - releases were more frequent
>>> - planned cut date of release branch was announced in advance (rather
>> than
>>> retroactively)
>>> - a process existed for making exceptions to the “critical issue” rule
>>> 
>>> I agree that the proposed SHA looks like a relatively stable branchpoint
>>> (coming near the end of a nice period of solid green in the pipeline),
>> and
>>> I acknowledge that fair warning was given a week ago that a branch was
>>> “coming soon”, but I wonder if there is anything we can do to make the
>>> rules for what gets in a release and what doesn’t feel a little less
>>> arbitrary?
>>> 
>>> -Owen
>>> 
>>> 
 On Jul 30, 2019, at 11:16 AM, Alexander Murmann 
>>> wrote:
 
 Dick, thank you for stepping up!
 
 I think it's great to cut the branch sooner rather than later. There
 already is GEODE-7012 which introduces a distributed deadlock during
 startup. That seems like a critical issue to fix. That should be able
>> to
 happen after we cut the branch though.
 
 Karen, I wonder if that could be merged after the branch got cut, but
>>> also
 wonder if that fits our "critical issue" rule for being merged after
>> the
 branch has been cut or hold up the release. This has been broken since
>> a
 very long time. Thoughts?
 
 On Tue, Jul 30, 2019 at 10:51 AM Karen Miller 
>>> wrote:
 
> I'd like to see the changes from
> https://issues.apache.org/jira/browse/GEODE-7013 included in the
>> Geode
> 1.10
> release. GEODE-7013's changes restore gfsh help/hint behavior that was
>>> lost
> during a refactor in the earliest
> releases of Geode.  The commit occurred after SHA1
> dc6890107a2651d8ba1450e8db8a1c39d712fdc7.
> Thanks.  Karen
> 
> 
> On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender 
>>> wrote:
> 
>> I'll take on the Release Manager role for Geode 1.10 with the 1.9.0
> release
>> manager's help (Owen:).
>> 
>> I'd like to propose cutting the release/1.10 branch off develop sha:
>> dc6890107a2651d8ba1450e8db8a1c39d712fdc7
>> 
>> aka: 1.10.0-SNAPSHOT.476
>> 
>> Please speak up and discuss. We'll then start taking considerations
>> for
>> additional changes for 1.1.0 after we get the branch and pipeline in
> place.
>> 
>> -Dick
>> 
>> 
>> 
>> 
>> On Mon, Jul 29, 2019 at 4:08 PM Alexander Murmann <
>> amurm...@apache.org
 
>> wrote:
>> 
>>> Thanks for calling this out Ernie!
>>> 
>>> It might be a good idea to cut the release and at the same time keep
>>> looking for urgent issues that need to be resolved and merged. Once
>>> the
>>> branch 

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Alexander Murmann]

Hi Karen,

Here is the previous discussion that was very positively received:
https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E

However, JIRA tells me that GEODE-7013 is already fixed. If we were to go
with a SHA from this week, for which Jake also chimed in with plenty of
reasons, this should be in the release.

On Tue, Jul 30, 2019 at 5:10 PM Karen Miller  wrote:

> Alexander, can you point me at the policy decision for the "critical issue"
> rule you mention? I always though it was up
> to the release manager.
>
> I want GEODE-7013 fixes in because it is the right thing to do.  Our gfsh
> help/hint wasn't working the way we say that it did.
> With the fix, it does.  I want either the documentation to match the code,
> or I want the code to match the documentation.
> The fix in GEODE-7013 changes the code to match the existing documentation,
> so we don't have to change the documentation
> (which would have needed to be cherry-picked into our 1.10 release branch).
>
>
> On Tue, Jul 30, 2019 at 11:47 AM Owen Nichols  wrote:
>
> > Our "critical issue” rule has the effect that the bar to commit to
> develop
> > is “low”, but the bar to cherry-pick to support branch is “very high”.
> >
> > Contributors could plan around this disparity more easily if any of the
> > following were true:
> > - releases were more frequent
> > - planned cut date of release branch was announced in advance (rather
> than
> > retroactively)
> > - a process existed for making exceptions to the “critical issue” rule
> >
> > I agree that the proposed SHA looks like a relatively stable branchpoint
> > (coming near the end of a nice period of solid green in the pipeline),
> and
> > I acknowledge that fair warning was given a week ago that a branch was
> > “coming soon”, but I wonder if there is anything we can do to make the
> > rules for what gets in a release and what doesn’t feel a little less
> > arbitrary?
> >
> > -Owen
> >
> >
> > > On Jul 30, 2019, at 11:16 AM, Alexander Murmann 
> > wrote:
> > >
> > > Dick, thank you for stepping up!
> > >
> > > I think it's great to cut the branch sooner rather than later. There
> > > already is GEODE-7012 which introduces a distributed deadlock during
> > > startup. That seems like a critical issue to fix. That should be able
> to
> > > happen after we cut the branch though.
> > >
> > > Karen, I wonder if that could be merged after the branch got cut, but
> > also
> > > wonder if that fits our "critical issue" rule for being merged after
> the
> > > branch has been cut or hold up the release. This has been broken since
> a
> > > very long time. Thoughts?
> > >
> > > On Tue, Jul 30, 2019 at 10:51 AM Karen Miller 
> > wrote:
> > >
> > >> I'd like to see the changes from
> > >> https://issues.apache.org/jira/browse/GEODE-7013 included in the
> Geode
> > >> 1.10
> > >> release. GEODE-7013's changes restore gfsh help/hint behavior that was
> > lost
> > >> during a refactor in the earliest
> > >> releases of Geode.  The commit occurred after SHA1
> > >> dc6890107a2651d8ba1450e8db8a1c39d712fdc7.
> > >> Thanks.  Karen
> > >>
> > >>
> > >> On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender 
> > wrote:
> > >>
> > >>> I'll take on the Release Manager role for Geode 1.10 with the 1.9.0
> > >> release
> > >>> manager's help (Owen:).
> > >>>
> > >>> I'd like to propose cutting the release/1.10 branch off develop sha:
> > >>> dc6890107a2651d8ba1450e8db8a1c39d712fdc7
> > >>>
> > >>> aka: 1.10.0-SNAPSHOT.476
> > >>>
> > >>> Please speak up and discuss. We'll then start taking considerations
> for
> > >>> additional changes for 1.1.0 after we get the branch and pipeline in
> > >> place.
> > >>>
> > >>> -Dick
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Jul 29, 2019 at 4:08 PM Alexander Murmann <
> amurm...@apache.org
> > >
> > >>> wrote:
> > >>>
> >  Thanks for calling this out Ernie!
> > 
> >  It might be a good idea to cut the release and at the same time keep
> >  looking for urgent issues that need to be resolved and merged. Once
> > the
> >  branch is cut, we release likelihood of new issues being introduced.
> > 
> >  Does anyone know of any other issues, we'd want to make sure get
> > >>> addressed
> >  before we ship?
> > 
> >  On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt <
> > >> eburgha...@pivotal.io>
> >  wrote:
> > 
> > > There is a PR #3844  up
> > >> to
> > > address GEODE-7012 <
> https://issues.apache.org/jira/browse/GEODE-7012
> > >>>
> > >>> I
> > > think this should be in the next release...
> > >
> > > EB
> > >
> > > On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann <
> > >> amurm...@apache.org
> > 
> > > wrote:
> > >
> > >> *Cutting the release*
> > >> Do we have any volunteers to take over the release manager role?
> > >>
> > >> *Re: Udo's concerns*
> > >> While I beli

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Karen Miller]

Alexander, can you point me at the policy decision for the "critical issue"
rule you mention? I always though it was up
to the release manager.

I want GEODE-7013 fixes in because it is the right thing to do.  Our gfsh
help/hint wasn't working the way we say that it did.
With the fix, it does.  I want either the documentation to match the code,
or I want the code to match the documentation.
The fix in GEODE-7013 changes the code to match the existing documentation,
so we don't have to change the documentation
(which would have needed to be cherry-picked into our 1.10 release branch).


On Tue, Jul 30, 2019 at 11:47 AM Owen Nichols  wrote:

> Our "critical issue” rule has the effect that the bar to commit to develop
> is “low”, but the bar to cherry-pick to support branch is “very high”.
>
> Contributors could plan around this disparity more easily if any of the
> following were true:
> - releases were more frequent
> - planned cut date of release branch was announced in advance (rather than
> retroactively)
> - a process existed for making exceptions to the “critical issue” rule
>
> I agree that the proposed SHA looks like a relatively stable branchpoint
> (coming near the end of a nice period of solid green in the pipeline), and
> I acknowledge that fair warning was given a week ago that a branch was
> “coming soon”, but I wonder if there is anything we can do to make the
> rules for what gets in a release and what doesn’t feel a little less
> arbitrary?
>
> -Owen
>
>
> > On Jul 30, 2019, at 11:16 AM, Alexander Murmann 
> wrote:
> >
> > Dick, thank you for stepping up!
> >
> > I think it's great to cut the branch sooner rather than later. There
> > already is GEODE-7012 which introduces a distributed deadlock during
> > startup. That seems like a critical issue to fix. That should be able to
> > happen after we cut the branch though.
> >
> > Karen, I wonder if that could be merged after the branch got cut, but
> also
> > wonder if that fits our "critical issue" rule for being merged after the
> > branch has been cut or hold up the release. This has been broken since a
> > very long time. Thoughts?
> >
> > On Tue, Jul 30, 2019 at 10:51 AM Karen Miller 
> wrote:
> >
> >> I'd like to see the changes from
> >> https://issues.apache.org/jira/browse/GEODE-7013 included in the Geode
> >> 1.10
> >> release. GEODE-7013's changes restore gfsh help/hint behavior that was
> lost
> >> during a refactor in the earliest
> >> releases of Geode.  The commit occurred after SHA1
> >> dc6890107a2651d8ba1450e8db8a1c39d712fdc7.
> >> Thanks.  Karen
> >>
> >>
> >> On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender 
> wrote:
> >>
> >>> I'll take on the Release Manager role for Geode 1.10 with the 1.9.0
> >> release
> >>> manager's help (Owen:).
> >>>
> >>> I'd like to propose cutting the release/1.10 branch off develop sha:
> >>> dc6890107a2651d8ba1450e8db8a1c39d712fdc7
> >>>
> >>> aka: 1.10.0-SNAPSHOT.476
> >>>
> >>> Please speak up and discuss. We'll then start taking considerations for
> >>> additional changes for 1.1.0 after we get the branch and pipeline in
> >> place.
> >>>
> >>> -Dick
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Jul 29, 2019 at 4:08 PM Alexander Murmann  >
> >>> wrote:
> >>>
>  Thanks for calling this out Ernie!
> 
>  It might be a good idea to cut the release and at the same time keep
>  looking for urgent issues that need to be resolved and merged. Once
> the
>  branch is cut, we release likelihood of new issues being introduced.
> 
>  Does anyone know of any other issues, we'd want to make sure get
> >>> addressed
>  before we ship?
> 
>  On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt <
> >> eburgha...@pivotal.io>
>  wrote:
> 
> > There is a PR #3844  up
> >> to
> > address GEODE-7012  >>>
> >>> I
> > think this should be in the next release...
> >
> > EB
> >
> > On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann <
> >> amurm...@apache.org
> 
> > wrote:
> >
> >> *Cutting the release*
> >> Do we have any volunteers to take over the release manager role?
> >>
> >> *Re: Udo's concerns*
> >> While I believe that iterations of this particular work have been
> > discussed
> >> on the mailing list as far back as March 2018, I do think that we
>  should
> >> take Udo's response as an indicator that something with our larger
> > proposal
> >> process needs to be improved. We used to have synchronous Geode
> >> club
> > house
> >> sessions. For future discussions and for proposals in particular, I
>  think
> >> it would be great to supplement our asynchronous mailing list
> > communication
> >> with a synchronous video chat discussions by the community.
> >>
> >> On Fri, Jul 26, 2019 at 4:02 PM Dan Smith 
> >> wrote:
> >>
> >>> +1 for cutting a 1.10.0 release br

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Owen Nichols]

Our "critical issue” rule has the effect that the bar to commit to develop is 
“low”, but the bar to cherry-pick to support branch is “very high”.

Contributors could plan around this disparity more easily if any of the 
following were true:
- releases were more frequent
- planned cut date of release branch was announced in advance (rather than 
retroactively)
- a process existed for making exceptions to the “critical issue” rule

I agree that the proposed SHA looks like a relatively stable branchpoint 
(coming near the end of a nice period of solid green in the pipeline), and I 
acknowledge that fair warning was given a week ago that a branch was “coming 
soon”, but I wonder if there is anything we can do to make the rules for what 
gets in a release and what doesn’t feel a little less arbitrary?

-Owen


> On Jul 30, 2019, at 11:16 AM, Alexander Murmann  wrote:
> 
> Dick, thank you for stepping up!
> 
> I think it's great to cut the branch sooner rather than later. There
> already is GEODE-7012 which introduces a distributed deadlock during
> startup. That seems like a critical issue to fix. That should be able to
> happen after we cut the branch though.
> 
> Karen, I wonder if that could be merged after the branch got cut, but also
> wonder if that fits our "critical issue" rule for being merged after the
> branch has been cut or hold up the release. This has been broken since a
> very long time. Thoughts?
> 
> On Tue, Jul 30, 2019 at 10:51 AM Karen Miller  wrote:
> 
>> I'd like to see the changes from
>> https://issues.apache.org/jira/browse/GEODE-7013 included in the Geode
>> 1.10
>> release. GEODE-7013's changes restore gfsh help/hint behavior that was lost
>> during a refactor in the earliest
>> releases of Geode.  The commit occurred after SHA1
>> dc6890107a2651d8ba1450e8db8a1c39d712fdc7.
>> Thanks.  Karen
>> 
>> 
>> On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender  wrote:
>> 
>>> I'll take on the Release Manager role for Geode 1.10 with the 1.9.0
>> release
>>> manager's help (Owen:).
>>> 
>>> I'd like to propose cutting the release/1.10 branch off develop sha:
>>> dc6890107a2651d8ba1450e8db8a1c39d712fdc7
>>> 
>>> aka: 1.10.0-SNAPSHOT.476
>>> 
>>> Please speak up and discuss. We'll then start taking considerations for
>>> additional changes for 1.1.0 after we get the branch and pipeline in
>> place.
>>> 
>>> -Dick
>>> 
>>> 
>>> 
>>> 
>>> On Mon, Jul 29, 2019 at 4:08 PM Alexander Murmann 
>>> wrote:
>>> 
 Thanks for calling this out Ernie!
 
 It might be a good idea to cut the release and at the same time keep
 looking for urgent issues that need to be resolved and merged. Once the
 branch is cut, we release likelihood of new issues being introduced.
 
 Does anyone know of any other issues, we'd want to make sure get
>>> addressed
 before we ship?
 
 On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt <
>> eburgha...@pivotal.io>
 wrote:
 
> There is a PR #3844  up
>> to
> address GEODE-7012 >> 
>>> I
> think this should be in the next release...
> 
> EB
> 
> On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann <
>> amurm...@apache.org
 
> wrote:
> 
>> *Cutting the release*
>> Do we have any volunteers to take over the release manager role?
>> 
>> *Re: Udo's concerns*
>> While I believe that iterations of this particular work have been
> discussed
>> on the mailing list as far back as March 2018, I do think that we
 should
>> take Udo's response as an indicator that something with our larger
> proposal
>> process needs to be improved. We used to have synchronous Geode
>> club
> house
>> sessions. For future discussions and for proposals in particular, I
 think
>> it would be great to supplement our asynchronous mailing list
> communication
>> with a synchronous video chat discussions by the community.
>> 
>> On Fri, Jul 26, 2019 at 4:02 PM Dan Smith 
>> wrote:
>> 
>>> +1 for cutting a 1.10.0 release branch.
>>> 
>>> 
>>> 
>>> On Fri, Jul 26, 2019 at 3:55 PM Nabarun Nag 
>>> wrote:
>>> 
 Hi,
 I believe the original authors of the feature has done their
>> due
>>> diligence
 and followed all steps, we can get this feature in under the
>> Experimental
 flag and let the community improve on it, if there is anything
>>> else
>> that
 needs to be done.
 
 We have done this before for Lucene re-index feature, where we
> involved
>>> the
 entire community in its development, phase by phase. The wiki
>> is
>>> up
> and
 running, if someone has any concerns can raise it as a JIRA or
> comment
>> in
 the wiki and the community as a whole can decide if it is a
>> valid
 concern or not and act upon it.
 
 

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Jacob Barrett]

The selected SHA seems rather arbitrary. Could you enlighten us as to why one 
from last week rather than say today?

GEODE-7006 fixes a bug introduced in 1.9.
GEODE-7008 fixes a similar issue introduced in incubation. 

Both were merged today.


> On Jul 30, 2019, at 10:38 AM, Dick Cavender  wrote:
> 
> I'd like to propose cutting the release/1.10 branch off develop sha:
> dc6890107a2651d8ba1450e8db8a1c39d712fdc7

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Alexander Murmann]

Dick, thank you for stepping up!

I think it's great to cut the branch sooner rather than later. There
already is GEODE-7012 which introduces a distributed deadlock during
startup. That seems like a critical issue to fix. That should be able to
happen after we cut the branch though.

Karen, I wonder if that could be merged after the branch got cut, but also
wonder if that fits our "critical issue" rule for being merged after the
branch has been cut or hold up the release. This has been broken since a
very long time. Thoughts?

On Tue, Jul 30, 2019 at 10:51 AM Karen Miller  wrote:

> I'd like to see the changes from
> https://issues.apache.org/jira/browse/GEODE-7013 included in the Geode
> 1.10
> release. GEODE-7013's changes restore gfsh help/hint behavior that was lost
> during a refactor in the earliest
> releases of Geode.  The commit occurred after SHA1
> dc6890107a2651d8ba1450e8db8a1c39d712fdc7.
> Thanks.  Karen
>
>
> On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender  wrote:
>
> > I'll take on the Release Manager role for Geode 1.10 with the 1.9.0
> release
> > manager's help (Owen:).
> >
> > I'd like to propose cutting the release/1.10 branch off develop sha:
> > dc6890107a2651d8ba1450e8db8a1c39d712fdc7
> >
> > aka: 1.10.0-SNAPSHOT.476
> >
> > Please speak up and discuss. We'll then start taking considerations for
> > additional changes for 1.1.0 after we get the branch and pipeline in
> place.
> >
> > -Dick
> >
> >
> >
> >
> > On Mon, Jul 29, 2019 at 4:08 PM Alexander Murmann 
> > wrote:
> >
> > > Thanks for calling this out Ernie!
> > >
> > > It might be a good idea to cut the release and at the same time keep
> > > looking for urgent issues that need to be resolved and merged. Once the
> > > branch is cut, we release likelihood of new issues being introduced.
> > >
> > > Does anyone know of any other issues, we'd want to make sure get
> > addressed
> > > before we ship?
> > >
> > > On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt <
> eburgha...@pivotal.io>
> > > wrote:
> > >
> > > > There is a PR #3844  up
> to
> > > > address GEODE-7012  >
> > I
> > > > think this should be in the next release...
> > > >
> > > > EB
> > > >
> > > > On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann <
> amurm...@apache.org
> > >
> > > > wrote:
> > > >
> > > > > *Cutting the release*
> > > > > Do we have any volunteers to take over the release manager role?
> > > > >
> > > > > *Re: Udo's concerns*
> > > > > While I believe that iterations of this particular work have been
> > > > discussed
> > > > > on the mailing list as far back as March 2018, I do think that we
> > > should
> > > > > take Udo's response as an indicator that something with our larger
> > > > proposal
> > > > > process needs to be improved. We used to have synchronous Geode
> club
> > > > house
> > > > > sessions. For future discussions and for proposals in particular, I
> > > think
> > > > > it would be great to supplement our asynchronous mailing list
> > > > communication
> > > > > with a synchronous video chat discussions by the community.
> > > > >
> > > > > On Fri, Jul 26, 2019 at 4:02 PM Dan Smith 
> wrote:
> > > > >
> > > > > > +1 for cutting a 1.10.0 release branch.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Jul 26, 2019 at 3:55 PM Nabarun Nag 
> > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > > I believe the original authors of the feature has done their
> due
> > > > > > diligence
> > > > > > > and followed all steps, we can get this feature in under the
> > > > > Experimental
> > > > > > > flag and let the community improve on it, if there is anything
> > else
> > > > > that
> > > > > > > needs to be done.
> > > > > > >
> > > > > > > We have done this before for Lucene re-index feature, where we
> > > > involved
> > > > > > the
> > > > > > > entire community in its development, phase by phase. The wiki
> is
> > up
> > > > and
> > > > > > > running, if someone has any concerns can raise it as a JIRA or
> > > > comment
> > > > > in
> > > > > > > the wiki and the community as a whole can decide if it is a
> valid
> > > > > > > concern or not and act upon it.
> > > > > > >
> > > > > > > Regards
> > > > > > > Nabarun Nag
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Jul 26, 2019 at 3:40 PM Udo Kohlmeyer 
> > > > wrote:
> > > > > > >
> > > > > > > > @Alexander + @Jared,
> > > > > > > >
> > > > > > > > So maybe that was my misunderstanding on the RFC (not being
> > > > optional
> > > > > on
> > > > > > > > new feature work). Given that this is a new feature, there is
> > > > > > > > significant risk to getting it "wrong".
> > > > > > > >
> > > > > > > > I was expecting more discussion around this. I have some
> > > objections
> > > > > to
> > > > > > > > the current approach/design. Given that my day job does not
> > allow
> > > > me
> > > > > to
> > > > > > > > respond in a timely manner, I would have not been able to ge

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Karen Miller]

I'd like to see the changes from
https://issues.apache.org/jira/browse/GEODE-7013 included in the Geode 1.10
release. GEODE-7013's changes restore gfsh help/hint behavior that was lost
during a refactor in the earliest
releases of Geode.  The commit occurred after SHA1
dc6890107a2651d8ba1450e8db8a1c39d712fdc7.
Thanks.  Karen


On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender  wrote:

> I'll take on the Release Manager role for Geode 1.10 with the 1.9.0 release
> manager's help (Owen:).
>
> I'd like to propose cutting the release/1.10 branch off develop sha:
> dc6890107a2651d8ba1450e8db8a1c39d712fdc7
>
> aka: 1.10.0-SNAPSHOT.476
>
> Please speak up and discuss. We'll then start taking considerations for
> additional changes for 1.1.0 after we get the branch and pipeline in place.
>
> -Dick
>
>
>
>
> On Mon, Jul 29, 2019 at 4:08 PM Alexander Murmann 
> wrote:
>
> > Thanks for calling this out Ernie!
> >
> > It might be a good idea to cut the release and at the same time keep
> > looking for urgent issues that need to be resolved and merged. Once the
> > branch is cut, we release likelihood of new issues being introduced.
> >
> > Does anyone know of any other issues, we'd want to make sure get
> addressed
> > before we ship?
> >
> > On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt 
> > wrote:
> >
> > > There is a PR #3844  up to
> > > address GEODE-7012 
> I
> > > think this should be in the next release...
> > >
> > > EB
> > >
> > > On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann  >
> > > wrote:
> > >
> > > > *Cutting the release*
> > > > Do we have any volunteers to take over the release manager role?
> > > >
> > > > *Re: Udo's concerns*
> > > > While I believe that iterations of this particular work have been
> > > discussed
> > > > on the mailing list as far back as March 2018, I do think that we
> > should
> > > > take Udo's response as an indicator that something with our larger
> > > proposal
> > > > process needs to be improved. We used to have synchronous Geode club
> > > house
> > > > sessions. For future discussions and for proposals in particular, I
> > think
> > > > it would be great to supplement our asynchronous mailing list
> > > communication
> > > > with a synchronous video chat discussions by the community.
> > > >
> > > > On Fri, Jul 26, 2019 at 4:02 PM Dan Smith  wrote:
> > > >
> > > > > +1 for cutting a 1.10.0 release branch.
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Jul 26, 2019 at 3:55 PM Nabarun Nag 
> wrote:
> > > > >
> > > > > > Hi,
> > > > > > I believe the original authors of the feature has done their due
> > > > > diligence
> > > > > > and followed all steps, we can get this feature in under the
> > > > Experimental
> > > > > > flag and let the community improve on it, if there is anything
> else
> > > > that
> > > > > > needs to be done.
> > > > > >
> > > > > > We have done this before for Lucene re-index feature, where we
> > > involved
> > > > > the
> > > > > > entire community in its development, phase by phase. The wiki is
> up
> > > and
> > > > > > running, if someone has any concerns can raise it as a JIRA or
> > > comment
> > > > in
> > > > > > the wiki and the community as a whole can decide if it is a valid
> > > > > > concern or not and act upon it.
> > > > > >
> > > > > > Regards
> > > > > > Nabarun Nag
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Jul 26, 2019 at 3:40 PM Udo Kohlmeyer 
> > > wrote:
> > > > > >
> > > > > > > @Alexander + @Jared,
> > > > > > >
> > > > > > > So maybe that was my misunderstanding on the RFC (not being
> > > optional
> > > > on
> > > > > > > new feature work). Given that this is a new feature, there is
> > > > > > > significant risk to getting it "wrong".
> > > > > > >
> > > > > > > I was expecting more discussion around this. I have some
> > objections
> > > > to
> > > > > > > the current approach/design. Given that my day job does not
> allow
> > > me
> > > > to
> > > > > > > respond in a timely manner, I would have not been able to get
> all
> > > my
> > > > > > > concerns raised. In addition, throwing something onto the wiki,
> > and
> > > > > then
> > > > > > > a few weeks before we'd like to cut a version raising a
> > discussion
> > > > > > > thread on work that has been going on for months already does
> not
> > > > help
> > > > > > > with the community being able to read, digest, think, reason
> and
> > > > > respond
> > > > > > > BEFORE it is released.
> > > > > > >
> > > > > > > I know `@Experimental` is non-binding on API's or usage, BUT I
> > > prefer
> > > > > > > some of the ground work to have been discussed, API's validated
> > > > BEFORE
> > > > > > > it is released into the wild. I mean this is a PUBLIC API, so
> > we'd
> > > > > > > prefer to get it more correct than the previous one.
> > > > > > >
> > > > > > > Maybe it is just me, taking it too serious... Where I prefer
> not
> > > > > release
> > > > > > > s

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Dick Cavender]

I'll take on the Release Manager role for Geode 1.10 with the 1.9.0 release
manager's help (Owen:).

I'd like to propose cutting the release/1.10 branch off develop sha:
dc6890107a2651d8ba1450e8db8a1c39d712fdc7

aka: 1.10.0-SNAPSHOT.476

Please speak up and discuss. We'll then start taking considerations for
additional changes for 1.1.0 after we get the branch and pipeline in place.

-Dick




On Mon, Jul 29, 2019 at 4:08 PM Alexander Murmann 
wrote:

> Thanks for calling this out Ernie!
>
> It might be a good idea to cut the release and at the same time keep
> looking for urgent issues that need to be resolved and merged. Once the
> branch is cut, we release likelihood of new issues being introduced.
>
> Does anyone know of any other issues, we'd want to make sure get addressed
> before we ship?
>
> On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt 
> wrote:
>
> > There is a PR #3844  up to
> > address GEODE-7012  I
> > think this should be in the next release...
> >
> > EB
> >
> > On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann 
> > wrote:
> >
> > > *Cutting the release*
> > > Do we have any volunteers to take over the release manager role?
> > >
> > > *Re: Udo's concerns*
> > > While I believe that iterations of this particular work have been
> > discussed
> > > on the mailing list as far back as March 2018, I do think that we
> should
> > > take Udo's response as an indicator that something with our larger
> > proposal
> > > process needs to be improved. We used to have synchronous Geode club
> > house
> > > sessions. For future discussions and for proposals in particular, I
> think
> > > it would be great to supplement our asynchronous mailing list
> > communication
> > > with a synchronous video chat discussions by the community.
> > >
> > > On Fri, Jul 26, 2019 at 4:02 PM Dan Smith  wrote:
> > >
> > > > +1 for cutting a 1.10.0 release branch.
> > > >
> > > >
> > > >
> > > > On Fri, Jul 26, 2019 at 3:55 PM Nabarun Nag  wrote:
> > > >
> > > > > Hi,
> > > > > I believe the original authors of the feature has done their due
> > > > diligence
> > > > > and followed all steps, we can get this feature in under the
> > > Experimental
> > > > > flag and let the community improve on it, if there is anything else
> > > that
> > > > > needs to be done.
> > > > >
> > > > > We have done this before for Lucene re-index feature, where we
> > involved
> > > > the
> > > > > entire community in its development, phase by phase. The wiki is up
> > and
> > > > > running, if someone has any concerns can raise it as a JIRA or
> > comment
> > > in
> > > > > the wiki and the community as a whole can decide if it is a valid
> > > > > concern or not and act upon it.
> > > > >
> > > > > Regards
> > > > > Nabarun Nag
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Jul 26, 2019 at 3:40 PM Udo Kohlmeyer 
> > wrote:
> > > > >
> > > > > > @Alexander + @Jared,
> > > > > >
> > > > > > So maybe that was my misunderstanding on the RFC (not being
> > optional
> > > on
> > > > > > new feature work). Given that this is a new feature, there is
> > > > > > significant risk to getting it "wrong".
> > > > > >
> > > > > > I was expecting more discussion around this. I have some
> objections
> > > to
> > > > > > the current approach/design. Given that my day job does not allow
> > me
> > > to
> > > > > > respond in a timely manner, I would have not been able to get all
> > my
> > > > > > concerns raised. In addition, throwing something onto the wiki,
> and
> > > > then
> > > > > > a few weeks before we'd like to cut a version raising a
> discussion
> > > > > > thread on work that has been going on for months already does not
> > > help
> > > > > > with the community being able to read, digest, think, reason and
> > > > respond
> > > > > > BEFORE it is released.
> > > > > >
> > > > > > I know `@Experimental` is non-binding on API's or usage, BUT I
> > prefer
> > > > > > some of the ground work to have been discussed, API's validated
> > > BEFORE
> > > > > > it is released into the wild. I mean this is a PUBLIC API, so
> we'd
> > > > > > prefer to get it more correct than the previous one.
> > > > > >
> > > > > > Maybe it is just me, taking it too serious... Where I prefer not
> > > > release
> > > > > > something as close to 95% correct (and discussed).
> > > > > >
> > > > > > Anyway.. If we want to cut 1.10... and we should... Let's do so..
> > but
> > > > > > I'd prefer that more on the correctness on the approach.
> > > > > >
> > > > > > --Udo
> > > > > >
> > > > > > On 7/25/19 11:08 AM, Alexander Murmann wrote:
> > > > > > >> I don't believe we should be including anything into the Geode
> > > > release
> > > > > > >> that has not gone through the correct process of feature
> > proposal.
> > > > > > >>
> > > > > > >> All work under the experimental cluster management service has
> > not
> > > > yet
> > > > > > >> been approved by the agreed upon RFC 

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Alexander Murmann]

Thanks for calling this out Ernie!

It might be a good idea to cut the release and at the same time keep
looking for urgent issues that need to be resolved and merged. Once the
branch is cut, we release likelihood of new issues being introduced.

Does anyone know of any other issues, we'd want to make sure get addressed
before we ship?

On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt 
wrote:

> There is a PR #3844  up to
> address GEODE-7012  I
> think this should be in the next release...
>
> EB
>
> On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann 
> wrote:
>
> > *Cutting the release*
> > Do we have any volunteers to take over the release manager role?
> >
> > *Re: Udo's concerns*
> > While I believe that iterations of this particular work have been
> discussed
> > on the mailing list as far back as March 2018, I do think that we should
> > take Udo's response as an indicator that something with our larger
> proposal
> > process needs to be improved. We used to have synchronous Geode club
> house
> > sessions. For future discussions and for proposals in particular, I think
> > it would be great to supplement our asynchronous mailing list
> communication
> > with a synchronous video chat discussions by the community.
> >
> > On Fri, Jul 26, 2019 at 4:02 PM Dan Smith  wrote:
> >
> > > +1 for cutting a 1.10.0 release branch.
> > >
> > >
> > >
> > > On Fri, Jul 26, 2019 at 3:55 PM Nabarun Nag  wrote:
> > >
> > > > Hi,
> > > > I believe the original authors of the feature has done their due
> > > diligence
> > > > and followed all steps, we can get this feature in under the
> > Experimental
> > > > flag and let the community improve on it, if there is anything else
> > that
> > > > needs to be done.
> > > >
> > > > We have done this before for Lucene re-index feature, where we
> involved
> > > the
> > > > entire community in its development, phase by phase. The wiki is up
> and
> > > > running, if someone has any concerns can raise it as a JIRA or
> comment
> > in
> > > > the wiki and the community as a whole can decide if it is a valid
> > > > concern or not and act upon it.
> > > >
> > > > Regards
> > > > Nabarun Nag
> > > >
> > > >
> > > >
> > > > On Fri, Jul 26, 2019 at 3:40 PM Udo Kohlmeyer 
> wrote:
> > > >
> > > > > @Alexander + @Jared,
> > > > >
> > > > > So maybe that was my misunderstanding on the RFC (not being
> optional
> > on
> > > > > new feature work). Given that this is a new feature, there is
> > > > > significant risk to getting it "wrong".
> > > > >
> > > > > I was expecting more discussion around this. I have some objections
> > to
> > > > > the current approach/design. Given that my day job does not allow
> me
> > to
> > > > > respond in a timely manner, I would have not been able to get all
> my
> > > > > concerns raised. In addition, throwing something onto the wiki, and
> > > then
> > > > > a few weeks before we'd like to cut a version raising a discussion
> > > > > thread on work that has been going on for months already does not
> > help
> > > > > with the community being able to read, digest, think, reason and
> > > respond
> > > > > BEFORE it is released.
> > > > >
> > > > > I know `@Experimental` is non-binding on API's or usage, BUT I
> prefer
> > > > > some of the ground work to have been discussed, API's validated
> > BEFORE
> > > > > it is released into the wild. I mean this is a PUBLIC API, so we'd
> > > > > prefer to get it more correct than the previous one.
> > > > >
> > > > > Maybe it is just me, taking it too serious... Where I prefer not
> > > release
> > > > > something as close to 95% correct (and discussed).
> > > > >
> > > > > Anyway.. If we want to cut 1.10... and we should... Let's do so..
> but
> > > > > I'd prefer that more on the correctness on the approach.
> > > > >
> > > > > --Udo
> > > > >
> > > > > On 7/25/19 11:08 AM, Alexander Murmann wrote:
> > > > > >> I don't believe we should be including anything into the Geode
> > > release
> > > > > >> that has not gone through the correct process of feature
> proposal.
> > > > > >>
> > > > > >> All work under the experimental cluster management service has
> not
> > > yet
> > > > > >> been approved by the agreed upon RFC process.
> > > > > >>
> > > > > > Udo, I didn't take the RFC process that we agreed on to be a gate
> > > > keeper,
> > > > > > but rather a way to de-risk work before making a PR.
> > > > > >
> > > > > >  From the RFC doc in the wiki:
> > > > > >
> > > > > >> When to write an RFC?
> > > > > >>
> > > > > >> Writing an RFC should be entirely voluntary. There is always the
> > > > option
> > > > > of
> > > > > >> going straight to a pull request. However, for larger changes,
> it
> > > > might
> > > > > be
> > > > > >> wise to de-risk the risk of rejection of the pull request by
> first
> > > > > >> gathering input from the community. Therefore it’s up to every
> > > member
> > > > of
> > > > > >> our com

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Ernest Burghardt]

There is a PR #3844  up to
address GEODE-7012  I
think this should be in the next release...

EB

On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann 
wrote:

> *Cutting the release*
> Do we have any volunteers to take over the release manager role?
>
> *Re: Udo's concerns*
> While I believe that iterations of this particular work have been discussed
> on the mailing list as far back as March 2018, I do think that we should
> take Udo's response as an indicator that something with our larger proposal
> process needs to be improved. We used to have synchronous Geode club house
> sessions. For future discussions and for proposals in particular, I think
> it would be great to supplement our asynchronous mailing list communication
> with a synchronous video chat discussions by the community.
>
> On Fri, Jul 26, 2019 at 4:02 PM Dan Smith  wrote:
>
> > +1 for cutting a 1.10.0 release branch.
> >
> >
> >
> > On Fri, Jul 26, 2019 at 3:55 PM Nabarun Nag  wrote:
> >
> > > Hi,
> > > I believe the original authors of the feature has done their due
> > diligence
> > > and followed all steps, we can get this feature in under the
> Experimental
> > > flag and let the community improve on it, if there is anything else
> that
> > > needs to be done.
> > >
> > > We have done this before for Lucene re-index feature, where we involved
> > the
> > > entire community in its development, phase by phase. The wiki is up and
> > > running, if someone has any concerns can raise it as a JIRA or comment
> in
> > > the wiki and the community as a whole can decide if it is a valid
> > > concern or not and act upon it.
> > >
> > > Regards
> > > Nabarun Nag
> > >
> > >
> > >
> > > On Fri, Jul 26, 2019 at 3:40 PM Udo Kohlmeyer  wrote:
> > >
> > > > @Alexander + @Jared,
> > > >
> > > > So maybe that was my misunderstanding on the RFC (not being optional
> on
> > > > new feature work). Given that this is a new feature, there is
> > > > significant risk to getting it "wrong".
> > > >
> > > > I was expecting more discussion around this. I have some objections
> to
> > > > the current approach/design. Given that my day job does not allow me
> to
> > > > respond in a timely manner, I would have not been able to get all my
> > > > concerns raised. In addition, throwing something onto the wiki, and
> > then
> > > > a few weeks before we'd like to cut a version raising a discussion
> > > > thread on work that has been going on for months already does not
> help
> > > > with the community being able to read, digest, think, reason and
> > respond
> > > > BEFORE it is released.
> > > >
> > > > I know `@Experimental` is non-binding on API's or usage, BUT I prefer
> > > > some of the ground work to have been discussed, API's validated
> BEFORE
> > > > it is released into the wild. I mean this is a PUBLIC API, so we'd
> > > > prefer to get it more correct than the previous one.
> > > >
> > > > Maybe it is just me, taking it too serious... Where I prefer not
> > release
> > > > something as close to 95% correct (and discussed).
> > > >
> > > > Anyway.. If we want to cut 1.10... and we should... Let's do so.. but
> > > > I'd prefer that more on the correctness on the approach.
> > > >
> > > > --Udo
> > > >
> > > > On 7/25/19 11:08 AM, Alexander Murmann wrote:
> > > > >> I don't believe we should be including anything into the Geode
> > release
> > > > >> that has not gone through the correct process of feature proposal.
> > > > >>
> > > > >> All work under the experimental cluster management service has not
> > yet
> > > > >> been approved by the agreed upon RFC process.
> > > > >>
> > > > > Udo, I didn't take the RFC process that we agreed on to be a gate
> > > keeper,
> > > > > but rather a way to de-risk work before making a PR.
> > > > >
> > > > >  From the RFC doc in the wiki:
> > > > >
> > > > >> When to write an RFC?
> > > > >>
> > > > >> Writing an RFC should be entirely voluntary. There is always the
> > > option
> > > > of
> > > > >> going straight to a pull request. However, for larger changes, it
> > > might
> > > > be
> > > > >> wise to de-risk the risk of rejection of the pull request by first
> > > > >> gathering input from the community. Therefore it’s up to every
> > member
> > > of
> > > > >> our community to decide themselves when they want to reach for
> this
> > > > tool.
> > > > >>
> > > > > If we want to change the role of the RFC process, that's fine with
> > me,
> > > > but
> > > > > we should have that discussion first.
> > > > >
> > > > > On Tue, Jul 23, 2019 at 10:30 AM Jared Stewart <
> > > stewart.ja...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> What was missing from the RFC process for the cluster management
> > > > service?
> > > > >> I saw a [Discuss] thread for it, as well as a proposal at
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
> > > > >>
> > > > >>

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Owen Nichols]

> I was expecting more discussion around this. I have some objections to the 
> current approach/design.

I encourage you to start a [DISCUSS] thread!



Also, thank you for the reminder that not everyone has been closely following 
the recent Cluster Management Service PRs, and since the original discussions 
on the proposal were a rather long time ago, a status update to the dev list 
would be a great idea.  I’ve just sent one out.

-Owen

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Alexander Murmann]

*Cutting the release*
Do we have any volunteers to take over the release manager role?

*Re: Udo's concerns*
While I believe that iterations of this particular work have been discussed
on the mailing list as far back as March 2018, I do think that we should
take Udo's response as an indicator that something with our larger proposal
process needs to be improved. We used to have synchronous Geode club house
sessions. For future discussions and for proposals in particular, I think
it would be great to supplement our asynchronous mailing list communication
with a synchronous video chat discussions by the community.

On Fri, Jul 26, 2019 at 4:02 PM Dan Smith  wrote:

> +1 for cutting a 1.10.0 release branch.
>
>
>
> On Fri, Jul 26, 2019 at 3:55 PM Nabarun Nag  wrote:
>
> > Hi,
> > I believe the original authors of the feature has done their due
> diligence
> > and followed all steps, we can get this feature in under the Experimental
> > flag and let the community improve on it, if there is anything else that
> > needs to be done.
> >
> > We have done this before for Lucene re-index feature, where we involved
> the
> > entire community in its development, phase by phase. The wiki is up and
> > running, if someone has any concerns can raise it as a JIRA or comment in
> > the wiki and the community as a whole can decide if it is a valid
> > concern or not and act upon it.
> >
> > Regards
> > Nabarun Nag
> >
> >
> >
> > On Fri, Jul 26, 2019 at 3:40 PM Udo Kohlmeyer  wrote:
> >
> > > @Alexander + @Jared,
> > >
> > > So maybe that was my misunderstanding on the RFC (not being optional on
> > > new feature work). Given that this is a new feature, there is
> > > significant risk to getting it "wrong".
> > >
> > > I was expecting more discussion around this. I have some objections to
> > > the current approach/design. Given that my day job does not allow me to
> > > respond in a timely manner, I would have not been able to get all my
> > > concerns raised. In addition, throwing something onto the wiki, and
> then
> > > a few weeks before we'd like to cut a version raising a discussion
> > > thread on work that has been going on for months already does not help
> > > with the community being able to read, digest, think, reason and
> respond
> > > BEFORE it is released.
> > >
> > > I know `@Experimental` is non-binding on API's or usage, BUT I prefer
> > > some of the ground work to have been discussed, API's validated BEFORE
> > > it is released into the wild. I mean this is a PUBLIC API, so we'd
> > > prefer to get it more correct than the previous one.
> > >
> > > Maybe it is just me, taking it too serious... Where I prefer not
> release
> > > something as close to 95% correct (and discussed).
> > >
> > > Anyway.. If we want to cut 1.10... and we should... Let's do so.. but
> > > I'd prefer that more on the correctness on the approach.
> > >
> > > --Udo
> > >
> > > On 7/25/19 11:08 AM, Alexander Murmann wrote:
> > > >> I don't believe we should be including anything into the Geode
> release
> > > >> that has not gone through the correct process of feature proposal.
> > > >>
> > > >> All work under the experimental cluster management service has not
> yet
> > > >> been approved by the agreed upon RFC process.
> > > >>
> > > > Udo, I didn't take the RFC process that we agreed on to be a gate
> > keeper,
> > > > but rather a way to de-risk work before making a PR.
> > > >
> > > >  From the RFC doc in the wiki:
> > > >
> > > >> When to write an RFC?
> > > >>
> > > >> Writing an RFC should be entirely voluntary. There is always the
> > option
> > > of
> > > >> going straight to a pull request. However, for larger changes, it
> > might
> > > be
> > > >> wise to de-risk the risk of rejection of the pull request by first
> > > >> gathering input from the community. Therefore it’s up to every
> member
> > of
> > > >> our community to decide themselves when they want to reach for this
> > > tool.
> > > >>
> > > > If we want to change the role of the RFC process, that's fine with
> me,
> > > but
> > > > we should have that discussion first.
> > > >
> > > > On Tue, Jul 23, 2019 at 10:30 AM Jared Stewart <
> > stewart.ja...@gmail.com>
> > > > wrote:
> > > >
> > > >> What was missing from the RFC process for the cluster management
> > > service?
> > > >> I saw a [Discuss] thread for it, as well as a proposal at
> > > >>
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
> > > >>
> > > >> On Tue, Jul 23, 2019 at 10:02 AM Udo Kohlmeyer 
> > wrote:
> > > >>
> > > >>> I don't believe we should be including anything into the Geode
> > release
> > > >>> that has not gone through the correct process of feature proposal.
> > > >>>
> > > >>> All work under the experimental cluster management service has not
> > yet
> > > >>> been approved by the agreed upon RFC process.
> > > >>>
> > > >>> I don't believe we should be including this work, experimental or
> > > >>> otherwise.
> > > >>>
> > > >>> 

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Dan Smith]

+1 for cutting a 1.10.0 release branch.



On Fri, Jul 26, 2019 at 3:55 PM Nabarun Nag  wrote:

> Hi,
> I believe the original authors of the feature has done their due diligence
> and followed all steps, we can get this feature in under the Experimental
> flag and let the community improve on it, if there is anything else that
> needs to be done.
>
> We have done this before for Lucene re-index feature, where we involved the
> entire community in its development, phase by phase. The wiki is up and
> running, if someone has any concerns can raise it as a JIRA or comment in
> the wiki and the community as a whole can decide if it is a valid
> concern or not and act upon it.
>
> Regards
> Nabarun Nag
>
>
>
> On Fri, Jul 26, 2019 at 3:40 PM Udo Kohlmeyer  wrote:
>
> > @Alexander + @Jared,
> >
> > So maybe that was my misunderstanding on the RFC (not being optional on
> > new feature work). Given that this is a new feature, there is
> > significant risk to getting it "wrong".
> >
> > I was expecting more discussion around this. I have some objections to
> > the current approach/design. Given that my day job does not allow me to
> > respond in a timely manner, I would have not been able to get all my
> > concerns raised. In addition, throwing something onto the wiki, and then
> > a few weeks before we'd like to cut a version raising a discussion
> > thread on work that has been going on for months already does not help
> > with the community being able to read, digest, think, reason and respond
> > BEFORE it is released.
> >
> > I know `@Experimental` is non-binding on API's or usage, BUT I prefer
> > some of the ground work to have been discussed, API's validated BEFORE
> > it is released into the wild. I mean this is a PUBLIC API, so we'd
> > prefer to get it more correct than the previous one.
> >
> > Maybe it is just me, taking it too serious... Where I prefer not release
> > something as close to 95% correct (and discussed).
> >
> > Anyway.. If we want to cut 1.10... and we should... Let's do so.. but
> > I'd prefer that more on the correctness on the approach.
> >
> > --Udo
> >
> > On 7/25/19 11:08 AM, Alexander Murmann wrote:
> > >> I don't believe we should be including anything into the Geode release
> > >> that has not gone through the correct process of feature proposal.
> > >>
> > >> All work under the experimental cluster management service has not yet
> > >> been approved by the agreed upon RFC process.
> > >>
> > > Udo, I didn't take the RFC process that we agreed on to be a gate
> keeper,
> > > but rather a way to de-risk work before making a PR.
> > >
> > >  From the RFC doc in the wiki:
> > >
> > >> When to write an RFC?
> > >>
> > >> Writing an RFC should be entirely voluntary. There is always the
> option
> > of
> > >> going straight to a pull request. However, for larger changes, it
> might
> > be
> > >> wise to de-risk the risk of rejection of the pull request by first
> > >> gathering input from the community. Therefore it’s up to every member
> of
> > >> our community to decide themselves when they want to reach for this
> > tool.
> > >>
> > > If we want to change the role of the RFC process, that's fine with me,
> > but
> > > we should have that discussion first.
> > >
> > > On Tue, Jul 23, 2019 at 10:30 AM Jared Stewart <
> stewart.ja...@gmail.com>
> > > wrote:
> > >
> > >> What was missing from the RFC process for the cluster management
> > service?
> > >> I saw a [Discuss] thread for it, as well as a proposal at
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
> > >>
> > >> On Tue, Jul 23, 2019 at 10:02 AM Udo Kohlmeyer 
> wrote:
> > >>
> > >>> I don't believe we should be including anything into the Geode
> release
> > >>> that has not gone through the correct process of feature proposal.
> > >>>
> > >>> All work under the experimental cluster management service has not
> yet
> > >>> been approved by the agreed upon RFC process.
> > >>>
> > >>> I don't believe we should be including this work, experimental or
> > >>> otherwise.
> > >>>
> > >>> --Udo
> > >>>
> > >>> On 7/22/19 4:51 PM, Alexander Murmann wrote:
> >  Udo, do you mind explaining how the RFC process comes into this? Are
> > >> you
> >  suggesting that we should wait if an RFC had a target release
> > attached?
> > 
> >  On Mon, Jul 22, 2019 at 4:47 PM Udo Kohlmeyer 
> wrote:
> > 
> > > I don't think we need to wait for this, as there has been no RFC
> > >> process
> > > followed.
> > >
> > > --Udo
> > >
> > > On 7/22/19 3:38 PM, Jinmei Liao wrote:
> > >> Work is still being planned to move the cluster management rest
> > >> service
> > >> under an experimental version flag and use a geode property to
> turn
> > >> it
> > >> on/off. I would say we are ready to cut the geode 1.10.0 after
> that
> > >>> work
> > > is
> > >> complete.
> > >>
> > >> On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann <
> > >> 

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Nabarun Nag]

Hi,
I believe the original authors of the feature has done their due diligence
and followed all steps, we can get this feature in under the Experimental
flag and let the community improve on it, if there is anything else that
needs to be done.

We have done this before for Lucene re-index feature, where we involved the
entire community in its development, phase by phase. The wiki is up and
running, if someone has any concerns can raise it as a JIRA or comment in
the wiki and the community as a whole can decide if it is a valid
concern or not and act upon it.

Regards
Nabarun Nag



On Fri, Jul 26, 2019 at 3:40 PM Udo Kohlmeyer  wrote:

> @Alexander + @Jared,
>
> So maybe that was my misunderstanding on the RFC (not being optional on
> new feature work). Given that this is a new feature, there is
> significant risk to getting it "wrong".
>
> I was expecting more discussion around this. I have some objections to
> the current approach/design. Given that my day job does not allow me to
> respond in a timely manner, I would have not been able to get all my
> concerns raised. In addition, throwing something onto the wiki, and then
> a few weeks before we'd like to cut a version raising a discussion
> thread on work that has been going on for months already does not help
> with the community being able to read, digest, think, reason and respond
> BEFORE it is released.
>
> I know `@Experimental` is non-binding on API's or usage, BUT I prefer
> some of the ground work to have been discussed, API's validated BEFORE
> it is released into the wild. I mean this is a PUBLIC API, so we'd
> prefer to get it more correct than the previous one.
>
> Maybe it is just me, taking it too serious... Where I prefer not release
> something as close to 95% correct (and discussed).
>
> Anyway.. If we want to cut 1.10... and we should... Let's do so.. but
> I'd prefer that more on the correctness on the approach.
>
> --Udo
>
> On 7/25/19 11:08 AM, Alexander Murmann wrote:
> >> I don't believe we should be including anything into the Geode release
> >> that has not gone through the correct process of feature proposal.
> >>
> >> All work under the experimental cluster management service has not yet
> >> been approved by the agreed upon RFC process.
> >>
> > Udo, I didn't take the RFC process that we agreed on to be a gate keeper,
> > but rather a way to de-risk work before making a PR.
> >
> >  From the RFC doc in the wiki:
> >
> >> When to write an RFC?
> >>
> >> Writing an RFC should be entirely voluntary. There is always the option
> of
> >> going straight to a pull request. However, for larger changes, it might
> be
> >> wise to de-risk the risk of rejection of the pull request by first
> >> gathering input from the community. Therefore it’s up to every member of
> >> our community to decide themselves when they want to reach for this
> tool.
> >>
> > If we want to change the role of the RFC process, that's fine with me,
> but
> > we should have that discussion first.
> >
> > On Tue, Jul 23, 2019 at 10:30 AM Jared Stewart 
> > wrote:
> >
> >> What was missing from the RFC process for the cluster management
> service?
> >> I saw a [Discuss] thread for it, as well as a proposal at
> >>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
> >>
> >> On Tue, Jul 23, 2019 at 10:02 AM Udo Kohlmeyer  wrote:
> >>
> >>> I don't believe we should be including anything into the Geode release
> >>> that has not gone through the correct process of feature proposal.
> >>>
> >>> All work under the experimental cluster management service has not yet
> >>> been approved by the agreed upon RFC process.
> >>>
> >>> I don't believe we should be including this work, experimental or
> >>> otherwise.
> >>>
> >>> --Udo
> >>>
> >>> On 7/22/19 4:51 PM, Alexander Murmann wrote:
>  Udo, do you mind explaining how the RFC process comes into this? Are
> >> you
>  suggesting that we should wait if an RFC had a target release
> attached?
> 
>  On Mon, Jul 22, 2019 at 4:47 PM Udo Kohlmeyer  wrote:
> 
> > I don't think we need to wait for this, as there has been no RFC
> >> process
> > followed.
> >
> > --Udo
> >
> > On 7/22/19 3:38 PM, Jinmei Liao wrote:
> >> Work is still being planned to move the cluster management rest
> >> service
> >> under an experimental version flag and use a geode property to turn
> >> it
> >> on/off. I would say we are ready to cut the geode 1.10.0 after that
> >>> work
> > is
> >> complete.
> >>
> >> On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann <
> >> amurm...@apache.org
> >> wrote:
> >>
> >>> Hi everyone!
> >>>
> >>> We released Geode 1.9.0 on April 25th. That's about 3 months ago.
> >> End
> >>> of
> >>> last year we discussed releasing quarterly. In the past we've had
> >>> about
> > a
> >>> month between cutting a release branch and actually shipping our
> new
> > minor.
> >>> This means

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Udo Kohlmeyer]

@Alexander + @Jared,

So maybe that was my misunderstanding on the RFC (not being optional on 
new feature work). Given that this is a new feature, there is 
significant risk to getting it "wrong".


I was expecting more discussion around this. I have some objections to 
the current approach/design. Given that my day job does not allow me to 
respond in a timely manner, I would have not been able to get all my 
concerns raised. In addition, throwing something onto the wiki, and then 
a few weeks before we'd like to cut a version raising a discussion 
thread on work that has been going on for months already does not help 
with the community being able to read, digest, think, reason and respond 
BEFORE it is released.


I know `@Experimental` is non-binding on API's or usage, BUT I prefer 
some of the ground work to have been discussed, API's validated BEFORE 
it is released into the wild. I mean this is a PUBLIC API, so we'd 
prefer to get it more correct than the previous one.


Maybe it is just me, taking it too serious... Where I prefer not release 
something as close to 95% correct (and discussed).


Anyway.. If we want to cut 1.10... and we should... Let's do so.. but 
I'd prefer that more on the correctness on the approach.


--Udo

On 7/25/19 11:08 AM, Alexander Murmann wrote:

I don't believe we should be including anything into the Geode release
that has not gone through the correct process of feature proposal.

All work under the experimental cluster management service has not yet
been approved by the agreed upon RFC process.


Udo, I didn't take the RFC process that we agreed on to be a gate keeper,
but rather a way to de-risk work before making a PR.

 From the RFC doc in the wiki:


When to write an RFC?

Writing an RFC should be entirely voluntary. There is always the option of
going straight to a pull request. However, for larger changes, it might be
wise to de-risk the risk of rejection of the pull request by first
gathering input from the community. Therefore it’s up to every member of
our community to decide themselves when they want to reach for this tool.


If we want to change the role of the RFC process, that's fine with me, but
we should have that discussion first.

On Tue, Jul 23, 2019 at 10:30 AM Jared Stewart 
wrote:


What was missing from the RFC process for the cluster management service?
I saw a [Discuss] thread for it, as well as a proposal at

https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service

On Tue, Jul 23, 2019 at 10:02 AM Udo Kohlmeyer  wrote:


I don't believe we should be including anything into the Geode release
that has not gone through the correct process of feature proposal.

All work under the experimental cluster management service has not yet
been approved by the agreed upon RFC process.

I don't believe we should be including this work, experimental or
otherwise.

--Udo

On 7/22/19 4:51 PM, Alexander Murmann wrote:

Udo, do you mind explaining how the RFC process comes into this? Are

you

suggesting that we should wait if an RFC had a target release attached?

On Mon, Jul 22, 2019 at 4:47 PM Udo Kohlmeyer  wrote:


I don't think we need to wait for this, as there has been no RFC

process

followed.

--Udo

On 7/22/19 3:38 PM, Jinmei Liao wrote:

Work is still being planned to move the cluster management rest

service

under an experimental version flag and use a geode property to turn

it

on/off. I would say we are ready to cut the geode 1.10.0 after that

work

is

complete.

On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann <

amurm...@apache.org

wrote:


Hi everyone!

We released Geode 1.9.0 on April 25th. That's about 3 months ago.

End

of

last year we discussed releasing quarterly. In the past we've had

about

a

month between cutting a release branch and actually shipping our new

minor.

This means we are already behind our target release cadence.

What are your thoughts on cutting a 1.10.0 release branch this week?

Would anyone like to volunteer to be the release manager for geode

1.10.0?

Thank you all!

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Alexander Murmann]

>
> I don't believe we should be including anything into the Geode release
> that has not gone through the correct process of feature proposal.
>
> All work under the experimental cluster management service has not yet
> been approved by the agreed upon RFC process.
>

Udo, I didn't take the RFC process that we agreed on to be a gate keeper,
but rather a way to de-risk work before making a PR.

>From the RFC doc in the wiki:

> When to write an RFC?
>
> Writing an RFC should be entirely voluntary. There is always the option of
> going straight to a pull request. However, for larger changes, it might be
> wise to de-risk the risk of rejection of the pull request by first
> gathering input from the community. Therefore it’s up to every member of
> our community to decide themselves when they want to reach for this tool.
>

If we want to change the role of the RFC process, that's fine with me, but
we should have that discussion first.

On Tue, Jul 23, 2019 at 10:30 AM Jared Stewart 
wrote:

> What was missing from the RFC process for the cluster management service?
> I saw a [Discuss] thread for it, as well as a proposal at
>
> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
>
> On Tue, Jul 23, 2019 at 10:02 AM Udo Kohlmeyer  wrote:
>
> > I don't believe we should be including anything into the Geode release
> > that has not gone through the correct process of feature proposal.
> >
> > All work under the experimental cluster management service has not yet
> > been approved by the agreed upon RFC process.
> >
> > I don't believe we should be including this work, experimental or
> > otherwise.
> >
> > --Udo
> >
> > On 7/22/19 4:51 PM, Alexander Murmann wrote:
> > > Udo, do you mind explaining how the RFC process comes into this? Are
> you
> > > suggesting that we should wait if an RFC had a target release attached?
> > >
> > > On Mon, Jul 22, 2019 at 4:47 PM Udo Kohlmeyer  wrote:
> > >
> > >> I don't think we need to wait for this, as there has been no RFC
> process
> > >> followed.
> > >>
> > >> --Udo
> > >>
> > >> On 7/22/19 3:38 PM, Jinmei Liao wrote:
> > >>> Work is still being planned to move the cluster management rest
> service
> > >>> under an experimental version flag and use a geode property to turn
> it
> > >>> on/off. I would say we are ready to cut the geode 1.10.0 after that
> > work
> > >> is
> > >>> complete.
> > >>>
> > >>> On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann <
> amurm...@apache.org
> > >
> > >>> wrote:
> > >>>
> >  Hi everyone!
> > 
> >  We released Geode 1.9.0 on April 25th. That's about 3 months ago.
> End
> > of
> >  last year we discussed releasing quarterly. In the past we've had
> > about
> > >> a
> >  month between cutting a release branch and actually shipping our new
> > >> minor.
> >  This means we are already behind our target release cadence.
> > 
> >  What are your thoughts on cutting a 1.10.0 release branch this week?
> > 
> >  Would anyone like to volunteer to be the release manager for geode
> > >> 1.10.0?
> >  Thank you all!
> > 
> >
>

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Jared Stewart]

What was missing from the RFC process for the cluster management service?
I saw a [Discuss] thread for it, as well as a proposal at
https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service

On Tue, Jul 23, 2019 at 10:02 AM Udo Kohlmeyer  wrote:

> I don't believe we should be including anything into the Geode release
> that has not gone through the correct process of feature proposal.
>
> All work under the experimental cluster management service has not yet
> been approved by the agreed upon RFC process.
>
> I don't believe we should be including this work, experimental or
> otherwise.
>
> --Udo
>
> On 7/22/19 4:51 PM, Alexander Murmann wrote:
> > Udo, do you mind explaining how the RFC process comes into this? Are you
> > suggesting that we should wait if an RFC had a target release attached?
> >
> > On Mon, Jul 22, 2019 at 4:47 PM Udo Kohlmeyer  wrote:
> >
> >> I don't think we need to wait for this, as there has been no RFC process
> >> followed.
> >>
> >> --Udo
> >>
> >> On 7/22/19 3:38 PM, Jinmei Liao wrote:
> >>> Work is still being planned to move the cluster management rest service
> >>> under an experimental version flag and use a geode property to turn it
> >>> on/off. I would say we are ready to cut the geode 1.10.0 after that
> work
> >> is
> >>> complete.
> >>>
> >>> On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann  >
> >>> wrote:
> >>>
>  Hi everyone!
> 
>  We released Geode 1.9.0 on April 25th. That's about 3 months ago. End
> of
>  last year we discussed releasing quarterly. In the past we've had
> about
> >> a
>  month between cutting a release branch and actually shipping our new
> >> minor.
>  This means we are already behind our target release cadence.
> 
>  What are your thoughts on cutting a 1.10.0 release branch this week?
> 
>  Would anyone like to volunteer to be the release manager for geode
> >> 1.10.0?
>  Thank you all!
> 
>

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Udo Kohlmeyer]

I don't believe we should be including anything into the Geode release 
that has not gone through the correct process of feature proposal.


All work under the experimental cluster management service has not yet 
been approved by the agreed upon RFC process.


I don't believe we should be including this work, experimental or otherwise.

--Udo

On 7/22/19 4:51 PM, Alexander Murmann wrote:

Udo, do you mind explaining how the RFC process comes into this? Are you
suggesting that we should wait if an RFC had a target release attached?

On Mon, Jul 22, 2019 at 4:47 PM Udo Kohlmeyer  wrote:


I don't think we need to wait for this, as there has been no RFC process
followed.

--Udo

On 7/22/19 3:38 PM, Jinmei Liao wrote:

Work is still being planned to move the cluster management rest service
under an experimental version flag and use a geode property to turn it
on/off. I would say we are ready to cut the geode 1.10.0 after that work

is

complete.

On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann 
wrote:


Hi everyone!

We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of
last year we discussed releasing quarterly. In the past we've had about

a

month between cutting a release branch and actually shipping our new

minor.

This means we are already behind our target release cadence.

What are your thoughts on cutting a 1.10.0 release branch this week?

Would anyone like to volunteer to be the release manager for geode

1.10.0?

Thank you all!

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Jinmei Liao]

I believe it's realistic to assume that

On Mon, Jul 22, 2019, 3:58 PM Alexander Murmann  wrote:

> Jinmei,
>
> Do you think it's realistic to add the property this week and still cut the
> branch at the end of this week?
>
> On Mon, Jul 22, 2019 at 3:38 PM Jinmei Liao  wrote:
>
> > Work is still being planned to move the cluster management rest service
> > under an experimental version flag and use a geode property to turn it
> > on/off. I would say we are ready to cut the geode 1.10.0 after that work
> is
> > complete.
> >
> > On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann 
> > wrote:
> >
> > > Hi everyone!
> > >
> > > We released Geode 1.9.0 on April 25th. That's about 3 months ago. End
> of
> > > last year we discussed releasing quarterly. In the past we've had
> about a
> > > month between cutting a release branch and actually shipping our new
> > minor.
> > > This means we are already behind our target release cadence.
> > >
> > > What are your thoughts on cutting a 1.10.0 release branch this week?
> > >
> > > Would anyone like to volunteer to be the release manager for geode
> > 1.10.0?
> > >
> > > Thank you all!
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Alexander Murmann]

Udo, do you mind explaining how the RFC process comes into this? Are you
suggesting that we should wait if an RFC had a target release attached?

On Mon, Jul 22, 2019 at 4:47 PM Udo Kohlmeyer  wrote:

> I don't think we need to wait for this, as there has been no RFC process
> followed.
>
> --Udo
>
> On 7/22/19 3:38 PM, Jinmei Liao wrote:
> > Work is still being planned to move the cluster management rest service
> > under an experimental version flag and use a geode property to turn it
> > on/off. I would say we are ready to cut the geode 1.10.0 after that work
> is
> > complete.
> >
> > On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann 
> > wrote:
> >
> >> Hi everyone!
> >>
> >> We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of
> >> last year we discussed releasing quarterly. In the past we've had about
> a
> >> month between cutting a release branch and actually shipping our new
> minor.
> >> This means we are already behind our target release cadence.
> >>
> >> What are your thoughts on cutting a 1.10.0 release branch this week?
> >>
> >> Would anyone like to volunteer to be the release manager for geode
> 1.10.0?
> >>
> >> Thank you all!
> >>
> >
>

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Udo Kohlmeyer]

I don't think we need to wait for this, as there has been no RFC process 
followed.


--Udo

On 7/22/19 3:38 PM, Jinmei Liao wrote:

Work is still being planned to move the cluster management rest service
under an experimental version flag and use a geode property to turn it
on/off. I would say we are ready to cut the geode 1.10.0 after that work is
complete.

On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann 
wrote:


Hi everyone!

We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of
last year we discussed releasing quarterly. In the past we've had about a
month between cutting a release branch and actually shipping our new minor.
This means we are already behind our target release cadence.

What are your thoughts on cutting a 1.10.0 release branch this week?

Would anyone like to volunteer to be the release manager for geode 1.10.0?

Thank you all!

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Alexander Murmann]

Jinmei,

Do you think it's realistic to add the property this week and still cut the
branch at the end of this week?

On Mon, Jul 22, 2019 at 3:38 PM Jinmei Liao  wrote:

> Work is still being planned to move the cluster management rest service
> under an experimental version flag and use a geode property to turn it
> on/off. I would say we are ready to cut the geode 1.10.0 after that work is
> complete.
>
> On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann 
> wrote:
>
> > Hi everyone!
> >
> > We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of
> > last year we discussed releasing quarterly. In the past we've had about a
> > month between cutting a release branch and actually shipping our new
> minor.
> > This means we are already behind our target release cadence.
> >
> > What are your thoughts on cutting a 1.10.0 release branch this week?
> >
> > Would anyone like to volunteer to be the release manager for geode
> 1.10.0?
> >
> > Thank you all!
> >
>
>
> --
> Cheers
>
> Jinmei
>

Re: [DISCUSS] Time to cut Geode 1.10.0?

[Jinmei Liao]

Work is still being planned to move the cluster management rest service
under an experimental version flag and use a geode property to turn it
on/off. I would say we are ready to cut the geode 1.10.0 after that work is
complete.

On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann 
wrote:

> Hi everyone!
>
> We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of
> last year we discussed releasing quarterly. In the past we've had about a
> month between cutting a release branch and actually shipping our new minor.
> This means we are already behind our target release cadence.
>
> What are your thoughts on cutting a 1.10.0 release branch this week?
>
> Would anyone like to volunteer to be the release manager for geode 1.10.0?
>
> Thank you all!
>


-- 
Cheers

Jinmei

[DISCUSS] Time to cut Geode 1.10.0?

[Alexander Murmann]

Hi everyone!

We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of
last year we discussed releasing quarterly. In the past we've had about a
month between cutting a release branch and actually shipping our new minor.
This means we are already behind our target release cadence.

What are your thoughts on cutting a 1.10.0 release branch this week?

Would anyone like to volunteer to be the release manager for geode 1.10.0?

Thank you all!