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 <n...@apache.org> 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=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! >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>> >> >>>>> >> >> >> >
