Martin Junghanns created FLINK-2910:
---
Summary: Combine tests for binary graph operators
Key: FLINK-2910
URL: https://issues.apache.org/jira/browse/FLINK-2910
Project: Flink
Issue Type: Test
Great work!
What puzzles me a little bit, is the shepherding of PR from committers.
Why should it be a different committer?
1) As a committer, you don't even need to open a PR for small code
changes at all (especially, if the committer is the most experience one
regard a certain component/library
Matthias J. Sax created FLINK-2911:
--
Summary:
AccumulatingAlignedProcessingTimeWindowOperatorTest.checkpointRestoreWithPendingWindowTumbling
Key: FLINK-2911
URL: https://issues.apache.org/jira/browse/FLINK-2911
Amazing and super interesting!
Any idea what are the plans for this project?
On Fri, Oct 23, 2015 at 3:43 PM, Maximilian Michels wrote:
> Great project. Thanks for sharing!
>
> On Thu, Oct 22, 2015 at 9:29 PM, Ufuk Celebi wrote:
>
> > Wow! Very nice. Thanks for sharing. I will try it out :-)
>
Ted Yu created FLINK-2912:
-
Summary: Potential resource leak due to unclosed RandomAccessFile
in StaticFileServerHandler
Key: FLINK-2912
URL: https://issues.apache.org/jira/browse/FLINK-2912
Project: Flink
Ted Yu created FLINK-2913:
-
Summary: Close of ObjectOutputStream should be enclosed in finally
block in FsStateBackend
Key: FLINK-2913
URL: https://issues.apache.org/jira/browse/FLINK-2913
Project: Flink
Ted Yu created FLINK-2914:
-
Summary: Missing break in
ZooKeeperSubmittedJobGraphStore#SubmittedJobGraphsPathCacheListener#childEvent()
Key: FLINK-2914
URL: https://issues.apache.org/jira/browse/FLINK-2914
Pro
Hey guys,
Have we disabled the default input copying after all? I don't remember
seeing a Jira or PR for this (maybe I just missed it).
And if not, do we want this in the 0.10 release?
Cheers,
Gyula
On Fri, Oct 2, 2015 at 7:57 PM, Till Rohrmann wrote:
> Do we know what kind of impact the non-
I don't recall that the default policy was changed.
If we change it, would be a good idea to change it for 0.10 - the latest
for 1.0
One thing I realized is that to get predictable behavior with chaining, we
should not do the special case parallelism 1 chaining (meaning shuffle
operations get cha
+1 for adding restriction for Javadoc at least at the header of public
classes and methods.
We did the exercise in Twill and seemed to work pretty well.
On Fri, Oct 23, 2015 at 1:34 AM, Maximilian Michels wrote:
> I don't think lazily adding comments will work. However, I'm fine with
> adding al
Yes, as committer we trust you to do the right thing when committing the code.
If a committer believe he/ she needs review,especially with large
patch, then he/ she should send PR for review.
- Henry
On Sat, Oct 24, 2015 at 3:53 AM, Matthias J. Sax wrote:
> Great work!
>
> What puzzles me a lit
https://ci.apache.org/projects/flink/flink-docs-master/api/java
needs to be fixed.
12 matches
Mail list logo
