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