deployed cleanly using examples from
https://github.com/streamshub/flink-sql-examples
Tom Cooper
On Tuesday, 15 October 2024 at 17:17, Őrhidi Mátyás
wrote:
> Hi everyone,
>
> Please review and vote on the release candidate #1 for the version 1.10.0
> of Apache Flink Kubernetes Op
require a FLIP?
We could also just specifically override the json-path version in the imported
calcite 1.32, but I am not sure if that is a common / acceptable practice in
Flink.
Any PR reviews/thoughts/help would be much appreciated.
Tom Cooper
[@tomncooper](https://twitter.com/tomncooper
Hi,
The Flink site [community
page](https://flink.apache.org/what-is-flink/community/#slack) says, that if
the Slack invite link is expired, to reach out to the dev list. So I am hoping
someone here can send me an invite?
Thanks in advance.
Tom Cooper
[@tomncooper](https://twitter.com
ecide what constitutes "old" (e.g. no
activity for a year) and set timeouts for responding.
This will probably clear a large number of stale PRs and issues quickly and
shrink the size of the pile that needs to be triaged.
Cheers,
Tom Cooper
On Monday, 4 November 2024 at 15:05, David Radley
+1 for a 1.20.1 release, thanks for driving this Alex.
I am new to Flink and not totally clear on the release process.
Is there going to be a code freeze date? There are a number of CVE fixes
([1],[2]) I would really like to be included.
Tom Cooper
[1](https://github.com/apache/flink/pull
moving the connector Kafka Client library to the
3.9.0 version if anyone has time to review?
Tom Cooper
[1] https://issues.apache.org/jira/browse/FLINK-36648
[2] https://issues.apache.org/jira/browse/FLINK-36245
[3] https://github.com/apache/flink-connector-kafka/pull/138
months and then
closing after a further 3 months of inactivity.
We can review this configuration at a later date, with the aim of bringing it
in line with other Apache projects (3 months inactive with 1 month to
reactivate).
Regards,
Tom Cooper
https://tomcooper.dev
[1] https
nting opinions.
Thanks,
Tom Cooper
@tomncooper | tomcooper.dev
On Tuesday, 7 January 2025 at 16:20, Sergey Nuyanzin
wrote:
> Hi Tom
>
> thanks for driving this
>
> one thing to clarify: If I understand correctly if the vote has been
> started it is still too early to close it
linking the Discussion and Vote threads on the mailing list.
I will create a JIRA and put up the PR for review.
Thanks,
Tom Cooper
@tomncooper | tomcooper.dev
[1] https://cwiki.apache.org/confluence/display/FLINK/Stale+PR+Cleanup
On Tuesday, 7 January 2025 at 14:13, Ahmed Hamdy wrote:
> Thanks
Hi Rui,
Good point about recording the proposal. I am not sure it fits the FLIP process
so I made a page [1] under the CHI workgroup.
That page has a summary of the proposal and links to the discussion and vote
threads.
Thanks,
Tom Cooper
@tomncooper | tomcooper.dev
[1] https
+1 from me. Getting a release out with the 2.0 preview for testing before the
full 2.0 release seems like a good idea.
Tom Cooper
@tomncooper | tomcooper.dev
On Friday, 31 January 2025 at 09:27, Gyula Fóra wrote:
> Hi All!
>
> I would like to kick off the release planning for
hanges requested but aren't being followed-up by the contributor
This is of course an option, but would probably require updating FlinkBot.
There is no reason we couldn't enable both the Stale PR GitHub Action and
update Flinkbot to enforce rules like those above.
Tom Cooper
[@tomncooper](https://twitter.com/tomncooper) |
[tomcooper.dev](https://tomcooper.dev/)
Thanks Alex,
+1 for option 2.
Tom Cooper
@tomncooper | tomcooper.dev
On Monday, 20 January 2025 at 15:36, Ferenc Csaky
wrote:
> Hi Alex,
>
> Thanks again for summarizing the situation! +1 for option 2, taking
> into account that a Pekko release just happened AFAIK.
>
>
t I wondered if
there is some restriction in the repository settings or on the GITHUB TOKEN
used by the action that prevents it creating the label? If someone with the
required authority could check I would be greatful.
Thanks,
Tom Cooper
@tomncooper | tomcooper.dev
[1] https://github.com/ap
would be preferable. We may get some repeat comments.
Thanks,
Tom Cooper
@tomncooper | tomcooper.dev
[1] https://github.com/apache/flink/pull/25992
On Wednesday, 15 January 2025 at 12:20, David Radley
wrote:
> Hi Rui,
> Looks good. I ran:
> https://github.com/apache/flink/pulls?q=i
mbers like myself and David Radley? I realise that
might actually need a wider discussion on the ML.
Thanks,
Tom Cooper
@tomncooper | tomcooper.dev
On Thursday, 16 January 2025 at 01:40, Rui Fan <1996fan...@gmail.com> wrote:
> Hi Tom and David,
>
> The Stale PR message isn&#
+ 1 on keeping the upgraded Pekko for 1.20.1.
>From what I could see, the only issues occurred in a end-to-end test that set
>the available memory to 7MB.
As that is unlikely to be a situation seen in the wild, I think the CVE fixes
alone are worth it.
Thanks,
Tom Cooper
@tomn
,
Tom Cooper
@tomncooper | tomcooper.dev
[1] https://cwiki.apache.org/confluence/display/FLINK/Stale+PR+Cleanup
[2] https://issues.apache.org/jira/browse/FLINK-37026
On Wednesday, 8 January 2025 at 06:21, Venkatakrishnan Sowrirajan
wrote:
> Thanks Tom for driving this, finally we are tackling
Hi Rui,
Thanks for doing that, it looks good to me!
Cheers,
Tom Cooper
@tomncooper | tomcooper.dev
On Friday, 17 January 2025 at 03:59, Rui Fan <1996fan...@gmail.com> wrote:
> Hi Tom,
>
> I searched the PR list based on "This PR is being marked as stale since it
> h
the move to GH Actions?
2) If the process has stalled due to a lack of developer time, then the CHI
members are willing to help but we may need context/help from those previously
involved.
3) As a minimum, would we be able to enable the pre-compile checks for all PRs?
Thanks,
Tom Cooper
checks we identify in the future
to that workflow.
Let me know what you think?
Cheers,
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
[1]
https://github.com/apache/flink/blob/master/.github/workflows/template.pre-compile-checks.yml
[2] https://issues.apache.org/jira/browse/FLINK-37534
I agree a pre-commit hook for these linting checks, should be available and
recommended in the developer documentation (I will put together a PR for this).
However, you can't enforce pre-commit hooks AFAIK so having something running
in CI would still help.
Tom Cooper
@tomcooper.dev |
client library update approach is for the connector. Do we want
to always rack the x.x.1 version of the Kafka clients so we are on a solid
base, or do we want to update ASAP and have a x.1 releases of the Kafka
Connector which tracks the more stable clients?
Thanks,
Tom Cooper
@tomcooper.dev
+1 from me. Thanks for driving this.
Is there anything I can do to help?
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
On Monday, 7 April 2025 at 08:54, Arvid Heise wrote:
> Hi folks,
>
> I would like to volunteer to drive the Kafka connector 4.0.0 release to
> make t
r the connector version
equates to the supported Kafka version.
However, that conversation can wait until later. I am happy to push ahead with
a 4.0 connector release with Flink 2.0.0 and Kafka 3.9.0.
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
[1] https://github.com/apache/flink-connector-
ority issue (particularly as no one seems to
have complained about the 3.4 release), but it would be good to make sure the
sources are usable by all.
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
On Monday, 14 April 2025 at 16:36, Martijn Visser
wrote:
> Hi Tom,
>
> Can you chec
'
Is it possible that whatever tooling you used to create the source code tar
file has injected characters into the files?
Regards,
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
[1] https://github.com/checkstyle/checkstyle/issues/2189
On Friday, 11 April 2025 at 10:55, Arvid Heise
our
[1] Flink SQL Runner (using minikube + Flink K8s Operator 1.11.0) and verified
it worked with Flink 1.20.1 and Kafka 3.9.0.
So I am happy to change my -1 to a +1 (non-binding).
Thanks,
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
[1] https://github.com/streamshub/flink-sql
On Wedn
Given that Flink 2.0.0 compiled with Java 17 and used a source version of Java
11 [1], we should do the same with the Kafka Connector?
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
[1]
https://github.com/apache/flink/blob/14e85eced10e98bc75870ac0360bad67d0722697/pom.xml#L127
On
Hi Sergey,
+1 from me. This would let us finally bump the JSON-Path dependencies to
address various CVEs.
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
On Tuesday, 18 February 2025 at 10:01, Sergey Nuyanzin
wrote:
> Hi everyone,
> I'd like to propose releasing flink-
1_20).
- Reviewed the Release Notes
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
On Tuesday, 25 February 2025 at 08:04, Gyula Fóra wrote:
> Hi Everyone,
>
> Please review and vote on the release candidate #1 for the
> version 1.11.0 of Apache Flink Kubernetes Operator,
>
be willing to support it once it moves?
Also does this require a new FLIP or can we resurrect the original FLIP-233?
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
On Friday, 23 May 2025 at 12:13, David Radley wrote:
> Hi,
> Flip-233 [2] has been closed due to lack of capacity. I and
This will be a great addition, it really plugs a missing functionality gap.
+1 (non-binding)
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
On Friday, 6 June 2025 at 17:09, David Radley wrote:
> Hi everyone,
>
> I'd like to start a vote on FLIP-532: Donate GetInData HTT
Kafka clusters would still be able to use 4.1.0 (which is
an argument for making sure that release has the most up-to-date dependencies).
Anyway, I would love to hear what the community think of the above.
Thanks,
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
[0] https://github.com/apache
working on this though it would be a good QoL improvement.
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
[1]
https://github.com/apache/flink/blob/c7ab7cacf0fe1d7e7c89b16f9c45a524359e323b/flink-kubernetes/pom.xml#L34
On Tuesday, 8 July 2025 at 17:02, David Radley wrote:
> Hi,
> I c
These sound like serious issues, so +1 (non-binding) from me on a .1 release.
Thanks for running this Gyula.
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
On Wednesday, 2 July 2025 at 16:34, Gyula Fóra wrote:
> Hi All!
>
> We released the Kubernetes operator 1.12.0 version abou
upgrade to a future 5.1 release?
Thanks for looking at this.
Regards,
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
On Monday, 28 July 2025 at 09:51, Fabian Paul wrote:
> Hi Tom,
>
> Thanks for starting this discussion. I think it's a good idea to do
> another 4.1
e new major Kafka client version.
What do people think?
Tom Cooper
@tomcooper.dev | https://tomcooper.dev
[1] https://github.com/apache/flink-connector-kafka/pull/161
[2] https://nvd.nist.gov/vuln/detail/CVE-2025-27817
On Wednesday, 9 July 2025 at 09:35, Tom Cooper wrote:
> Hi,
>
> I
Hi Joao,
+1 from me on this proposal.
I think having a more dynamic (and up-to-date) connector eco-system is vital
for Flink's success.
Being able to take advantage of new features (and patch old bugs and
vulnerabilities) as soon as possible is a big plus point!
Tom Cooper
@tomcoope
39 matches
Mail list logo
