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