Hey Rui, hey Ryan, Good points. Non-committers can't directly release but they can assist with the release. It would be great to get help from both of you in the release process.
I'd be happy to be the release manager for the 1.8 release. As for the timing, I think we need to reach consensus in which form to include the new memory tuning. Also, considering that Gyula just merged a pretty big improvement / refactor of the metric collection code, we might want to give it another week. I would target the end of February to begin with the release process. Cheers, Max On Sun, Feb 18, 2024 at 4:48 AM Rui Fan <1996fan...@gmail.com> wrote: > > Thanks Max and Ryan for the volunteering. > > To Ryan: > > I'm not sure whether non-flink-committers have permission to release. > If I remember correctly, multiple steps of the release process[1] need > the apache account, such as: Apache GPG key and Apache Nexus. > > If the release process needs the committer permission, feel free to > assist this release, thanks~ > > To all: > > Max is one of the very active contributors to the > flink-kuberneters-operator > project, and he didn't release before. So Max as the release manager > makes sense to me. > > I can assist this release if all of you don't mind. In particular, > Autoscaler Standalone 1.8.0 is much improved compared to 1.7.0, > and I can help write the related Release note. Besides, I can help > check and test this release. > > [1] > https://cwiki.apache.org/confluence/display/FLINK/Creating+a+Flink+Kubernetes+Operator+Release > > Best, > Rui > > On Wed, Feb 7, 2024 at 11:01 PM Ryan van Huuksloot < > ryan.vanhuuksl...@shopify.com> wrote: > > > I can volunteer to be a release manager. I haven't done it for > > Apache/Flink or the operator before so I may be a good candidate. > > > > Ryan van Huuksloot > > Sr. Production Engineer | Streaming Platform > > [image: Shopify] > > <https://www.shopify.com/?utm_medium=salessignatures&utm_source=hs_email> > > > > > > On Wed, Feb 7, 2024 at 6:06 AM Maximilian Michels <m...@apache.org> wrote: > > > >> It's very considerate that you want to volunteer to be the release > >> manager, but given that you have already managed one release, I would > >> ideally like somebody else to do it. Personally, I haven't managed an > >> operator release, although I've done it for Flink itself in the past. > >> Nevertheless, it would be nice to have somebody new to the process. > >> > >> Anyone reading this who wants to try being a release manager, please > >> don't be afraid to volunteer. Of course we'll be able to assist. That > >> would also be a good opportunity for us to update the docs regarding > >> the release process. > >> > >> Cheers, > >> Max > >> > >> > >> On Wed, Feb 7, 2024 at 10:08 AM Rui Fan <1996fan...@gmail.com> wrote: > >> > > >> > If the release is postponed 1-2 more weeks, I could volunteer > >> > as the one of the release managers. > >> > > >> > Best, > >> > Rui > >> > > >> > On Wed, Feb 7, 2024 at 4:54 AM Gyula Fóra <gyula.f...@gmail.com> wrote: > >> >> > >> >> Given the proposed timeline was a bit short / rushed I agree with Max > >> that > >> >> we could wait 1-2 more weeks to wrap up the current outstanding bigger > >> >> features around memory tuning and the JDBC state store. > >> >> > >> >> In the meantime it would be great to involve 1-2 new committers (or > >> other > >> >> contributors) in the operator release process so that we have some > >> fresh > >> >> eyes on the process. > >> >> Would anyone be interested in volunteering to help with the next > >> release? > >> >> > >> >> Cheers, > >> >> Gyula > >> >> > >> >> On Tue, Feb 6, 2024 at 4:35 PM Maximilian Michels <m...@apache.org> > >> wrote: > >> >> > >> >> > Thanks for starting the discussion Gyula! > >> >> > > >> >> > It comes down to how important the outstanding changes are for the > >> >> > release. Both the memory tuning as well as the JDBC changes probably > >> >> > need 1-2 weeks realistically to complete the initial spec. For the > >> >> > memory tuning, I would prefer merging it in the current state as an > >> >> > experimental feature for the release which comes disabled out of the > >> >> > box. The reason is that it can already be useful to users who want to > >> >> > try it out; we have seen some interest in it. Then for the next > >> >> > release we will offer a richer feature set and might enable it by > >> >> > default. > >> >> > > >> >> > Cheers, > >> >> > Max > >> >> > > >> >> > On Tue, Feb 6, 2024 at 10:53 AM Rui Fan <1996fan...@gmail.com> > >> wrote: > >> >> > > > >> >> > > Thanks Gyula for driving this release! > >> >> > > > >> >> > > Release 1.8.0 sounds make sense to me. > >> >> > > > >> >> > > As you said, I'm developing the JDBC event handler. > >> >> > > Since I'm going on vacation starting this Friday, and I have some > >> >> > > other work before I go on vacation. After evaluating my time today, > >> >> > > I found that I cannot complete the development, testing, and > >> merging > >> >> > > of the JDBC event handler this week. So I tend to put the JDBC > >> >> > > event handler in the next version. > >> >> > > > >> >> > > Best, > >> >> > > Rui > >> >> > > > >> >> > > On Mon, Feb 5, 2024 at 11:42 PM Gyula Fóra <gyula.f...@gmail.com> > >> wrote: > >> >> > > > >> >> > > > Hi all! > >> >> > > > > >> >> > > > I would like to kick off the release planning for the operator > >> 1.8.0 > >> >> > > > release. The last operator release was November 22 last year. > >> Since > >> >> > then we > >> >> > > > have added a number of fixes and improvements to both the > >> operator and > >> >> > the > >> >> > > > autoscaler logic. > >> >> > > > > >> >> > > > There are a few outstanding PRs currently, including some larger > >> >> > features > >> >> > > > for the Autoscaler (JDBC event handler, Heap tuning), we have to > >> make a > >> >> > > > decision regarding those as well whether to include in the > >> release or > >> >> > not. @Maximilian > >> >> > > > Michels <m...@apache.org> , @Rui Fan <1996fan...@gmail.com> > >> what's your > >> >> > > > take regarding those PRs? I generally like to be a bit more > >> >> > conservative > >> >> > > > with large new features to avoid introducing last minute > >> instabilities. > >> >> > > > > >> >> > > > My proposal would be to aim for the end of this week as the > >> freeze date > >> >> > > > (Feb 9) and then we can prepare RC1 on monday. > >> >> > > > > >> >> > > > I am happy to volunteer as a release manager but I am of course > >> open to > >> >> > > > working together with someone on this. > >> >> > > > > >> >> > > > What do you think? > >> >> > > > > >> >> > > > Cheers, > >> >> > > > Gyula > >> >> > > > > >> >> > > >> > >
