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