Hi Guys,
I want to contribute to Apache Flink.
Would you please give me the permission as a contributor?
My JIRA ID is yutaochina.
2019-02-28
博彦科技股份有限公司
--上海泓智信息科技有限公司
地址：上海市长宁区天山路8号402室
邮编：200336
手机：15501079221
邮箱：hdxg1101300...@163.com，yuta...@beyondsoft.com
Sorry, not looked into it much... but it occurred to me that it would be great
to have it as "Throttling: Operator" that can be applied anywhere after a
source and before a sink. Each parallel instance of it can operate at the
specified rate limit divided by the number of parallel instances o
zhijiang created FLINK-11776:
Summary: Refactor to simplify the process of
scheduleOrUpdateConsumers
Key: FLINK-11776
URL: https://issues.apache.org/jira/browse/FLINK-11776
Project: Flink
Issue
sunjincheng created FLINK-11777:
---
Summary: fix hadoop_compatibility.md link bug
Key: FLINK-11777
URL: https://issues.apache.org/jira/browse/FLINK-11777
Project: Flink
Issue Type: Improvement
Jingsong Lee created FLINK-11775:
Summary: Introduce MemorySegmentWritable to let DataOutputView
direct copy to internal bytes
Key: FLINK-11775
URL: https://issues.apache.org/jira/browse/FLINK-11775
P
Thanks a lot for the great release Jincheng. Great work!
> 在 2019年2月28日，上午8:22，jincheng sun 写道：
>
> Sorry Chesnay, we have discussed when will remove 1.6.3 files, when we
> added the 1.6.4 files. Just like Robert mentioned above!
> Anyway thanks for your reminder @Chesnay Schepler !
> And thanks
Sorry Chesnay, we have discussed when will remove 1.6.3 files, when we
added the 1.6.4 files. Just like Robert mentioned above!
Anyway thanks for your reminder @Chesnay Schepler !
And thanks for your big help @Robert Metzger !
Best,
Jincheng
Robert Metzger 于2019年2月27日周三 下午8:48写道：
> Sorry, this
Hi,
this topic has been discussed a lot recently in the community as "Event
Time Alignment/Synchronization" [1,2]. These discussion should provide a
starting point.
Cheers,
Konstantin
[1]
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/Sharing-state-between-subtasks-td24489.html
Kirill Vainer created FLINK-11774:
-
Summary: IllegalArgumentException in HeapPriorityQueueSet
Key: FLINK-11774
URL: https://issues.apache.org/jira/browse/FLINK-11774
Project: Flink
Issue Type
Igal Shilman created FLINK-11773:
Summary: KryoSerializerSnapshot would fail to deserialize if a
type is missing
Key: FLINK-11773
URL: https://issues.apache.org/jira/browse/FLINK-11773
Project: Flink
"Connectors / Misc"
On 27.02.2019 15:20, Robert Metzger wrote:
I have now started renaming the components.
You can track my progress on the wiki page:
https://cwiki.apache.org/confluence/display/FLINK/Proposal+for+new+JIRA+Components
Since one has to re-open closed tickets to update their comp
Fore code-quality/description I agree, but consensus and the final
approval should require a committer IMO.
On 27.02.2019 15:08, Robert Metzger wrote:
I did not put any restrictions on who can communicate with the bot!
But since there is currently no way of overriding somebody's approval
for s
I have now started renaming the components.
You can track my progress on the wiki page:
https://cwiki.apache.org/confluence/display/FLINK/Proposal+for+new+JIRA+Components
Since one has to re-open closed tickets to update their component, I will
focus on the open tickets with the migration.
I have
I did not put any restrictions on who can communicate with the bot!
But since there is currently no way of overriding somebody's approval for
something, this can easily lead to such a situation.
My thinking was that a committer still needs to manually check who approved
a pull request, and I wante
I agree with Chesnay, and I would like to add that the most important step
towards fixing flakiness is awareness and willingness. As soon as you accept
flakiness and start working around it (as you mentioned) more flakiness will
creep in, making it harder to get rid of it in the future.
Aljosch
I like this idea and I would like to try it to see if it solves the problem.
I can also offer to add a functionality to the Flinkbot to automatically
close pull requests which have been opened against a unassigned JIRA ticket.
Being rejected by an automated system, which just applies a rule is nic
Just noticed that _anyone_ can approve a PR now, see
https://github.com/apache/flink/pull/7801.
Not sure about the solution, but as it stands it is rather trivial to
nuke the review process of the entire project.
On 13.02.2019 10:29, Robert Metzger wrote:
Hey all,
the flinkbot has been acti
Sorry, this was somewhere on my TODO list to remove.
We added the 1.6.4 files on Friday afternoon, but announced the
release/updated the website on Monday morning. That's why I didn't want
remove the files before the links have been updated.
On Wed, Feb 27, 2019 at 10:57 AM Chesnay Schepler
wrot
@Chesnay - yes, this is possible, according to infra.
On Wed, Feb 27, 2019 at 11:09 AM ZiLi Chen wrote:
> Hi,
>
> @Hequn
> It might be hard to separate JIRAs into conditional and unconditional ones.
>
> Even if INFRA supports such separation, we meet the problem that whether
> a contributor is g
Tzu-Li (Gordon) Tai created FLINK-11772:
---
Summary: InternalTimerServiceSerializationProxy should not be
serializing timers' key / namespace serializers anymore
Key: FLINK-11772
URL: https://issues.apache.org
We've been in the same position a while back with the same effects. We
solved it by creating JIRAs for every failing test and cracking down
hard on them; I don't think there's any other way to address this.
However to truly solve this one must look at the original cause to
prevent new flaky test
Hey there Flink community,
I work on a fellow open-source project - Apache Kafka - and there we have been
fighting flaky tests a lot. We run Java 8 and Java 11 builds on every Pull
Request and due to test flakiness, almost all of them turn out red with 1 or 2
tests (completely unrelated to the
Hi,
@Hequn
It might be hard to separate JIRAs into conditional and unconditional ones.
Even if INFRA supports such separation, we meet the problem that whether
a contributor is granted to decide the type of a JIRA. If so, then
contributors might
tend to create JIRAs as unconditional; and if not,
Note that for future releases the files for the previous version (in
this case 1.6.3) should also be removed once the website was updated.
I have taken care of this already.
On 26.02.2019 05:12, Thomas Weise wrote:
Jincheng, thanks for running the release!
Please also send the announcement to
We currently cannot change the JIRA permissions. Have you asked INFRA
whether it is possible to setup a Flink-specific permission scheme?
On 25.02.2019 14:23, Timo Walther wrote:
Hi everyone,
as some of you might have noticed during the last weeks, the Flink
community grew quite a bit. A lot
Thanks for the feedback.
I created a PR in https://github.com/apache/flink/pull/7843.
@Aljoscha Krettek: Do you think we can include this in the 1.8 branch?
– Ufuk
On Tue, Feb 26, 2019 at 3:37 PM Till Rohrmann wrote:
>
> +1 from my side for the proposal.
>
> Cheers,
> Till
>
> On Tue, Feb 26,
Tzu-Li (Gordon) Tai created FLINK-11771:
---
Summary: Serializer snapshot cannot be read if directly upgraded
in-place to a TypeSerializerSnapshot from a TypeSerializerConfigSnapshot
written in 1.7+
Key: FLINK-11771
27 matches
Mail list logo
