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