There appears to be consensus that this is a critical fix. The following commits have been brought into support/1.10.0 <https://github.com/apache/geode/tree/release/1.10.0> as the critical fix for GEODE-7051 <https://issues.apache.org/jira/browse/GEODE-7051>:
git cherry-pick -x 413800bc16d05df689a2af5c30797f180aad6088 <https://github.com/apache/geode/commit/413800bc16d05df689a2af5c30797f180aad6088> git cherry-pick -x e1b61cdcaf38966bbb732b0b3db5223f2cc4f5e4 <https://github.com/apache/geode/commit/e1b61cdcaf38966bbb732b0b3db5223f2cc4f5e4> GEODE-7051 <https://issues.apache.org/jira/browse/GEODE-7051> has been marked as 'resolved in' 1.10.0. -Owen > On 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! >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>> >>>
