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