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=0x00007fc204009800 nid=0x69aa waiting on condition [0x00007fc1de195000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f10d8098> (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 <bschucha...@pivotal.io> 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 <onich...@pivotal.io> 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 <kl...@apache.org> 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 <di...@apache.org> > 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 <onich...@pivotal.io> > >> 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 <amurm...@apache.org > > > >>>>> 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 <kmil...@pivotal.io> > >>>> 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 <onich...@pivotal.io > > > >>>>> 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 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 < > kmil...@pivotal.io> > >>>>>>>> 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 < > di...@apache.org> > >>>>>>>> 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 < > https://github.com/apache/geode/pull/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 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 < > dsm...@pivotal.io> > >>>>>>>>>> wrote: > >>>>>>>>>>>>>>> +1 for cutting a 1.10.0 release branch. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Fri, Jul 26, 2019 at 3:55 PM Nabarun Nag < > n...@apache.org > >>>>>>>>>>> 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 < > >>>> u...@apache.com> > >>>>>>>>>>>>> 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 < > >>>>>>>>>>>> u...@apache.com> > >>>>>>>>>>>>>>>> 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 < > >>>>>>>>>>>> u...@apache.com > >>>>>>>>>>>>>>>> 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! > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> > >>>>> > >> >
