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 <https://github.com/spring-projects/spring-boot/tree/1.5.x/spring-boot-starters/spring-boot-starter-data-gemfire>* [1] (and there was also an Example <https://github.com/spring-projects/spring-boot/tree/1.5.x/spring-boot-samples/spring-boot-sample-data-gemfire> [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* <https://github.com/spring-projects/spring-boot-data-geode> [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 <https://github.com/spring-projects/spring-boot-data-geode/issues/42> [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 <https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L145> [5]) and used by Geode 1.9 (Log4j 2.11 <https://github.com/apache/geode/blob/rel/v1.9.0/boms/geode-all-bom/src/test/resources/expected-pom.xml#L461-L469> [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 <https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L37-L238> [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 <n...@apache.org> 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 <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! > >> >>>>>>>>>>>>>>>>>>>>>>>> > >> >>>>>>>> > >> >>>>> > >> >> > >> > > > -- -John john.blum10101 (skype)
