Re: [DISCUSS] Kubernetes Operator 1.8.0 release planning

Hey everyone, I don't see any immediate blockers, so I'm going to start the release process. Thanks, Max On Tue, Feb 20, 2024 at 8:55 PM Maximilian Michels wrote: > > Hey Rui, hey Ryan, > > Good points. Non-committers can't directly release but they can assist > with the release. It would be gr

Re: [DISCUSS] Kubernetes Operator 1.8.0 release planning

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 w

Re: [DISCUSS] Kubernetes Operator 1.8.0 release planning

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

Re: [DISCUSS] Kubernetes Operator 1.8.0 release planning

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] On Wed, Feb

Re: [DISCUSS] Kubernetes Operator 1.8.0 release planning

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

Re: [DISCUSS] Kubernetes Operator 1.8.0 release planning

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

Re: [DISCUSS] Kubernetes Operator 1.8.0 release planning

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 o

Re: [DISCUSS] Kubernetes Operator 1.8.0 release planning

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 curre

Re: [DISCUSS] Kubernetes Operator 1.8.0 release planning

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 th

[DISCUSS] Kubernetes Operator 1.8.0 release planning

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