Yaroslav Tkachenko created FLINK-25164:
--
Summary: DogStatsD Metrics Reporter
Key: FLINK-25164
URL: https://issues.apache.org/jira/browse/FLINK-25164
Project: Flink
Issue Type: New Featur
刘方奇 created FLINK-25163:
---
Summary: Add more options for rocksdb state backend to make
configuration more flexible
Key: FLINK-25163
URL: https://issues.apache.org/jira/browse/FLINK-25163
Project: Flink
Sergey Nuyanzin created FLINK-25162:
---
Summary: Flink : Connectors : Hive fails with VectorizedRowBatch
not found
Key: FLINK-25162
URL: https://issues.apache.org/jira/browse/FLINK-25162
Project: Fli
> Would it be enough to say that for example all classes in the module
flink-java have to be annotated? What I would like to avoid is having to
annotate all classes in some internal module like flink-rpc.
I don't think it is, but we certainly could restrict it to certain top
level o.a.f.xyz packag
>That's still a much weaker requirement, though, as classes can just be
left unannotated, which is why I prefer annotating all classes regardless
of location.
Would it be enough to say that for example all classes in the module
flink-java have to be annotated? What I would like to avoid is having
Hi Till,
> Personally, I'd be fine to say that in API modules (tbd what this is
> (probably transitive closure of all APIs)) we require every class to be
> annotated.
At least we'll then need the reverse rule: no classes outside *.api.*
packages CAN have an API annotation (other than Internal), o
Hi Ingo, thanks for your feedback.
Do you think that two release cycles per graduation step would be long
enough or should it be longer?
Cheers,
Till
On Fri, Dec 3, 2021 at 4:29 PM Ingo Bürk wrote:
> Hi Till,
>
> Overall I whole-heartedly agree with the proposals in this FLIP. Thank you
> for
Hi Ingo, thanks a lot for your thoughts and the work you've spent on this
topic already.
Personally, I'd be fine to say that in API modules (tbd what this is
(probably transitive closure of all APIs)) we require every class to be
annotated.
For sake of clarity and having clear rules, this should
Hi Till,
Overall I whole-heartedly agree with the proposals in this FLIP. Thank you
for starting this discussion as well! This seems like something that could
be tested quite nicely with ArchUnit as well; I'll be happy to help should
the FLIP be accepted.
> I would propose per default a single re
Sergey Nuyanzin created FLINK-25161:
---
Summary: Update dependency for japicmp-maven-plugin
Key: FLINK-25161
URL: https://issues.apache.org/jira/browse/FLINK-25161
Project: Flink
Issue Type:
Thank you everyone for the warm welcome!
Best
Ingo
On Fri, Dec 3, 2021 at 11:47 AM Ryan Skraba
wrote:
> Congratulations Ingo!
>
> On Fri, Dec 3, 2021 at 8:17 AM Yun Tang wrote:
>
> > Congratulations, Ingo!
> >
> > Best
> > Yun Tang
> >
> > From: Yuepeng Pan
>
Hi Till,
Thanks for starting this discussion, and as you noticed, I qutie care for
it as well. :-)
When implementing the ArchUnit rules, I noticed that project-wide,
different teams / modules use and understand the API annotations in
different ways. Therefore, I think it is important to both get
Thank you! I'm looking forward to continue working with you.
On Fri, Dec 3, 2021 at 7:29 AM Jingsong Li wrote:
> Congratulations, Matthias!
>
> On Fri, Dec 3, 2021 at 2:13 PM Yuepeng Pan wrote:
> >
> > Congratulations Matthias!
> >
> > Best,Yuepeng Pan.
> > 在 2021-12-03 13:47:20，"Yun Gao" 写道：
Jun Qin created FLINK-25160:
---
Summary: Make doc clear: tolerable-failed-checkpoints counts
consecutive failures
Key: FLINK-25160
URL: https://issues.apache.org/jira/browse/FLINK-25160
Project: Flink
Chesnay Schepler created FLINK-25159:
Summary: Streaming E2E surefire configuration setup
Key: FLINK-25159
URL: https://issues.apache.org/jira/browse/FLINK-25159
Project: Flink
Issue Type
I just opened a PR for
https://issues.apache.org/jira/browse/FLINK-25126 I'll expect to merge
it sometime next week.
Best,
Fabian
On Fri, Dec 3, 2021 at 10:49 AM Martijn Visser wrote:
>
> Hi all,
>
> Just a status update on the open blockers for 1.14.1:
> * https://issues.apache.org/jira/browse/
Francesco Guardiani created FLINK-25158:
---
Summary: Fix formatting for true, false and null to uppercase
Key: FLINK-25158
URL: https://issues.apache.org/jira/browse/FLINK-25158
Project: Flink
Francesco Guardiani created FLINK-25156:
---
Summary: DISTINCT is not handled correctly by CastRules
Key: FLINK-25156
URL: https://issues.apache.org/jira/browse/FLINK-25156
Project: Flink
Francesco Guardiani created FLINK-25157:
---
Summary: Introduce NULL type to string cast rule
Key: FLINK-25157
URL: https://issues.apache.org/jira/browse/FLINK-25157
Project: Flink
Issue T
Dawid Wysakowicz created FLINK-25155:
Summary: Implement claim snapshot mode
Key: FLINK-25155
URL: https://issues.apache.org/jira/browse/FLINK-25155
Project: Flink
Issue Type: Sub-task
Dawid Wysakowicz created FLINK-25154:
Summary: FLIP-193: Snapshots ownership
Key: FLINK-25154
URL: https://issues.apache.org/jira/browse/FLINK-25154
Project: Flink
Issue Type: Improvement
Definitely +1 from me as well. Otherwise backporting tests (accompanying
fixes) would consume significant time.
On Fri, Dec 3, 2021 at 11:42 AM Till Rohrmann wrote:
> I think this is a very good idea, Matthias. +1 for backporting the jassert
> changes to 1.14 and 1.13 if possible.
>
> Cheers,
>
Fyi: Ingo already implemented most of the FLIP by introducing the
ApiAnnotationRules.PUBLIC_API_METHODS_USE_ONLY_PUBLIC_API_TYPES and
.PUBLIC_EVOLVING_API_METHODS_USE_ONLY_PUBLIC_EVOLVING_API_TYPES [1] using
ArchUnit :-)
[1]
https://github.com/apache/flink/blob/master/flink-architecture-tests/src/
Hi Konstantin and Francesco,
> * Are you planning to implement the required tests via ArchUnit?
If ArchUnit is the best tool for the job, then I will probably use it. But
I haven't investigated it yet.
> * Fixing existing "test failures" is in the scope of this FLIP, correct?
Yes I think that f
Congratulations Ingo!
On Fri, Dec 3, 2021 at 8:17 AM Yun Tang wrote:
> Congratulations, Ingo!
>
> Best
> Yun Tang
>
> From: Yuepeng Pan
> Sent: Friday, December 3, 2021 14:14
> To: dev@flink.apache.org
> Cc: Ingo Bürk
> Subject: Re:Re: [ANNOUNCE] New Apache Fl
I think this is a very good idea, Matthias. +1 for backporting the jassert
changes to 1.14 and 1.13 if possible.
Cheers,
Till
On Fri, Dec 3, 2021 at 11:38 AM Matthias Pohl
wrote:
> Currently, we only added the jassert to the master branch. I was wondering
> whether we could backport the corresp
Thanks for starting this discussion Yingjie,
How will our tests be affected by these changes? Will Flink require more
resources and, thus, will it risk destabilizing our testing infrastructure?
I would propose to create a FLIP for these changes since you propose to
change the default behaviour. I
Currently, we only added the jassert to the master branch. I was wondering
whether we could backport the corresponding PR [1] to release-1.14 and
release-1.13, too. Otherwise, we would have to implement tests twice when
providing PRs with new tests that need to be backported: The jassert
version fo
Thanks for the feedback Konstantin.
* I agree that if we think that one release cycle to graduate is too short,
then we should extend it to something we believe we can achieve. For
FLIP-27, I think we could have stabilized the API faster if it had been our
priority (not sure whether two release cy
Hi all,
Just a status update on the open blockers for 1.14.1:
* https://issues.apache.org/jira/browse/FLINK-22113 - UniqueKey constraint
is lost with multiple sources join in SQL -> I believe most review comments
have been fixed and it's just the final review remarks before it's ready.
* https://i
Hi Till,
Thanks for starting this discussion, I think it's very beneficial for the
community to have stable APIs, in particular to develop connectors and
formats.
A couple of comments:
> I would suggest that we document these guarantees prominently under
/docs/dev/api_stability.
I think it woul
Hi dev & users,
We propose to change some default values of blocking shuffle to improve the
user out-of-box experience (not influence streaming). The default values we
want to change are as follows:
1. Data compression
(taskmanager.network.blocking-shuffle.compression.enabled): Currently, the
def
Hi Till,
This makes sense to me, in general. I am wondering two things:
* is one release to promote enough or will it lead to a lot of exclusions?
FLIP-27, for example, took much longer to stabilize, I believe. If we
think, this is quite a strict rule, then in my experience, let's rather
start wi
Hi Till,
Thank you for picking up this topic. Explicit and consistent stability
guarantees are important for our users as well as any downstream project of
Apache Flink. Documenting the de-facto status quo and tackling existing
inconsistencies sounds like a good first step. So, +1 from my side.
T
+1
Thanks for driving this, Dawid.
Best
Yun Tang
From: Roman Khachatryan
Sent: Thursday, December 2, 2021 17:02
To: dev
Subject: Re: [VOTE] FLIP-193: Snapshots ownership
+1
Thanks for driving this effort Dawid
Regards,
Roman
On Wed, Dec 1, 2021 at 2:04 PM K
Junfan Zhang created FLINK-25153:
Summary: Inappropriate variable naming
Key: FLINK-25153
URL: https://issues.apache.org/jira/browse/FLINK-25153
Project: Flink
Issue Type: Improvement
36 matches
Mail list logo
