Hi Zakelly,
Thanks for your feedback! I address the comments in the following:
1. Good point! I’ve updated the REST API in the FLIP to make the URL more
specific.
2. The deployment details are omitted in the FLIP to maintain focus on the core
interaction between Flink subtasks and the compacti
melin created FLINK-38326:
-
Summary: Kubernetes support oAuthToken authentication
Key: FLINK-38326
URL: https://issues.apache.org/jira/browse/FLINK-38326
Project: Flink
Issue Type: Improvement
I think it would be good idea to have an auto applied "backport" label (if the
target branch is not main and matches release-*).
Cheers,
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
On Wednesday, 13 August 2025 at 16:33, David Radley
wrote:
> Hello,
> I have been reviewing PRs and no
Thomas Cooper created FLINK-38322:
-
Summary: Update to Kafka Client 4.1.0
Key: FLINK-38322
URL: https://issues.apache.org/jira/browse/FLINK-38322
Project: Flink
Issue Type: Improvement
Jacky Lau created FLINK-38321:
-
Summary: Optimize the timer registration logic n window early/late
firing scenarios
Key: FLINK-38321
URL: https://issues.apache.org/jira/browse/FLINK-38321
Project: Flink
Lucas Borges created FLINK-38325:
Summary: Checkpoints are hanging and timing out frequently
Key: FLINK-38325
URL: https://issues.apache.org/jira/browse/FLINK-38325
Project: Flink
Issue Type:
Lucas Borges created FLINK-38324:
Summary: Job fails to restore keyed state backend when using Forst
state backend on S3
Key: FLINK-38324
URL: https://issues.apache.org/jira/browse/FLINK-38324
Project
Hi David,
+1 – an automated labelling would help. The baseRefName attribute could be
requested from the GraphQL query [1], allowing to add/remove a “backport” label
accordingly. Do you already have an idea of the labelling, such as
“Backport_”?
[1]
https://github.com/apache/flink/blob/maste
Salva created FLINK-38323:
-
Summary: Global Scale Factor Mode
Key: FLINK-38323
URL: https://issues.apache.org/jira/browse/FLINK-38323
Project: Flink
Issue Type: New Feature
Components: Auto
Hi, Ramin
In FLIP-492[1], we introduced the `CREATE OR REPLACE MATERIALIZED TABLE`
syntax to support modifying materialized tables. Can we extend this syntax
to achieve the functionality you need, such as introducing clause
parameters to determine whether to replace the entire table or just some o
Hi devs,
I'm happy to announce that FLIP-490: Enhanced Job History Retention Policies
for HistoryServer[1]
has been accepted with 5 approving votes[2]:
- 3 bindings
- Becket Qin (binding)
- Wei Zhong (binding)
- Rui Fan (binding)
- 2 non-bindings:
- Yuepeng Pan (non-binding)
- Zhanghao Che
Hi all,
Thank you for the voting.
I'm closing the vote and I'll post the result in a new email thread.
Best regards,
Yuepeng Pan
Replied Message
| From | Yuepeng Pan |
| Date | 09/4/2025 10:39 |
| To | dev@flink.apache.org |
| Subject | Re: [VOTE] FLIP-490: Enhanced Job History Retentio
Good morning, Mate,
Thanks for the feedback! When I wrote this, the FLIP was not yet closed! I
have added the DISTRIBUTED BY/INTO clause to the FLIP.
Cheers,
Ramin
On Wed, Sep 3, 2025 at 7:58 PM Mate Czagany wrote:
> Hi Ramin,
>
> Thank you for the proposal, I think this new command makes perf
13 matches
Mail list logo
