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