Re: Re: Re: [VOTE] Accept Flink CDC into Apache Flink

2024-01-13 Thread Yun Gao
+1 (binding) On Sat, Jan 13, 2024 at 10:08 AM Rodrigo Meneses wrote: > > +1 (non binding) > > On Fri, Jan 12, 2024 at 5:45 PM Dong Lin wrote: > > > +1 (binding) > > > > On Sat, Jan 13, 2024 at 6:04 AM Austin Bennett wrote: > > > > > +1 (non-binding) > > > > > > On Fri, Jan 12, 2024 at 5:44 PM

Re: [VOTE] Release flink-connector-rabbitmq, v3.0.2 release candidate #1

2024-01-13 Thread Hang Ruan
+1 (non-binding) - Validated checksum hash - Verified signature - Verified that no binaries exist in the source archive - Build the source with Maven and jdk11 - Verified web PR Best, Hang Jiabao Sun 于2024年1月13日周六 16:51写道: > +1 (non-binding) > > - Validated hashes > - Verified signature > -

[jira] [Created] (FLINK-34071) Deadlock in AWS Kinesis Data Streams AsyncSink connector

2024-01-13 Thread Aleksandr Pilipenko (Jira)
Aleksandr Pilipenko created FLINK-34071: --- Summary: Deadlock in AWS Kinesis Data Streams AsyncSink connector Key: FLINK-34071 URL: https://issues.apache.org/jira/browse/FLINK-34071 Project: Flink

Re: [VOTE] Release flink-connector-rabbitmq, v3.0.2 release candidate #1

2024-01-13 Thread Jiabao Sun
+1 (non-binding) - Validated hashes - Verified signature - Verified tags - Verified Lisence - Reviewed web pr Best, Jiabao > 2024年1月12日 20:50,Martijn Visser 写道: > > Hi everyone, > Please review and vote on the release candidate #1 for the version > 3.0.2, as follows: > [ ] +1, Approve the

Re: [VOTE] Release flink-connector-opensearch v1.1.0, release candidate #1

2024-01-13 Thread Jiabao Sun
+1 (non-binding) - Validated hashes - Verified signature - Verified tags - Verified no binaries in the source archive - Reviewed web pr and found that there're some conflicts need to be resolved Best, Jiabao > 2024年1月12日 23:58,Danny Cranmer 写道: > > Apologies I jumped the gun on this one. We

Re: [DISCUSS] FLIP-416: Deprecate and remove the RestoreMode#LEGACY

2024-01-13 Thread Yanfei Lei
Thanks Zakelly for starting this discussion. Regardless of whether it is for users or developers, deprecating RestoreMode#LEGACY makes the semantics clearer and lower maintenance costs, and Flink 2.0 is a good time point to do this. So +1 for the overall idea. Best, Yanfei Zakelly Lan