Re: [VOTE] FLIP-468: Introducing StreamGraph-Based Job Submission

[Yuepeng Pan]

Thanks for driving it !+1(non-binding)

Best regards,
Yuepeng Pan



At 2024-07-26 11:49:41, "Rui Fan" <1996fan...@gmail.com> wrote:
>Thanks Junrui for driving this proposal!
>
>+1(binding)
>
>Best,
>Rui
>
>On Fri, Jul 26, 2024 at 11:02 AM Junrui Lee  wrote:
>
>> Hi everyone,
>>
>> Thanks for all the feedback about FLIP-468: Introducing StreamGraph-Based
>> Job Submission [1]. The discussion thread can be found here [2].
>>
>> The vote will be open for at least 72 hours unless there are any objections
>> or insufficient votes.
>>
>> Best,
>>
>> Junrui
>>
>> [1]
>>
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-468%3A+Introducing+StreamGraph-Based+Job+Submission
>>
>> [2] https://lists.apache.org/thread/l65mst4prx09rmloydn64z1w1zp8coyz
>>

Re: [VOTE] FLIP-460: Display source/sink I/O metrics on Flink Web UI

[Yuepeng Pan]

+1 (non-binding)

Best, 
Yuepeng Pan














At 2024-07-17 05:57:28, "Aleksandr Pilipenko"  wrote:
>+1 (non-binding)
>
>Thanks,
>Aleksandr
>
>On Tue, 16 Jul 2024 at 22:56, Ahmed Hamdy  wrote:
>
>> +1 (non-binding)
>>
>> Best Regards
>> Ahmed Hamdy
>>
>>
>> On Tue, 16 Jul 2024 at 21:58, Becket Qin  wrote:
>>
>> > +1 (binding)
>> >
>> > Thanks,
>> >
>> > Jiangjie (Becket) Qin
>> >
>> > On Tue, Jul 16, 2024 at 12:19 AM Leonard Xu  wrote:
>> >
>> > > +1(binding)
>> > >
>> > > Best,
>> > > Leonard
>> > >
>> > > > 2024年7月16日 下午3:15，Robert Metzger  写道：
>> > > >
>> > > > +1 (binding)
>> > > >
>> > > > Nice to see this fixed ;)
>> > > >
>> > > >
>> > > >
>> > > > On Tue, Jul 16, 2024 at 8:46 AM Yong Fang  wrote:
>> > > >
>> > > >> +1 (binding)
>> > > >>
>> > > >> Best,
>> > > >> FangYong
>> > > >>
>> > > >>
>> > > >> On Tue, Jul 16, 2024 at 1:14 PM Zhanghao Chen <
>> > > zhanghao.c...@outlook.com>
>> > > >> wrote:
>> > > >>
>> > > >>> Hi everyone,
>> > > >>>
>> > > >>>
>> > > >>> Thanks for all the feedback about the FLIP-460: Display source/sink
>> > I/O
>> > > >>> metrics on Flink Web UI [1]. The discussion
>> > > >>> thread is here [2]. I'd like to start a vote on it.
>> > > >>>
>> > > >>> The vote will be open for at least 72 hours unless there is an
>> > > objection
>> > > >>> or insufficient votes.
>> > > >>>
>> > > >>> [1]
>> > > >>>
>> > > >>
>> > >
>> >
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=309496355
>> > > >>> [2]
>> https://lists.apache.org/thread/sy271nhd2jr1r942f29xbvbgq7fsd841
>> > > >>>
>> > > >>> Best,
>> > > >>> Zhanghao Chen
>> > > >>>
>> > > >>
>> > >
>> > >
>> >
>>

Re: [VOTE] FLIP-456: CompiledPlan support for Batch Execution Mode

[Yuepeng Pan]

+1 (non-binding)

Best regards,

Yuepeng Pan





At 2024-07-03 01:46:13, "Sergey Nuyanzin"  wrote:
>Thanks for driving this
>
>+1 (binding)
>
>On Tue, Jul 2, 2024, 11:21 Martijn Visser  wrote:
>
>> +1 (binding)
>>
>> On Mon, Jul 1, 2024 at 7:00 PM Jim Hughes 
>> wrote:
>>
>> > Hi Alexey,
>> >
>> > +1 (non-binding)
>> >
>> > I'm looking forward to parity between streaming and batch bound for
>> > compiled plans!
>> >
>> > Cheers,
>> >
>> > Jim
>> >
>> > On Mon, Jul 1, 2024 at 12:55 PM Alexey Leonov-Vendrovskiy <
>> > vendrov...@gmail.com> wrote:
>> >
>> > > Hello everyone,
>> > >
>> > > We had a good discussion of FLIP-456: CompiledPlan support for Batch
>> > > Execution Mode [1]. Discussion thread is here: [2].
>> > >
>> > > Let's start voting on it. The vote will be open for at least 72
>> > > hours unless there is an objection or insufficient votes. The FLIP will
>> > be
>> > > considered accepted if 3 binding votes (from active committers
>> according
>> > to
>> > > the Flink bylaws [3]) are gathered by the community.
>> > >
>> > > Thanks,
>> > > Alexey
>> > >
>> > > [1]
>> > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-456%3A+CompiledPlan+support+for+Batch+Execution+Mode
>> > > [2] https://lists.apache.org/thread/7gpyqvdnnbjwbh3vbk6b0pj38l91crvv
>> > > [3]
>> > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws#FlinkBylaws-Approvals
>> > > <
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws#FlinkBylaws-Approvals](https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws%23FlinkBylaws-Approvals)
>> > > >
>> > >
>> >
>>

Re: [VOTE] FLIP-444: Native file copy support

[Yuepeng Pan]

+1 (non-binding)




Best regards,

Yuepeng Pan










At 2024-06-26 15:27:17, "Piotr Nowojski"  wrote:
>Thanks for pointing this out Zakelly. After the discussion on the dev
>mailing list, I have updated the `PathsCopyingFileSystem` to merge its
>functionalities with `DuplicatingFileSystem`, but I've just forgotten to
>mention that it will removed/replaced with `PathsCopyingFileSystem`.
>
>Vote can be resumed.
>
>Best,
>Piotrek
>
>wt., 25 cze 2024 o 18:57 Piotr Nowojski  napisał(a):
>
>> Ops, I must have forgotten to update the FLIP as we discussed. I will fix
>> it tomorrow and the vote period will be extended.
>>
>> Best,
>> Piotrek
>>
>> wt., 25 cze 2024 o 13:56 Zakelly Lan  napisał(a):
>>
>>> Hi Piotrek,
>>>
>>> I don't see any statement about removing or renaming the
>>> `DuplicatingFileSystem` in the FLIP, shall we do that as mentioned in the
>>> discussion thread?
>>>
>>>
>>> Best,
>>> Zakelly
>>>
>>> On Tue, Jun 25, 2024 at 4:58 PM Piotr Nowojski 
>>> wrote:
>>>
>>> > Hi all,
>>> >
>>> > I would like to start a vote for the FLIP-444 [1]. The discussion
>>> thread is
>>> > here [2].
>>> >
>>> > The vote will be open for at least 72.
>>> >
>>> > Best,
>>> > Piotrek
>>> >
>>> > [1] https://cwiki.apache.org/confluence/x/rAn9EQ
>>> > [2] https://lists.apache.org/thread/lkwmyjt2bnmvgx4qpp82rldwmtd4516c
>>> >
>>>
>>

Re:[ANNOUNCE] New Apache Flink Committer - Hang Ruan

[Yuepeng Pan]

Congratulations !


Best regards Yuepeng Pan














At 2024-06-17 11:17:13, "Leonard Xu"  wrote:
>Hi everyone,
>On behalf of the PMC, I'm happy to let you know that Hang Ruan has become a 
>new Flink Committer !
>
>Hang Ruan has been continuously contributing to the Flink project since August 
>2021. Since then, he has continuously contributed to Flink, Flink CDC, and 
>various Flink connector repositories, including flink-connector-kafka, 
>flink-connector-elasticsearch, flink-connector-aws, flink-connector-rabbitmq, 
>flink-connector-pulsar, and flink-connector-mongodb. Hang Ruan focuses on the 
>improvements related to connectors and catalogs and initiated FLIP-274. He is 
>most recognized as a core contributor and maintainer for the Flink CDC 
>project, contributing many features such as MySQL CDC newly table addition and 
>the Schema Evolution feature.
>
>Beyond his technical contributions, Hang Ruan is an active member of the Flink 
>community. He regularly engages in discussions on the Flink dev mailing list 
>and the user-zh and user mailing lists, participates in FLIP discussions, 
>assists with user Q, and consistently volunteers for release verifications.
>
>Please join me in congratulating Hang Ruan for becoming an Apache Flink 
>committer!
>
>Best,
>Leonard (on behalf of the Flink PMC)

Re:[ANNOUNCE] New Apache Flink Committer - Zhongqiang Gong

[Yuepeng Pan]

Congratulations ! Best regards Yuepeng Pan





At 2024-06-17 11:20:30, "Leonard Xu"  wrote:
>Hi everyone,
>On behalf of the PMC, I'm happy to announce that Zhongqiang Gong has become a 
>new Flink Committer!
>
>Zhongqiang has been an active Flink community member since November 2021, 
>contributing numerous PRs to both the Flink and Flink CDC repositories. As a 
>core contributor to Flink CDC, he developed the Oracle and SQL Server CDC 
>Connectors and managed essential website and CI migrations during the donation 
>of Flink CDC to Apache Flink.
>
>Beyond his technical contributions, Zhongqiang actively participates in 
>discussions on the Flink dev mailing list and responds to threads on the user 
>and user-zh mailing lists. As an Apache StreamPark (incubating) Committer, he 
>promotes Flink SQL and Flink CDC technologies at meetups and within the 
>StreamPark community.
>
>Please join me in congratulating Zhongqiang Gong for becoming an Apache Flink 
>committer!
>
>Best,
>Leonard (on behalf of the Flink PMC)

Re: [VOTE] FLIP-464: Merge "flink run" and "flink run-application"

[Yuepeng Pan]

+1 (non-binding)

Thanks for driving it!


Best,
Yuepeng Pan
在 2024-06-13 10:47:11，"Zakelly Lan"  写道：
>+1 (binding)
>
>Thanks for driving this!
>
>
>Best,
>Zakelly
>
>On Thu, Jun 13, 2024 at 10:05 AM Junrui Lee  wrote:
>
>> +1 (non-binding)
>>
>> Best,
>> Junrui
>>
>> Biao Geng  于2024年6月13日周四 09:54写道：
>>
>> > Thanks for driving this.
>> > +1 (non-binding)
>> >
>> > Best,
>> > Biao Geng
>> >
>> >
>> > weijie guo  于2024年6月13日周四 09:48写道：
>> >
>> > > Thanks for driving this!
>> > >
>> > > +1(binding)
>> > >
>> > > Best regards,
>> > >
>> > > Weijie
>> > >
>> > >
>> > > Xintong Song  于2024年6月13日周四 09:04写道：
>> > >
>> > > > +1(binding)
>> > > >
>> > > > Best,
>> > > >
>> > > > Xintong
>> > > >
>> > > >
>> > > >
>> > > > On Thu, Jun 13, 2024 at 5:15 AM Márton Balassi <
>> > balassi.mar...@gmail.com
>> > > >
>> > > > wrote:
>> > > >
>> > > > > +1 (binding)
>> > > > >
>> > > > > On Wed, Jun 12, 2024 at 7:25 PM Őrhidi Mátyás <
>> > matyas.orh...@gmail.com
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > > > Sounds reasonable,
>> > > > > > +1
>> > > > > >
>> > > > > > Cheers,
>> > > > > > Matyas
>> > > > > >
>> > > > > >
>> > > > > > On Wed, Jun 12, 2024 at 8:54 AM Mate Czagany > >
>> > > > wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > Thank you for driving this Ferenc,
>> > > > > > > +1 (non-binding)
>> > > > > > >
>> > > > > > > Regards,
>> > > > > > > Mate
>> > > > > > >
>> > > > > > > Ferenc Csaky  ezt írta (időpont:
>> > 2024.
>> > > > > jún.
>> > > > > > > 12., Sze, 17:23):
>> > > > > > >
>> > > > > > > > Hello devs,
>> > > > > > > >
>> > > > > > > > I would like to start a vote about FLIP-464 [1]. The FLIP is
>> > > about
>> > > > to
>> > > > > > > > merge back the
>> > > > > > > > "flink run-application" functionality to "flink run", so the
>> > > latter
>> > > > > > will
>> > > > > > > > be capable to deploy jobs in
>> > > > > > > > all deployment modes. More details in the FLIP. Discussion
>> > thread
>> > > > > [2].
>> > > > > > > >
>> > > > > > > > The vote will be open for at least 72 hours (until 2024 March
>> > 23
>> > > > > 14:03
>> > > > > > > > UTC) unless there
>> > > > > > > > are any objections or insufficient votes.
>> > > > > > > >
>> > > > > > > > Thanks,Ferenc
>> > > > > > > >
>> > > > > > > > [1]
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=311626179
>> > > > > > > > [2]
>> > > > https://lists.apache.org/thread/xh58xs0y58kqjmfvd4yor79rv6dlcg5g
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>

Re: [VOTE] FLIP-459: Support Flink hybrid shuffle integration with Apache Celeborn

[Yuepeng Pan]

+1 (non-binding)

Best regards,
Yuepeng Pan

At 2024-06-11 16:34:12, "Rui Fan" <1996fan...@gmail.com> wrote:
>+1（binding）
>
>Best,
>Rui
>
>On Tue, Jun 11, 2024 at 4:14 PM Muhammet Orazov
> wrote:
>
>> +1 (non-binding)
>>
>> Thanks Yuxin for driving this!
>>
>> Best,
>> Muhammet
>>
>>
>> On 2024-06-07 08:02, Yuxin Tan wrote:
>> > Hi everyone,
>> >
>> > Thanks for all the feedback about the FLIP-459 Support Flink
>> > hybrid shuffle integration with Apache Celeborn[1].
>> > The discussion thread is here [2].
>> >
>> > I'd like to start a vote for it. The vote will be open for at least
>> > 72 hours unless there is an objection or insufficient votes.
>> >
>> > [1]
>> >
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-459%3A+Support+Flink+hybrid+shuffle+integration+with+Apache+Celeborn
>> > [2] https://lists.apache.org/thread/gy7sm7qrf7yrv1rl5f4vtk5fo463ts33
>> >
>> > Best,
>> > Yuxin
>>

Re: [ANNOUNCE] New Apache Flink PMC Member - Fan Rui

[Yuepeng Pan]

Congratulations !

Best,
Yuepeng Pan

On 2024/06/05 10:01:58 Piotr Nowojski wrote:
> Hi everyone,
> 
> On behalf of the PMC, I'm very happy to announce another new Apache Flink
> PMC Member - Fan Rui.
> 
> Rui has been active in the community since August 2019. During this time he
> has contributed a lot of new features. Among others:
>   - Decoupling Autoscaler from Kubernetes Operator, and supporting
> Standalone Autoscaler
>   - Improvements to checkpointing, flamegraphs, restart strategies,
> watermark alignment, network shuffles
>   - Optimizing the memory and CPU usage of large operators, greatly
> reducing the risk and probability of TaskManager OOM
> 
> He reviewed a significant amount of PRs and has been active both on the
> mailing lists and in Jira helping to both maintain and grow Apache Flink's
> community. He is also our current Flink 1.20 release manager.
> 
> In the last 12 months, Rui has been the most active contributor in the
> Flink Kubernetes Operator project, while being the 2nd most active Flink
> contributor at the same time.
> 
> Please join me in welcoming and congratulating Fan Rui!
> 
> Best,
> Piotrek (on behalf of the Flink PMC)
> 

Re:[ANNOUNCE] New Apache Flink PMC Member - Weijie Guo

[Yuepeng Pan]

Congratulations !


Best,
Yuepeng Pan

At 2024-06-04 14:45:45, "Xintong Song"  wrote:
>Hi everyone,
>
>On behalf of the PMC, I'm very happy to announce that Weijie Guo has joined
>the Flink PMC!
>
>Weijie has been an active member of the Apache Flink community for many
>years. He has made significant contributions in many components, including
>runtime, shuffle, sdk, connectors, etc. He has driven / participated in
>many FLIPs, authored and reviewed hundreds of PRs, been consistently active
>on mailing lists, and also helped with release management of 1.20 and
>several other bugfix releases.
>
>Congratulations and welcome Weijie!
>
>Best,
>
>Xintong (on behalf of the Flink PMC)

Re: [VOTE] Release flink-connector-jdbc v3.2.0, release candidate #2

[Yuepeng Pan]

Thanks Leonard for the checking and Rui for the discussion.

I cancel the '-1 (non-binding)' vote.
And +1(non-binding) for the vote thread.

- Verified hash
- Test a few of usage demo on mysql-5.7
- build from source code with jdk-1.8 on MacOS.

Best regards,
Yuepeng Pan.

On 2024/06/03 14:46:35 Leonard Xu wrote:
> 
> > -1 (non-binding)
> > blocked by https://issues.apache.org/jira/browse/FLINK-35496.
> 
> 
> I just replied in https://issues.apache.org/jira/browse/FLINK-35496 
> <https://issues.apache.org/jira/browse/FLINK-35496>, I think the API 
> annotation understanding is incorrect in this case, hope to see your comments
> 
> Best,
> Leonard
> 
> 
> 
> 
> > Best, 
> > Yuepeng Pan
> > 
> > 
> > On 2024/05/22 12:13:51 Leonard Xu wrote:
> >> +1 (binding)
> >> 
> >> - verified signatures
> >> - verified hashsums
> >> - built from source code with java 1.8 succeeded
> >> - checked Github release tag 
> >> - checked release notes
> >> - reviewed the web PR
> >> 
> >> Best,
> >> Leonard
> >> 
> >>> 2024年4月21日 下午9:42，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 jdk8
> >>> - Verified web PR
> >>> - Check that the jar is built by jdk8
> >>> 
> >>> Best,
> >>> Hang
> >>> 
> >>> Ahmed Hamdy  于2024年4月18日周四 21:37写道：
> >>> 
> >>>> +1 (non-binding)
> >>>> 
> >>>> - Verified Checksums and hashes
> >>>> - Verified Signatures
> >>>> - No binaries in source
> >>>> - Build source
> >>>> - Github tag exists
> >>>> - Reviewed Web PR
> >>>> 
> >>>> 
> >>>> Best Regards
> >>>> Ahmed Hamdy
> >>>> 
> >>>> 
> >>>> On Thu, 18 Apr 2024 at 11:22, Danny Cranmer 
> >>>> wrote:
> >>>> 
> >>>>> Sorry for typos:
> >>>>> 
> >>>>>> Please review and vote on the release candidate #1 for the version
> >>>> 3.2.0,
> >>>>> as follows:
> >>>>> Should be "release candidate #2"
> >>>>> 
> >>>>>> * source code tag v3.2.0-rc1 [5],
> >>>>> Should be "source code tag v3.2.0-rc2"
> >>>>> 
> >>>>> Thanks,
> >>>>> Danny
> >>>>> 
> >>>>> On Thu, Apr 18, 2024 at 11:19 AM Danny Cranmer 
> >>>>> wrote:
> >>>>> 
> >>>>>> Hi everyone,
> >>>>>> 
> >>>>>> Please review and vote on the release candidate #1 for the version
> >>>> 3.2.0,
> >>>>>> as follows:
> >>>>>> [ ] +1, Approve the release
> >>>>>> [ ] -1, Do not approve the release (please provide specific comments)
> >>>>>> 
> >>>>>> This release supports Flink 1.18 and 1.19.
> >>>>>> 
> >>>>>> The complete staging area is available for your review, which includes:
> >>>>>> * JIRA release notes [1],
> >>>>>> * the official Apache source release to be deployed to dist.apache.org
> >>>>>> [2], which are signed with the key with fingerprint 125FD8DB [3],
> >>>>>> * all artifacts to be deployed to the Maven Central Repository [4],
> >>>>>> * source code tag v3.2.0-rc1 [5],
> >>>>>> * website pull request listing the new release [6].
> >>>>>> * CI run of tag [7].
> >>>>>> 
> >>>>>> The vote will be open for at least 72 hours. It is adopted by majority
> >>>>>> approval, with at least 3 PMC affirmative votes.
> >>>>>> 
> >>>>>> Thanks,
> >>>>>> Danny
> >>>>>> 
> >>>>>> [1]
> >>>>>> 
> >>>>> 
> >>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522=12353143
> >>>>>> [2]
> >>>>>> 
> >>>>> 
> >>>> https://dist.apache.org/repos/dist/dev/flink/flink-connector-jdbc-3.2.0-rc2
> >>>>>> [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> >>>>>> [4]
> >>>>>> 
> >>>> https://repository.apache.org/content/repositories/orgapacheflink-1718/
> >>>>>> [5]
> >>>>> https://github.com/apache/flink-connector-jdbc/releases/tag/v3.2.0-rc2
> >>>>>> [6] https://github.com/apache/flink-web/pull/734
> >>>>>> [7]
> >>>>> https://github.com/apache/flink-connector-jdbc/actions/runs/8736019099
> >>>>>> 
> >>>>> 
> >>>> 
> >> 
> >> 
> 
> 

Re: [VOTE] Release flink-connector-jdbc v3.2.0, release candidate #2

[Yuepeng Pan]

-1 (non-binding)
blocked by https://issues.apache.org/jira/browse/FLINK-35496.

Best, 
Yuepeng Pan


On 2024/05/22 12:13:51 Leonard Xu wrote:
> +1 (binding)
> 
> - verified signatures
> - verified hashsums
> - built from source code with java 1.8 succeeded
> - checked Github release tag 
> - checked release notes
> - reviewed the web PR
> 
> Best,
> Leonard
> 
> > 2024年4月21日 下午9:42，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 jdk8
> > - Verified web PR
> > - Check that the jar is built by jdk8
> > 
> > Best,
> > Hang
> > 
> > Ahmed Hamdy  于2024年4月18日周四 21:37写道：
> > 
> >> +1 (non-binding)
> >> 
> >> - Verified Checksums and hashes
> >> - Verified Signatures
> >> - No binaries in source
> >> - Build source
> >> - Github tag exists
> >> - Reviewed Web PR
> >> 
> >> 
> >> Best Regards
> >> Ahmed Hamdy
> >> 
> >> 
> >> On Thu, 18 Apr 2024 at 11:22, Danny Cranmer 
> >> wrote:
> >> 
> >>> Sorry for typos:
> >>> 
> >>>> Please review and vote on the release candidate #1 for the version
> >> 3.2.0,
> >>> as follows:
> >>> Should be "release candidate #2"
> >>> 
> >>>> * source code tag v3.2.0-rc1 [5],
> >>> Should be "source code tag v3.2.0-rc2"
> >>> 
> >>> Thanks,
> >>> Danny
> >>> 
> >>> On Thu, Apr 18, 2024 at 11:19 AM Danny Cranmer 
> >>> wrote:
> >>> 
> >>>> Hi everyone,
> >>>> 
> >>>> Please review and vote on the release candidate #1 for the version
> >> 3.2.0,
> >>>> as follows:
> >>>> [ ] +1, Approve the release
> >>>> [ ] -1, Do not approve the release (please provide specific comments)
> >>>> 
> >>>> This release supports Flink 1.18 and 1.19.
> >>>> 
> >>>> The complete staging area is available for your review, which includes:
> >>>> * JIRA release notes [1],
> >>>> * the official Apache source release to be deployed to dist.apache.org
> >>>> [2], which are signed with the key with fingerprint 125FD8DB [3],
> >>>> * all artifacts to be deployed to the Maven Central Repository [4],
> >>>> * source code tag v3.2.0-rc1 [5],
> >>>> * website pull request listing the new release [6].
> >>>> * CI run of tag [7].
> >>>> 
> >>>> The vote will be open for at least 72 hours. It is adopted by majority
> >>>> approval, with at least 3 PMC affirmative votes.
> >>>> 
> >>>> Thanks,
> >>>> Danny
> >>>> 
> >>>> [1]
> >>>> 
> >>> 
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522=12353143
> >>>> [2]
> >>>> 
> >>> 
> >> https://dist.apache.org/repos/dist/dev/flink/flink-connector-jdbc-3.2.0-rc2
> >>>> [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> >>>> [4]
> >>>> 
> >> https://repository.apache.org/content/repositories/orgapacheflink-1718/
> >>>> [5]
> >>> https://github.com/apache/flink-connector-jdbc/releases/tag/v3.2.0-rc2
> >>>> [6] https://github.com/apache/flink-web/pull/734
> >>>> [7]
> >>> https://github.com/apache/flink-connector-jdbc/actions/runs/8736019099
> >>>> 
> >>> 
> >> 
> 
> 

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

[Yuepeng Pan]

+1 (non-binding)

- Built from source code with JDK 1.8 on MaxOS- Run examples locally.- Checked 
release notes Best, Yuepeng Pan


At 2024-05-28 22:53:10, "gongzhongqiang"  wrote:
>+1(non-binding)
>
>- Verified signatures and hash sums
>- Reviewed the web PR
>- Built from source code with JDK 1.8 on Ubuntu 22.04
>- Checked release notes
>
>Best,
>Zhongqiang Gong
>
>
>Sergey Nuyanzin  于2024年5月16日周四 06:03写道：
>
>> Hi everyone,
>> Please review and vote on release candidate #1 for
>> flink-connector-opensearch v1.2.0, as follows:
>> [ ] +1, Approve the release
>> [ ] -1, Do not approve the release (please provide specific comments)
>>
>>
>> The complete staging area is available for your review, which includes:
>> * JIRA release notes [1],
>> * the official Apache source release to be deployed to dist.apache.org
>> [2],
>> which are signed with the key with fingerprint
>> F7529FAE24811A5C0DF3CA741596BBF0726835D8 [3],
>> * all artifacts to be deployed to the Maven Central Repository [4],
>> * source code tag v1.2.0-rc1 [5],
>> * website pull request listing the new release [6].
>> * CI build of the tag [7].
>>
>> The vote will be open for at least 72 hours. It is adopted by majority
>> approval, with at least 3 PMC affirmative votes.
>>
>> Note that this release is for Opensearch v1.x
>>
>> Thanks,
>> Release Manager
>>
>> [1] https://issues.apache.org/jira/projects/FLINK/versions/12353812
>> [2]
>>
>> https://dist.apache.org/repos/dist/dev/flink/flink-connector-opensearch-1.2.0-rc1
>> [3] https://dist.apache.org/repos/dist/release/flink/KEYS
>> [4] https://repository.apache.org/content/repositories/orgapacheflink-1734
>> [5]
>>
>> https://github.com/apache/flink-connector-opensearch/releases/tag/v1.2.0-rc1
>> [6] https://github.com/apache/flink-web/pull/740
>> [7]
>>
>> https://github.com/apache/flink-connector-opensearch/actions/runs/9102334125
>>

Re: [VOTE] FLIP-453: Promote Unified Sink API V2 to Public and Deprecate SinkFunction

[Yuepeng Pan]

+1(non-binding)


Best,
Yuepeng Pan


At 2024-05-15 21:09:04, "Jing Ge"  wrote:
>+1(binding) Thanks Martijn!
>
>Best regards,
>Jing
>
>On Wed, May 15, 2024 at 7:00 PM Muhammet Orazov
> wrote:
>
>> Thanks Martijn driving this! +1 (non-binding)
>>
>> Best,
>> Muhammet
>>
>> On 2024-05-14 06:43, Martijn Visser wrote:
>> > Hi everyone,
>> >
>> > With no more discussions being open in the thread [1] I would like to
>> > start
>> > a vote on FLIP-453: Promote Unified Sink API V2 to Public and Deprecate
>> > SinkFunction [2]
>> >
>> > The vote will be open for at least 72 hours unless there is an
>> > objection or
>> > insufficient votes.
>> >
>> > Best regards,
>> >
>> > Martijn
>> >
>> > [1] https://lists.apache.org/thread/hod6bg421bzwhbfv60lwsck7r81dvo59
>> > [2]
>> >
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-453%3A+Promote+Unified+Sink+API+V2+to+Public+and+Deprecate+SinkFunction
>>

Re: [VOTE] FLIP-449: Reorganization of flink-connector-jdbc

[Yuepeng Pan]

Hi, Boto.

+1 (non-binding).

Thanks for your driving it.

Best regards,
Yuepeng Pan.

On 2024/05/09 12:01:04 Joao Boto wrote:
> Hi everyone,
> 
> Thanks for all the feedback, I'd like to start a vote on the FLIP-449:
> Reorganization of flink-connector-jdbc [1].
> The discussion thread is here [2].
> 
> The vote will be open for at least 72 hours unless there is an objection or
> insufficient votes.
> 
> [1]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-449%3A+Reorganization+of+flink-connector-jdbc
> [2] https://lists.apache.org/thread/jc1yvvo35xwqzlxl5mj77qw3hq6f5sgr
> 
> Best
> Joao Boto
> 

Re: Re:[DISCUSSION] FLIP-449: Reorganization of flink-connector-jdbc

[Yuepeng Pan]

Hi, Boto.

It's already clear enough to me.
Thanks for your reply.

Best,
Yuepeng Pan

On 2024/04/25 15:41:01 João Boto wrote:
> Hi Pan,
> 
> Users who wish to utilize only one database and prefer not to use 
> flink-connector-jdbc-${version}.jar + ${database-connector-driver}.jar should 
> opt for option 1: flink-connector-jdbc-core-${version}.jar + 
> flink-connector-jdbc-mysql-${version}.jar + ${database-connector-driver}.jar.
> 
> We could introduce a flink-connector-jdbc-mysql-${version}-fat.jar that 
> includes flink-connector-jdbc-core-${version}.jar, but this could create 
> potential challenges. This approach could lead to duplicate classes if a user 
> intends to read from MySQL and write to PostgreSQL while utilizing both fat 
> JARs simultaneously.
> 
> To maintain clarity and minimize conflicts, we're currently leaning towards 
> maintaining the existing structure, where flink-connector-jdbc-${version}.jar 
> remains shaded for simplicity, encompassing the core functionality and all 
> database-related features within the same JAR.
> 
> Please let me know if you require further clarification on any aspect.
> 
> Best regards,
> Joao Boto
> 
> 
> 
> On 2024/04/25 11:41:00 Yuepeng Pan wrote:
> > Hi, Boto.
> > 
> > Thanks for your driving it !
> > +1 from me on the proposal.
> > 
> > 
> > 
> > 
> > Maybe we need to ensure that a simple usage method is provided to users 
> > after the refactoring.
> > 
> > In the current situation, which supported database does the user intend to 
> > use,
> > 
> > Users only need to add the flink-connector-jdbc-${version}.jar + 
> > ${database-connector-driver}.jar
> > 
> >  into the dependencies, which could be used out of the box.
> > 
> > I noticed in FLIP that we will perform shadow related operations to ensure 
> > 
> > the same usage and semantics as before.
> > 
> > So, if users only want to use one type of database (eg. MySQL), 
> > 
> > what forms would we plan to provide jars in?
> > 
> > For example: 
> > 
> > 1. flink-connector-jdbc-core-${version}.jar + 
> > flink-connector-jdbc-mysql-${version}.jar + 
> > ${database-connector-driver}.jar.
> > 
> > 2. Or flink-connector-jdbc-mysql-${version}.jar + 
> > ${database-connector-driver}.jar.
> > 
> > 3. Or a another different concise way?
> > 
> > 
> > 
> > 
> > Thank you.
> > 
> > Best, 
> > Yuepeng Pan
> > 
> > 
> > 
> > 
> > At 2024-04-25 16:54:13, "Joao Boto"  wrote:
> > >Hi all,
> > >
> > >I'd like to start a discussion on FLIP-449: Reorganization of
> > >flink-connector-jdbc [1].
> > >As Flink continues to evolve, we've noticed an increasing level of
> > >complexity within the JDBC connector.
> > >The proposed solution is to address this complexity by separating the core
> > >functionality from individual database components, thereby streamlining the
> > >structure into distinct modules.
> > >
> > >Looking forward to your feedback and suggestions, thanks.
> > >Best regards,
> > >Joao Boto
> > >
> > >[1]
> > >https://cwiki.apache.org/confluence/display/FLINK/FLIP-449%3A+Reorganization+of+flink-connector-jdbc
> > 
> 

Re:[DISCUSSION] FLIP-449: Reorganization of flink-connector-jdbc

[Yuepeng Pan]

Hi, Boto.

Thanks for your driving it !
+1 from me on the proposal.




Maybe we need to ensure that a simple usage method is provided to users after 
the refactoring.

In the current situation, which supported database does the user intend to use,

Users only need to add the flink-connector-jdbc-${version}.jar + 
${database-connector-driver}.jar

 into the dependencies, which could be used out of the box.

I noticed in FLIP that we will perform shadow related operations to ensure 

the same usage and semantics as before.

So, if users only want to use one type of database (eg. MySQL), 

what forms would we plan to provide jars in?

For example: 

1. flink-connector-jdbc-core-${version}.jar + 
flink-connector-jdbc-mysql-${version}.jar + ${database-connector-driver}.jar.

2. Or flink-connector-jdbc-mysql-${version}.jar + 
${database-connector-driver}.jar.

3. Or a another different concise way?




Thank you.

Best, 
Yuepeng Pan




At 2024-04-25 16:54:13, "Joao Boto"  wrote:
>Hi all,
>
>I'd like to start a discussion on FLIP-449: Reorganization of
>flink-connector-jdbc [1].
>As Flink continues to evolve, we've noticed an increasing level of
>complexity within the JDBC connector.
>The proposed solution is to address this complexity by separating the core
>functionality from individual database components, thereby streamlining the
>structure into distinct modules.
>
>Looking forward to your feedback and suggestions, thanks.
>Best regards,
>Joao Boto
>
>[1]
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-449%3A+Reorganization+of+flink-connector-jdbc

Re: [VOTE] FLIP-446: Kubernetes Operator State Snapshot CRD

[Yuepeng Pan]

+1(non-binding)


Best,
Yuepeng Pan 

At 2024-04-24 16:05:07, "Rui Fan" <1996fan...@gmail.com> wrote:
>+1(binding)
>
>Best,
>Rui
>
>On Wed, Apr 24, 2024 at 4:03 PM Mate Czagany  wrote:
>
>> Hi everyone,
>>
>> I'd like to start a vote on the FLIP-446: Kubernetes Operator State
>> Snapshot CRD [1]. The discussion thread is here [2].
>>
>> The vote will be open for at least 72 hours unless there is an objection or
>> insufficient votes.
>>
>> [1]
>>
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-446%3A+Kubernetes+Operator+State+Snapshot+CRD
>> [2] https://lists.apache.org/thread/q5dzjwj0qk34rbg2sczyypfhokxoc3q7
>>
>> Regards,
>> Mate
>>

Re: [VOTE] FLIP-435: Introduce a New Materialized Table for Simplifying Data Pipelines

[Yuepeng Pan]

+1(non-binding)

Best,
Yuepeng Pan

At 2024-04-19 15:22:04, "gongzhongqiang"  wrote:
>+1(non-binding)
>
>
>Best,
>
>Zhongqiang Gong
>
>Ron liu  于2024年4月17日周三 14:28写道：
>
>> Hi Dev,
>>
>> Thank you to everyone for the feedback on FLIP-435: Introduce a New
>> Materialized Table for Simplifying Data Pipelines[1][2].
>>
>> I'd like to start a vote for it. The vote will be open for at least 72
>> hours unless there is an objection or not enough votes.
>>
>> [1]
>>
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-435%3A+Introduce+a+New+Materialized+Table+for+Simplifying+Data+Pipelines
>> [2] https://lists.apache.org/thread/c1gnn3bvbfs8v1trlf975t327s4rsffs
>>
>> Best,
>> Ron
>>

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

[Yuepeng Pan]

+1 (non-binding)

- Checked source-build for source code tag v3.2.0-rc1
- Did test for some examples with mysql 5.8.
- Checked release note page.


Thanks for driving it!


Best,
Yuepeng Pan




At 2024-04-17 18:02:06, "Danny Cranmer"  wrote:
>Hi everyone,
>
>Please review and vote on the release candidate #1 for the version 3.2.0,
>as follows:
>[ ] +1, Approve the release
>[ ] -1, Do not approve the release (please provide specific comments)
>
>This release supports Flink 1.18 and 1.19.
>
>The complete staging area is available for your review, which includes:
>* JIRA release notes [1],
>* the official Apache source release to be deployed to dist.apache.org [2],
>which are signed with the key with fingerprint 125FD8DB [3],
>* all artifacts to be deployed to the Maven Central Repository [4],
>* source code tag v3.2.0-rc1 [5],
>* website pull request listing the new release [6].
>* CI run of tag [7].
>
>The vote will be open for at least 72 hours. It is adopted by majority
>approval, with at least 3 PMC affirmative votes.
>
>Thanks,
>Danny
>
>[1]
>https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522=12353143
>[2]
>https://dist.apache.org/repos/dist/dev/flink/flink-connector-jdbc-3.2.0-rc1
>[3] https://dist.apache.org/repos/dist/release/flink/KEYS
>[4] https://repository.apache.org/content/repositories/orgapacheflink-1714/
>[5] https://github.com/apache/flink-connector-jdbc/releases/tag/v3.2.0-rc1
>[6] https://github.com/apache/flink-web/pull/734
>[7] https://github.com/apache/flink-connector-jdbc/actions/runs/8719743185

Re:[VOTE] FLIP-435: Introduce a New Materialized Table for Simplifying Data Pipelines

[Yuepeng Pan]

+1(non-binding).




Best, 
Yuepeng Pan

At 2024-04-17 14:27:27, "Ron liu"  wrote:
>Hi Dev,
>
>Thank you to everyone for the feedback on FLIP-435: Introduce a New
>Materialized Table for Simplifying Data Pipelines[1][2].
>
>I'd like to start a vote for it. The vote will be open for at least 72
>hours unless there is an objection or not enough votes.
>
>[1]
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-435%3A+Introduce+a+New+Materialized+Table+for+Simplifying+Data+Pipelines
>[2] https://lists.apache.org/thread/c1gnn3bvbfs8v1trlf975t327s4rsffs
>
>Best,
>Ron

Re:Re: [ANNOUNCE] New Apache Flink PMC Member - Jing Ge

[Yuepeng Pan]

Congratulations ! Gejing.

Best,Yuepeng Pan
At 2024-04-12 16:28:36, "Rui Fan" <1996fan...@gmail.com> wrote:
>Congratulations, Jing~
>
>Best,
>Rui
>
>On Fri, Apr 12, 2024 at 4:28 PM Yun Tang  wrote:
>
>> Congratulations, Jing!
>>
>> Best
>> Yun Tang
>> 
>> From: Jark Wu 
>> Sent: Friday, April 12, 2024 16:02
>> To: dev 
>> Cc: gej...@gmail.com 
>> Subject: [ANNOUNCE] New Apache Flink PMC Member - Jing Ge
>>
>> Hi everyone,
>>
>> On behalf of the PMC, I'm very happy to announce that Jing Ge has
>> joined the Flink PMC!
>>
>> Jing has been contributing to Apache Flink for a long time. He continuously
>> works on SQL, connectors, Source, and Sink APIs, test, and document
>> modules while contributing lots of code and insightful discussions. He is
>> one of the maintainers of Flink CI infra. He is also willing to help a lot
>> in the
>> community work, such as being the release manager for both 1.18 and 1.19,
>> verifying releases, and answering questions on the mailing list. Besides
>> that,
>> he is continuously helping with the expansion of the Flink community and
>> has
>> given several talks about Flink at many conferences, such as Flink Forward
>> 2022 and 2023.
>>
>> Congratulations and welcome Jing!
>>
>> Best,
>> Jark (on behalf of the Flink PMC)
>>

Re:Re: [ANNOUNCE] New Apache Flink PMC Member - Lincoln Lee

[Yuepeng Pan]

Congratulations, Lincoln!

Best,Yuepeng Pan
At 2024-04-12 16:24:01, "Yun Tang"  wrote:
>Congratulations, Lincoln!
>
>
>Best
>Yun Tang
>
>From: Jark Wu 
>Sent: Friday, April 12, 2024 15:59
>To: dev 
>Cc: Lincoln Lee 
>Subject: [ANNOUNCE] New Apache Flink PMC Member - Lincoln Lee
>
>Hi everyone,
>
>On behalf of the PMC, I'm very happy to announce that Lincoln Lee has
>joined the Flink PMC!
>
>Lincoln has been an active member of the Apache Flink community for
>many years. He mainly works on Flink SQL component and has driven
>/pushed many FLIPs around SQL, including FLIP-282/373/415/435 in
>the recent versions. He has a great technical vision of Flink SQL and
>participated in plenty of discussions in the dev mailing list. Besides
>that,
>he is community-minded, such as being the release manager of 1.19,
>verifying releases, managing release syncs, writing the release
>announcement etc.
>
>Congratulations and welcome Lincoln!
>
>Best,
>Jark (on behalf of the Flink PMC)

Re: [VOTE] FLIP-441: Show the JobType and remove Execution Mode on Flink WebUI

[Yuepeng Pan]

Hi Rui,

Thanks for driving it!
+1  (non-binding)
Best,
Yuepeng Pan

At 2024-04-12 10:31:19, "Yanfei Lei"  wrote:
>Hi Rui,
>
>Thanks for driving it!
>
>+1  (binding)
>
>Hangxiang Yu  于2024年4月12日周五 10:26写道：
>>
>> +1  (binding)
>>
>> On Fri, Apr 12, 2024 at 10:22 AM Jinzhong Li 
>> wrote:
>>
>> > +1  (non binding)
>> >
>> > Bests,
>> > Jinzhong
>> >
>> > On Thu, Apr 11, 2024 at 7:26 AM Muhammet Orazov
>> >  wrote:
>> >
>> > > Hey Rui,
>> > >
>> > > +1 (non-binding).
>> > >
>> > > Thanks for driving it!
>> > >
>> > > Best,
>> > > Muhammet
>> > >
>> > > On 2024-04-10 04:36, Rui Fan wrote:
>> > > > Hi devs,
>> > > >
>> > > > Thank you to everyone for the feedback on FLIP-441: Show
>> > > > the JobType and remove Execution Mode on Flink WebUI[1]
>> > > > which has been discussed in this thread [2].
>> > > >
>> > > > I would like to start a vote for it. The vote will be open for at least
>> > > > 72
>> > > > hours unless there is an objection or not enough votes.
>> > > >
>> > > > [1] https://cwiki.apache.org/confluence/x/agrPEQ
>> > > > [2] https://lists.apache.org/thread/0s52w17w24x7m2zo6ogl18t1fy412vcd
>> > > >
>> > > > Best,
>> > > > Rui
>> > >
>> >
>>
>>
>> --
>> Best,
>> Hangxiang.
>
>
>
>-- 
>Best,
>Yanfei

Re: [VOTE] FLIP-399: Flink Connector Doris

[Yuepeng Pan]

Hi, Di.

Thank you for driving it !

+1 (non-binding).

Best,
Yuepeng Pan

On 2024/04/09 02:47:55 wudi wrote:
> Hi devs,
> 
> I would like to start a vote about FLIP-399 [1]. The FLIP is about 
> contributing the Flink Doris Connector[2] to the Flink community. Discussion 
> thread [3].
> 
> The vote will be open for at least 72 hours unless there is an objection or
> insufficient votes.
> 
> 
> Thanks,
> Di.Wu
> 
> 
> [1] 
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-399%3A+Flink+Connector+Doris
> [2] https://github.com/apache/doris-flink-connector
> [3] https://lists.apache.org/thread/p3z4wsw3ftdyfs9p2wd7bbr2gfyl3xnh
> 
> 

Re: [VOTE] FLIP-433: State Access on DataStream API V2

[Yuepeng Pan]

+1(non-binding)

Best,
Yuepeng Pan


On 2024/03/28 10:44:25 Yuan Mei wrote:
> +1 (binding)
> 
> Best,
> Yuan
> 
> On Tue, Mar 26, 2024 at 8:59 AM Yunfeng Zhou 
> wrote:
> 
> > +1 (non-binding)
> >
> > Best,
> > Yunfeng
> >
> > On Wed, Mar 20, 2024 at 8:29 PM weijie guo 
> > wrote:
> > >
> > > Hi everyone,
> > >
> > >
> > > Thanks for all the feedback about the FLIP-433: State Access on
> > > DataStream API V2 [1]. The discussion thread is here [2].
> > >
> > >
> > > The vote will be open for at least 72 hours unless there is an
> > > objection or insufficient votes.
> > >
> > >
> > > Best regards,
> > >
> > > Weijie
> > >
> > >
> > > [1]
> > >
> > https://cwiki.apache.org/confluence/display/FLINK/FLIP-433%3A+State+Access+on+DataStream+API+V2
> > >
> > > [2] https://lists.apache.org/thread/8ghzqkvt99p4k7hjqxzwhqny7zb7xrwo
> >
> 

Re: [VOTE] FLIP-426: Grouping Remote State Access

[Yuepeng Pan]

+1(non-binding)

Best,
Yuepeng Pan


On 2024/03/29 02:55:40 gongzhongqiang wrote:
> +1(non-binding)
> 
> Best,
> 
> Zhongqiang Gong
> 
> Jinzhong Li  于2024年3月27日周三 18:57写道：
> 
> > Hi devs,
> >
> > I'd like to start a vote on the FLIP-426: Grouping Remote State Access [1].
> > The discussion thread is here [2].
> >
> > The vote will be open for at least 72 hours unless there is an objection or
> > insufficient votes.
> >
> >
> > [1] https://cwiki.apache.org/confluence/x/TYp3EQ
> >
> > [2] https://lists.apache.org/thread/bt931focfl9971cwq194trmf3pkdsxrf
> >
> >
> > Best,
> >
> > Jinzhong
> >
> 

Re: [VOTE] FLIP-424: Asynchronous State APIs

[Yuepeng Pan]

+1(non-binding)

Best,
Yuepeng Pan


On 2024/03/29 03:03:53 Yunfeng Zhou wrote:
> +1 (non-binding)
> 
> Best,
> Yunfeng
> 
> On Wed, Mar 27, 2024 at 6:23 PM Zakelly Lan  wrote:
> >
> > Hi devs,
> >
> > I'd like to start a vote on the FLIP-424: Asynchronous State APIs [1]. The
> > discussion thread is here [2].
> >
> > The vote will be open for at least 72 hours unless there is an objection or
> > insufficient votes.
> >
> > [1] https://cwiki.apache.org/confluence/x/SYp3EQ
> > [2] https://lists.apache.org/thread/nmd9qd0k8l94ygcfgllxms49wmtz1864
> >
> >
> > Best,
> > Zakelly
> 

Re: [VOTE] FLIP-427: Disaggregated state Store

[Yuepeng Pan]

+1(non-binding)

Best,
Yuepeng Pan

On 2024/03/29 04:17:15 Yun Tang wrote:
> +1 (binding)
> 
> Best,
> Yun Tang
> 
> From: Rui Fan <1996fan...@gmail.com>
> Sent: Friday, March 29, 2024 10:28
> To: dev@flink.apache.org 
> Subject: Re: Re: [VOTE] FLIP-427: Disaggregated state Store
> 
> +1(binding)
> 
> Best,
> Rui
> 
> On Thu, Mar 28, 2024 at 10:30 PM Piotr Nowojski 
> wrote:
> 
> > +1 (binding)
> >
> > czw., 28 mar 2024 o 13:31 Feifan Wang  napisał(a):
> >
> > > +1 (non-binding)
> > >
> > >
> > >
> > >
> > > ——
> > >
> > > Best regards,
> > >
> > > Feifan Wang
> > >
> > >
> > >
> > >
> > > At 2024-03-28 19:01:01, "Yuan Mei"  wrote:
> > > >+1 (binding)
> > > >
> > > >Best
> > > >Yuan
> > > >
> > > >
> > > >
> > > >
> > > >On Wed, Mar 27, 2024 at 6:37 PM Hangxiang Yu 
> > wrote:
> > > >
> > > >> Hi devs,
> > > >>
> > > >> Thanks all for your valuable feedback about FLIP-427: Disaggregated
> > > state
> > > >> Store [1].
> > > >> I'd like to start a vote on it.  The discussion thread is here [2].
> > > >>
> > > >> The vote will be open for at least 72 hours unless there is an
> > > objection or
> > > >> insufficient votes.
> > > >>
> > > >> [1] https://cwiki.apache.org/confluence/x/T4p3EQ
> > > >> [2] https://lists.apache.org/thread/vktfzqvb7t4rltg7fdlsyd9sfdmrc4ft
> > > >>
> > > >>
> > > >> Best,
> > > >> Hangxiang
> > > >>
> > >
> >
> 

Re: [VOTE] FLIP-439: Externalize Kudu Connector from Bahir

[Yuepeng Pan]

+1 (non-binding)


Regards,
Yuepeng Pan














在 2024-03-22 04:11:32，"Jeyhun Karimov"  写道：
>+1 (non-binding)
>
>Regards,
>Jeyhun
>
>On Thu, Mar 21, 2024 at 2:04 PM Márton Balassi 
>wrote:
>
>> +1(binding)
>>
>> On Thu, Mar 21, 2024 at 1:24 PM Leonard Xu  wrote:
>>
>> > +1(binding)
>> >
>> > Best,
>> > Leonard
>> >
>> > > 2024年3月21日 下午5:21，Martijn Visser  写道：
>> > >
>> > > +1 (binding)
>> > >
>> > > On Thu, Mar 21, 2024 at 8:01 AM gongzhongqiang <
>> > gongzhongqi...@apache.org>
>> > > wrote:
>> > >
>> > >> +1 (non-binding)
>> > >>
>> > >> Bests,
>> > >> Zhongqiang Gong
>> > >>
>> > >> Ferenc Csaky  于2024年3月20日周三 22:11写道：
>> > >>
>> > >>> Hello devs,
>> > >>>
>> > >>> I would like to start a vote about FLIP-439 [1]. The FLIP is about to
>> > >>> externalize the Kudu
>> > >>> connector from the recently retired Apache Bahir project [2] to keep
>> it
>> > >>> maintainable and
>> > >>> make it up to date as well. Discussion thread [3].
>> > >>>
>> > >>> The vote will be open for at least 72 hours (until 2024 March 23
>> 14:03
>> > >>> UTC) unless there
>> > >>> are any objections or insufficient votes.
>> > >>>
>> > >>> Thanks,
>> > >>> Ferenc
>> > >>>
>> > >>> [1]
>> > >>>
>> > >>
>> >
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-439%3A+Externalize+Kudu+Connector+from+Bahir
>> > >>> [2] https://attic.apache.org/projects/bahir.html
>> > >>> [3] https://lists.apache.org/thread/oydhcfkco2kqp4hdd1glzy5vkw131rkz
>> > >>
>> >
>> >
>>

Re:[VOTE] FLIP-436: Introduce Catalog-related Syntax

[Yuepeng Pan]

Hi, Yubin


Thanks for driving it !

+1 non-binding.







Best,
Yuepeng Pan.








At 2024-03-19 17:56:42, "Yubin Li"  wrote:
>Hi everyone,
>
>Thanks for all the feedback, I'd like to start a vote on the FLIP-436:
>Introduce Catalog-related Syntax [1]. The discussion thread is here
>[2].
>
>The vote will be open for at least 72 hours unless there is an
>objection or insufficient votes.
>
>[1] 
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-436%3A+Introduce+Catalog-related+Syntax
>[2] https://lists.apache.org/thread/10k1bjb4sngyjwhmfqfky28lyoo7sv0z
>
>Best regards,
>Yubin

Re: [ANNOUNCE] Apache Flink 1.19.0 released

[Yuepeng Pan]

Congratulations!


Thanks to release managers and everyone involved.




Best,
Yuepeng Pan








At 2024-03-18 18:09:45, "Yubin Li"  wrote:
>Congratulations!
>
>Thanks to release managers and everyone involved.
>
>On Mon, Mar 18, 2024 at 5:55 PM Hangxiang Yu  wrote:
>>
>> Congratulations!
>> Thanks release managers and all involved!
>>
>> On Mon, Mar 18, 2024 at 5:23 PM Hang Ruan  wrote:
>>
>> > Congratulations!
>> >
>> > Best,
>> > Hang
>> >
>> > Paul Lam  于2024年3月18日周一 17:18写道：
>> >
>> > > Congrats! Thanks to everyone involved!
>> > >
>> > > Best,
>> > > Paul Lam
>> > >
>> > > > 2024年3月18日 16:37，Samrat Deb  写道：
>> > > >
>> > > > Congratulations !
>> > > >
>> > > > On Mon, 18 Mar 2024 at 2:07 PM, Jingsong Li 
>> > > wrote:
>> > > >
>> > > >> Congratulations!
>> > > >>
>> > > >> On Mon, Mar 18, 2024 at 4:30 PM Rui Fan <1996fan...@gmail.com> wrote:
>> > > >>>
>> > > >>> Congratulations, thanks for the great work!
>> > > >>>
>> > > >>> Best,
>> > > >>> Rui
>> > > >>>
>> > > >>> On Mon, Mar 18, 2024 at 4:26 PM Lincoln Lee 
>> > > >> wrote:
>> > > >>>>
>> > > >>>> The Apache Flink community is very happy to announce the release of
>> > > >> Apache Flink 1.19.0, which is the fisrt release for the Apache Flink
>> > > 1.19
>> > > >> series.
>> > > >>>>
>> > > >>>> Apache Flink® is an open-source stream processing framework for
>> > > >> distributed, high-performing, always-available, and accurate data
>> > > streaming
>> > > >> applications.
>> > > >>>>
>> > > >>>> The release is available for download at:
>> > > >>>> https://flink.apache.org/downloads.html
>> > > >>>>
>> > > >>>> Please check out the release blog post for an overview of the
>> > > >> improvements for this bugfix release:
>> > > >>>>
>> > > >>
>> > >
>> > https://flink.apache.org/2024/03/18/announcing-the-release-of-apache-flink-1.19/
>> > > >>>>
>> > > >>>> The full release notes are available in Jira:
>> > > >>>>
>> > > >>
>> > >
>> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522=12353282
>> > > >>>>
>> > > >>>> We would like to thank all contributors of the Apache Flink
>> > community
>> > > >> who made this release possible!
>> > > >>>>
>> > > >>>>
>> > > >>>> Best,
>> > > >>>> Yun, Jing, Martijn and Lincoln
>> > > >>
>> > >
>> > >
>> >
>>
>>
>> --
>> Best,
>> Hangxiang.

Re: [ANNOUNCE] New Apache Flink Committer - Jiabao Sun

[Yuepeng Pan]

Congratulations~ :)

Best,
Yuepeng Pan










在 2024-02-21 09:52:17，"Hongshun Wang"  写道：
>Congratulations, Jiabao :)
>Congratulations Jiabao!
>
>Best,
>Hongshun
>Best regards,
>
>Weijie
>
>On Tue, Feb 20, 2024 at 2:19 PM Runkang He  wrote:
>
>> Congratulations Jiabao!
>>
>> Best,
>> Runkang He
>>
>> Jane Chan  于2024年2月20日周二 14:18写道：
>>
>> > Congrats, Jiabao!
>> >
>> > Best,
>> > Jane
>> >
>> > On Tue, Feb 20, 2024 at 10:32 AM Paul Lam  wrote:
>> >
>> > > Congrats, Jiabao!
>> > >
>> > > Best,
>> > > Paul Lam
>> > >
>> > > > 2024年2月20日 10:29，Zakelly Lan  写道：
>> > > >
>> > > >> Congrats! Jiabao!
>> > >
>> > >
>> >
>>

Re: [VOTE] FLIP-418: Show data skew score on Flink Dashboard

[Yuepeng Pan]

+1(non-binding)


Best,
Yuepeng.

At 2024-02-15 19:13:21, "Rui Fan" <1996fan...@gmail.com> wrote:
>+1(binding)
>
>Thanks for driving this proposal!
>
>Best,
>Rui
>
>On Thu, 15 Feb 2024 at 17:47, Danny Cranmer  wrote:
>
>> Thanks for driving thie Emre,
>>
>> +1 (binding)
>>
>> Thanks,
>> Danny.
>>
>> On Mon, Feb 12, 2024 at 9:42 PM Hong Liang  wrote:
>>
>> > +1 (binding)
>> >
>> > Thank you for driving this Emre! This is a good step towards better user
>> > experience when diagnosing performance issues with Flink jobs.
>> >
>> > Best,
>> > Hong
>> >
>> > On Wed, Jan 31, 2024 at 3:00 AM Aleksandr Pilipenko 
>> > wrote:
>> >
>> > > Thanks for the FLIP!
>> > >
>> > > +1 (non-binding)
>> > >
>> > > Best,
>> > > Aleksandr
>> > >
>> > > On Mon, 29 Jan 2024 at 10:11, Kartoglu, Emre
>> > > >
>> > > wrote:
>> > >
>> > > > Hello,
>> > > >
>> > > > I'd like to call votes on FLIP-418: Show data skew score on Flink
>> > > > Dashboard.
>> > > >
>> > > > FLIP:
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-418%3A+Show+data+skew+score+on+Flink+Dashboard
>> > > > Discussion:
>> > > > https://lists.apache.org/thread/m5ockoork0h2zr78h77dcrn71rbt35ql
>> > > >
>> > > > Kind regards,
>> > > > Emre
>> > > >
>> > > >
>> > >
>> >
>>

[DISCUSS] FLIP-388: Support Dynamic Logger Level Adjustment

[Yuepeng Pan]

Hi all,




I created the FLIP-388[1] to support dynamic logger level adjustment.




 Comprehensive and detailed system logs(like debug, trace, all, etc.) 

could contribute to improved visibility of internal system execution 
information 

and also enhance the efficiency of program debugging. Flink currently only 

supports static log level configuration(like debug, trace, all, etc.) to help 
application 

debugging, which can lead to the following issues when using static log 
configuration:

  1. A sharp increase in log volume, accelerating disk occupancy.

 2. Potential risks of system performance degradation due to a large volume 
of log printing.

 3. The need to simplify log configuration subsequently, which causes 
inevitably cause the program to restart.

 

 Therefore, introducing a mechanism to dynamically adjust the online log 
output level 

in the event of debugging programs will be meaningful, which can complete the 
switch 

of log level configuration without restarting the program. 




 I really appreciate Fan Rui(CC'ed), Zhanghao Chen(CC'ed)  for providing 
some valuable help and suggestions. 

 Please refer to the FLIP[1] document for more details about the proposed 
design and implementation. 

We welcome any feedback and opinions on this proposal.




[1] 
https://cwiki.apache.org/confluence/display/FLINK/FLIP-388%3A+Support+Dynamic+Logger+Level+Adjustment
 

[2] https://issues.apache.org/jira/browse/FLINK-33320




Best,

Yuepeng Pan

Re:[ANNOUNCE] New Apache Flink Committer - Alexander Fedulov

[Yuepeng Pan]

Congrats, Alex!

Best,
Yuepeng Pan
At 2024-01-02 20:15:08, "Maximilian Michels"  wrote:
>Happy New Year everyone,
>
>I'd like to start the year off by announcing Alexander Fedulov as a
>new Flink committer.
>
>Alex has been active in the Flink community since 2019. He has
>contributed more than 100 commits to Flink, its Kubernetes operator,
>and various connectors [1][2].
>
>Especially noteworthy are his contributions on deprecating and
>migrating the old Source API functions and test harnesses, the
>enhancement to flame graphs, the dynamic rescale time computation in
>Flink Autoscaling, as well as all the small enhancements Alex has
>contributed which make a huge difference.
>
>Beyond code contributions, Alex has been an active community member
>with his activity on the mailing lists [3][4], as well as various
>talks and blog posts about Apache Flink [5][6].
>
>Congratulations Alex! The Flink community is proud to have you.
>
>Best,
>The Flink PMC
>
>[1] https://github.com/search?type=commits=author%3Aafedulov+org%3Aapache
>[2] 
>https://issues.apache.org/jira/browse/FLINK-28229?jql=status%20in%20(Resolved%2C%20Closed)%20AND%20assignee%20in%20(afedulov)%20ORDER%20BY%20resolved%20DESC%2C%20created%20DESC
>[3] https://lists.apache.org/list?dev@flink.apache.org:lte=100M:Fedulov
>[4] https://lists.apache.org/list?u...@flink.apache.org:lte=100M:Fedulov
>[5] 
>https://flink.apache.org/2020/01/15/advanced-flink-application-patterns-vol.1-case-study-of-a-fraud-detection-system/
>[6] 
>https://www.ververica.com/blog/presenting-our-streaming-concepts-introduction-to-flink-video-series

Re: [VOTE] FLIP-400: AsyncScalarFunction for asynchronous scalar function support

[Yuepeng Pan]

+1 (non-binding).

Best,
Yuepeng Pan.




At 2023-12-28 09:19:37, "Lincoln Lee"  wrote:
>+1 (binding)
>
>Best,
>Lincoln Lee
>
>
>Martijn Visser  于2023年12月27日周三 23:16写道：
>
>> +1 (binding)
>>
>> On Fri, Dec 22, 2023 at 1:44 AM Jim Hughes 
>> wrote:
>> >
>> > Hi Alan,
>> >
>> > +1 (non binding)
>> >
>> > Cheers,
>> >
>> > Jim
>> >
>> > On Wed, Dec 20, 2023 at 2:41 PM Alan Sheinberg
>> >  wrote:
>> >
>> > > Hi everyone,
>> > >
>> > > I'd like to start a vote on FLIP-400 [1]. It covers introducing a new
>> UDF
>> > > type, AsyncScalarFunction for completing invocations asynchronously.
>> It
>> > > has been discussed in this thread [2].
>> > >
>> > > I would like to start a vote.  The vote will be open for at least 72
>> hours
>> > > (until December 28th 18:00 GMT) unless there is an objection or
>> > > insufficient votes.
>> > >
>> > > [1]
>> > >
>> > >
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-400%3A+AsyncScalarFunction+for+asynchronous+scalar+function+support
>> > > [2] https://lists.apache.org/thread/q3st6t1w05grd7bthzfjtr4r54fv4tm2
>> > >
>> > > Thanks,
>> > > Alan
>> > >
>>

Re:[VOTE] FLIP-383: Support Job Recovery for Batch Jobs

[Yuepeng Pan]

+1 (non-binding)


Best,
Yuepeng Pan.

At 2023-12-14 15:12:48, "Lijie Wang"  wrote:
>Hi devs, Thanks for all feedback about the FLIP-383: Support Job Recovery
>for Batch Jobs[1]. This FLIP was discussed in [2].
>
>I'd like to start a vote for it. The vote will be open for at least 72
>hours (until December 19th 12:00 GMT) unless there is an objection or
>insufficient votes. [1]
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-383%3A+Support+Job+Recovery+for+Batch+Jobs
>
>[2] https://lists.apache.org/thread/074z237c07vtj74685nxo6bttkq3kshz
>  Best, Lijie

Re: [VOTE] FLIP-381: Deprecate configuration getters/setters that return/set complex Java objects

[Yuepeng Pan]

+1(non-binding)

Best,
Roc

On 2023/11/10 03:58:10 Junrui Lee wrote:
> Hi everyone,
> 
> Thank you to everyone for the feedback on FLIP-381: Deprecate configuration
> getters/setters that return/set complex Java objects[1] which has been
> discussed in this thread [2].
> 
> I would like to start a vote for it. The vote will be open for at least 72
> hours (excluding weekends) unless there is an objection or not enough votes.
> 
> [1]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=278464992
> [2]https://lists.apache.org/thread/y5owjkfxq3xs9lmpdbl6d6jmqdgbjqxo
> 

Re:[ANNOUNCE] Apache Flink 1.18.0 released

[Yuepeng Pan]

Thanks for the great work! Congratulations to everyone involved!


Best,
Yuepeng Pan

At 2023-10-27 15:06:40, "ConradJam"  wrote:
>Congratulations!
>
>Jingsong Li  于2023年10月27日周五 13:55写道：
>
>> Congratulations!
>>
>> Thanks Jing and other release managers and all contributors.
>>
>> Best,
>> Jingsong
>>
>> On Fri, Oct 27, 2023 at 1:52 PM Zakelly Lan  wrote:
>> >
>> > Congratulations and thank you all!
>> >
>> >
>> > Best,
>> > Zakelly
>> >
>> > On Fri, Oct 27, 2023 at 12:39 PM Jark Wu  wrote:
>> > >
>> > > Congratulations and thanks release managers and everyone who has
>> > > contributed!
>> > >
>> > > Best,
>> > > Jark
>> > >
>> > > On Fri, 27 Oct 2023 at 12:25, Hang Ruan 
>> wrote:
>> > >
>> > > > Congratulations!
>> > > >
>> > > > Best,
>> > > > Hang
>> > > >
>> > > > Samrat Deb  于2023年10月27日周五 11:50写道：
>> > > >
>> > > > > Congratulations on the great release
>> > > > >
>> > > > > Bests,
>> > > > > Samrat
>> > > > >
>> > > > > On Fri, 27 Oct 2023 at 7:59 AM, Yangze Guo 
>> wrote:
>> > > > >
>> > > > > > Great work! Congratulations to everyone involved!
>> > > > > >
>> > > > > > Best,
>> > > > > > Yangze Guo
>> > > > > >
>> > > > > > On Fri, Oct 27, 2023 at 10:23 AM Qingsheng Ren > >
>> > > > wrote:
>> > > > > > >
>> > > > > > > Congratulations and big THANK YOU to everyone helping with this
>> > > > > release!
>> > > > > > >
>> > > > > > > Best,
>> > > > > > > Qingsheng
>> > > > > > >
>> > > > > > > On Fri, Oct 27, 2023 at 10:18 AM Benchao Li <
>> libenc...@apache.org>
>> > > > > > wrote:
>> > > > > > >>
>> > > > > > >> Great work, thanks everyone involved!
>> > > > > > >>
>> > > > > > >> Rui Fan <1996fan...@gmail.com> 于2023年10月27日周五 10:16写道：
>> > > > > > >> >
>> > > > > > >> > Thanks for the great work!
>> > > > > > >> >
>> > > > > > >> > Best,
>> > > > > > >> > Rui
>> > > > > > >> >
>> > > > > > >> > On Fri, Oct 27, 2023 at 10:03 AM Paul Lam <
>> paullin3...@gmail.com>
>> > > > > > wrote:
>> > > > > > >> >
>> > > > > > >> > > Finally! Thanks to all!
>> > > > > > >> > >
>> > > > > > >> > > Best,
>> > > > > > >> > > Paul Lam
>> > > > > > >> > >
>> > > > > > >> > > > 2023年10月27日 03:58，Alexander Fedulov <
>> > > > > alexander.fedu...@gmail.com>
>> > > > > > 写道：
>> > > > > > >> > > >
>> > > > > > >> > > > Great work, thanks everyone!
>> > > > > > >> > > >
>> > > > > > >> > > > Best,
>> > > > > > >> > > > Alexander
>> > > > > > >> > > >
>> > > > > > >> > > > On Thu, 26 Oct 2023 at 21:15, Martijn Visser <
>> > > > > > martijnvis...@apache.org>
>> > > > > > >> > > > wrote:
>> > > > > > >> > > >
>> > > > > > >> > > >> Thank you all who have contributed!
>> > > > > > >> > > >>
>> > > > > > >> > > >> Op do 26 okt 2023 om 18:41 schreef Feng Jin <
>> > > > > > jinfeng1...@gmail.com>
>> > > > > > >> > > >>
>> > > > > > >> > > >>> Thanks for the great work! Congratulations
>> > > > > > >> > > >>>
>> > > > > > >> > &g

Re: [VOTE] FLIP-370: Support Balanced Tasks Scheduling

[Yuepeng Pan]

+1 (non-binding)

Regards,
Yuepeng Pan

On 2023/10/23 08:25:30 xiangyu feng wrote:
> Thanks for driving that.
> +1 (non-binding)
> 
> Regards,
> Xiangyu
> 
> Yu Chen  于2023年10月23日周一 15:19写道：
> 
> > +1 (non-binding)
> >
> > We deeply need this capability to balance Tasks at the Taskmanager level in
> > production, which helps to make a more sufficient usage of Taskmanager
> > resources. Thanks for driving that.
> >
> > Best,
> > Yu Chen
> >
> > Yangze Guo  于2023年10月23日周一 15:08写道：
> >
> > > +1 (binding)
> > >
> > > Best,
> > > Yangze Guo
> > >
> > > On Mon, Oct 23, 2023 at 12:00 PM Rui Fan <1996fan...@gmail.com> wrote:
> > > >
> > > > +1(binding)
> > > >
> > > > Thanks to Yuepeng and to everyone who participated in the discussion!
> > > >
> > > > Best,
> > > > Rui
> > > >
> > > > On Mon, Oct 23, 2023 at 11:55 AM Roc Marshal  wrote:
> > > >>
> > > >> Hi all,
> > > >>
> > > >> Thanks for all the feedback on FLIP-370[1][2].
> > > >> I'd like to start a vote for  FLIP-370. The vote will last for at
> > least
> > > 72 hours (Oct. 26th at 10:00 A.M. GMT) unless there is an objection or
> > > insufficient votes.
> > > >>
> > > >> Thanks,
> > > >> Yuepeng Pan
> > > >>
> > > >> [1]
> > >
> > https://cwiki.apache.org/confluence/display/FLINK/FLIP-370%3A+Support+Balanced+Tasks+Scheduling
> > > >> [2] https://lists.apache.org/thread/mx3ot0fmk6zr02ccdby0s8oqxqm2pn1x
> > >
> >
> 

Re:[DISCUSS] FLIP-370 : Support Balanced Tasks Scheduling

[Yuepeng Pan]

Hi, dev.




After reviewing the entire email discussion thread with Rui, I noticed that my 
previous ambiguous understanding led to a few incorrect conclusions. 

So I need to change the corresponding conclusions. And Thanks for the help from 
Rui.




>For David: 

>The problem you're trying to solve only exists in complex graphs with

>different per-vertex parallelism. If the parallelism is set globally

>(assuming the pipeline has roughly even data skew), the algorithm could

>make things slightly worse by eliminating some local exchanges. Is that

>correct?

I re-checked that if all parallelisms of all nodes are equal, the new strategy 
will not disrupt local exchanges, all subtasks with forward shuffle are still 
in the same Slot.

As described in the 2.1.1 core logic of FLIP-370[1],  If all parallelisms of 
all nodes are equal, The new strategy would traverse all SEVs of JV, assign the 
SEVs[subtask_index] to the ESSGs[subtask_index]. As the result of the new 
strategy:

a.  This strategy ensures that SEVs with the same index can be assigned to the 
same ESSG. 

b. In the case of forward edges, all subtasks with forward shuffle are still in 
the same Slot, and they are local data exchanges.  



--




If there are no additional comments about the FLIP, I’d  plan to initiate a 
vote about the FLIP next Monday.




Best Regards,

Yuepeng




[1] 
https://cwiki.apache.org/confluence/display/FLINK/FLIP-370%3A+Support+Balanced+Tasks+Scheduling




At 2023-09-25 16:25:03, "Yuepeng Pan"  wrote:
>Hi all,
>
>
>
>
>I and Fan Rui(CC’ed) created the FLIP-370[1] to support balanced tasks 
>scheduling.
>
>
>
>
>The current strategy of Flink to deploy tasks sometimes leads some 
>TMs(TaskManagers) to have more tasks while others have fewer tasks, resulting 
>in excessive resource utilization at some TMs that contain more tasks and 
>becoming a bottleneck for the entire job processing. Developing strategies to 
>achieve task load balancing for TMs and reducing job bottlenecks becomes very 
>meaningful.
>
>
>
>
>The raw design and discussions could be found in the Flink JIRA[2] and Google 
>doc[3]. We really appreciate Zhu Zhu(CC’ed) for providing some valuable help 
>and suggestions in advance. 
>
>
>
>
>Please refer to the FLIP[1] document for more details about the proposed 
>design and implementation. We welcome any feedback and opinions on this 
>proposal.
>
>
>
>
>[1] 
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-370%3A+Support+Balanced+Tasks+Scheduling
>
>[2] https://issues.apache.org/jira/browse/FLINK-31757
>
>[3] 
>https://docs.google.com/document/d/14WhrSNGBdcsRl3IK7CZO-RaZ5KXU2X1dWqxPEFr3iS8
>
>
>
>
>Best,
>
>Yuepeng Pan

Re: [DISCUSS] FLIP-370 : Support Balanced Tasks Scheduling

[Yuepeng Pan]

Hi, Rui.

Thank you for the update.
+1 for the updated edition of the FLIP page.
And thanks Zhu Zhu, Yangze Guo for the discussion. 

Best Regards.
Yuepeng Pan

On 2023/10/17 03:45:08 Rui Fan wrote:
> Hi all,
> 
> Offline discussed with Zhu Zhu, Yangze Guo, Yuepeng Pan.
> We reached consensus on slot.request.max-interval and
> taskmanager.load-balance.mode. And I have updated the FLIP.
> 
> For a detailed introduction to taskmanager.load-balance.mode,
> please refer to FLIP’s 3.1 Public Interfaces[1].
> 
> And the strategy for slot.request.max-intervel has been improved.
> The latest strategy can be referred from FLIP’s 2.2.2 Waiting mechanism[2].
> For comparison of old and new strategies, please refer to
> RejectedAlternatives[3].
> 
> Thanks again to everyone who participated in the discussion.
> Looking forward to your continued feedback.
> 
> [1]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-370%3A+Support+Balanced+Tasks+Scheduling#FLIP370:SupportBalancedTasksScheduling-3.1PublicInterfaces
> [2]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-370%3A+Support+Balanced+Tasks+Scheduling#FLIP370:SupportBalancedTasksScheduling-2.2.2Waitingmechanism
> [3]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-370%3A+Support+Balanced+Tasks+Scheduling#FLIP370:SupportBalancedTasksScheduling-RejectedAlternatives
> 
> Best,
> Rui
> 
> On Thu, Oct 12, 2023 at 9:49 AM Yuepeng Pan  wrote:
> 
> > Hi, Shammon.
> > Thanks for your feedback.
> >
> > >1. This mechanism will be only supported in `SlotPool` or both `SlotPool`
> > and `DeclarativeSlotPool`?
> >
> > As described on the FLIP page, the current design plans to introduce the
> > waiting mechanism only in the `SlotPool`, because the existing
> > `WaitingForResources` can already achieve this effect.
> >
> > >Currently the two slot pools are used in different schedulers.
> >
> > Yes, that's indeed the case.
> >
> > >I think this will also bring value to `DeclarativeSlotPool`, but
> > currently FLIP content seems to be based on `SlotPool`, right?
> >
> > Yes. your expectations are indeed reasonable. In theory, the
> > `DeclarativeSlotPool` could also benefit from a waiting mechanism, as
> > discussed. The purpose of introducing the waiting mechanism is to enable
> > the `SlotPool` to have a global view to calculate the globally optimal
> > solution. I've rechecked the relevant logic in the `AdaptiveScheduler`, and
> > as I understand, the existing mechanisms already fulfill the current
> > feature requirements. You could find more conclusions on this in FLIP
> > `3.2.5`. Of course, I'd be appreciated with your confirmation. If there's
> > any misunderstanding on my part, please correct me.
> >
> > >2. ... What should be done when the slot selected by the round-robin
> > strategy cannot meet the resource requirements?
> >
> > Is this referring to the phase of task-to-slot allocation? I'm not quite
> > sure, would you mind explaining it? Thanks~.
> >
> > >3. Is the assignment of tasks to slots balanced based on region or job
> > level?
> >
> > Currently, there is no specific handling based on regions, and there is no
> > job-level balancing. The target effect of the current feature is to achieve
> > load balancing based on the number of tasks at the Task Manager (TM) level.
> > Looking forward to any suggestions regarding the item you mentioned.
> >
> > >When multiple TMs fail over, will it cause the balancing strategy to fail
> > or even worse?
> >
> > IIUC, when multiple Task Managers undergo failover, the results after
> > successful recovery will still be maintained in a relatively balanced state.
> >
> > >What is the current processing strategy?
> >
> > The Slot-to-TM strategy does not change after a Task Manager undergoes
> > failover.
> >
> > Best, Regards.
> > Yuepeng Pan
> >
> > On 2023/09/28 05:10:13 Shammon FY wrote:
> > > Thanks Yuepeng for initiating this discussion.
> > >
> > > +1 in general too, in fact we have implemented a similar mechanism
> > > internally to ensure a balanced allocation of tasks to slots, it works
> > well.
> > >
> > > Some comments about the mechanism
> > >
> > > 1. This mechanism will be only supported in `SlotPool` or both `SlotPool`
> > > and `DeclarativeSlotPool`? Currently the two slot pools are used in
> > > different schedulers. I think this will also bring value to
> > > `DeclarativeSlotPool`, but currently FLIP content seems to be based on
> 

Re:[VOTE] FLIP-375: Built-in cross-platform powerful java profiler

[Yuepeng Pan]

+1 (non-binding)

Best,Yuepeng Pan


At 2023-10-17 15:51:59, "Yu Chen"  wrote:
>Hi all,
>
>Thank you to everyone for the feedback and detailed comments on FLIP-375[1].
>Based on the discussion thread [2], I think we are ready to take a vote to
>contribute this to Flink.
>I'd like to start a vote for it.
>The vote will be open for at least 72 hours (excluding weekends, unless
>there is an objection or an insufficient number of votes).
>
>Thanks,
>Yu Chen
>
>[1]
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-375%3A+Built-in+cross-platform+powerful+java+profiler
>[2] https://lists.apache.org/thread/tp5vqgspsdko66dr6vm7cgtod9k2pct7

Re: [VOTE] FLIP-371: Provide initialization context for Committer creation in TwoPhaseCommittingSink

[Yuepeng Pan]

+1 (non-binding)Best,
Yuepeng Pan




在 2023-10-16 23:21:59，"Tzu-Li (Gordon) Tai"  写道：
>+1 (binding)
>
>On Mon, Oct 16, 2023 at 4:57 AM Martijn Visser 
>wrote:
>
>> +1 (binding)
>>
>> On Mon, Oct 16, 2023 at 1:14 PM Leonard Xu  wrote:
>> >
>> > No more comments,  give my +1(binding)
>> >
>> > Best,
>> > Leonard
>> >
>> > > 2023年10月16日 下午6:20，Péter Váry  写道：
>> > >
>> > > Any more comments?
>> > >
>> > > Leonard Xu  ezt írta (időpont: 2023. okt. 16., H,
>> 8:22):
>> > >
>> > >> Thanks Peter for driving this work.
>> > >>
>> > >>
>> > >> +1(binding)
>> > >>
>> > >> Best,
>> > >> Leonard
>> > >>
>> > >>> 2023年10月12日 下午10:58，Márton Balassi  写道：
>> > >>>
>> > >>> +1 (binding)
>> > >>>
>> > >>> Marton
>> > >>>
>> > >>> On Wed, Oct 11, 2023 at 8:20 PM Gyula Fóra 
>> wrote:
>> > >>>
>> > >>>> Thanks , Peter.
>> > >>>>
>> > >>>> +1
>> > >>>>
>> > >>>> Gyula
>> > >>>>
>> > >>>> On Wed, 11 Oct 2023 at 14:47, Péter Váry <
>> peter.vary.apa...@gmail.com>
>> > >>>> wrote:
>> > >>>>
>> > >>>>> Hi all,
>> > >>>>>
>> > >>>>> Thank you to everyone for the feedback on FLIP-371[1].
>> > >>>>> Based on the discussion thread [2], I think we are ready to take a
>> vote
>> > >>>> to
>> > >>>>> contribute this to Flink.
>> > >>>>> I'd like to start a vote for it.
>> > >>>>> The vote will be open for at least 72 hours (excluding weekends,
>> unless
>> > >>>>> there is an objection or an insufficient number of votes).
>> > >>>>>
>> > >>>>> Thanks,
>> > >>>>> Peter
>> > >>>>>
>> > >>>>>
>> > >>>>> [1]
>> > >>>>>
>> > >>>>>
>> > >>>>
>> > >>
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-371%3A+Provide+initialization+context+for+Committer+creation+in+TwoPhaseCommittingSink
>> > >>>>> [2]
>> https://lists.apache.org/thread/v3mrspdlrqrzvbwm0lcgr0j4v03dx97c
>> > >>>>>
>> > >>>>
>> > >>
>> > >>
>> >
>>

Re: [VOTE] FLIP-366: Support standard YAML for FLINK configuration

[Yuepeng Pan]

+1 (non-binding)

Best,Yuepeng Pan

At 2023-10-17 10:00:05, "Xintong Song"  wrote:
>+1 (binding)
>
>Best,
>
>Xintong
>
>
>
>On Mon, Oct 16, 2023 at 7:23 PM Chesnay Schepler  wrote:
>
>> +1 (binding)
>>
>> On 13/10/2023 04:12, Junrui Lee wrote:
>> > Hi all,
>> >
>> > Thank you to everyone for the feedback on FLIP-366[1]: Support standard
>> > YAML for FLINK configuration in the discussion thread [2].
>> > I would like to start a vote for it. The vote will be open for at least
>> 72
>> > hours (excluding weekends, unless there is an objection or an
>> insufficient
>> > number of votes).
>> >
>> > Thanks,
>> > Junrui
>> >
>> > [1]
>> >
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-366%3A+Support+standard+YAML+for+FLINK+configuration
>> > [2]https://lists.apache.org/thread/qfhcm7h8r5xkv38rtxwkghkrcxg0q7k5
>> >
>>
>>

Re:[ANNOUNCE] New Apache Flink Committer - Jane Chan

[Yuepeng Pan]

Congratulations, Jane !



Best,
Yuepeng Pan

At 2023-10-16 09:58:02, "Jark Wu"  wrote:
>Hi, everyone
>
>On behalf of the PMC, I'm very happy to announce Jane Chan as a new Flink
>Committer.
>
>Jane started code contribution in Jan 2021 and has been active in the Flink
>community since. She authored more than 60 PRs and reviewed more than 40
>PRs. Her contribution mainly revolves around Flink SQL, including Plan
>Advice (FLIP-280), operator-level state TTL (FLIP-292), and ALTER TABLE
>statements (FLINK-21634). Jane participated deeply in development
>discussions and also helped answer user question emails. Jane was also a
>core contributor of Flink Table Store (now Paimon) when the project was in
>the early days.
>
>Please join me in congratulating Jane Chan for becoming a Flink Committer!
>
>Best,
>Jark Wu (on behalf of the Flink PMC)

Re:[ANNOUNCE] New Apache Flink Committer - Ron Liu

[Yuepeng Pan]

Congratulations, Ron!

Best,
Yuepeng PanAt 2023-10-16 09:56:56, "Jark Wu"  wrote:
>Hi, everyone
>
>On behalf of the PMC, I'm very happy to announce Ron Liu as a new Flink
>Committer.
>
>Ron has been continuously contributing to the Flink project for many years,
>authored and reviewed a lot of codes. He mainly works on Flink SQL parts
>and drove several important FLIPs, e.g., USING JAR (FLIP-214), Operator
>Fusion CodeGen (FLIP-315), Runtime Filter (FLIP-324). He has a great
>knowledge of the Batch SQL and improved a lot of batch performance in the
>past several releases. He is also quite active in mailing lists,
>participating in discussions and answering user questions.
>
>Please join me in congratulating Ron Liu for becoming a Flink Committer!
>
>Best,
>Jark Wu (on behalf of the Flink PMC)

Re:[VOTE] FLIP-366: Support standard YAML for FLINK configuration

[Yuepeng Pan]

+1(non-binding)

Best,
Yuepeng Pan
At 2023-10-13 10:24:15, "Wencong Liu"  wrote:
>+1(non-binding)
>
>Best,
>Wencong Liu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>At 2023-10-13 10:12:06, "Junrui Lee"  wrote:
>>Hi all,
>>
>>Thank you to everyone for the feedback on FLIP-366[1]: Support standard
>>YAML for FLINK configuration in the discussion thread [2].
>>I would like to start a vote for it. The vote will be open for at least 72
>>hours (excluding weekends, unless there is an objection or an insufficient
>>number of votes).
>>
>>Thanks,
>>Junrui
>>
>>[1]
>>https://cwiki.apache.org/confluence/display/FLINK/FLIP-366%3A+Support+standard+YAML+for+FLINK+configuration
>>[2]https://lists.apache.org/thread/qfhcm7h8r5xkv38rtxwkghkrcxg0q7k5

Re: [DISCUSS] FLIP-370 : Support Balanced Tasks Scheduling

[Yuepeng Pan]

Hi, Shammon.
Thanks for your feedback.

>1. This mechanism will be only supported in `SlotPool` or both `SlotPool` and 
>`DeclarativeSlotPool`? 

As described on the FLIP page, the current design plans to introduce the 
waiting mechanism only in the `SlotPool`, because the existing 
`WaitingForResources` can already achieve this effect.

>Currently the two slot pools are used in different schedulers. 

Yes, that's indeed the case.

>I think this will also bring value to `DeclarativeSlotPool`, but currently 
>FLIP content seems to be based on `SlotPool`, right?

Yes. your expectations are indeed reasonable. In theory, the 
`DeclarativeSlotPool` could also benefit from a waiting mechanism, as 
discussed. The purpose of introducing the waiting mechanism is to enable the 
`SlotPool` to have a global view to calculate the globally optimal solution. 
I've rechecked the relevant logic in the `AdaptiveScheduler`, and as I 
understand, the existing mechanisms already fulfill the current feature 
requirements. You could find more conclusions on this in FLIP `3.2.5`. Of 
course, I'd be appreciated with your confirmation. If there's any 
misunderstanding on my part, please correct me.

>2. ... What should be done when the slot selected by the round-robin strategy 
>cannot meet the resource requirements?

Is this referring to the phase of task-to-slot allocation? I'm not quite sure, 
would you mind explaining it? Thanks~.

>3. Is the assignment of tasks to slots balanced based on region or job level? 

Currently, there is no specific handling based on regions, and there is no 
job-level balancing. The target effect of the current feature is to achieve 
load balancing based on the number of tasks at the Task Manager (TM) level.
Looking forward to any suggestions regarding the item you mentioned.

>When multiple TMs fail over, will it cause the balancing strategy to fail or 
>even worse? 

IIUC, when multiple Task Managers undergo failover, the results after 
successful recovery will still be maintained in a relatively balanced state.

>What is the current processing strategy?

The Slot-to-TM strategy does not change after a Task Manager undergoes failover.

Best, Regards.
Yuepeng Pan

On 2023/09/28 05:10:13 Shammon FY wrote:
> Thanks Yuepeng for initiating this discussion.
> 
> +1 in general too, in fact we have implemented a similar mechanism
> internally to ensure a balanced allocation of tasks to slots, it works well.
> 
> Some comments about the mechanism
> 
> 1. This mechanism will be only supported in `SlotPool` or both `SlotPool`
> and `DeclarativeSlotPool`? Currently the two slot pools are used in
> different schedulers. I think this will also bring value to
> `DeclarativeSlotPool`, but currently FLIP content seems to be based on
> `SlotPool`, right?
> 
> 2. In fine-grained resource management, we can set different resource
> requirements for different nodes, which means that the resources of each
> slot are different. What should be done when the slot selected by the
> round-robin strategy cannot meet the resource requirements? Will this lead
> to the failure of the balance strategy?
> 
> 3. Is the assignment of tasks to slots balanced based on region or job
> level? When multiple TMs fail over, will it cause the balancing strategy to
> fail or even worse? What is the current processing strategy?
> 
> For Zhuzhu and Rui:
> 
> IIUC, the overall balance is divided into two parts: slot to TM and task to
> slot.
> 1. Slot to TM is guaranteed by SlotManager in ResourceManager
> 2. Task to slot is guaranteed by the slot pool in JM
> 
> These two are completely independent, what are the benefits of unifying
> these two into one option? Also, do we want to share the same
> option between SlotPool in JM and SlotManager in RM? This sounds a bit
> strange.
> 
> Best,
> Shammon FY
> 
> 
> 
> On Thu, Sep 28, 2023 at 12:08 PM Rui Fan <1996fan...@gmail.com> wrote:
> 
> > Hi Zhu Zhu,
> >
> > Thanks for your feedback here!
> >
> > You are right, user needs to set 2 options:
> > - cluster.evenly-spread-out-slots=true
> > - slot.sharing-strategy=TASK_BALANCED_PREFERRED
> >
> > Update it to one option is useful at user side, so
> > `taskmanager.load-balance.mode` sounds good to me.
> > I want to check some points and behaviors about this option:
> >
> > 1. The default value is None, right?
> > 2. When it's set to Tasks, how to assign slots to TM?
> > - Option1: It's just check task number
> > - Option2: It''s check the slot number first, then check the
> > task number when the slot number is the same.
> >
> > Giving an example to explain what's the difference between them:
> >
> > - A session cluster has 2 flink jobs, they are jobA and jobB
>

Re: [DISCUSS] FLIP-370 : Support Balanced Tasks Scheduling

[Yuepeng Pan]

Hi, xiangyu.
Thanks for your quick reply.

>interface currently only includes a description of the number of tasks. So,
>IIUC, If there is a need to further expand
>current interface and its implementations, right?

Yes, that's indeed the case.

>I checked the interface design of LoadingWeight and WeightLoadable, AFAIK
>currently it only supports comparing the load for one factor. If we want to
>add more loading factors, LoadingWeight might need to add a 'LoadType'
>field for distinction, WeightLoadable might need to return
>Set.

Thank you for the clarification, I think I roughly understand your description:
In fact, regarding the specific implementation and extension of this 
LoadingWeight, we can extend it based on this interface and its implementation 
as mentioned above.
If making frequent changes to the interface and its implementation is really 
tiresome, we can also consider introducing a built-in collapsible Map or other 
type of attribute, like the SlotSharingGroup class in the 
org.apache.flink.api.common.operators package, to describe the specific 
collection of load values and types. This way, these loads are collapsed within 
the LoadingWeight's implementation and can be expanded when needed for use. Of 
course, we can also consider an implementation like the one you mentioned, 
introducing a method in WeightLoadable that returns a collection as the return 
type, so the load values are expanded at the calling site and then used. As I 
understand it, both approaches can achieve the goal.

Of course, I also look forward to hearing others' suggestions. If there are any 
mistakes in my statement, please correct me. 
Looking forward to your reply.

Best regards.
Yuepeng Pan

On 2023/10/11 08:44:51 xiangyu feng wrote:
> Hi Yuepeng,
> 
> Thx for ur reply.
> 
> > Nice feedback. In fact, as mentioned in the Google Doc, the LoadingWeight
> interface currently only includes a description of the number of tasks. So,
> IIUC, If there is a need to further expand
> > descriptions of other resource loads, we just extend it based on the
> current interface and its implementations, right?
> 
> I checked the interface design of LoadingWeight and WeightLoadable, AFAIK
> currently it only supports comparing the load for one factor. If we want to
> add more loading factors, LoadingWeight might need to add a 'LoadType'
> field for distinction, WeightLoadable might need to return
> Set.
> 
> I'm not sure I understand this correctly, WDYT?
> 
> Regards,
> Xiangyu
> 
> Yuepeng Pan  于2023年10月11日周三 13:53写道：
> 
> > Hi, xiangyu,
> > Thanks for your attention as well.
> >
> > >1, About the waiting mechanism: Will the waiting mechanism happen only in
> > >the second level 'assigning slots to TM'? IIUC, the first level 'assigning
> > >Tasks to Slots' needs only the asynchronous slot result from slotpool.
> >
> > As described in the latest FLIP, the introduction of the waiting mechanism
> > at the second level is to ensure that, in all deployment modes such as
> > application, session, etc., we do not fall into a local greedy state when
> > selecting the optimal slot position. This requires obtaining a global
> > resource view to get the best result.
> > IIUC, The allocation process from Task to Slot is the generation of a
> > mapping relationship between two abstract descriptions, and at this point,
> > there is no coupling of information between tasks/slots and Task Managers
> > (TMs).
> >
> >
> > >2, About the slot LoadingWeight: it is reasonable to use the number of
> > >tasks by default in the beginning, but it would be better if this could be
> > >easily extended in future to distinguish between CPU-intensive and
> > >IO-intensive workloads. In some cases, TMs may have IO bottlenecks but
> > >others have CPU bottlenecks.
> >
> > Nice feedback. In fact, as mentioned in the Google Doc, the LoadingWeight
> > interface currently only includes a description of the number of tasks. So,
> > IIUC, If there is a need to further expand descriptions of other resource
> > loads, we just extend it based on the current interface and its
> > implementations, right?
> > Please correct me if I have misunderstood. Thanks a lot~
> >
> > Best,
> > Yuepeng.
> >
> > On 2023/10/06 10:19:21 xiangyu feng wrote:
> > > Thanks Yuepeng and Rui for driving this Discussion.
> > >
> > > Internally when we try to use Flink 1.17.1 in production, we are also
> > > suffering from the unbalanced task distribution problem for jobs with
> > high
> > > qps and complex dag. So +1 for the overall proposal.
> > >
> > > Some questions about the details:
> &g

Re: [VOTE] FLIP-239: Port JDBC Connector to FLIP-27-143

[Yuepeng Pan]

+1(non-binding)
Thanks for your driving the voting thread.

Best Regards.
Yuepeng Pan

On 2023/10/06 16:33:40 Joao Boto wrote:
> Hi all, Thank you to everyone for the feedback on FLIP-239[1]. Based on the
> discussion thread [2] and some offline discussions, we have come to a
> consensus on the design and are ready to take a vote to contribute this to
> Flink. I'd like to start a vote for it. The vote will be open for at least
> 72 hours(excluding weekends, unless there is an objection or an
> insufficient number of votes. [1]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=217386271
> [2]https://lists.apache.org/thread/yx833h5h3fjlyor0bfm32chy3sjw8hwt  Best,
> Joao Boto
> 

Re:[VOTE] FLIP-374: Adding a separate configuration for specifying Java Options of the SQL Gateway

[Yuepeng Pan]

+1(non-binding).


Best Regards,
Yuepeng Pan.
At 2023-10-11 10:07:38, "Yangze Guo"  wrote:
>Hi everyone,
>
>I'd like to start the vote of FLIP-374 [1]. This FLIP is discussed in
>the thread [2].
>
>The vote will be open for at least 72 hours. Unless there is an
>objection, I'll try to close it by October 16, 2023 if we have
>received sufficient votes.
>
>[1] 
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-374%3A+Adding+a+separate+configuration+for+specifying+Java+Options+of+the+SQL+Gateway
>[2] https://lists.apache.org/thread/g4vl8mgnwgl7vjyvjy6zrc8w54b2lthv
>
>Best,
>Yangze Guo

Re: [DISCUSS] FLIP-370 : Support Balanced Tasks Scheduling

[Yuepeng Pan]

Hi, xiangyu,
Thanks for your attention as well.

>1, About the waiting mechanism: Will the waiting mechanism happen only in
>the second level 'assigning slots to TM'? IIUC, the first level 'assigning
>Tasks to Slots' needs only the asynchronous slot result from slotpool.

As described in the latest FLIP, the introduction of the waiting mechanism at 
the second level is to ensure that, in all deployment modes such as 
application, session, etc., we do not fall into a local greedy state when 
selecting the optimal slot position. This requires obtaining a global resource 
view to get the best result.
IIUC, The allocation process from Task to Slot is the generation of a mapping 
relationship between two abstract descriptions, and at this point, there is no 
coupling of information between tasks/slots and Task Managers (TMs). 


>2, About the slot LoadingWeight: it is reasonable to use the number of
>tasks by default in the beginning, but it would be better if this could be
>easily extended in future to distinguish between CPU-intensive and
>IO-intensive workloads. In some cases, TMs may have IO bottlenecks but
>others have CPU bottlenecks.

Nice feedback. In fact, as mentioned in the Google Doc, the LoadingWeight 
interface currently only includes a description of the number of tasks. So, 
IIUC, If there is a need to further expand descriptions of other resource 
loads, we just extend it based on the current interface and its 
implementations, right?
Please correct me if I have misunderstood. Thanks a lot~

Best,
Yuepeng.

On 2023/10/06 10:19:21 xiangyu feng wrote:
> Thanks Yuepeng and Rui for driving this Discussion.
> 
> Internally when we try to use Flink 1.17.1 in production, we are also
> suffering from the unbalanced task distribution problem for jobs with high
> qps and complex dag. So +1 for the overall proposal.
> 
> Some questions about the details:
> 
> 1, About the waiting mechanism: Will the waiting mechanism happen only in
> the second level 'assigning slots to TM'?  IIUC, the first level 'assigning
> Tasks to Slots' needs only the asynchronous slot result from slotpool.
> 
> 2, About the slot LoadingWeight: it is reasonable to use the number of
> tasks by default in the beginning, but it would be better if this could be
> easily extended in future to distinguish between CPU-intensive and
> IO-intensive workloads. In some cases, TMs may have IO bottlenecks but
> others have CPU bottlenecks.
> 
> Regards,
> Xiangyu
> 
> 
> Yuepeng Pan  于2023年10月5日周四 18:34写道：
> 
> > Hi, Zhu Zhu,
> >
> > Thanks for your feedback!
> >
> > > I think we can introduce a new config option
> > > `taskmanager.load-balance.mode`,
> > > which accepts "None"/"Slots"/"Tasks". `cluster.evenly-spread-out-slots`
> > > can be superseded by the "Slots" mode and get deprecated. In the future
> > > it can support more mode, e.g. "CpuCores", to work better for jobs with
> > > fine-grained resources. The proposed config option
> > > `slot.request.max-interval`
> > > then can be renamed to
> > `taskmanager.load-balance.request-stablizing-timeout`
> > > to show its relation with the feature. The proposed
> > `slot.sharing-strategy`
> > > is not needed, because the configured "Tasks" mode will do the work.
> >
> > The new proposed configuration option sounds good to me.
> >
> > I have a small question, If we set our configuration value to 'Tasks,' it
> > will initiate two processes: balancing the allocation of task quantities at
> > the slot level and balancing the number of tasks across TaskManagers (TMs).
> > Alternatively, if we configure it as 'Slots,' the system will employ the
> > LocalPreferred allocation policy (which is the default) when assigning
> > tasks to slots, and it will ensure that the number of slots used across TMs
> > is balanced.
> > Does  this configuration essentially combine a balanced selection strategy
> > across two dimensions into fixed configuration items, right?
> >
> > I would appreciate it if you could correct me if I've made any errors.
> >
> > Best,
> > Yuepeng.
> >
> 

Re: [DISCUSS] FLIP-370 : Support Balanced Tasks Scheduling

[Yuepeng Pan]

wo into one option? Also, do we want to share the same
> > > >> option between SlotPool in JM and SlotManager in RM? This sounds a bit
> > > >> strange.
> > > >>
> > > >> Best,
> > > >> Shammon FY
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Sep 28, 2023 at 12:08 PM Rui Fan <1996fan...@gmail.com>
> > wrote:
> > > >>
> > > >> > Hi Zhu Zhu,
> > > >> >
> > > >> > Thanks for your feedback here!
> > > >> >
> > > >> > You are right, user needs to set 2 options:
> > > >> > - cluster.evenly-spread-out-slots=true
> > > >> > - slot.sharing-strategy=TASK_BALANCED_PREFERRED
> > > >> >
> > > >> > Update it to one option is useful at user side, so
> > > >> > `taskmanager.load-balance.mode` sounds good to me.
> > > >> > I want to check some points and behaviors about this option:
> > > >> >
> > > >> > 1. The default value is None, right?
> > > >> > 2. When it's set to Tasks, how to assign slots to TM?
> > > >> > - Option1: It's just check task number
> > > >> > - Option2: It''s check the slot number first, then check the
> > > >> > task number when the slot number is the same.
> > > >> >
> > > >> > Giving an example to explain what's the difference between them:
> > > >> >
> > > >> > - A session cluster has 2 flink jobs, they are jobA and jobB
> > > >> > - Each TM has 4 slots.
> > > >> > - The task number of one slot of jobA is 3
> > > >> > - The task number of one slot of jobB is 1
> > > >> > - We have 2 TaskManagers:
> > > >> >   - tm1 runs 3 slots of jobB, so tm1 runs 3 tasks
> > > >> >   - tm2 runs 1 slot of jobA, and 1 slot of jobB, so tm2 runs 4
> > tasks.
> > > >> >
> > > >> > Now, we need to run a new slot, which tm should offer it?
> > > >> > - Option1: If we just check the task number, the tm1 is better.
> > > >> > - Option2: If we check the slot number first, and then check task,
> > the
> > > >> tm2
> > > >> > is better
> > > >> >
> > > >> > The original FLIP selected option2, that's why we didn't add the
> > > >> > third option. The option2 didn't break the semantics when
> > > >> > `cluster.evenly-spread-out-slots` is true, and it just improve the
> > > >> > behavior without the semantics is changed.
> > > >> >
> > > >> > In the other hands, if we choose option2, when user set
> > > >> > `taskmanager.load-balance.mode` is Tasks. It also can achieve
> > > >> > the goal when it's Slots.
> > > >> >
> > > >> > So I think the `Slots` enum isn't needed if we choose option2.
> > > >> > Of course, If we choose the option1, the enum is needed.
> > > >> >
> > > >> > Looking forward to your feedback, thanks~
> > > >> >
> > > >> > Best,
> > > >> > Rui
> > > >> >
> > > >> > On Wed, Sep 27, 2023 at 9:11 PM Zhu Zhu  wrote:
> > > >> >
> > > >> > > Thanks Yuepeng and Rui for creating this FLIP.
> > > >> > >
> > > >> > > +1 in general
> > > >> > > The idea is straight forward: best-effort gather all the slot
> > requests
> > > >> > > and offered slots to form an overview before assigning slots,
> > trying
> > > >> to
> > > >> > > balance the loads of task managers when assigning slots.
> > > >> > >
> > > >> > > I have one comment regarding the configuration for ease of use:
> > > >> > >
> > > >> > > IIUC, this FLIP uses an existing config
> > > >> 'cluster.evenly-spread-out-slots'
> > > >> > > as the main switch of the new feature. That is, from user
> > perspective,
> > > >> > > with this improvement, the 'cluster.evenly-spread-out-slots'
> > feature
> > > >> not
> > > >> > > only balances the number of slots on task managers, but also
> > balances
> > > >> the
> > > >> > > number of tasks. This is a behavior change anyway. Besides that,
> > it
> > > >> also
> > > >> > > requires users to set 'slot.sharing-strategy' to
> > > >> > 'TASK_BALANCED_PREFERRED'
> > > >> > > to balance the tasks in each slot.
> > > >> > >
> > > >> > > I think we can introduce a new config option
> > > >> > > `taskmanager.load-balance.mode`,
> > > >> > > which accepts "None"/"Slots"/"Tasks".
> > > >> `cluster.evenly-spread-out-slots`
> > > >> > > can be superseded by the "Slots" mode and get deprecated. In the
> > > >> future
> > > >> > > it can support more mode, e.g. "CpuCores", to work better for jobs
> > > >> with
> > > >> > > fine-grained resources. The proposed config option
> > > >> > > `slot.request.max-interval`
> > > >> > > then can be renamed to
> > > >> > > `taskmanager.load-balance.request-stablizing-timeout`
> > > >> > > to show its relation with the feature. The proposed
> > > >> > `slot.sharing-strategy`
> > > >> > > is not needed, because the configured "Tasks" mode will do the
> > work.
> > > >> > >
> > > >> > > WDYT?
> > > >> > >
> > > >> > > Thanks,
> > > >> > > Zhu Zhu
> > > >> > >
> > > >> > > Yuepeng Pan  于2023年9月25日周一 16:26写道：
> > > >> > >
> > > >> > >> Hi all,
> > > >> > >>
> > > >> > >>
> > > >> > >> I and Fan Rui(CC’ed) created the FLIP-370[1] to support balanced
> > > >> tasks
> > > >> > >> scheduling.
> > > >> > >>
> > > >> > >>
> > > >> > >> The current strategy of Flink to deploy tasks sometimes leads
> > some
> > > >> > >> TMs(TaskManagers) to have more tasks while others have fewer
> > tasks,
> > > >> > >> resulting in excessive resource utilization at some TMs that
> > contain
> > > >> > more
> > > >> > >> tasks and becoming a bottleneck for the entire job processing.
> > > >> > Developing
> > > >> > >> strategies to achieve task load balancing for TMs and reducing
> > job
> > > >> > >> bottlenecks becomes very meaningful.
> > > >> > >>
> > > >> > >>
> > > >> > >> The raw design and discussions could be found in the Flink
> > JIRA[2]
> > > >> and
> > > >> > >> Google doc[3]. We really appreciate Zhu Zhu(CC’ed) for providing
> > some
> > > >> > >> valuable help and suggestions in advance.
> > > >> > >>
> > > >> > >>
> > > >> > >> Please refer to the FLIP[1] document for more details about the
> > > >> proposed
> > > >> > >> design and implementation. We welcome any feedback and opinions
> > on
> > > >> this
> > > >> > >> proposal.
> > > >> > >>
> > > >> > >>
> > > >> > >> [1]
> > > >> > >>
> > > >> >
> > > >>
> > https://cwiki.apache.org/confluence/display/FLINK/FLIP-370%3A+Support+Balanced+Tasks+Scheduling
> > > >> > >>
> > > >> > >> [2] https://issues.apache.org/jira/browse/FLINK-31757
> > > >> > >>
> > > >> > >> [3]
> > > >> > >>
> > > >> >
> > > >>
> > https://docs.google.com/document/d/14WhrSNGBdcsRl3IK7CZO-RaZ5KXU2X1dWqxPEFr3iS8
> > > >> > >>
> > > >> > >>
> > > >> > >> Best,
> > > >> > >>
> > > >> > >> Yuepeng Pan
> > > >> > >>
> > > >> > >
> > > >> >
> > > >>
> > > >
> >
> 

Re: [DISCUSS] FLIP-370 : Support Balanced Tasks Scheduling

[Yuepeng Pan]

Hi, Zhu Zhu,

Thanks for your feedback!

> I think we can introduce a new config option
> `taskmanager.load-balance.mode`,
> which accepts "None"/"Slots"/"Tasks". `cluster.evenly-spread-out-slots`
> can be superseded by the "Slots" mode and get deprecated. In the future
> it can support more mode, e.g. "CpuCores", to work better for jobs with
> fine-grained resources. The proposed config option
> `slot.request.max-interval`
> then can be renamed to `taskmanager.load-balance.request-stablizing-timeout`
> to show its relation with the feature. The proposed `slot.sharing-strategy`
> is not needed, because the configured "Tasks" mode will do the work.

The new proposed configuration option sounds good to me. 

I have a small question, If we set our configuration value to 'Tasks,' it will 
initiate two processes: balancing the allocation of task quantities at the slot 
level and balancing the number of tasks across TaskManagers (TMs).
Alternatively, if we configure it as 'Slots,' the system will employ the 
LocalPreferred allocation policy (which is the default) when assigning tasks to 
slots, and it will ensure that the number of slots used across TMs is balanced.
Does  this configuration essentially combine a balanced selection strategy 
across two dimensions into fixed configuration items, right?

I would appreciate it if you could correct me if I've made any errors.

Best,
Yuepeng.

Re: [VOTE] FLIP-314: Support Customized Job Lineage Listener

[Yuepeng Pan]

+1(non-binding)

Best,
Yuepeng Pan

在 2023-09-28 17:44:46，"Rui Fan" <1996fan...@gmail.com> 写道：
>+1(binding)
>
>Best,
>Rui
>
>On Thu, 28 Sep 2023 at 14:41, Chen Zhanghao 
>wrote:
>
>> +1 (non-binding), thanks for driving this.
>>
>> Best,
>> Zhanghao Chen
>> 
>> 发件人: Shammon FY 
>> 发送时间: 2023年9月25日 13:28
>> 收件人: dev 
>> 主题: [VOTE] FLIP-314: Support Customized Job Lineage Listener
>>
>> Hi devs,
>>
>> Thanks for all the feedback on FLIP-314: Support Customized Job Lineage
>> Listener [1] in thread [2].
>>
>> I would like to start a vote for it. The vote will be opened for at least
>> 72 hours unless there is an objection or insufficient votes.
>>
>> [1]
>>
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-314%3A+Support+Customized+Job+Lineage+Listener
>> [2] https://lists.apache.org/thread/wopprvp3ww243mtw23nj59p57cghh7mc
>>
>> Best,
>> Shammon FY
>>

[DISCUSS] FLIP-370 : Support Balanced Tasks Scheduling

[Yuepeng Pan]

Hi all,




I and Fan Rui(CC’ed) created the FLIP-370[1] to support balanced tasks 
scheduling.




The current strategy of Flink to deploy tasks sometimes leads some 
TMs(TaskManagers) to have more tasks while others have fewer tasks, resulting 
in excessive resource utilization at some TMs that contain more tasks and 
becoming a bottleneck for the entire job processing. Developing strategies to 
achieve task load balancing for TMs and reducing job bottlenecks becomes very 
meaningful.




The raw design and discussions could be found in the Flink JIRA[2] and Google 
doc[3]. We really appreciate Zhu Zhu(CC’ed) for providing some valuable help 
and suggestions in advance. 




Please refer to the FLIP[1] document for more details about the proposed design 
and implementation. We welcome any feedback and opinions on this proposal.




[1] 
https://cwiki.apache.org/confluence/display/FLINK/FLIP-370%3A+Support+Balanced+Tasks+Scheduling

[2] https://issues.apache.org/jira/browse/FLINK-31757

[3] 
https://docs.google.com/document/d/14WhrSNGBdcsRl3IK7CZO-RaZ5KXU2X1dWqxPEFr3iS8




Best,

Yuepeng Pan

Re:[VOTE] FLIP-327: Support switching from batch to stream mode to improve throughput when processing backlog data

[Yuepeng Pan]

+1(non-binding), thank you for driving this proposal.

Best,
Yuepeng Pan.
At 2023-09-22 14:07:45, "Dong Lin"  wrote:
>Hi all,
>
>We would like to start the vote for FLIP-327: Support switching from batch
>to stream mode to improve throughput when processing backlog data [1]. This
>FLIP was discussed in this thread [2].
>
>The vote will be open until at least Sep 27th (at least 72
>hours), following the consensus voting process.
>
>Cheers,
>Xuannan and Dong
>
>[1]
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-327%3A+Support+switching+from+batch+to+stream+mode+to+improve+throughput+when+processing+backlog+data
>[2] https://lists.apache.org/thread/29nvjt9sgnzvs90browb8r6ng31dcs3n

Re: [VOTE] FLIP-361: Improve GC Metrics

[Yuepeng Pan]

+1 (non-binding).


Best,
Yuepeng.





在 2023-09-16 12:52:09，"Weihua Hu"  写道：
>+1 (binding)
>
>Best,
>Weihua
>
>
>On Fri, Sep 15, 2023 at 4:28 PM Yangze Guo  wrote:
>
>> +1 (binding)
>>
>> Best,
>> Yangze Guo
>>
>> On Thu, Sep 14, 2023 at 5:47 PM Maximilian Michels  wrote:
>> >
>> > +1 (binding)
>> >
>> > On Thu, Sep 14, 2023 at 4:26 AM Venkatakrishnan Sowrirajan
>> >  wrote:
>> > >
>> > > +1 (non-binding)
>> > >
>> > > On Wed, Sep 13, 2023, 6:55 PM Matt Wang  wrote:
>> > >
>> > > > +1 (non-binding)
>> > > >
>> > > >
>> > > > Thanks for driving this FLIP
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > >
>> > > > Best,
>> > > > Matt Wang
>> > > >
>> > > >
>> > > >  Replied Message 
>> > > > | From | Xintong Song |
>> > > > | Date | 09/14/2023 09:54 |
>> > > > | To |  |
>> > > > | Subject | Re: [VOTE] FLIP-361: Improve GC Metrics |
>> > > > +1 (binding)
>> > > >
>> > > > Best,
>> > > >
>> > > > Xintong
>> > > >
>> > > >
>> > > >
>> > > > On Thu, Sep 14, 2023 at 2:40 AM Samrat Deb 
>> wrote:
>> > > >
>> > > > +1 ( non binding)
>> > > >
>> > > > These improved GC metrics will be a great addition.
>> > > >
>> > > > Bests,
>> > > > Samrat
>> > > >
>> > > > On Wed, 13 Sep 2023 at 7:58 PM, ConradJam 
>> wrote:
>> > > >
>> > > > +1 (non-binding)
>> > > > gc metrics help with autoscale tuning features
>> > > >
>> > > > Chen Zhanghao  于2023年9月13日周三 22:16写道：
>> > > >
>> > > > +1 (unbinding). Looking forward to it
>> > > >
>> > > > Best,
>> > > > Zhanghao Chen
>> > > > 
>> > > > 发件人: Gyula Fóra 
>> > > > 发送时间: 2023年9月13日 21:16
>> > > > 收件人: dev 
>> > > > 主题: [VOTE] FLIP-361: Improve GC Metrics
>> > > >
>> > > > Hi All!
>> > > >
>> > > > Thanks for all the feedback on FLIP-361: Improve GC Metrics [1][2]
>> > > >
>> > > > I'd like to start a vote for it. The vote will be open for at least
>> 72
>> > > > hours unless there is an objection or insufficient votes.
>> > > >
>> > > > Cheers,
>> > > > Gyula
>> > > >
>> > > > [1]
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/FLINK/FLIP-361*3A*Improve*GC*Metrics__;JSsrKw!!IKRxdwAv5BmarQ!dpHSOqsSHlPJ5gCvZ2yxSGjcR4xA2N-mpGZ1w2jPuKb78aujNpbzENmi1e7B26d6v4UQ8bQZ7IQaUcI$
>> > > > [2]
>> > > >
>> https://urldefense.com/v3/__https://lists.apache.org/thread/qqqv54vyr4gbp63wm2d12q78m8h95xb2__;!!IKRxdwAv5BmarQ!dpHSOqsSHlPJ5gCvZ2yxSGjcR4xA2N-mpGZ1w2jPuKb78aujNpbzENmi1e7B26d6v4UQ8bQZFdEMnAg$
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Best
>> > > >
>> > > > ConradJam
>> > > >
>> > > >
>> > > >
>>

Re: [VOTE] FLIP-356: Support Nested Fields Filter Pushdown

[Yuepeng Pan]

+1 (non-binding)

Best,
Yuepeng



At 2023-09-01 14:32:19, "Jark Wu"  wrote:
>+1 (binding)
>
>Best,
>Jark
>
>> 2023年8月30日 02:40，Venkatakrishnan Sowrirajan  写道：
>> 
>> Hi everyone,
>> 
>> Thank you all for your feedback on FLIP-356. I'd like to start a vote.
>> 
>> Discussion thread:
>> https://lists.apache.org/thread/686bhgwrrb4xmbfzlk60szwxos4z64t7
>> FLIP:
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-356%3A+Support+Nested+Fields+Filter+Pushdown
>> 
>> Regards
>> Venkata krishnan

Re: [ANNOUNCE] New Apache Flink Committer - Weihua Hu

[Yuepeng Pan]

Congratulations, Weihua!

Best,
Yuepeng Pan





在 2023-08-07 09:17:41，"yh z"  写道：
>Congratulations, Weihua!
>
>Best,
>Yunhong Zheng (Swuferhong)
>
>Runkang He  于2023年8月5日周六 21:34写道：
>
>> Congratulations, Weihua!
>>
>> Best,
>> Runkang He
>>
>> Kelu Tao  于2023年8月4日周五 18:21写道：
>>
>> > Congratulations!
>> >
>> > On 2023/08/04 08:35:49 Danny Cranmer wrote:
>> > > Congrats and welcome to the team, Weihua!
>> > >
>> > > Thanks,
>> > > Danny
>> > >
>> > > On Fri, Aug 4, 2023 at 9:30 AM Feng Jin  wrote:
>> > >
>> > > > Congratulations Weihua!
>> > > >
>> > > > Best regards,
>> > > >
>> > > > Feng
>> > > >
>> > > > On Fri, Aug 4, 2023 at 4:28 PM weijie guo > >
>> > > > wrote:
>> > > >
>> > > > > Congratulations Weihua!
>> > > > >
>> > > > > Best regards,
>> > > > >
>> > > > > Weijie
>> > > > >
>> > > > >
>> > > > > Lijie Wang  于2023年8月4日周五 15:28写道：
>> > > > >
>> > > > > > Congratulations, Weihua!
>> > > > > >
>> > > > > > Best,
>> > > > > > Lijie
>> > > > > >
>> > > > > > yuxia  于2023年8月4日周五 15:14写道：
>> > > > > >
>> > > > > > > Congratulations, Weihua!
>> > > > > > >
>> > > > > > > Best regards,
>> > > > > > > Yuxia
>> > > > > > >
>> > > > > > > - 原始邮件 -
>> > > > > > > 发件人: "Yun Tang" 
>> > > > > > > 收件人: "dev" 
>> > > > > > > 发送时间: 星期五, 2023年 8 月 04日 下午 3:05:30
>> > > > > > > 主题: Re: [ANNOUNCE] New Apache Flink Committer - Weihua Hu
>> > > > > > >
>> > > > > > > Congratulations, Weihua!
>> > > > > > >
>> > > > > > >
>> > > > > > > Best
>> > > > > > > Yun Tang
>> > > > > > > 
>> > > > > > > From: Jark Wu 
>> > > > > > > Sent: Friday, August 4, 2023 15:00
>> > > > > > > To: dev@flink.apache.org 
>> > > > > > > Subject: Re: [ANNOUNCE] New Apache Flink Committer - Weihua Hu
>> > > > > > >
>> > > > > > > Congratulations, Weihua!
>> > > > > > >
>> > > > > > > Best,
>> > > > > > > Jark
>> > > > > > >
>> > > > > > > On Fri, 4 Aug 2023 at 14:48, Yuxin Tan > >
>> > > > wrote:
>> > > > > > >
>> > > > > > > > Congratulations Weihua!
>> > > > > > > >
>> > > > > > > > Best,
>> > > > > > > > Yuxin
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > Junrui Lee  于2023年8月4日周五 14:28写道：
>> > > > > > > >
>> > > > > > > > > Congrats, Weihua!
>> > > > > > > > > Best,
>> > > > > > > > > Junrui
>> > > > > > > > >
>> > > > > > > > > Geng Biao  于2023年8月4日周五 14:25写道：
>> > > > > > > > >
>> > > > > > > > > > Congrats, Weihua!
>> > > > > > > > > > Best,
>> > > > > > > > > > Biao Geng
>> > > > > > > > > >
>> > > > > > > > > > 发送自 Outlook for iOS<https://aka.ms/o0ukef>
>> > > > > > > > > > 
>> > > > > > > > > > 发件人: 周仁祥 
>> > > > > > > > > > 发送时间: Friday, August 4, 2023 2:23:42 PM
>> > > > > > > > > > 收件人: dev@flink.apache.org 
>> > > > > > > > > > 抄送: Weihua Hu 
>> > > > > > > > > > 主题: Re: [ANNOUNCE] New Apache Flink Committer - Weihua Hu
>> >

Re:[VOTE][2.0] FLIP-343: Remove parameter in WindowAssigner#getDefaultTrigger()

[Yuepeng Pan]

+1 (non-binding)

Thanks.

Yuepeng Pan.
At 2023-07-26 14:26:04, "Wencong Liu"  wrote:
>Hi dev, 
>
>
>I'd like to start a vote on FLIP-343.
>
>
>Discussion thread: 
>https://lists.apache.org/thread/zn11f460x70nn7f2ckqph41bvx416wxc
>FLIP: 
>https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263425229
>
>
>Best regards, 
>Wencong Liu

Re: [ANNOUNCE] New Apache Flink Committer - Yong Fang

[Yuepeng Pan]

Congrats, Yong Fang!

Best,
Yuepeng Pan



在 2023-07-24 16:51:08，"Dan Zou"  写道：
>Congrats, Yong Fang!
>
>Best,
>Dan Zou   
>
>
>
>
>
>> 2023年7月24日 15:41，Matt Wang  写道：
>> 
>> Yong Fang
>

Re: [VOTE] FLIP-309: Support using larger checkpointing interval when source is processing backlog

[Yuepeng Pan]

+1  non-binding.


Best.
Yuepeng Pan


 Replied Message 
| From | Jingsong Li |
| Date | 06/29/2023 13:25 |
| To | dev |
| Cc | flink.zhouyunfeng |
| Subject | Re: [VOTE] FLIP-309: Support using larger checkpointing interval 
when source is processing backlog |
+1 binding

On Thu, Jun 29, 2023 at 11:03 AM Dong Lin  wrote:
>
> Hi all,
>
> We would like to start the vote for FLIP-309: Support using larger
> checkpointing interval when source is processing backlog [1]. This FLIP was
> discussed in this thread [2].
>
> Flink 1.18 release will feature freeze on July 11. We hope to make this
> feature available in Flink 1.18.
>
> The vote will be open until at least July 4th (at least 72 hours), following
> the consensus voting process.
>
> Cheers,
> Yunfeng and Dong
>
> [1]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-309%3A+Support+using+larger+checkpointing+interval+when+source+is+processing+backlog
> [2] https://lists.apache.org/thread/l1l7f30h7zldjp6ow97y70dcthx7tl37

Re: [VOTE] Release flink-connector-jdbc v3.1.1, release candidate #2

[Yuepeng Pan]

+1 (non-binding)

- verified signatures

- compiled from sources
- ran tests locally
- checked release notes
Best,
Yuepeng Pan

At 2023-06-27 07:42:00, "Sergey Nuyanzin"  wrote:
>+1 (non-binding)
>
>- verified hashes
>- verified signatures
>- built from sources
>- checked release notes
>- review web pr
>
>Non-blocking finding:
>  it seems the release date in web PR should be changed
>
>On Mon, Jun 26, 2023 at 1:34 PM Leonard Xu  wrote:
>
>> +1 (binding)
>>
>> - built from source code succeeded
>> - verified signatures
>> - verified hashsums
>> - checked release notes
>> - checked the contents contains jar and pom files in apache repo
>> - reviewed the web PR
>>
>> Best,
>> Leonard
>>
>> > On Jun 19, 2023, at 6:57 PM, Danny Cranmer 
>> wrote:
>> >
>> > Thanks for driving this Martijn.
>> >
>> > +1 (binding)
>> >
>> > - Reviewed web PR
>> > - Jira release notes look good
>> > - Tag exists in Github
>> > - Source archive signature/checksum looks good
>> > - Binary (from Maven) signature/checksum looks good
>> > - No binaries in the source archive
>> > - Source archive builds from source and tests pass
>> > - CI passes [1]
>> >
>> > Non blocking findings:
>> > - NOTICE files year is 2022 and needs to be updated to 2023
>> > - pom.xml is referencing Flink 1.17.0 and can be updated to 1.17.1
>> > - Some unit tests (notably OracleExactlyOnceSinkE2eTest) appear to be
>> > integration/e2e and are run in the unit test suite
>> >
>> > Thanks,
>> > Danny
>> >
>> > [1]
>> https://github.com/apache/flink-connector-jdbc/actions/runs/5278297177
>> >
>> > On Thu, Jun 15, 2023 at 12:40 PM Martijn Visser <
>> martijnvis...@apache.org>
>> > wrote:
>> >
>> >> Hi everyone,
>> >> Please review and vote on the release candidate #2 for the version
>> 3.1.1,
>> >> as follows:
>> >> [ ] +1, Approve the release
>> >> [ ] -1, Do not approve the release (please provide specific comments)
>> >>
>> >>
>> >> The complete staging area is available for your review, which includes:
>> >> * JIRA release notes [1],
>> >> * the official Apache source release to be deployed to dist.apache.org
>> >> [2],
>> >> which are signed with the key with fingerprint
>> >> A5F3BCE4CBE993573EC5966A65321B8382B219AF [3],
>> >> * all artifacts to be deployed to the Maven Central Repository [4],
>> >> * source code tag v3.1.1-rc2 [5],
>> >> * website pull request listing the new release [6].
>> >>
>> >> The vote will be open for at least 72 hours. It is adopted by majority
>> >> approval, with at least 3 PMC affirmative votes.
>> >>
>> >> Thanks,
>> >> Release Manager
>> >>
>> >> [1]
>> >>
>> >>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522=12353281
>> >> [2]
>> >>
>> https://dist.apache.org/repos/dist/dev/flink/flink-connector-jdbc-3.1.1-rc2
>> >> [3] https://dist.apache.org/repos/dist/release/flink/KEYS
>> >> [4]
>> https://repository.apache.org/content/repositories/orgapacheflink-1642
>> >> [5] https://github.com/apache/flink-connector-
>> >> /releases/tag/v3.1.1-rc2
>> >> [6] https://github.com/apache/flink-web/pull/654
>> >>
>>
>>
>
>-- 
>Best regards,
>Sergey

Re:[VOTE] FLIP-324: Introduce Runtime Filter for Flink Batch Jobs

[Yuepeng Pan]

+1 (non-binding)

Thanks,
Yuepeng Pan















At 2023-06-23 23:49:53, "Lijie Wang"  wrote:
>Hi all,
>
>Thanks for all the feedback about the FLIP-324: Introduce Runtime Filter
>for Flink Batch Jobs[1]. This FLIP was discussed in [2].
>
>I'd like to start a vote for it. The vote will be open for at least 72
>hours (until June 29th 12:00 GMT) unless there is an objection or
>insufficient votes.
>
>[1]
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-324%3A+Introduce+Runtime+Filter+for+Flink+Batch+Jobs
>[2] https://lists.apache.org/thread/mm0o8fv7x7k13z11htt88zhy7lo8npmg
>
>Best,
>Lijie

Re:Re: [VOTE] FLIP-287: Extend Sink#InitContext to expose TypeSerializer, ObjectReuse and JobID

[Yuepeng Pan]

+1 (non-binding)

Thanks,
Roc






在 2023-06-19 10:55:05，"Zhu Zhu"  写道：
>+1 (binding)
>
>Thanks,
>Zhu
>
>Tzu-Li (Gordon) Tai  于2023年6月17日周六 11:32写道：
>>
>> +1 (binding)
>>
>> On Fri, Jun 16, 2023, 09:53 Jing Ge  wrote:
>>
>> > +1(binding)
>> >
>> > Best Regards,
>> > Jing
>> >
>> > On Fri, Jun 16, 2023 at 10:10 AM Lijie Wang 
>> > wrote:
>> >
>> > > +1 (binding)
>> > >
>> > > Thanks for driving it, Joao.
>> > >
>> > > Best,
>> > > Lijie
>> > >
>> > > Joao Boto  于2023年6月16日周五 15:53写道：
>> > >
>> > > > Hi all,
>> > > >
>> > > > Thank you to everyone for the feedback on FLIP-287[1]. Based on the
>> > > > discussion thread [2], we have come to a consensus on the design and
>> > are
>> > > > ready to take a vote to contribute this to Flink.
>> > > >
>> > > > I'd like to start a vote for it. The vote will be open for at least 72
>> > > > hours(excluding weekends, unless there is an objection or an
>> > insufficient
>> > > > number of votes.
>> > > >
>> > > > [1]
>> > > >
>> > >
>> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=240880853
>> > > > [2]https://lists.apache.org/thread/wb3myhqsdz81h08ygwx057mkn1hc3s8f
>> > > >
>> > > >
>> > > > Best,
>> > > > Joao Boto
>> > > >
>> > >
>> >

Re:[ANNOUNCE] New Apache Flink Committer - Jing Ge

[Yuepeng Pan]

Congratulations, Jing Ge !

Best,Yuepeng Pan






At 2023-02-14 15:49:24, "godfrey he"  wrote:
>Hi everyone,
>
>On behalf of the PMC, I'm very happy to announce Jing Ge as a new Flink
>committer.
>
>Jing has been consistently contributing to the project for over 1 year.
>He authored more than 50 PRs and reviewed more than 40 PRs
>with mainly focus on connector, test, and document modules.
>He was very active on the mailing list (more than 90 threads) last year,
>which includes participating in a lot of dev discussions (30+),
>providing many effective suggestions for FLIPs and answering
>many user questions. He was the Flink Forward 2022 keynote speaker
>to help promote Flink and  a trainer for Flink troubleshooting and performance
>tuning of Flink Forward 2022 training program.
>
>Please join me in congratulating Jing for becoming a Flink committer!
>
>Best,
>Godfrey

Re:Re: [ANNOUNCE] New Apache Flink Committer - Weijie Guo

[Yuepeng Pan]

Congratulations, Weijie!

Best,

Best, Yuepeng Pan.

在 2023-02-13 16:26:32，"Lincoln Lee"  写道：
>Congratulations, Weijie!
>
>Best,
>Lincoln Lee
>
>
>Martijn Visser  于2023年2月13日周一 16:17写道：
>
>> Congrats Weijie!
>>
>> On Mon, Feb 13, 2023 at 7:19 AM Weihua Hu  wrote:
>>
>> > Congratulations, Weijie!
>> >
>> > Best,
>> > Weihua
>> >
>> > > On Feb 13, 2023, at 11:55, Lijie Wang 
>> wrote:
>> > >
>> > > Congratulations, Weijie!
>> >
>> >
>>

Re:Re: [ANNOUNCE] New Apache Flink Committers: Feng Wang, Zhipeng Zhang

[Yuepeng Pan]

Congratulations!


Best,
Yuepeng Pan














在 2022-02-18 12:41:18，"Jingsong Li"  写道：
>Congratulations!
>
>Best,
>Jingsong
>
>On Fri, Feb 18, 2022 at 9:47 AM Zhipeng Zhang  wrote:
>>
>> Thank you everyone for the warm welcome!
>>
>> Best,
>> Zhipeng
>>
>> Jinzhong Li  于2022年2月17日周四 19:58写道：
>>
>> > Congratulations!
>> >
>> >
>> > Best,
>> >
>> > Jinzhong
>> >
>> > Robert Metzger  于2022年2月16日周三 21:32写道：
>> >
>> > > Hi everyone,
>> > >
>> > > On behalf of the PMC, I'm very happy to announce two new Flink
>> > > committers: Feng Wang and Zhipeng Zhang!
>> > >
>> > > Feng is one of the most active Flink evangelists in China, with plenty of
>> > > public talks, blog posts and other evangelization activities. The PMC
>> > wants
>> > > to recognize and value these efforts by making Feng a committer!
>> > >
>> > > Zhipeng Zhang has made significant contributions to flink-ml, like most
>> > of
>> > > the FLIPs for our ML efforts.
>> > >
>> > > Please join me in welcoming them as committers!
>> > >
>> > >
>> > > Best,
>> > > Robert
>> > >
>> >
>>
>>
>> --
>> best,
>> Zhipeng

Re:Re: [VOTE] FLIP-205: Support cache in DataStream for Batch Processing

[Yuepeng Pan]

+1 (non-binding)


Thanks for driving this. Looking forward to this feature.




Best, 
Roc.

At 2022-01-21 17:22:36, "Dian Fu"  wrote:
>+1 (binding)
>
>Thanks for driving this. Looking forward to this feature.
>
>Regards,
>Dian
>
>On Thu, Jan 20, 2022 at 5:57 PM Gen Luo  wrote:
>
>> +1 (non-binding)
>>
>> On Thu, Jan 20, 2022 at 3:26 PM Yun Gao 
>> wrote:
>>
>> > +1 (binding)
>> >
>> > Thanks Xuannan for driving this!
>> >
>> > Best,
>> > Yun
>> >
>> >
>> > --
>> > From:David Morávek 
>> > Send Time:2022 Jan. 20 (Thu.) 15:12
>> > To:dev 
>> > Subject:Re: [VOTE] FLIP-205: Support cache in DataStream for Batch
>> > Processing
>> >
>> > +1 (non-binding)
>> >
>> > D.
>> >
>> > On Thu 20. 1. 2022 at 4:09, Xuannan Su  wrote:
>> >
>> > > Hi devs,
>> > >
>> > > I would like to start the vote for FLIP-205 [1], which was discussed
>> and
>> > > reached a consensus in the discussion thread [2].
>> > >
>> > > The vote will be open for at least 72h, unless there is an objection or
>> > not
>> > > enough votes.
>> > >
>> > > Best,
>> > > Xuannan
>> > >
>> > > [1]
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-205%3A+Support+Cache+in+DataStream+for+Batch+Processing
>> > > [2] https://lists.apache.org/thread/sqxyb5bh99f904g8zpj8tv60m75dmyox
>> > >
>> >
>>

Re:Re: About FLIP Page Edit Permission & confluence permission apply

[Yuepeng Pan]

Hi,
  Rohrmann, Xintong. I'm granted the wiki permission now. Thank you very 
much.
Best,
Yuepeng Pan.


At 2021-12-11 16:25:16, "Xintong Song"  wrote:
>Hi Yuepeng,
>
>I've granted you the wiki permission. Please try it out.
>
>Thank you~
>
>Xintong Song
>
>
>
>On Sat, Dec 11, 2021 at 12:43 AM Yuepeng Pan  wrote:
>
>> Hi, Community.
>>
>>
>>  I want to contribute to Flink. Could someone help me to get the 'FLIP
>> Page Edit Permission' ?
>>  JIRA Username: RocMarshal
>>  Confluence Username: RocMarshal
>>
>>
>>  Thank you.
>>
>>
>> Best,
>> Roc.
>>

confluence permission apply

[Yuepeng Pan]

Hi,  Till Rohrmann.


  I want to contribute to Flink. Would you please give me the confluence 
permission for flip? 
  My Confluence ID is RocMarshal. 
  My JIRA ID is RocMarshal.
  
  Thank you very much.


Best, 
Roc.

About FLIP Page Edit Permission

[Yuepeng Pan]

Hi, Community.


 I want to contribute to Flink. Could someone help me to get the 'FLIP Page 
Edit Permission' ? 
 JIRA Username: RocMarshal
 Confluence Username: RocMarshal


 Thank you.


Best,
Roc.
 

Re:Re: [ANNOUNCE] New Apache Flink Committer - Ingo Bürk

[Yuepeng Pan]

Congratulations, Ingo!


Best,
Yuepeng Pan





At 2021-12-03 13:47:38, "Yun Gao"  wrote:
>Congratulations Ingo!
>
>Best,
>Yun
>
>
>--
>From:刘建刚 
>Send Time:2021 Dec. 3 (Fri.) 11:52
>To:dev 
>Cc:"Ingo Bürk" 
>Subject:Re: [ANNOUNCE] New Apache Flink Committer - Ingo Bürk
>
>Congratulations！
>
>Best,
>Liu Jiangang
>
>Till Rohrmann  于2021年12月2日周四 下午11:24写道：
>
>> Hi everyone,
>>
>> On behalf of the PMC, I'm very happy to announce Ingo Bürk as a new Flink
>> committer.
>>
>> Ingo has started contributing to Flink since the beginning of this year. He
>> worked mostly on SQL components. He has authored many PRs and helped review
>> a lot of other PRs in this area. He actively reported issues and helped our
>> users on the MLs. His most notable contributions were Support SQL 2016 JSON
>> functions in Flink SQL (FLIP-90), Register sources/sinks in Table API
>> (FLIP-129) and various other contributions in the SQL area. Moreover, he is
>> one of the few people in our community who actually understands Flink's
>> frontend.
>>
>> Please join me in congratulating Ingo for becoming a Flink committer!
>>
>> Cheers,
>> Till
>>

Re:Re: [ANNOUNCE] New Apache Flink Committer - Matthias Pohl

[Yuepeng Pan]

Congratulations Matthias!

Best,Yuepeng Pan.
在 2021-12-03 13:47:20，"Yun Gao"  写道：
>Congratulations Matthias!
>
>Best,
>Yun
>
>
>--
>From:Jing Zhang 
>Send Time:2021 Dec. 3 (Fri.) 13:45
>To:dev 
>Cc:Matthias Pohl 
>Subject:Re: [ANNOUNCE] New Apache Flink Committer - Matthias Pohl
>
>Congratulations, Matthias!
>
>刘建刚  于2021年12月3日周五 11:51写道：
>
>> Congratulations！
>>
>> Best,
>> Liu Jiangang
>>
>> Till Rohrmann  于2021年12月2日周四 下午11:28写道：
>>
>> > Hi everyone,
>> >
>> > On behalf of the PMC, I'm very happy to announce Matthias Pohl as a new
>> > Flink committer.
>> >
>> > Matthias has worked on Flink since August last year. He helped review a
>> ton
>> > of PRs. He worked on a variety of things but most notably the tracking
>> and
>> > reporting of concurrent exceptions, fixing HA bugs and deprecating and
>> > removing our Mesos support. He actively reports issues helping Flink to
>> > improve and he is actively engaged in Flink's MLs.
>> >
>> > Please join me in congratulating Matthias for becoming a Flink committer!
>> >
>> > Cheers,
>> > Till
>> >
>>

Re:[ANNOUNCE] New Apache Flink Committer - Yingjie Cao

[Yuepeng Pan]

Congratulations !


Best, 
Yuepeng Pan.


At 2021-11-17 12:55:29, "Guowei Ma"  wrote:
>Hi everyone,
>
>On behalf of the PMC, I'm very happy to announce Yingjie Cao as a new Flink
>committer.
>
>Yingjie has submitted 88 PRs since he joined the Flink community for more
>than 2 years. In general, his main contributions are concentrated in
>Flink's Shuffle. Yingjie has done a lot of work in promoting the
>performance and stability of TM Blocking Shuffle[1][2];In order to allow
>Flink to use External/Remote Shuffle Service in batch production scenarios,
>he also improves the Flink Shuffle architecture in 1.14 [3]. At the same
>time, he has also done some related work in Streaming Shuffle, such as
>Buffer Management[4] , Non-Blocking Network Output and some important bug
>fixes.
>
>Please join me in congratulating Yingjie for becoming a Flink committer!
>
>[1]
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-148%3A+Introduce+Sort-Based+Blocking+Shuffle+to+Flink
>[2] https://flink.apache.org/2021/10/26/sort-shuffle-part1.html
>[3]
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-184%3A+Refine+ShuffleMaster+lifecycle+management+for+pluggable+shuffle+service+framework
>[4] https://issues.apache.org/jira/browse/FLINK-16428
>
>Best,
>Guowei

[jira] [Created] (FLINK-24931) Remove deprecated/unused class files in flink-scala module.

[Yuepeng Pan (Jira)]

Yuepeng Pan created FLINK-24931:
---

 Summary: Remove deprecated/unused class files in flink-scala 
module.
 Key: FLINK-24931
 URL: https://issues.apache.org/jira/browse/FLINK-24931
 Project: Flink
  Issue Type: Improvement
  Components: API / Scala
Reporter: Yuepeng Pan


Remove deprecated/unused class files in flink-scala module. 


org.apache.flink.api.scala.typeutils.ScalaOptionSerializerConfigSnapshot
org.apache.flink.api.scala.typeutils.ScalaTrySerializerConfigSnapshot
org.apache.flink.api.scala.typeutils.TraversableSerializerConfigSnapshot

 

These class files were tagged with 'Deprecated' in beginning of the year 2019.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re:[ANNOUNCE] New Apache Flink Committer - Fabian Paul

[Yuepeng Pan]

Congratulations Fabian!

Best,
Yuepeng Pan

At 2021-11-15 21:17:13, "Arvid Heise"  wrote:
>Hi everyone,
>
>On behalf of the PMC, I'm very happy to announce Fabian Paul as a new Flink
>committer.
>
>Fabian Paul has been actively improving the connector ecosystem by
>migrating Kafka and ElasticSearch to the Sink interface and is currently
>driving FLIP-191 [1] to tackle the sink compaction issue. While he is
>active on the project (authored 70 PRs and reviewed 60), it's also worth
>highlighting that he has also been guiding external efforts, such as the
>DeltaLake Flink connector or the Pinot sink in Bahir.
>
>Please join me in congratulating Fabian for becoming a Flink committer!
>
>Best,
>
>Arvid
>
>[1]
>https://cwiki.apache.org/confluence/display/FLINK/FLIP-191%3A+Extend+unified+Sink+interface+to+support+small+file+compaction

Re:[ANNOUNCE] New Apache Flink Committer - Jing Zhang

[Yuepeng Pan]

Congrats.


Best,
Yuepeng Pan











At 2021-11-15 21:39:47, "Timo Walther"  wrote:
>Hi everyone,
>
>On behalf of the PMC, I'm very happy to announce Jing Zhang as a new 
>Flink committer.
>
>Jing has been very active in the Flink community esp. in the Table/SQL 
>area for quite some time: 81 PRs [1] in total and is also active on 
>answering questions on the user mailing list. She is currently 
>contributing a lot around the new windowing table-valued functions [2].
>
>Please join me in congratulating Jing Zhang for becoming a Flink committer!
>
>Thanks,
>Timo
>
>[1] https://github.com/apache/flink/pulls/beyond1920
>[2] https://issues.apache.org/jira/browse/FLINK-23997

Re:[ANNOUNCE] New Apache Flink Committer - Leonard Xu

[Yuepeng Pan]

Congrats.

Best,
Yuepeng Pan.
At 2021-11-12 12:12:21, "Jark Wu"  wrote:
>Hi everyone,
>
>On behalf of the PMC, I'm very happy to announce Leonard Xu as a new Flink
>committer.
>
>Leonard has been a very active contributor for more than two year, authored
>150+ PRs and reviewed many PRs which is quite outstanding.
>Leonard mainly works on Flink SQL parts and drives several important FLIPs,
>e.g. FLIP-132 (temporal table join) and FLIP-162 (correct time behaviors).
>He is also the maintainer of flink-cdc-connectors[1] project which helps a
>lot for users building a real-time data warehouse and data lake.
>
>Please join me in congratulating Leonard for becoming a Flink committer!
>
>Cheers,
>Jark Wu
>
>[1]: https://github.com/ververica/flink-cdc-connectors

Re:[ANNOUNCE] New Apache Flink Committer - Yangze Guo

[Yuepeng Pan]

Congrats.


Best,
Yuepeng Pan.







At 2021-11-12 10:10:43, "Xintong Song"  wrote:
>Hi everyone,
>
>On behalf of the PMC, I'm very happy to announce Yangze Guo as a new Flink
>committer.
>
>Yangze has been consistently contributing to this project for almost 3
>years. His contributions are mainly in the resource management and
>deployment areas, represented by the fine-grained resource management and
>external resource framework. In addition to feature works, he's also active
>in miscellaneous contributions, including PR reviews, document enhancement,
>mailing list services and meetup/FF talks.
>
>Please join me in congratulating Yangze Guo for becoming a Flink committer!
>
>Thank you~
>
>Xintong Song

Re:Re: [DISCUSS] Improve the name and structure of job vertex and operator name for job

[Yuepeng Pan]

+1. It's useful to understand the job topology.
Looking forward to this feature.
Best,
Yuepeng Pan.






At 2021-11-11 19:44:44, "Yangze Guo"  wrote:
>+1. That's gonna help a lot for debugging.
>
>Best,
>Yangze Guo
>
>On Thu, Nov 11, 2021 at 7:37 PM Till Rohrmann  wrote:
>>
>> This improvement looks like it makes the life of our users a lot easier
>> when it comes to understanding logs and reading the UI. Hence +1.
>>
>> Cheers,
>> Till
>>
>> On Thu, Nov 11, 2021 at 11:59 AM JING ZHANG  wrote:
>>
>> > Big +1.
>> >
>> > This is a problem frequently encountered in our production platform, look
>> > forward to this improvement.
>> >
>> > Best,
>> > Jing Zhang
>> >
>> > Martijn Visser  于2021年11月11日周四 下午6:26写道：
>> >
>> > > +1. Looks much better now
>> > >
>> > > On Thu, 11 Nov 2021 at 11:07, godfrey he  wrote:
>> > >
>> > > > Thanks for driving this, this improvement solves a long-complained
>> > > > problem, +1
>> > > >
>> > > > Best,
>> > > > Godfrey
>> > > >
>> > > > Jark Wu  于2021年11月11日周四 下午5:40写道：
>> > > > >
>> > > > > +1 for this. It looks much more clear and structured.
>> > > > >
>> > > > > Best,
>> > > > > Jark
>> > > > >
>> > > > > On Thu, 11 Nov 2021 at 17:23, Chesnay Schepler 
>> > > > wrote:
>> > > > >
>> > > > > > I'm generally in favor of it, and there are already tickets that
>> > > > > > proposed a dedicated operator/vertex description:
>> > > > > >
>> > > > > > https://issues.apache.org/jira/browse/FLINK-20388
>> > > > > > https://issues.apache.org/jira/browse/FLINK-21858
>> > > > > >
>> > > > > > On 11/11/2021 10:02, wenlong.lwl wrote:
>> > > > > > > Hi, all, I would like to start a discussion about an improvement
>> > on
>> > > > name
>> > > > > > > and structure of job vertex name, mainly to improve experience of
>> > > > > > debugging
>> > > > > > > and analyzing sql job at runtime.
>> > > > > > >
>> > > > > > > the main proposed changes including:
>> > > > > > > 1. separate description and name for operator, so that we can
>> > have
>> > > > > > detailed
>> > > > > > > info at description and shorter name, which could be more
>> > friendly
>> > > > for
>> > > > > > > external systems like logging/metrics without losing useful
>> > > > information.
>> > > > > > > 2. introduce a tree-mode vertex description which can make the
>> > > > > > description
>> > > > > > > more readable and easier to understand
>> > > > > > > 3. clean up and improve description for sql operator
>> > > > > > >
>> > > > > > > here is an example with the changes for a sql job:
>> > > > > > >
>> > > > > > > vertex name:
>> > > > > > > GlobalGroupAggregate[52] -> (Calc[53] -> NotNullEnforcer[54] ->
>> > > Sink:
>> > > > > > > tb_ads_dwi_pub_hbd_spm_dtr_002_003[54], Calc[55] ->
>> > > > NotNullEnforcer[56]
>> > > > > > ->
>> > > > > > > Sink: tb_ads_dwi_pub_hbd_spm_dtr_002_004[56])
>> > > > > > > vertex description:
>> > > > > > > [52]:GlobalGroupAggregate(groupBy=[stat_date, spm_url_ab,
>> > client],
>> > > > > > > select=[stat_date, spm_url_ab, client, COUNT(count1$0) AS
>> > > > > > > clk_cnt_app_mtr_001, COUNT(distinct$0 count$1) AS
>> > > clk_uv_app_mtr_001,
>> > > > > > > COUNT(count1$2) AS clk_cnt_app_mtr_002, COUNT(distinct$0 count$3)
>> > > AS
>> > > > > > > clk_uv_app_mtr_002, COUNT(count1$4) AS clk_cnt_app_mtr_003,
>> > > > > > > COUNT(distinct$0 count$5) AS clk_uv_app_mtr_003]) :-
>> > > > > > > [53]:Calc(select=[CASE((client <> ''), CONCAT_WS('\u0004',
>> > > > > > > CONCAT(SUBSTRING(MD5(CONCAT(s

Re:Re: [VOTE] FLIP-189: SQL Client Usability Improvements

[Yuepeng Pan]

+1 (non-binding)Best,
Roc

At 2021-11-09 09:13:58, "Jark Wu"  wrote:
>+1 (binding)
>
>Best,
>Jark
>
>On Mon, 8 Nov 2021 at 23:57, Till Rohrmann  wrote:
>
>> +1 (binding)
>>
>> Cheers,
>> Till
>>
>> On Fri, Nov 5, 2021 at 9:24 PM Ingo Bürk  wrote:
>>
>> > +1 (non-binding)
>> >
>> > I think it has all been said before. :-)
>> >
>> > On Fri, Nov 5, 2021, 17:45 Konstantin Knauf  wrote:
>> >
>> > > +1 (binding)
>> > >
>> > > On Fri, Nov 5, 2021 at 4:03 PM Martijn Visser 
>> > > wrote:
>> > >
>> > > > +1 (non-binding). Looking forward!
>> > > >
>> > > > Best regards,
>> > > >
>> > > > Martijn
>> > > >
>> > > > On Fri, 5 Nov 2021 at 15:36, Timo Walther 
>> wrote:
>> > > >
>> > > > > +1 (binding) thanks for working on this.
>> > > > >
>> > > > > Regards,
>> > > > > Timo
>> > > > >
>> > > > >
>> > > > > On 05.11.21 10:14, Sergey Nuyanzin wrote:
>> > > > > > Also there is a short demo showing some of the features mentioned
>> > in
>> > > > this
>> > > > > > FLIP.
>> > > > > > It is available at https://asciinema.org/a/446247?speed=3.0 (It
>> > was
>> > > > also
>> > > > > > mentioned in [DISCUSS] thread)
>> > > > > >
>> > > > > > On Wed, Nov 3, 2021 at 11:04 PM Sergey Nuyanzin <
>> > snuyan...@gmail.com
>> > > >
>> > > > > wrote:
>> > > > > >
>> > > > > >>
>> > > > > >> Hi everyone,
>> > > > > >>
>> > > > > >> I would like to start a vote on FLIP-189: SQL Client Usability
>> > > > > >> Improvements [1].
>> > > > > >> The FLIP was discussed in this thread [2].
>> > > > > >> FLIP-189 targets usability improvements of SQL Client such as
>> > > parsing
>> > > > > >> improvement,
>> > > > > >> syntax highlighting, completion, prompts
>> > > > > >>
>> > > > > >> The vote will be open for at least 72 hours unless there is an
>> > > > objection
>> > > > > >> or not enough votes.
>> > > > > >>
>> > > > > >> [1]
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-189%3A+SQL+Client+Usability+Improvements
>> > > > > >> [2]
>> > > https://lists.apache.org/thread/8d580jcqzpcbmfwqvhjso82hdd2x0461
>> > > > > >>
>> > > > > >> --
>> > > > > >> Best,
>> > > > > >> Sergey
>> > > > > >>
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> > > --
>> > >
>> > > Konstantin Knauf
>> > >
>> > > https://twitter.com/snntrable
>> > >
>> > > https://github.com/knaufk
>> > >
>> >
>>

Re:Re: [NOTICE] CiBot improvements

[Yuepeng Pan]

Thank you for your effort!
Best,
Roc

At 2021-10-12 14:07:18, "Arvid Heise"  wrote:
>Awesome!
>
>On Tue, Oct 12, 2021 at 3:11 AM Guowei Ma  wrote:
>
>> Thanks for your effort!
>>
>> Best,
>> Guowei
>>
>>
>> On Mon, Oct 11, 2021 at 9:26 PM Stephan Ewen  wrote:
>>
>> > Great initiative, thanks for doing this!
>> >
>> > On Mon, Oct 11, 2021 at 10:52 AM Till Rohrmann 
>> > wrote:
>> >
>> > > Thanks a lot for this effort Chesnay! The improvements sound really
>> good.
>> > >
>> > > Cheers,
>> > > Till
>> > >
>> > > On Mon, Oct 11, 2021 at 8:46 AM David Morávek  wrote:
>> > >
>> > > > Nice! Thanks for the effort Chesnay, this is really a huge step
>> > forward!
>> > > >
>> > > > Best,
>> > > > D.
>> > > >
>> > > > On Mon, Oct 11, 2021 at 6:02 AM Xintong Song 
>> > > > wrote:
>> > > >
>> > > > > Thanks for the effort, @Chesnay. This is super helpful.
>> > > > >
>> > > > > @Jing,
>> > > > > Every push to the PR branch should automatically trigger an entire
>> > new
>> > > > > build. `@flinkbot run azure` should only be used when you want to
>> > > re-run
>> > > > > the failed stages without changing the PR. E.g., when running into
>> > > known
>> > > > > unstable cases that are unrelated to the PR.
>> > > > >
>> > > > > Thank you~
>> > > > >
>> > > > > Xintong Song
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Mon, Oct 11, 2021 at 11:45 AM JING ZHANG 
>> > > > wrote:
>> > > > >
>> > > > > > Hi Chesnay,
>> > > > > > Thanks for the effort. It is a very useful improvement.
>> > > > > > I have a minor question. Please forgive me if the question is too
>> > > > naive.
>> > > > > > Since '@flinkbot run azure' now behaves like "Rerun failed jobs",
>> > is
>> > > > > there
>> > > > > > any way to trigger an entirely new build? Because some times I'm
>> > not
>> > > > sure
>> > > > > > the passed cases in the last build could still success in the new
>> > > build
>> > > > > > because of introduced updates in new commit.
>> > > > > >
>> > > > > > Best,
>> > > > > > JING ZHANG
>> > > > > >
>> > > > > >
>> > > > > > Yangze Guo  于2021年10月11日周一 上午10:31写道：
>> > > > > >
>> > > > > > > Thanks for that great job, Chesnay! "Rerun failed jobs" will
>> > help a
>> > > > > lot.
>> > > > > > >
>> > > > > > > Best,
>> > > > > > > Yangze Guo
>> > > > > > >
>> > > > > > > On Sun, Oct 10, 2021 at 4:56 PM Chesnay Schepler <
>> > > ches...@apache.org
>> > > > >
>> > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > I made a number of changes to the CiBot over the weekend.
>> > > > > > > >
>> > > > > > > > - '@flinkbot run azure' previously triggered an entirely new
>> > > build
>> > > > > > based
>> > > > > > > > on the last completed one. It now instead retries the last
>> > > > completed
>> > > > > > > > build, only running the jobs that actually failed. It
>> basically
>> > > > > behaves
>> > > > > > > > like the "Rerun failed jobs" button in the Azure UI.
>> > > > > > > > - various optimizations to increase responsiveness (primarily
>> > by
>> > > > > doing
>> > > > > > > > significantly less unnecessary work / requests to GH)
>> > > > > > > > - removed TravisCI support (since we no longer support a
>> > release
>> > > > that
>> > > > > > > > used Travis)
>> > > > > > > >
>> > > > > > > > Please ping me if you spot anything weird.
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>