Hi everyone,
Thanks for all the feedback to Hybrid Source so far. Based on the discussion[1]
we seem to have consensus, so I would like to start a vote on FLIP-150 for
which the FLIP has also been updated[2].
The vote will last for at least 72 hours (Sun, Jul 4th 12:00 GMT) unless there
Carl created FLINK-23198:
Summary: An old interface method is used in this section of
[Passing Options Factory to RocksDB].
Key: FLINK-23198
URL: https://issues.apache.org/jira/browse/FLINK-23198
Project:
wangqinghuan created FLINK-23197:
Summary: Errorneous description about 'TIMESTAMP WITH TIME ZONE'
date type
Key: FLINK-23197
URL: https://issues.apache.org/jira/browse/FLINK-23197
Project: Flink
Xintong Song created FLINK-23196:
Summary: JobMasterITCase fail on azure due to BindException
Key: FLINK-23196
URL: https://issues.apache.org/jira/browse/FLINK-23196
Project: Flink
Issue
MOBIN created FLINK-23195:
-
Summary: No value for kafka metrics in Flink Web ui
Key: FLINK-23195
URL: https://issues.apache.org/jira/browse/FLINK-23195
Project: Flink
Issue Type: Bug
>
> * Even if there is a major breaking version, Flink releases major versions
> too where it could be added
> Netty framework locking is true but AFAIK there was a discussion to
> rewrite the Netty stuff to a more sexy thing but there was no agreement to
> do that.
>
Flink major releases seem to
Thanks Gen! cc flink-dev to collect more inputs.
Best
Lu
On Wed, Jun 30, 2021 at 12:55 AM Gen Luo wrote:
> I'm also wondering here.
>
> In my opinion, it's because the JM can not confirm whether the TM is lost
> or it's a temporary network trouble and will recover soon, since I can see
> in
zlzhang0122 created FLINK-23194:
---
Summary: Cache and reuse the ContainerLaunchContext and accelarate
the progress of createTaskExecutorLaunchContext on yarn
Key: FLINK-23194
URL:
Dear devs,
As discussed in the thread[1], I’d like to start a vote on migrating the
test framework of Flink project to JUnit 5.
JUnit 5[2] provides many exciting new features that can simplify the
development of test cases and make our test structure cleaner, such as
pluggable extension models
Thanks Arvid for the feedback! I think merging the giant commit after cutting
1.14 release branch would be a good idea.
Since no one has objections in the discussion, I’d like to move a step forward
and raise a vote on the migration. Looking forward to having JUnit 5 in the
1.14 release cycle!
Thanks Arvid for the feedback! I think merging the giant commit after cutting
1.14 release branch would be a good idea.
Since no one has objections in the discussion, I’d like to move a step forward
and raise a vote on the migration. Looking forward to having JUnit 5 in the
1.14 release cycle!
Answered here because the text started to be crowded.
> It also locks Flink into the current major version of Netty (and the
Netty framework itself) for the foreseeable future.
It's not doing any Netty version locking because:
* Netty not necessarily will add breaking changes in major versions,
Small correction:
I am *not *saying we should not do this, perhaps this is the best solution
to finding a good compromise here, but I am trying to discover +
acknowledge the full implications of this proposal so they can be
discussed.
Sorry :)
On Wed, Jun 30, 2021 at 9:53 AM Austin
Hi Gabor,
Thanks for your answers. I appreciate the explanations. Please see my
responses + further questions below.
* What stability semantics do you envision for this API?
>>
> As I foresee the API will be as stable as Netty API. Since there is
> guarantee on no breaking changes between minor
Fangliang Liu created FLINK-23193:
-
Summary: Support to display Options when using desc table statement
Key: FLINK-23193
URL: https://issues.apache.org/jira/browse/FLINK-23193
Project: Flink
Hi devs,
As discussed in [1], I would like to start a discussion for releasing Flink
1.11.4.
I would like to volunteer as the release manger for 1.11.4, and will start
the release process on the next Wednesday (July 7th).
There are 75 issues that have been closed or resolved [2],
and no blocker
Ingo Bürk created FLINK-23192:
-
Summary: Move connector/format option classes into a common package
Key: FLINK-23192
URL: https://issues.apache.org/jira/browse/FLINK-23192
Project: Flink
Issue
I agree that we shouldn't discourage contributions.
For me the main idea of the bot is not to clean up the JIRA but to improve
our communication and expectation management with the community. There are
many things we could do but for a lot of things we don't have the time and
capacity. Then to
I second Tison's opinion.
Similar to how we skip docs_404_check for PRs that do not touch the
documentation, we can skip other stages for PRs that only contain
documentation changes.
In addition to making merging documentation PRs easier, we can also reduce
the workload on CI workers. Especially
Hi Austin,
Please see my answers embedded down below.
BR,
G
On Tue, Jun 29, 2021 at 9:59 PM Austin Cawley-Edwards <
austin.caw...@gmail.com> wrote:
> Hi all,
>
> Thanks for the updated proposal. I have a few questions about the API,
> please see below.
>
> * What stability semantics do you
> * Introduce "Not a Priority" priority and stop closing tickets.
+1 for this one (I also like the name you proposed for this Konstantin)
I also have no objections to other proposals that you summarised. Just a
remark, that independently of this discussion we might want to revisit or
reconfirm
Hi everyone,
Thank you for the additional comments and suggestions.
@Stephan, Kurt: I agree that we shouldn't discourage or dishearten
contributors, and probably 14 days until a ticket becomes "stale-assigned"
are too few. That's why I've already proposed to increase that to 30 days.
Similarly
I think you are right Tison that docs are a special case and they only
require flink-docs to pass. What I am wondering is how much of a problem
this will be (assuming that we have a decent build stability). The more
exceptions we add, the harder it will be to properly follow the guidelines.
Maybe
Robert Metzger created FLINK-23191:
--
Summary: Azure: Upload CI logs to S3 as well
Key: FLINK-23191
URL: https://issues.apache.org/jira/browse/FLINK-23191
Project: Flink
Issue Type:
+1 to Stephan's opinion, with just one minor difference. For my experience
and a project
as big as Flink, picking up an issue created 1-2 years ago seems normal to
me. To be more
specific, during the blink planner merge, I created lots of clean up &
refactor issues, trying
to make the code be more
Thanks for addressing this issue :)
Best, Piotrek
wt., 29 cze 2021 o 17:58 Hausmann, Steffen napisał(a):
> Hey Poitr,
>
> I've just adapted the FLIP and changed the signature for the
> `submitRequestEntries` method:
>
> protected abstract void submitRequestEntries(List
> requestEntries,
Hi,
There are a number of PRs modifying docs only, but we still require all
tests passed on that.
It is a good proposal we avoid merge PR with "unrelated" failure, but can
we improve the case where the contributor only works for docs?
For example, base on the file change set, run doc tests
+1 for the proposal. Thanks Xintong!
Best,
Godfrey
Rui Li 于2021年6月30日周三 上午11:36写道：
> Thanks Xintong. +1 to the proposal.
>
> On Tue, Jun 29, 2021 at 11:05 AM 刘建刚 wrote:
>
> > +1 for the proposal. Since the test time is long and environment may
> vary,
> > unstable tests are really annoying
28 matches
Mail list logo
