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