Re: [VOTE] Release Apache Flink 1.2.0 (RC2)

; > Robert also found an issue that pending checkpoint files are not > > properly > > > > cleaned up: https://issues.apache.org/jira/browse/FLINK-5660. To my > > > > surprise, the issue was already fixed in 1.1.4 so I guess I've > > forgotten > &g

Re: [VOTE] Release Apache Flink 1.2.0 (RC3)

+1 from my side: - Re-verified signatures and checksums - Re-checked out the Java quickstarts and ran the jobs - Re-checked that all poms point to 1.2.0 - Re-ran streaming state machine with Kafka source, RocksDB backend and master and worker failures (standalone cluster) - Tested externalized che

Re: [RESULT][VOTE] Release Apache Flink 1.2.0 (RC3)

> > >> > > > > >> > > > > Not rerun for RC3, but is reasonable to forward: >> > > > > - Kerberos authentication against YARN, Kafka, HDFS, Zookeeper. All >> > > files >> > > > > (including shipped keytabs) no

Re: [jira] [Created] (FLINK-5710) Add ProcTime() function to indicate StreamSQL

Send an email to  dev-unsubscr...@flink.apache.org from the email address you want to unsubscribe with. On 5 February 2017 at 17:05:31, Harish Kumard (harish.kum...@tcs.com) wrote: > > How do I unscubscribe. I already did but am, still getting emails. Please help > > -"Stefano Bortoli (

Re: [Discuss] Organizing Documentation for Configuration Options

I fully agree with you Greg. Since this is doomed to get out of sync again very shortly after clean up, I vote to automate this. Stephan introduced the ConfigOption type, which makes it easy to define the options. It's already planned to migrate all configuration options from ConfigConstants to

[ANNOUNCE] Welcome Stefan Richter as a new committer

Hey everyone, I'm very happy to announce that the Flink PMC has accepted Stefan Richter to become a committer of the Apache Flink project. Stefan is part of the community for almost a year now and worked on major features of the latest 1.2 release, most notably rescaling and backwards compatibili

Re: Using QueryableState inside Flink jobs (and Parameter Server implementation)

Hey Gabor, great ideas here. It's only slightly related, but I'm currently working on a proposal to improve the queryable state APIs for lookups (partly along the lines of what you suggested with higher level accessors). Maybe you are interested in contributing there? I really like your ideas

Re: [Discuss] Organizing Documentation for Configuration Options

aling of network buffers. > > On Tue, Feb 7, 2017 at 3:04 AM, Ufuk Celebi wrote: > >> I fully agree with you Greg. >> >> Since this is doomed to get out of sync again very shortly after clean up, >> I vote to automate this. Stephan introduced the ConfigOption type, w

Re: [DISCUSS] Code style / checkstyle

Kurt's proposal sounds reasonable. What about the following: - We try to capture the current style in an code style configuration (for IntelliJ and maybe Eclipse) - We provide that on the website for contributors to download - We don't enforce it, but new contributions and changes are free to form

Re: Visualizing topologies

Hey Ken! This looks really good. +1 to make this available publicly. We can link it from the Flink website and the viz tool Pat linked to. The vizualizer has currently some open issues, it is not up to date with the one that is part of the Flink web UI. – Ufuk On Wed, Feb 22, 2017 at 3:01 AM,

Re: [DISCUSS] Should we supply a new Iterator instance for Functions with Iterable input(s) like CoGroupFunction ?

On Wed, Feb 22, 2017 at 11:19 AM, Till Rohrmann wrote: > In general, you’re right Lin Li that we don’t honour the Iterable contract > which should allow you to create an arbitrary number of iterators over the > data. Honestly, I’m not sure why we did this change because it’s not very > intuitive.

Re: [DISCUSS] Code style / checkstyle

On Fri, Feb 24, 2017 at 10:46 AM, Fabian Hueske wrote: > I agree with Till that encouraging a code style without enforcing it does > not make a lot of sense. > If we enforce it, we need to touch all files and PRs. I think it makes sense for new contributors to have a starting point without enforc

Re: [DISCUSS] Side Outputs and Split/Select

1. I like the variant without the explicit OutputTag for the WindowOperator: WindowedOperator windowedResult = input .keyBy(...) .window(...) .apply(...) DataStream lateData = windowedResult.getLateDataSideOutput(); I like Jamie's proposal getLateStream() a little better though. On the oth

Re: [DISCUSS] Side Outputs and Split/Select

On Tue, Feb 28, 2017 at 11:38 AM, Aljoscha Krettek wrote: > I see the ProcessFunction as a bit of the generalised future of FlatMap, so > to me it makes sense to only allow side outputs on the ProcessFunction but > I'm open for anything. If we decide for this I'm happy with an additional > method

Re: [DISCUSS] Official policy for release maintenance

Hey Ismael, thanks for bringing this up. I think it's a very important to communicate this on the project web page. On Tue, Mar 14, 2017 at 9:30 AM, Ismaël Mejía wrote: > What do you think guys? Has this been discussed before? Maybe this is a > good moment to decide this, if we haven’t. There w

Re: [DISCUSS] Official policy for release maintenance

rticle and include the details into our wiki. > > In addition, what do you think about adding the "update guarantees" on the > download or FAQ page? > > On Tue, Mar 14, 2017 at 1:18 PM, Ufuk Celebi wrote: > >> Hey Ismael, >> >> thanks for bringing this

Re: [DISCUSS] Release Flink 1.1.5 / Flink 1.2.1

Big +1 Gordon! I think (10) is very critical to have in 1.2.1. – Ufuk On Tue, Mar 14, 2017 at 3:37 PM, Stefan Richter wrote: > Hi, > > I would suggest to also include in 1.2.1: > > (9) https://issues.apache.org/jira/browse/FLINK-6044 > > Repl

Re: [DISCUSS] Release Flink 1.1.5 / Flink 1.2.1

>> >> >> >> >> >> Cheers, >> >> Gordon >> >> >> >> On March 15, 2017 at 7:16:53 PM, Jinkui Shi (shijinkui...@163.com) >> wrote: >> >> >> >> Can we fix this issue in the 1.2.1: >> >> >

Re: [DISCUSS] deprecated function need more detail

There is a related checkstyle rule: http://checkstyle.sourceforge.net/apidocs/com/puppycrawl/tools/checkstyle/checks/annotation/MissingDeprecatedCheck.html Added a JIRA for adding it here: https://issues.apache.org/jira/browse/FLINK-6127 We actually wrote this down in our hidden Wiki at https://c

Re: [DISCUSS] TravisCI status on GitHub Page

I merged the PR and therefore obviously think it's fine. ;-) Didn't see Robert's comment in the issue though ("We once had the travis build status badge in our readme, but decided to remove it, because it often shows "Build failed" due to travis issues etc. This gives people the impression that our

Re: Future of Queryable State Feature

On Mon, Mar 20, 2017 at 3:25 PM, Aljoscha Krettek wrote: > I think adding this could be as simple as adding a > makeWindowContentsQueryable(String) call to WindowedStream. In there, we > create the StateDescriptor for keeping the window contents so we can call > setQueryable() on the StateDescr

Re: [jira] [Updated] (FLINK-6126) Yet another conflict : guava

I don't think so: https://issues.apache.org/jira/browse/FLINK-6125 >From a related issue brought to the mailing list by another user. On Mon, Mar 20, 2017 at 2:36 PM, Aljoscha Krettek wrote: > So it is resolved now? Thanks for letting us know! >> On 20 Mar 2017, at 12:55, Liangfei Su wrote: >

Re: [ANNOUNCE] New committer: Theodore Vasiloudis

Great news! :-) On Tue, Mar 21, 2017 at 10:32 AM, Aljoscha Krettek wrote: > Welcome (to committership)! (Since you’re already with us for such a long > time…) :-) >> On 21 Mar 2017, at 10:08, Tzu-Li (Gordon) Tai wrote: >> >> Welcome Theodore! Great to have you on board :-) >> >> >> On March 21

Re: [DISCUSS] TravisCI status on GitHub Page

problems surface >> is not a way to make it better. I feel it actually gives people a positive >> impression that Flink is an up-to-date project, because older projects >> don't usually have it according to my observation. >> >> On Mon, Mar 20, 2017 at 6:20 AM,

Re: [VOTE] Release Apache Flink 1.2.1 (RC1)

RC1 doesn't contain Stefan's backport for the Asynchronous snapshots for heap-based keyed state that has been merged. Should we create RC2 with that fix since the voting period only starts on Monday? I think it would only mean rerunning the scripts on your side, right? – Ufuk On Fri, Mar 24, 201

Re: [VOTE] Release Apache Flink 1.2.1 (RC1)

I agree with Aljoscha. -1 because of FLINK-6188 On Sat, Mar 25, 2017 at 9:38 AM, Aljoscha Krettek wrote: > I filed this issue, which was observed by a user: > https://issues.apache.org/jira/browse/FLINK-6188 > > I think that’s blocking for 1.2.1. > >> On 24 Mar 2017,

Re: [VOTE] Release Apache Flink 1.2.1 (RC1)

houghts on this? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On

Re: [VOTE] Adopt jemalloc as default memory allocator in docker image

+1 (binding) Thanks Yun for debugging and running the benchmarks. – Ufuk On Fri, Nov 6, 2020 at 3:49 PM Fabian Paul wrote: > +1 (non-binding) > > Thanks, Yun for the efforts to bring this topic to a vote. > > Best, > Fabian >

Re: [DISCUSS] FLIP-157 Migrate Flink Documentation from Jekyll to Hugo

+1 to do this. I really like what you have build and the advantages to Jekyll seem overwhelming to me. Hugo is very flexible and I've seen a few other projects use it successfully for docs. On Wed, Jan 13, 2021, at 5:14 PM, Seth Wiesman wrote: > Hi All, > > I would like to start a discussion fo

Re: [VOTE] Release Apache Flink 0.8.0 (RC1)

Marton, could you also cherry-pick 7f659f6 and 7e08fa1 for the next RC? It's a minor update to the README describing the IDE setup. I will closed the respective issue FLINK-1109. On 08 Jan 2015, at 23:50, Henry Saputra wrote: > Marton, could you close this VOTE thread by replying to the origin

Re: December in Flink

On 09 Jan 2015, at 15:12, Max Michels wrote: > I think it would be good to have an additional mailing list for news. > For open source projects, it's pretty common to have an announce > mailing list. In addition to the monthly newsletter we could also > announce releases. +1 I think this is a go

Re: [VOTE] Release Apache Flink 0.8.0 (RC1)

gt;> Scala API. >>>>>>>> >>>>>>>> It is also an isolated change that does not affect other >>>> components, >>>>> so >>>>>>> it >>>>>>>> should be testable very well. >>>&g

Re: [VOTE] Release Apache Flink 0.8.0 (RC1)

On Mon, Jan 12, 2015 at 11:22 AM, Stephan Ewen wrote: > It would be good to have the patch, but it is also a very tricky patch, so > pushing it hastily may be problematic. > I agree. @Till: would that be OK with you? If yes, I think we are good to go for the next RC.

Re: Gather a distributed dataset

Hey Alexander, On 12 Jan 2015, at 11:42, Alexander Alexandrov wrote: > Hi there, > > I wished for intermediate datasets, and Santa Ufuk made my wishes come true > (thank you, Santa)! > > Now that FLINK-986 is in the mainline, I want to ask some practical > questions. > > In Spark, there is a

Re: Gather a distributed dataset

On 13 Jan 2015, at 16:50, Stephan Ewen wrote: > Hi! > > To follow up on what Ufuk explaned: > > - Ufuk is right, the problem is not getting the data set. > https://github.com/apache/flink/pull/210 does that for anything that is not > too gigantic, which is a good start. I think we should merge

Re: flink git commit: [FLINK-1183] Generate gentle notification message when Flink is started with Java 6

pache.org/repos/asf/flink/commit/22fdf766 > > Tree: http://git-wip-us.apache.org/repos/asf/flink/tree/22fdf766 > > Diff: http://git-wip-us.apache.org/repos/asf/flink/diff/22fdf766 > > > > Branch: refs/heads/mastaer > > Commit: 22fdf76682b69a27de87a221dc47466484a0

Re: API behavior with data sinks (lazy) and eager operations

I think this question depends on how much both subgraphs overlap? But in general, I agree that the first approach seems more desirable from the runtime view (multiple consumers at the branch point). On Mon, Jan 19, 2015 at 10:59 AM, Robert Metzger wrote: > I would also execute the sinks immediat

Re: Handling custom types with Kryo

On 20 Jan 2015, at 11:51, Alexander Alexandrov wrote: > +1 for program analysis from me too... > > Should be doable also on a lower level (e.g. analysis of compiled *.class > files) with some off-the-shelf libraries, right? Yes. There was a prototypical implementation using byte code analysis

Re: Master not building and how to notice it faster in the future

On 20 Jan 2015, at 23:57, Robert Metzger wrote: > There are certainly ways to fix this. Right now, the best approach is > probably setting up a REST 2 e-mail service somewhere which is mailing to > our dev@ list ( > http://docs.travis-ci.com/user/notifications/#Webhook-notification). That sound

Re: Master not building and how to notice it faster in the future

On 21 Jan 2015, at 00:19, Robert Metzger wrote: > I think its just a missing import. Yes. > Maybe we can use Google AppEngine for that. It seems that their free > offering is sufficient for our purpose: > https://cloud.google.com/pricing/#app-engine. It also allows sending emails. > I guess it

Re: Master not building and how to notice it faster in the future

On 21 Jan 2015, at 10:40, Till Rohrmann wrote: > I like both approaches because maven won't necessarily find all problems if > executed locally. Especially concurrency problems seem to occur more often > on travis than on my local machine. I agree with Till. Let's add a git hook to catch most o

Re: Master not building and how to notice it faster in the future

On 21 Jan 2015, at 11:40, Robert Metzger wrote: > Is the git hook something we can control for everybody? I thought its more > like a personal thing everybody can set up if wanted? > > I'm against enforcing something like this for every committer. I don't want > to wait for 15 minutes for pushi

Re: Master not building and how to notice it faster in the future

y resides in your local repository. It >> cannot be pushed. Thus, we cannot enforce this check but it certainly >> helps to prevent mistakes. As Ufuk mentioned, you can then even skip >> the check with the --no-verify option if you're really sure. >> >> On We

Re: Turn lazy operator execution off for streaming jobs

Hey Gyula, On 21 Jan 2015, at 15:41, Gyula Fóra wrote: > Hey Guys, > > I think it would make sense to turn lazy operator execution off for > streaming programs because it would make life simpler for windowing. I > also created a JIRA issue here >

Re: Implementing a list accumulator

I just checked out your branch and ran it with a break point set at the CollectHelper. If you look into the (list) accumulator you see that always the same object is added to it. Strangely enough, object re-use is disabled in the config. I don't have time to look further into it now, but it seem

Re: Implementing a list accumulator

it becomes problematic. On 21 Jan 2015, at 17:12, Ufuk Celebi wrote: > I just checked out your branch and ran it with a break point set at the > CollectHelper. If you look into the (list) accumulator you see that always > the same object is added to it. Strangely enough, object re-use is disabl

Re: Turn lazy operator execution off for streaming jobs

On 22 Jan 2015, at 11:37, Till Rohrmann wrote: > I'm not sure whether it is currently possible to schedule first the > receiver and then the sender. Recently, I had to fix the > TaskManagerTest.testRunWithForwardChannel test case where this was exactly > the case. Due to first scheduling the rece

Re: Turn lazy operator execution off for streaming jobs

On 22 Jan 2015, at 18:10, Stephan Ewen wrote: > So the crux is that the JobManager has a location for the sender task (and > tell that to the receivers) before the senders have registered their > transfer queues. > > Can we just establish a "happens-before" there? > - The TaskManager may send th

Re: YARN ITCases fail, master broken?

What's the state of this? I got an error, which I didn't see before: https://s3.amazonaws.com/archive.travis-ci.org/jobs/49194479/log.txt On 27 Jan 2015, at 13:35, Fabian Hueske wrote: > Robert, thanks for fixing the MacOS build! > > Building on my Ubuntu VM is still failing though. Will send

Task manager memory configuration with intermediate results

Currently, the memory configuration of a task manager encompasses two things: 1) NETWORK buffers: Fixed amount of memory for the network buffer pool (default: 2048 buffers, each 32 KB => 64 MB) 2) OPERATOR buffers: A configurable fraction of the available heap memory (default 0.7) for the memor

Re: [jira] [Created] (FLINK-1462) Add documentation guide for the graph API

I think it is GitHub flavored markdown. GH has a reference with the additions. On Wednesday, February 4, 2015, Vasia Kalavri (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/FLINK-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306036#

Re: Cluster execution - Jobmanager unreachable

Hey Chesnay, I will look into it. Can you share the complete LOGs? – Ufuk On 04 Feb 2015, at 14:49, Chesnay Schepler wrote: > Hello, > > I'm trying to run python jobs with the latest master on a cluster and get the > following exception: > > Error: The program execution failed: JobManager

Re: Events not received

On 09 Feb 2015, at 15:06, Hermann Gábor wrote: > Hi all, > > We've been trying to use events for two-way communication, but it seems > like some of the backward events (at a BufferReader) are not sent at all if > the connection is not initialized yet (i.e. the given input channel is > UNKNOWN).

Re: Events not received

Hey Gabor, can you try this branch: https://github.com/uce/incubator-flink/tree/flink-1496-lost Is this working for you? This is a quick fix. It keeps track of events, which could not be delivered to uninitialized channels and delivers them after they are initialized. (The BufferReader, which

Re: Events not received

On 10 Feb 2015, at 02:13, Hermann Gábor wrote: > Hey Ufuk, > > Thanks for the fast reply and fix! It's working now :) > > Unfortunately the "other side" of the AbstractInvokable lifecycle is > causing a bit of a trouble, > as the AbstractInvokable does not wait for possible events before > fin

Re: Cluster execution - Jobmanager unreachable

tionResult after having send the ScheduleOrUpdateConsumers >> message. This can either mean that something went wrong in >> ExecutionGraph.scheduleOrUpdateConsumers method or the connection was >> disassociated for some reasons. The logs would indeed be very helpful to >> understand wha

Re: [VOTE] Release Apache Flink 0.8.1 (RC0)

There is a problem with a change added yesterday to master and release-0.8. See here: https://github.com/apache/flink/pull/376 On 11 Feb 2015, at 01:10, Felix Neutatz wrote: > +1 > > + Built from source > + tested some Protobuf examples > + tested some Parquet examples > > Best regards, > Fel

Re: [VOTE] Release Apache Flink 0.8.1 (RC0)

-1 The problem I've mentioned occurs for every shutdown of the job/taskmanagers using the scripts (bin/stop-cluster.sh) and results in an exception at the end of the log files. On 11 Feb 2015, at 10:59, Ufuk Celebi wrote: > There is a problem with a change added yesterday to ma

Re: [DISCUSS] Distributed TPC-H DataGenerator for flink-contrib

Nice, this is a great tool. :) On 09 Feb 2015, at 17:05, Robert Metzger wrote: > However, the website is not really helpful: http://www.tpc.org/trademarks/ > > As one data point, the Apache Calcite (incubating) project also depends on > the mentioned airlift/tpch repository: > https://github.co

Re: Gelly is in!

Superb. :-) On 11 Feb 2015, at 15:00, Kostas Tzoumas wrote: > Nice!!! Welcome Gelly! > > On Wed, Feb 11, 2015 at 1:05 PM, Hermann Gábor wrote: > >> Cool! Congrats! :) >> >> On Wed Feb 11 2015 at 12:45:17 Max Michels wrote: >> >>> Great contribution! Thanks to everyone who made it possible.

Re: Master not building and how to notice it faster in the future

I just found out that we can simply activate email notifications for build failures. Can we allow bu...@travis-ci.org to send to dev@f.a.o? On Wed, Jan 21, 2015 at 9:41 PM, Robert Metzger wrote: > I'm actually quite happy with the travis setup. Since most of the > contributors/committers have t

Re: Getting fail test at BlobUtilsTest.testExceptionOnCreateStorageDirectoryFailure from master

Hey Henry, On 13 Feb 2015, at 01:47, Henry Saputra wrote: > BlobUtilsTest.testExceptionOnCreateStorageDirectoryFailure Expected > exception: java.lang.Exception > > > Anyone else seen this error before? Nope. The test tries to create the root directory "/cannot-create-this", which should no

Re: [VOTE] Accept Flink CDC into Apache Flink

+1 (binding) – Ufuk On Mon, Jan 15, 2024, at 12:38 PM, Congxian Qiu wrote: > +1 (non-binding) > > Best, > Congxian > > > Gyula Fóra 于2024年1月15日周一 15:37写道： > > > +1 (binding) > > > > On Sun, Jan 14, 2024 at 9:01 AM Yun Tang wrote: > > > > > +1 (non-binding) > > > > > > On 2024/01/14 02:26:13

Re: [DISCUSS] Planning Flink 1.20

Hey all, I'd like to join the release managers for 1.20 as well. I'm looking forward to getting more actively involved again. Cheers, Ufuk On Sun, Mar 24, 2024, at 11:27 AM, Ahmed Hamdy wrote: > +1 for the proposed timeline and release managers. > Best Regards > Ahmed Hamdy > > > On Fri, 22

Re: Flink Kubernetes Operator 1.9.0 release planning

+1 to release 1.9.0 > On 12. Jun 2024, at 17:10, Peter Huang wrote: > > +1 Thanks Gyula for driving this release! > > > Best Regards > Peter Huang > > On Tue, Jun 11, 2024 at 12:28 PM Márton Balassi > wrote: > >> +1 for cutting the release and Gyula as the release manager. >> >> On Tue, Ju

Re: [DISCUSS] Proposing an LTS Release for the 1.x Line

Hi folks! 1) Big +1 on being strict with limiting the LTS version to patches and no feature backports. I think that it would open up a big can of worms. What does it even mean to backport a feature to a LTS version? My understanding is that we want to designate a single 1.x version as LTS. But

Re: [DISCUSS] Flink configuration from environment variables

Hey all, I think that approach 2 is more idiomatic for container deployments where it can be cumbersome to manually map flink-conf.yaml contents to env vars [1]. The precedence order outlined by Till would also cover Steven's hierarchical overwrite requirement. I'm really excited about this fe

Re: [ANNOUNCE] Welcome Guowei Ma as a new Apache Flink Committer

Congrats and welcome! :-) On Wed, Jan 20, 2021, at 9:57 AM, Cranmer, Danny wrote: > Congratulations Guowei!! > > On 20/01/2021, 05:35, "Kurt Young" wrote: > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm t

Re: [DISCUSS] FLIP-161: Configuration through environment variables

Thanks for starting the discussion, Ingo! Regarding approach 1: I like the idea of having a mapping scheme from ConfigOption to env var(s), but I'm concerned about the implications of lazy eval. I think it would be preferable to keep the Configuration object as the source of truth, requiring u

Re: [DISCUSS] FLIP-161: Configuration through environment variables

LGTM. Let's see what the others think... On Thu, Jan 21, 2021, at 11:37 AM, Ingo Bürk wrote: > Regarding env.java.opts, what special handling is needed there? AFAICT only > the rejected alternative of substituting values would've had an effect on > this. Makes sense 👍 >From the FLIP: > This mapp

Re: [DISCUSS] FLIP-161: Configuration through environment variables

es, in that they allow config options to > > > >> be set on the command-line? > > > >> > > > >> What use-case do they currently not support? > > > >> I assume it's something along the lines of setting some envir

Re: [DISCUSS] FLIP-161: Configuration through environment variables

I'm including Steven and Yang into this discussion (cc'd) who raised some good points in the initial DISCUSS thread. Do you have any opinion on the current discussion here? On Tue, Jan 26, 2021, at 10:59 AM, Ufuk Celebi wrote: > Chesnay, thanks for bringing this up. I think it

Re: [DISCUSS] FLIP-161: Configuration through environment variables

@Xingtong: The assumption for the mapping was that we only have dots and hyphens in the keys. Do you have an example for a key which include underscores? If underscores are common for keys (I couldn't find any existing options that use it), it would certainly be a blocker for the discussed appr

Re: [DISCUSS] Removal of flink-swift-fs-hadoop module

+1 On Wed, Jan 27, 2021, at 11:02 AM, Dawid Wysakowicz wrote: > +1 > > On 27/01/2021 11:00, Chesnay Schepler wrote: > > +1 > > > > While I don't think the filesystem is really useless, in it's current > > state it is not maintainable, and so far no one rose up to remedy this. > > > > On 1/27/2021

Re: [DISCUSS] FLIP-161: Configuration through environment variables

amic > >> > >>>>> properties/flink-conf.yaml . For the use-cases that people seems > >> to > >> > be > >> > >>>>> concerned about (where you have lots of variables) I would think > >> that > >> > >>&

Re: [DISCUSS] Adding support for Hadoop 3 and removing flink-shaded-hadoop

Hey Robert and others, overall +1 to support Hadoop 3. It would be a great to unblock Flink support in EMR 6.0 as noted in the linked FLINK ticket. The arguments raised against flink-shaded-hadoop make sense to me. I have a few general questions still: 1) Will the flink-shaded-hadoop module (in

Re: [VOTE] Release 1.10.1, release candidate #3

+1 (binding) - checked release notes - verified sums and hashes - reviewed website PR - successfully built an internal Flink distribution based on the 1.10.1-rc3 commit - successfully built internal jobs against the staging repo and deployed those jobs to a 1.10.1 job cluster on Kubernetes and tes

Re: [Discuss] Breaking API Change in 1.10.1

Thanks for the analysis Till. 1/ I think breaking binary compatibility is acceptable between minor releases (1.10 -> 1.11) as you suggested since the API is marked as @PublicEvolving. 2/ I'm quite torn about how to proceed with the 1.10.x patch release, but slightly leaning towards the "pragmatic

Re: [VOTE] Guarantee that @PublicEvolving classes are API and binary compatible across bug fix releases (x.y.u and x.y.v)

+1 – Ufuk On Fri, May 15, 2020 at 4:54 PM Zhijiang wrote: > Sounds good, +1. > > Best, > Zhijiang > > > -- > From:Thomas Weise > Send Time:2020年5月15日(星期五) 21:33 > To:dev > Subject:Re: [VOTE] Guarantee that @PublicEvolving classe

Re: Shall we avoid binding "unsafe ports" during random port selection?

I agree with Till. I think this should be a concern of the user configuring the port range. – Ufuk On Mon, May 25, 2020 at 10:27 AM Till Rohrmann wrote: > Hi Weike, > > would it be good enough if the user did not include unsafe ranges when > specifying `rest.bind-port`? My concern with excludi

Re: [DISCUSS] (Document) Backwards Compatibility of Savepoints

I agree with Konstantin and Steven that it makes sense to point this out explicitly. I think that the following would be helpful: 1/ Mention breaking compatibility in release notes 2/ Update the linked table to reflect compatibilities while pointing out what the community commits to maintain goi

Re: [ANNOUNCE] Yu Li is now part of the Flink PMC

Congrats! :-) – Ufuk On Thu, Jun 18, 2020 at 9:47 AM Marta Paes Moreira wrote: > Awesome! Congratulations, Yu! > > On Thu, Jun 18, 2020 at 9:16 AM Zhu Zhu wrote: > > > Congratulations! > > > > Thanks, > > Zhu Zhu > > > > Guowei Ma 于2020年6月18日周四 上午10:41写道： > > > > > Congratulations , Yu! > >

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

+1 (binding) - checked release notes ✅ - verified signatures and checksums ✅ - reviewed website PR ✅ - built an internal Flink distribution from source ✅ - built internal jobs against the staging repo ✅ - deployed a job cluster on Kubernetes and tested checkpointing ✅ - tested fix for FLINK-18902

Re: Splitting input stream in to multiple windows and process individually

Hey! I think this question is better suited for the user mailing list. Your solution should work, but will require a lot of memory if you can't use an incrementally aggregating window (e.g. fold/reduce/etc.). – Ufuk On Thu, Apr 13, 2017 at 7:39 AM, madhairsilence wrote: > I have a Datastream . I

Re: [VOTE] Release Apache Flink 1.2.1 (RC2)

I agree with Till and would NOT cancel this release. It has been delayed already quite a bit already and the feature freeze for 1.3.0 is coming up (i.e. most contributors will be busy and not spend a lot of time for 1.2.1). – Ufuk On Mon, Apr 24, 2017 at 9:31 AM, Till Rohrmann wrote: > If this

[DISCUSS] Feature Freeze

Hey devs! :-) We decided to follow a time-based release model with the upcoming 1.3 release and the planned feature freeze is on Monday, May 1st. I wanted to start a discussion to get a quick overview of the current state of things. - Is everyone on track and aware of the feature freeze? ;) - Ar

Re: [DISCUSS] What is a "Blocker" in our JIRA?

Thanks for this discussion Robert. I agree with your points. +1 Regarding the documentation: I also agree with Kostas and others that it is very important to have good documentation in place. The good thing about our current doc deployment model is that we can update the docs for a released versio

Re: [DISCUSS] What is a "Blocker" in our JIRA?

On Fri, May 5, 2017 at 2:24 PM, Greg Hogan wrote: > -1 to post-hoc documentation and unreleased publication [0] Could you quickly confirm that I understand this correctly: - Post-hoc documentation means not documenting features separately from their initial PRs? - Unreleased publication means *no

Re: [DISCUSS] Feature Freeze

On Fri, May 5, 2017 at 3:59 PM, Stephan Ewen wrote: > Also, if no release candidate would be created today, it would not make any > difference anyways... If no one tests a RC (if created today) over the weekend it also wouldn't make a difference. ;-) Thanks to all for chiming in here and Robert

Re: [DISCUSS] Changing Flink's shading model

The advantages you've listed sound really compelling to me. - Do you have time to implement these changes or do we need a volunteer? ;) - I assume that republishing the artifacts as you propose doesn't have any new legal implications since we already publish them with our JARs, right? - We might

Re: [DISCUSS] Changing Flink's shading model

On Thu, May 11, 2017 at 10:59 AM, Till Rohrmann wrote: > Have we somewhere documented how to publish > artifacts on Maven central? Pulling in Robert who published frocks. @Robert: Would you like to volunteer for this? Would really help to combine this with some docs about publishing Maven artefac

Re: [DISCUSS] Reorganize Table API / SQL documentation

On Thu, May 18, 2017 at 1:52 PM, Till Rohrmann wrote: > I think we have a history of creating too long monolithic documentation > pages which are hard to digest. So a big +1 for splitting the Table API/SQL > documentation up into more easily digestible pieces. +1 Thanks for bringing it up

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

I agree with Robert that this could be fixed in a bugfix release, but I really don't like immediately starting a new 1.3.1 vote a day after the 1.3.0 vote ends. I think it potentially gives a bad/sloppy impression to our users. Therefore, I lean towards cancelling this RC and creating a new one wi

Re: [DISCUSS] GitBox

I would also like to see this happening for both flink-web and flink if it allows committers to have control over the respective repos. On Sat, Jun 10, 2017 at 4:05 PM, Chesnay Schepler wrote: > What are the downsides of this? Actually, is there any ASF resource that > outlines what this would en

Re: [DISCUSS] FLIP-21 - Improve object Copying/Reuse Mode for Streaming Runtime

Thanks for the write up and illustrations. :-) +1 to do this. I'm fine with both proposed "changed behaviour" variants, but lean towards option 1: change the default, make the change explicit in the release notes and add a good docs page about configuring object reuse (ideally re-using your illust

Re: [DISCUSS] A more thorough Pull Request check list and template

I really like this and vote to change our current template. The simple yes/no/... options are a really good idea. I would add to your email that the questions will equally help reviewers to remember to look at these things, which is just as important. When we merge this, we should make sure to st

Re: [DISCUSS] A more thorough Pull Request check list and template

On Tue, Jul 18, 2017 at 10:47 AM, Fabian Hueske wrote: > For example even if the question about changed dependencies is answered > with "no", the reviewer still has to check that. But having it as a required option/text in the PR descriptions helps reviewers to actually remember to check that. I

Re: [DISCUSS] A more thorough Pull Request check list and template

On Tue, Jul 18, 2017 at 11:03 PM, Chesnay Schepler wrote: > I'm sorry but i can't follow your logic. I understand where you're coming from Chesnay, but I agree with Stephan that a link is easier to ignore than a text. I think Stephan gave good pointers to why he thinks that people don't read the

Re: [DISCUSS] A more thorough Pull Request check list and template

an the current one and >>>>>> >>>>> only >>>> >>>>> have the link, the sections to fill out, and checkboxes. >>>>>> >>>>>> I'm also not sure how much the detailed questions will help. >&g

Re: [DISCUSS] A more thorough Pull Request check list and template

gt; > > On 24.07.2017 18:52, Ufuk Celebi wrote: >> >> What's the conclusion of last weeks discussion here? >> >> Fabian and Chesnay raised concerns about the introductory text. Are >> you still concerned? >> >> On Wed, Jul 19, 2017 at 10

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