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