Re: [DISCUSS] Flink project bylaws

l definition of Apache glossary and other projects. >>>> 3. review board -> pull request >>>> >>>> - >>>> Re: Chesnay >>>> >>>> The emeritus stuff seems like unnecessary noise. >>>> As Till menti

Re: [DISCUSS] Flink project bylaws

Big +1 How different is this from the Kafka bylaws? I’m asking because I quite like them and wouldn’t mind essentially adopting the Kafka bylaws. I mean, it’s open source, and we don’t have to try to re-invent the wheel here. I think it’s worthwhile to discuss the “committer +1” requirement.

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

a clear >>>>>>> understanding what binding votes in this case mean. I think it >>> makes >>>>>> sense >>>>>>> to consider PMC's and committers' votes as binding for FLIPs >>> voting. >>>>>>> Otherwise we would l

Re: [VOTE] How to Deal with Split/Select in DataStream API

I think this would benefit from a FLIP, that neatly sums up the options, and which then gives us also a point where we can vote and ratify a decision. As a gut feeling, I most like Option 3). Initially I would have preferred option 1) (because of a sense of API purity), but by now I think it’s

Re: [VOTE] Migrate to sponsored Travis account

+1 Aljoscha > On 4. Jul 2019, at 11:09, Stephan Ewen wrote: > > +1 to move to a private Travis account. > > I can confirm that Ververica will sponsor a Travis CI plan that is > equivalent or a bit higher than the previous ASF quota (10 concurrent build > queues) > > Best, > Stephan > > On

[jira] [Created] (FLINK-13062) Set ScheduleMode based on boundedness of streaming Pipeline

Aljoscha Krettek created FLINK-13062: Summary: Set ScheduleMode based on boundedness of streaming Pipeline Key: FLINK-13062 URL: https://issues.apache.org/jira/browse/FLINK-13062 Project: Flink

Re: [VOTE] Release 1.8.1, release candidate #1

+1 (binding) - I checked the diff in the POM files since 1.8.0 and they look good, i.e. no new dependencies that could lead to licensing problems > On 1. Jul 2019, at 10:02, Tzu-Li (Gordon) Tai wrote: > > +1 (binding) > > - checked signatures and hashes > - built from source without

[jira] [Created] (FLINK-13041) Make ScheduleMode configurable on ExecutionConfig

Aljoscha Krettek created FLINK-13041: Summary: Make ScheduleMode configurable on ExecutionConfig Key: FLINK-13041 URL: https://issues.apache.org/jira/browse/FLINK-13041 Project: Flink

[DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

Hi All, When we originally introduced the FLIP process (which is based on the KIP process from Kafka and refers to the Kafka bylaws for how votes work) voting was set to be “lazy majority”. This means that a FLIP vote "requires 3 binding +1 votes and more binding +1 votes than -1 votes”

Re: [ANNOUNCE] Feature freeze for Apache Flink 1.9.0 release

A few threads are converging around supporting the new Blink-based Table API Runner/Planner. I think hitting the currently proposed feature freeze date is hard, if not impossible, and that the work would benefit from an additional week to get everything in with good quality. What do the others

Re: [DISCUSS] Connectors and NULL handling

(for >>> Kafka) and DataFetcher (for Kinesis); this way we can also handle error's >>> other than deserializing problem, for example some even lower level >>> exceptions like CRC check failure. >>> >>> I think either way will work. Also, as long as there's a way f

Re: [ANNOUNCE] Jincheng Sun is now part of the Flink PMC

Congratulations! :-) > On 25. Jun 2019, at 11:34, Wei Zhong wrote: > > Congratulations Jincheng! > > Best, > Wei > > >> 在 2019年6月25日，15:18，JingsongLee 写道： >> >> Jincheng, Congratulations! >> >> Best, JingsongLee >> >> >> --

[DISCUSS] Connectors and NULL handling

Hi All, Thanks to Gary, I recently came upon an interesting cluster of issues: - https://issues.apache.org/jira/browse/FLINK-3679: Allow Kafka consumer to skip corrupted messages - https://issues.apache.org/jira/browse/FLINK-5583: Support flexible error handling in the Kafka consumer -

Re: [VOTE] FLIP-41: Unified binary format for keyed state

+1 With the restriction that it should be “canonical format”/“unified format” (or something like it) and not save point format, i.e. not KeyedBackendSavepointStrategyBase in the doc, for example Aljoscha > On 17. Jun 2019, at 14:05, Congxian Qiu wrote: > > +1 from my side. > Best, >

Re: [DISCUSS] FLIP-41: Unify Keyed State Snapshot Binary Format for Savepoints

ified Format" although > in the short term it only unifies savepoint. > > I've also wrote a document [1] to include more details and please refer to > it if interested. Thanks! > > [1] https://docs.google.com/document/d/1uE4R3wNal6e67FkDe0UvcnsIMMDpr35j > > Best Regards

Re: Updating Kinesis Connector to latest Apache licensed libs

+1 Nice! Less special-case handling is always good. > On 14. Jun 2019, at 10:30, Thomas Weise wrote: > > Dyana, thanks for taking this up! > > The flink-connector-kinesis module is already part of the CI pipeline, it > is just excluded when creating the release. So what needs to be done is to

Re: [DISCUSS] Adopting a Code Style and Quality Guide

+1 I think this is a very good effort and should put to rest some back-and-forth discussions on PRs and some differences in “style” between committers. ;-) > On 13. Jun 2019, at 10:21, JingsongLee > wrote: > > big +1, the content is very useful and enlightening. > But it's really too long to

[jira] [Created] (FLINK-12832) Enhance StreamGraphGenerator/StreamGraph for Blink Table Runner

Aljoscha Krettek created FLINK-12832: Summary: Enhance StreamGraphGenerator/StreamGraph for Blink Table Runner Key: FLINK-12832 URL: https://issues.apache.org/jira/browse/FLINK-12832 Project

Re: [DISCUSS] Putting Table API jars in /lib by default

+1 I agree that Table API should be in lib because it will become a first-class-citizen. Currently, both the classic Flink Table Runner and the new Blink-based Table Runner share the same package structure, i.e they are both rooted in org.apache.flink.table. We have to resolve this before we

Re: Apply for confluence Wiki create and edit permission

I gave you the permissions  > On 12. Jun 2019, at 05:26, vino yang wrote: > > Hi, > > I am going to create a new FLIP for Proposal of supporting local > aggregation in Flink. > > The discussion thread in the Flink dev mailing list is here.[1] > > Could you please give me the create and edit

Re: [DISCUSS] Flink client api enhancement for downstream project

Some points to consider: * Any API we expose should not have dependencies on the runtime (flink-runtime) package or other implementation details. To me, this means that the current ClusterClient cannot be exposed to users because it uses quite some classes from the optimiser and runtime

Re: [DISCUSS] Support Local Aggregation in Flink

Hi, I think this proposed change is big enough to warrant a FLIP [1], which should have a voting process as described in that link before the FLIP is accepted. I’m writing this because such a bigger change has the possibility of languishing for a long time due to lack of PMC/committer

Re: [DISCUSS] FLIP-41: Unify Keyed State Snapshot Binary Format for Savepoints

Btw, I think this FLIP is a very good effort, we just need to reframe the effort a tiny bit. +1 > On 6. Jun 2019, at 13:41, Aljoscha Krettek wrote: > > Hi, > > I had a brief discussion with Stephan that helped me sort my thoughts on the > broader topics of checkpoints,

Re: [DISCUSS] FLIP-41: Unify Keyed State Snapshot Binary Format for Savepoints

Hi, I had a brief discussion with Stephan that helped me sort my thoughts on the broader topics of checkpoints, savepoints, binary formats, user-triggered checkpoints, and periodic savepoints. I’ll try to summarise my stance on this and also comment with the same message on the other relevant

Re: [Discuss] FLIP-43: Savepoint Connector

+1 I think is is a very valuable new additional and we should try and not get stuck on trying to design the perfect solution for everything > On 4. Jun 2019, at 13:24, Tzu-Li (Gordon) Tai wrote: > > +1 to renaming it as State Processing API and adding it under the > flink-libraries module. >

[jira] [Created] (FLINK-12613) Move SinkFunction to flink-core

Aljoscha Krettek created FLINK-12613: Summary: Move SinkFunction to flink-core Key: FLINK-12613 URL: https://issues.apache.org/jira/browse/FLINK-12613 Project: Flink Issue Type

[jira] [Created] (FLINK-12606) Move SourceFunction to flink-core

Aljoscha Krettek created FLINK-12606: Summary: Move SourceFunction to flink-core Key: FLINK-12606 URL: https://issues.apache.org/jira/browse/FLINK-12606 Project: Flink Issue Type

[jira] [Created] (FLINK-12587) Add pure-API Watermark class

Aljoscha Krettek created FLINK-12587: Summary: Add pure-API Watermark class Key: FLINK-12587 URL: https://issues.apache.org/jira/browse/FLINK-12587 Project: Flink Issue Type: Improvement

Re: [DISCUSS] FLIP-39: Flink ML pipeline and ML libs

We discussed this in private and came to the conclusion that we should (for now) have the dependency on flink-table-api-xxx-bridge because we need access to the collect() method, which is not yet available in the Table API. Once that is available the code can be refactored but for now we want

Re: [DISCUSS] FLIP-39: Flink ML pipeline and ML libs

achine learning concept. The flink-ml is mainly towards to > algorithm engineers and scientists, I believe it's better to make the api > clean and hide the detail of implementation as much as possible. Hopefully > there would another way to acquire the tableEnv and the api could sta

Re: [DISCUSS] FLIP-39: Flink ML pipeline and ML libs

Hi, I had a look at the document mostly from a module structure/dependency structure perspective. We should make the expected dependency structure explicit in the document. From the discussion in the doc it seems that the intention is that flink-ml-lib should depend on flink-table-planner

Re: [DISCUSS] Improve Queryable State and introduce a QueryServerProxy component

Hi Everyone, I think this is a good discussion and valuable ideas have come up. However, it seems none of the committers and/or PMCs currently have time to work on this subject. Till, who’s focusing on the distributed runtime side, which is touched quite a bit by queryable state, is currently

[jira] [Created] (FLINK-12501) AvroTypeSerializer does not work with types generated by avrohugger

Aljoscha Krettek created FLINK-12501: Summary: AvroTypeSerializer does not work with types generated by avrohugger Key: FLINK-12501 URL: https://issues.apache.org/jira/browse/FLINK-12501 Project

[jira] [Created] (FLINK-12164) JobMasterTest.testJobFailureWhenTaskExecutorHeartbeatTimeout is unstable

Aljoscha Krettek created FLINK-12164: Summary: JobMasterTest.testJobFailureWhenTaskExecutorHeartbeatTimeout is unstable Key: FLINK-12164 URL: https://issues.apache.org/jira/browse/FLINK-12164

[ANNOUNCE] Apache Flink 1.8.0 released

The Apache Flink community is very happy to announce the release of Apache Flink 1.8.0, which is the next major release. Apache Flink® is an open-source stream processing framework for distributed, high-performing, always-available, and accurate data streaming applications. The release is

[RESULT] [VOTE] Release 1.8.0, release candidate #5

I'm happy to announce that we have unanimously approved this release. There are 5 approving votes, 4 of which are binding: * Rong * Chesnay * Thomas * Gordon * Aljoscha (I’m hereby +1’ing) There are no disapproving votes. Thanks everyone! > On 9. Apr 2019, at 10:22, Aljoscha Krettek wr

Re: [VOTE] Release 1.8.0, release candidate #5

Thanks everyone for checking the release and voting! I’ll tally the results in a separate email. > On 8. Apr 2019, at 10:04, Aljoscha Krettek wrote: > > @Thomas There is a note about this in the documentation release notes: > https://github.com/apach

Re: [Discuss] Semantics of event time for state TTL

imer processing to simply expire stale data that may not be accessed > otherwise is expensive. > > On Mon, Apr 8, 2019 at 7:11 AM Aljoscha Krettek wrote: > >> I had a discussion with Andrey and now think that also the case >> event-time-timestamp/watermark-cle

Re: [Discuss] Semantics of event time for state TTL

. An example can be the one that I described above. And this > also defeats one of the main advantages of event time, in my opinion, which > is reproducability of the results. > > I may be wrong, but I would appreciate any opinions on this. > > Cheers, > Kostas > > On

Re: [Discuss] Semantics of event time for state TTL

Oh boy, this is an interesting pickle. For *last-access-timestamp*, I think only *event-time-of-current-record* makes sense. I’m looking at this from a GDPR/regulatory compliance perspective. If you update a state, by say storing the event you just received in state, you want to use the exact

Re: [VOTE] Release 1.8.0, release candidate #5

n number for shaded hadoop2 surprised me: >> >> Example: flink-shaded-hadoop2-2.8.3-1.8.0.jar >> >> If 2.8.3 is part of the version number (vs. artifactId), then shouldn't the >> version number be 1.8.0-2.8.3? (Alternatively, the hadoop version could be >> include

Re: [VOTE] Release 1.8.0, release candidate #5

Ah, the first two are not on 1.8.0-rc5, but FLINK-11855 is. > On 6. Apr 2019, at 08:23, Aljoscha Krettek wrote: > > Thanks, Chesnay! I had that tab open already and was prepared to do it but > it’s good you also thought about it. :-) What about these three issues, > t

Re: [VOTE] Release 1.8.0, release candidate #5

ickstart-scala and quickstart-java are working with the staging >>> repository. >>> >>> -- >>> Rong >>> >>> >>> On Wed, Apr 3, 2019 at 11:22 PM Aljoscha Krettek >>> wrote: >>> >>>> Hi everyone,

[VOTE] Release 1.8.0, release candidate #5

Hi everyone, Please review and vote on the release candidate 5 for Flink 1.8.0, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) The complete staging area is available for your review, which includes: * JIRA release notes [1], * the

[CANCEL][VOTE] Release 1.8.0, release candidate #4

xisting PORT setting. However, I wasn't able to >>> find any test that is related, maybe @Till can provide more insight here? >>> >>> Maybe @Richard can provide more detail on the YARN run command used to >>> reproduce the problem? >>> >>> Thanks, >

Re: [VOTE] Release 1.8.0, release candidate #4

r deserialization of the AvroSerializer. >>> Piotr also pointed out that after the number of records was increased in >>> the serializer benchmarks, this drop was no longer observable before / >>> after the changes in mid February. >>> IMO, this is not crit

Re: [VOTE] Release 1.8.0, release candidate #4

rializerAvro benchmark, as explained earlier in >>> previous >>>> voting threads of earlier RCs, was due to a slower job initialization >>> phase >>>> caused by slower deserialization of the AvroSerializer. >>>> Piotr also pointed out that after the number of

Re: [VOTE] Release 1.8.0, release candidate #4

use the network bandwidth is not enough. and > > > it > > > > > > runs smoothly when using VPN acceleration. The overall end-to-end > > > > > > run > > > > was > > > > > > passed twice. The Docker resource configuration (CUPs 7, Mem

[jira] [Created] (FLINK-12030) KafkaITCase.testMultipleSourcesOnePartition is unstable

Aljoscha Krettek created FLINK-12030: Summary: KafkaITCase.testMultipleSourcesOnePartition is unstable Key: FLINK-12030 URL: https://issues.apache.org/jira/browse/FLINK-12030 Project: Flink

[jira] [Created] (FLINK-12019) ZooKeeperHaServicesTest.testCloseAndCleanupAllDataWithUncle is unstable

Aljoscha Krettek created FLINK-12019: Summary: ZooKeeperHaServicesTest.testCloseAndCleanupAllDataWithUncle is unstable Key: FLINK-12019 URL: https://issues.apache.org/jira/browse/FLINK-12019

[jira] [Created] (FLINK-12015) TaskManagerRunnerTest is unstable

Aljoscha Krettek created FLINK-12015: Summary: TaskManagerRunnerTest is unstable Key: FLINK-12015 URL: https://issues.apache.org/jira/browse/FLINK-12015 Project: Flink Issue Type: Bug

Re: [VOTE] Release 1.8.0, release candidate #4

gt; 4. Review the PR > - [Add 1.8 Release Blog Post] - Just a reminder, updated the release > date to correct date before merging. > > Cheers, > Jincheng > > Piotr Nowojski 于2019年3月25日周一 下午4:11写道： > >> +1 from my side. Previously spotted performance regression seems

[jira] [Created] (FLINK-12006) ZooKeeperHaServicesTest is unstable

Aljoscha Krettek created FLINK-12006: Summary: ZooKeeperHaServicesTest is unstable Key: FLINK-12006 URL: https://issues.apache.org/jira/browse/FLINK-12006 Project: Flink Issue Type: Bug

Re: [DISCUSS] Using Guava in Flink "core" packages

> On Wed, Mar 6, 2019 at 7:13 AM Thomas Weise wrote: > >> How I managed to do that.. >> >> Here is the discussion about the shared package: >> >> >> https://lists.apache.org/thread.html/3de9d2353cf22aea0448fb744314103b5f88195216acc3bff449354a@%3Cdev.f

Re: [DISCUSS] Reorganizing Table-related Jira components some more

; Table SQL / Runtime >>> Table SQL / Ecosystem (such as table connectors, formats, Hive catalog >>> etc.) >>> >>> This should make everyone happy, no? >>> >>> Thanks for proosing this Aljoscha. Big +1. >>> >>> Regards, >>> Tim

[VOTE] Release 1.8.0, release candidate #4

Hi everyone, Please review and vote on the release candidate 4 for Flink 1.8.0, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) The complete staging area is available for your review, which includes: * JIRA release notes [1], * the

Re: [DISCUSS] Reorganizing Table-related Jira components some more

ic planner" and "new planner", the > naming will be inaccurate after blink merge done and we deprecated classic > planner later (if it happens). > If only one planner left, then what component should we use when creating > jira? > > How about this: > Table SQL / API

[CANCEL][VOTE] Release 1.8.0, release candidate #3

e user thread and not the dev thread anymore. Let’s see what we do next time. > On 21. Mar 2019, at 14:15, Aljoscha Krettek wrote: > > Hi Yu, > > I commented on the issue. For me both Hadoop 2.8.3 and Hadoop 2.4.1 seem to > work. Could you have a look at my comment? > &

[DISCUSS] Reorganizing Table-related Jira components some more

Hi, First of all, I hope I cc’ed all the relevant people. Sorry if I forgot anyone. I would like to restructure the Table/SQL-related Jira components a bit more to better reflect the current state of components. Right now we have: * API / Table SQL: this is just a wild collection of

[VOTE] Release 1.8.0, release candidate #3

Hi everyone, Please review and vote on the release candidate 3 for Flink 1.8.0, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) The complete staging area is available for your review, which includes: * JIRA release notes [1], * the

[CANCEL][VOTE] Release 1.8.0, release candidate #2

le. I also tried >>>> the >>>>>>> benchmark locally and observed obvious wave even with the same >>>>> commit... >>>>>>> >>>>>>> I guess we may need to improve it such as increasing the >

Re: [REMINDER] Please add entries for newly added dependencies to NOTICE file

d a conditional check for this into flink-bot in case a pom.xml was > modified. Otherwise it will be easy to forget in the future. > > – Ufuk > > On Mon, Mar 18, 2019 at 12:03 PM Aljoscha Krettek wrote: >> >> Hi All, >> >> Please remember to add newly ad

Re: [VOTE] Release 1.8.0, release candidate #2

`downloads.html#optional-components`, add the Hadoop relation JARs >>> download >>>> link first. >>>> 2. Then add instructions on how to get the dependencies of the >>> Hadoop or >>>> add the correct download link directly in the next VOTE mail, du

[REMINDER] Please add entries for newly added dependencies to NOTICE file

Hi All, Please remember to add newly added dependencies to the NOTICE file of flink-dist (which will then end up in NOTICE-binary and so on). Discovering this late will cause delays in releases, as it is doing now. There is a handy guide that Chesnay and Till worked on that explains licensing

[VOTE] Release 1.8.0, release candidate #2

Hi everyone, Please review and vote on the release candidate 2 for Flink 1.8.0, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) The complete staging area is available for your review, which includes: * JIRA release notes [1], * the

Re: [CANCEL][VOTE] Release 1.8.0, release candidate #1

. >> Looking forward to the new RC. >> >> Best, >> Jincheng >> >> Aljoscha Krettek 于2019年3月13日周三 下午7:25写道： >> >>> Hi, >>> >>> I’m hereby canceling the vote for RC1 of Flink 1.8.0 because of the >>> aforementioned issues

[CANCEL][VOTE] Release 1.8.0, release candidate #1

Hi, I’m hereby canceling the vote for RC1 of Flink 1.8.0 because of the aforementioned issues. I’ll create a new RC as soon as those issues are resolved. Best, Aljoscha > On 13. Mar 2019, at 12:24, Aljoscha Krettek wrote: > > Hi, > > Thanks for the verification performed so

Re: [VOTE] Release 1.8.0, release candidate #1

;>> - checked that all POM files point to the same version >>>>> - build from source >>>>> >>>>> Best, >>>>> Kurt >>>>> >>>>> >>>>> On Tue, Mar 12, 2019 at 9:20 AM Congxian Qiu >&

Re: [DISCUSS] FLIP-33: Terminate/Suspend Job with Savepoint

I agree and already created a Jira issue for removing the old “stop” feature as preparation: https://issues.apache.org/jira/browse/FLINK-11889 Aljoscha > On 7. Mar 2019, at 11:08, Kostas Kloudas wrote: > > Hi, > > Thanks for the comments.

[jira] [Created] (FLINK-11889) Remove "stop" signal along with Stoppable interfaces

Aljoscha Krettek created FLINK-11889: Summary: Remove "stop" signal along with Stoppable interfaces Key: FLINK-11889 URL: https://issues.apache.org/jira/browse/FLINK-11889 Proj

[VOTE] Release 1.8.0, release candidate #1

Hi everyone, Please review and vote on the release candidate 1 for Flink 1.8.0, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) The complete staging area is available for your review, which includes: * JIRA release notes [1], * the

[jira] [Created] (FLINK-11865) Code generation in TraversableSerializer is prohibitively slow

Aljoscha Krettek created FLINK-11865: Summary: Code generation in TraversableSerializer is prohibitively slow Key: FLINK-11865 URL: https://issues.apache.org/jira/browse/FLINK-11865 Project

Re: [ANNOUNCE] Update on Flink 1.8 Release Progress

browse/FLINK-11501> > > Thanks, > Thomas > > > On Fri, Mar 1, 2019 at 7:43 AM Aljoscha Krettek <mailto:aljos...@apache.org>> wrote: > >> Hi Everyone, >> >> We are now about a week after cutting the release-1.8 branch and things >> are l

Re: [DISCUSS] Using Guava in Flink "core" packages

ser-facing class. >> If this is to be used by connectors, which are included in the user-jar, >> then we're violating the principle above, in which case the class should >> be relocated/removed. >> >> On 06.03.2019 15:10, Aljoscha Krettek wrote: >>> Hi, >>

[DISCUSS] Using Guava in Flink "core" packages

Hi, I recently saw that we added a dependency on our shaded-guava to flink-core [1]. Just for the record, I don’t want do diminish the contributions of anyone involved in the PR in any way. It just made me realise that we have some implicit agreements or assumptions about adding certain things

[jira] [Created] (FLINK-11836) Update NOTICE-binary and licenses-binary for Flink 1.8.0

Aljoscha Krettek created FLINK-11836: Summary: Update NOTICE-binary and licenses-binary for Flink 1.8.0 Key: FLINK-11836 URL: https://issues.apache.org/jira/browse/FLINK-11836 Project: Flink

Re: [DISCUSS] Introducing Builder in FlinkKafkaProducer

I think before doing anything quick here we should look at this more holistically: How do the different connectors work, i.e. how do you construct them? Can we find a way to unify that, maybe using a Builder pattern? And then should we make a plan of getting the connectors there, possibly with

[ANNOUNCE] Update on Flink 1.8 Release Progress

Hi Everyone, We are now about a week after cutting the release-1.8 branch and things are looking quite good! The community has worked hard on fixing bugs and test instabilities. There are now only two issues that are marked as “blocker” in our Jira: [1]. The first of which is about updating

[jira] [Created] (FLINK-11791) Describe how to build Flink with Hadoop in build guide

Aljoscha Krettek created FLINK-11791: Summary: Describe how to build Flink with Hadoop in build guide Key: FLINK-11791 URL: https://issues.apache.org/jira/browse/FLINK-11791 Project: Flink

[jira] [Created] (FLINK-11780) Change version scheme of Hadoop-based modules to conform to SNAPSHOT guidelines

Aljoscha Krettek created FLINK-11780: Summary: Change version scheme of Hadoop-based modules to conform to SNAPSHOT guidelines Key: FLINK-11780 URL: https://issues.apache.org/jira/browse/FLINK-11780

Re: Flaky tests

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.

[jira] [Created] (FLINK-11751) Extend release notes for Flink 1.8

Aljoscha Krettek created FLINK-11751: Summary: Extend release notes for Flink 1.8 Key: FLINK-11751 URL: https://issues.apache.org/jira/browse/FLINK-11751 Project: Flink Issue Type: Task

[ANNOUNCE] Flink 1.8 release branch has been cut

Hi Everyone, I just created the branch for the Flink 1.8 release [1] and updated the version on master to 1.9-SNAPSHOT. Apparently we already had a 1.9.0 version in our jira [2]. I’ll create a first release candidate shortly, stay tuned! Best, Aljoscha [1]

[jira] [Created] (FLINK-11693) Add KafkaSerializationSchema that directly uses ProducerRecord

Aljoscha Krettek created FLINK-11693: Summary: Add KafkaSerializationSchema that directly uses ProducerRecord Key: FLINK-11693 URL: https://issues.apache.org/jira/browse/FLINK-11693 Project

Re: [VOTE] Release Apache Flink 1.7.2, release candidate #1

+1 - verified signatures and hashes - started cluster for both Scala 2.11 and 2.12, ran examples, verified web ui and log output (there is an exception in the log when running without Hadoop, should fix that but not a blocker) - manually verified the diff pom files between 1.7.1 and 1.7.2 to

Re: List of consumed kafka topics should not be restored from state

I think these two Jira issues are relevant here: - https://issues.apache.org/jira/browse/FLINK-10342 - https://issues.apache.org/jira/browse/FLINK-9303 The second one only because it’s

Re: [DISCUSS] Enhance Operator API to Support Dynamically Selective Reading and EndOfInput Event

While we’re on operators and tasks, I think it would also make sense in the long run to move the logic that is now in AbstractStreamOperator.setup()/initializeState()/snapshot()/snapshotState()(and the other snapshotState()…)/dispose() outside of the operator itself. This logic is the same for

[DISCUSS] Releasing Flink 1.8 / Feature Freeze

Hi All, In reference to a recent mail by Ufuk [1] and because it has been a while since the last Flink release we should start thinking about a Flink 1.8 release. We’re actually a bit behind the cadence but I think we still shouldn’t rush things. I’m hereby proposing myself as release manager

[jira] [Created] (FLINK-11539) Add TypeSerializerSnapshot for TraversableSerializer

Aljoscha Krettek created FLINK-11539: Summary: Add TypeSerializerSnapshot for TraversableSerializer Key: FLINK-11539 URL: https://issues.apache.org/jira/browse/FLINK-11539 Project: Flink

Re: [DISCUSS] Start new Review Process

What do you mean by “merging cannot happen through the GitHub user interface”? You can in fact merge PRs by clicking on the merge button, or “rebase and merge”. Aljoscha > On 29. Jan 2019, at 11:58, Robert Metzger wrote: > > @Fabian: Thank you for your suggestions. Multiple approvals in one

Re: [DISCUSS] Bot for stale PRs on GitHub

ntribution >>> guide as a means of preventing such PRs from being opened again. This >>> also provides committers with a reference based on which they can >>> close future PRs. >>> >>> Recommending contributors to continuously update their PRs to prevent &g

Re: [DISCUSS] Bot for stale PRs on GitHub

I think the automatic closing is an integral part, without it we would never close those stale PRs that we have lying around from 2015 and 2016. I would suggest to set the staleness interval quite high, say 2 months. Thus initially the bot would mainly close very old PRs and we shouldn’t even

Re: [DISCUSS] Bot for stale PRs on GitHub

me PRs that I had open at Beam Aljoscha > On 10. Jan 2019, at 11:21, Chesnay Schepler wrote: > > Without any new argument for doing so, I'm still against it. > > On 10.01.2019 09:54, Aljoscha Krettek wrote: >> Hi, >> >> I know we had similar discussio

[DISCUSS] Bot for stale PRs on GitHub

Hi, I know we had similar discussions in the past but I’d like to bring up this topic again. What do you think about adding a stale bot (https://probot.github.io/apps/stale/ ) to our Github Repo? This would automatically nag about stale PRs and close them

Re: [NOTICE] Mandatory migration of git repositories to gitbox.apache.org

Sounds good. > On 3. Jan 2019, at 14:27, Chesnay Schepler wrote: > > Since neither of these repositories are in use (flink-libraries is empty, and > incubator-flink is 3+ years old) we could just drop them I suppose. > > Any objections? > > On 03.01.2019 14:18, Apache Infrastructure Team

Re: [VOTE] Release 1.5.6, release candidate #1

+1 - signatures/hashes are ok - manually checked the logs after running an example on a local cluster There is this exception in the client log when running without Hadoop in the classpath: 2018-12-19 18:34:54,876 WARN org.apache.flink.client.cli.CliFrontend - Could not

Re: [VOTE] Release 1.6.3, release candidate #1

+1 - signatures/hashes are ok - verified that the log contains no suspicious output when running a local cluster > On 18. Dec 2018, at 14:31, Chesnay Schepler wrote: > > +1 > > - signatures ok > - src contains no binaries > - binary not missing any jars > - tag exists > - release notes

Re: [DISCUSS] Long-term goal of making flink-table Scala-free

Hi, this is a very nice effort! There is one thing that we should change, though. In the batch API we have a clear separation between API and runtime, and using the API (depending on flink-batch) does not "expose" the runtime classes that are in flink-runtime. For the streaming API, we made

Re: [DISCUSS] FLIP-27: Refactor Source Interface

ead will perform a >> bunch >>>>>>>> of >>>>>>>>> IO asynchronously. >>>>>>>>> - When take() is called, the same calling thread will perform a >>>>>>>> bunch >>>>>>>

Re: StreamingFileSink Bug? Committing results on stream close

Hi Addison, unfortunately, there is a long-standing problem that user functions cannot differentiate between successful and erroneous shutdown [1]. I had this high on my private list of things that I finally want to see fixed in Flink 1.8. And your message further confirms this. Best,

<    1   2   3   4   5   6   7   8   9   10   >