+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! > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>> > >>> > >>> > >> > >
