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