Re: [DISCUSS] [Contributing] (2) - Review Steps
Thanks for start the discussion Stephan! (1) Do we agree on the five basic steps below?* +1 to the five steps and making the third question in the proposal the first. (2) How do we understand that consensus is reached about adding the feature? +1 to lazy consensus with one committer's +1 (3) To answer the question whether a PR needs special attention Contributor can ask for special attention, which is treated as a suggestion. Committer can ask for another committers' attention, either for advice or transfer the right of decision. IMO it is quite help to add a page about "component experts", attach or link it from README. This would be a really helpful information to new contributors so that they know to whom he can cc or ask for advice. Besides it would be helpful for those who want to know more about the mechanism underneath Flink, now they know with whom they can consult. Best, tison.
Re: [DISCUSS] [Contributing] (2) - Review Steps
Hi Fabian, You convinced me. I miss the advantage we can take from mailing lists. Now I am of the same opinion. Best, tison. Fabian Hueske 于2018年9月25日周二 下午3:01写道： > Hi, > > I think questions about Flink should be posted on the public mailing lists > instead of asking just a single expert. > > There's many reasons for that: > * usually more than one person can answer the question (what if the expert > is not available?) > * non-committers can join the discussion and contribute to the community > (how can they become experts otherwise?) > * the knowledge is shared on the mailing list (helps in cases when only one > person can answer the question) > > Last but not least, my concern is that committers for popular contribution > areas would be flooded with requests. > Even without being listed as a "component expert", I cannot handle all > review requests directed at me. > I work on issues (PR reviews, my contributions, discussions) that I deem > important and being constantly pinged does not really help to speed things > up. > There are of course cases when it is important to be notified, but IMO > chances that those get the right attention decrease with the number of > requests. > > Best, Fabian > > > > > Am Di., 25. Sep. 2018 um 04:10 Uhr schrieb Tzu-Li Chen < > wander4...@gmail.com > >: > > > Thanks for start the discussion Stephan! > > > > (1) Do we agree on the five basic steps below?* > > +1 to the five steps and making the third question in the proposal the > > first. > > > > (2) How do we understand that consensus is reached about adding the > > feature? > > +1 to lazy consensus with one committer's +1 > > > > (3) To answer the question whether a PR needs special attention > > > > Contributor can ask for special attention, which is treated as a > > suggestion. > > Committer can ask for another committers' attention, either for advice or > > transfer > > the right of decision. > > > > IMO it is quite help to add a page about "component experts", attach or > > link it > > from README. This would be a really helpful information to new > contributors > > so that they know to whom he can cc or ask for advice. Besides it would > > be helpful for those who want to know more about the mechanism underneath > > Flink, now they know with whom they can consult. > > > > Best, > > tison. > > >
Re: [DISCUSS] [Contributing] (2) - Review Steps
I agree with Chesnay that we don't guarantee (quick) review of a PR at the project level. As ASF statement[1]: > Please show some patience with the developers if your patch is not applied as fast as you'd like or a developer asks you to make changes to the patch. If you do not receive any feedback in a reasonable amount of time (say a week or two), feel free to send a follow-up e-mail to the developer list. Open Source developers are all volunteers, often doing the development in their spare time. However, an open source community shows its friendliness to contributors. Thus contributors believe their contribution would be take care of, even be rejected with a reason; project members are thought kind to provide help to the process. Just like this thread kicked off, it is glad to see that Flink community try best to help its contributors and committers, then take advantage of "open source". Best, tison. [1] http://www.apache.org/dev/contributors#patches Chesnay Schepler 于2018年9月25日周二 下午11:21写道： > There is no guarantee that a PR will be looked at nor is it possible to > provide this in any way on the project level. > > As far as Apache is concerned all contributors/committers etc. work > voluntarily, and > as such assigning work (which includes ownership if it implies such) or > similar is simply not feasible. > > On 25.09.2018 16:54, Thomas Weise wrote: > > I think that all discussion/coordination related to a contribution / PR > > should be handled through the official project channel. > > > > I would also prefer that there are no designated "owners" and "experts", > > for the reasons Fabian mentioned. > > > > Ideally there is no need to have "suggested reviewers" either, but then > > what will be the process to ensure that PRs will be looked at? > > > > Thanks, > > Thomas > > > > > > > > On Tue, Sep 25, 2018 at 6:17 AM Tzu-Li Chen > wrote: > > > >> Hi Fabian, > >> > >> You convinced me. I miss the advantage we can take from mailing lists. > >> > >> Now I am of the same opinion. > >> > >> Best, > >> tison. > >> > >> > >> Fabian Hueske 于2018年9月25日周二 下午3:01写道： > >> > >>> Hi, > >>> > >>> I think questions about Flink should be posted on the public mailing > >> lists > >>> instead of asking just a single expert. > >>> > >>> There's many reasons for that: > >>> * usually more than one person can answer the question (what if the > >> expert > >>> is not available?) > >>> * non-committers can join the discussion and contribute to the > community > >>> (how can they become experts otherwise?) > >>> * the knowledge is shared on the mailing list (helps in cases when only > >> one > >>> person can answer the question) > >>> > >>> Last but not least, my concern is that committers for popular > >> contribution > >>> areas would be flooded with requests. > >>> Even without being listed as a "component expert", I cannot handle all > >>> review requests directed at me. > >>> I work on issues (PR reviews, my contributions, discussions) that I > deem > >>> important and being constantly pinged does not really help to speed > >> things > >>> up. > >>> There are of course cases when it is important to be notified, but IMO > >>> chances that those get the right attention decrease with the number of > >>> requests. > >>> > >>> Best, Fabian > >>> > >>> > >>> > >>> > >>> Am Di., 25. Sep. 2018 um 04:10 Uhr schrieb Tzu-Li Chen < > >>> wander4...@gmail.com > >>>> : > >>>> Thanks for start the discussion Stephan! > >>>> > >>>> (1) Do we agree on the five basic steps below?* > >>>> +1 to the five steps and making the third question in the proposal the > >>>> first. > >>>> > >>>> (2) How do we understand that consensus is reached about adding the > >>>> feature? > >>>> +1 to lazy consensus with one committer's +1 > >>>> > >>>> (3) To answer the question whether a PR needs special attention > >>>> > >>>> Contributor can ask for special attention, which is treated as a > >>>> suggestion. > >>>> Committer can ask for another committers' attention, either for advice > >> or > >>>> transfer > >>>> the right of decision. > >>>> > >>>> IMO it is quite help to add a page about "component experts", attach > or > >>>> link it > >>>> from README. This would be a really helpful information to new > >>> contributors > >>>> so that they know to whom he can cc or ask for advice. Besides it > would > >>>> be helpful for those who want to know more about the mechanism > >> underneath > >>>> Flink, now they know with whom they can consult. > >>>> > >>>> Best, > >>>> tison. > >>>> > >
Re: [DISCUSS] Dropping flink-storm?
+1 to drop it. It seems few people use it. Commits history of an experimental module sparse often means that there is low interest. Best, tison. 远远 于2018年9月29日周六 下午2:16写道： > +1， it‘s time to drop it😂 > > Zhijiang(wangzhijiang999) 于2018年9月29日周六 > 下午1:53写道： > >> Very agree with to drop it. +1 >> >> -- >> 发件人：Jeff Carter >> 发送时间：2018年9月29日(星期六) 10:18 >> 收件人：dev >> 抄 送：chesnay ; Till Rohrmann ; >> user >> 主 题：Re: [DISCUSS] Dropping flink-storm? >> >> +1 to drop it. >> >> On Fri, Sep 28, 2018, 7:25 PM Hequn Cheng wrote: >> >> > Hi, >> > >> > +1 to drop it. It seems that few people use it. >> > >> > Best, Hequn >> > >> > On Fri, Sep 28, 2018 at 10:22 PM Chesnay Schepler >> > wrote: >> > >> > > I'm very much in favor of dropping it. >> > > >> > > Flink has been continually growing in terms of features, and IMO we've >> > > reached the point where we should cull some of the more obscure ones. >> >> > > flink-storm, while interesting from a theoretical standpoint, offers too >> > > little value. >> > > >> >> > > Note that the bolt/spout wrapper parts of the part are still compatible, >> > > it's only topologies that aren't working. >> > > >> > > IMO compatibility layers only add value if they ease the migration to >> > > Flink APIs. >> >> > > * bolt/spout wrappers do this, but they will continue to work even if we >> > > drop it >> > > * topologies don't do this, so I'm not interested in then. >> > > >> > > On 28.09.2018 15:22, Till Rohrmann wrote: >> > > > Hi everyone, >> > > > >> > > > I would like to discuss how to proceed with Flink's storm >> > > > compatibility layer flink-strom. >> > > > >> > > > While working on removing Flink's legacy mode, I noticed that some >> >> > > > parts of flink-storm rely on the legacy Flink client. In fact, at the >> >> > > > moment flink-storm does not work together with Flink's new distributed >> > > > architecture. >> > > > >> > > > I'm also wondering how many people are actually using Flink's Storm >> > > > compatibility layer and whether it would be worth porting it. >> > > > >> > > > I see two options how to proceed: >> > > > >> > > > 1) Commit to maintain flink-storm and port it to Flink's new >> > architecture >> > > > 2) Drop flink-storm >> > > > >> >> > > > I doubt that we can contribute it to Apache Bahir [1], because once we >> >> > > > remove the legacy mode, this module will no longer work with all newer >> > > > Flink versions. >> > > > >> >> > > > Therefore, I would like to hear your opinion on this and in particular >> > > > if you are using or planning to use flink-storm in the future. >> > > > >> > > > [1] https://github.com/apache/bahir-flink >> > > > >> > > > Cheers, >> > > > Till >> > > >> > > >> > > >> > >> >> >>
Re: Request for contributor permission
Hi Gao, Welcome to Flink community! cc Till and Stephan for you. Best, tison. yungao.gy 于2018年10月1日周一 下午1:42写道： > > Hi all, > > I want to start contributing to Flink with FLINK-10469. Could someone > grant me the contributor permission? My Jira ID is gaoyunhaii and my full > name is Yun Gao. Thanks a lot ! :) > > > Yours sincerely > Yun Gao
Re: Request for contributor permission
@ches...@apache.org OK, I get it. Best, tison. Yun Gao 于2018年10月1日周一 下午5:15写道： > Thanks a lot ! @Chesnay Schepler@Tzu-Li Chen : ) > > > Yours > Yun Gao > > -- > 发件人：Chesnay Schepler > 发送时间：2018年10月1日(星期一) 17:10 > 收件人：dev ; Tzu-Li Chen ; > yungao.gy ; trohrmann ; > Stephan Ewen > 主 题：Re: Request for contributor permission > > @Yun Gao: You now have contributor permission. > > @Tzu-Li Chen: Please don't ping specific people for these kind of mails > as plenty of other people can resolve them. > > On 01.10.2018 08:27, Tzu-Li Chen wrote: > > Hi Gao, > > > > Welcome to Flink community! cc Till and Stephan for you. > > > > Best, > > tison. > > > > > > yungao.gy 于2018年10月1日周一 下午1:42写道： > > > >> Hi all, > >> > >> I want to start contributing to Flink with FLINK-10469. Could someone > > >> grant me the contributor permission? My Jira ID is gaoyunhaii and my full > >> name is Yun Gao. Thanks a lot ! :) > >> > >> > >> Yours sincerely > >>Yun Gao > >
Re: [DISCUSS] Move hadoop 2.4 test profiles to cron jobs
+1, sounds good to cut down travis burden. Best, tison. Fabian Hueske 于2018年10月2日周二 下午9:02写道： > +1 > > Am Di., 2. Okt. 2018 um 14:50 Uhr schrieb Till Rohrmann < > trohrm...@apache.org>: > > > Great idea Chesnay. +1 for running Hadoop 2.4 in a cron job. This will > help > > us to cut down our Travis time by almost 2. > > > > Cheers, > > Till > > > > On Tue, Oct 2, 2018 at 1:49 PM Chesnay Schepler > > wrote: > > > > > Hello, > > > > > > As part of FLINK-10453 I would like to move the travis profiles that > run > > > against hadoop 2.4 into a cron job. The cron job would be organized as > a > > > eparate branch in the apache/flink repository that would be run daily. > > > > > > My reasoning is that most changes made to Flink aren't actually related > > > to hadoop, so we're running twice the amount of tests than required. > > > > > > This would be in line with FLINK-8745, which aims to reduce our travis > > > usage. > > > > > > Regards, > > > > > > Chesnay > > > > > > > > >
Re: Flink Low level APIs How To’s
Hi Ramesh, Apart from Till recommended, internal classes go with document around the source code define them, and for the "practices" part, maybe you can take a look at their tests. But after all, these are all about Flink dev topics and so unstable to be used in production codes. Best, tison. Till Rohrmann 于2018年10月2日周二 下午9:51写道： > Hi Ramesh, > > the JobGraph, JobVertex, JobGraphGenerator, etc. are all internal classes > for which the community does not give any stability guarantees. Thus, they > can change from one version to another breaking all your programs. > Therefore, I would not recommend using these primitives if you are not > willing to resolve potential version upgrade problems. > > Apart from that, there is only little documentation for these components. > The best documentation is actually the code. > > Cheers, > Till > > On Tue, Oct 2, 2018 at 3:21 PM Ramesh Byndoor > wrote: > > > Team, > > > > would like to create jobs from DAG's with details which is maintained > > externally(Filters, transform and Stream SQL). Idea is to create JobGraph > > and submit to Flink. I have started looking into JobGraph, Job, Vertex, > > JobGenerator from flink low level API's, Looks promising but is there any > > guidelines documented or any better practices for the same. Are these > used > > by any in the community.? > > >
Re: Future of JobManager.scala
Hi Sun, JobManager.scala is component of legacy mode, they would be removed as a sub task of FLINK-10392[1]. For the evolution from "legacy mode" to FLIP-6 new mode, see also [2]. For short, the previous JobManager is split mainly into JobMaster and Dispatcher. [1] https://issues.apache.org/jira/browse/FLINK-10392 [2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65147077 Best, tison. Jin Sun 于2018年10月4日周四 上午8:06写道： > Hi Team, > > > > What is the future of JobManager in > org/apache/flink/runtime/jobmanager/JobManager.scala? > > > > I noticed that there are some duplicate logic between JobManager.scala and > JobMaster/Dispatcher, that somehow confuse me, and I also saw > LegacyYarnClusterDescriptor.java depends on JobManager.scala, this sounds > like JobManager.scale will deprecated, what is the future of > JobManager.scala? > > > > Jin > >
Re: [DISCUSS] [Contributing] (2) - Review Steps
+1 Jin Sun 于2018年10月9日周二 上午2:10写道： > +1, look forward to see the change. > > > On Oct 9, 2018, at 12:07 AM, Fabian Hueske wrote: > > > > Hi everyone, > > > > Since we have addressed all comments (please raise your voice if not!), I > > would like to move forward and convert the proposal [1] into a page for > > Flink's website [2]. > > I will create a pull request against the website repo [3]. > > > > Once the page got merged, we can start posting the review form on new > pull > > requests. > > > > Best, Fabian > > > > [1] > > > https://docs.google.com/document/d/1yaX2b9LNh-6LxrAmE23U3D2cRbocGlGKCYnvJd9lVhk > > [2] https://flink.apache.org > > [3] https://github.com/apache/flink-web > > > > Am Di., 25. Sep. 2018 um 17:56 Uhr schrieb Tzu-Li Chen < > wander4...@gmail.com > >> : > > > >> I agree with Chesnay that we don't guarantee (quick) review of a PR at > the > >> project level. As ASF statement[1]: > >> > >>> Please show some patience with the developers if your patch is not > >> applied as fast as you'd like or a developer asks you to make changes to > >> the patch. If you do not receive any feedback in a reasonable amount of > >> time (say a week or two), feel free to send a follow-up e-mail to the > >> developer list. Open Source developers are all volunteers, often doing > the > >> development in their spare time. > >> > >> However, an open source community shows its friendliness to > contributors. > >> Thus contributors believe their contribution would be take care of, > even be > >> rejected with a reason; project members are thought kind to provide > help to > >> the process. > >> > >> Just like this thread kicked off, it is glad to see that Flink community > >> try best to help its contributors and committers, then take advantage of > >> "open source". > >> > >> Best, > >> tison. > >> > >> [1] http://www.apache.org/dev/contributors#patches > >> > >> > >> Chesnay Schepler 于2018年9月25日周二 下午11:21写道： > >> > >>> There is no guarantee that a PR will be looked at nor is it possible to > >>> provide this in any way on the project level. > >>> > >>> As far as Apache is concerned all contributors/committers etc. work > >>> voluntarily, and > >>> as such assigning work (which includes ownership if it implies such) or > >>> similar is simply not feasible. > >>> > >>> On 25.09.2018 16:54, Thomas Weise wrote: > >>>> I think that all discussion/coordination related to a contribution / > PR > >>>> should be handled through the official project channel. > >>>> > >>>> I would also prefer that there are no designated "owners" and > >> "experts", > >>>> for the reasons Fabian mentioned. > >>>> > >>>> Ideally there is no need to have "suggested reviewers" either, but > then > >>>> what will be the process to ensure that PRs will be looked at? > >>>> > >>>> Thanks, > >>>> Thomas > >>>> > >>>> > >>>> > >>>> On Tue, Sep 25, 2018 at 6:17 AM Tzu-Li Chen > >>> wrote: > >>>> > >>>>> Hi Fabian, > >>>>> > >>>>> You convinced me. I miss the advantage we can take from mailing > lists. > >>>>> > >>>>> Now I am of the same opinion. > >>>>> > >>>>> Best, > >>>>> tison. > >>>>> > >>>>> > >>>>> Fabian Hueske 于2018年9月25日周二 下午3:01写道： > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I think questions about Flink should be posted on the public mailing > >>>>> lists > >>>>>> instead of asking just a single expert. > >>>>>> > >>>>>> There's many reasons for that: > >>>>>> * usually more than one person can answer the question (what if the > >>>>> expert > >>>>>> is not available?) > >>>>>> * non-committers can join the discussion and contribute to the > >>> community > >>>>>> (how can they become experts otherwise?) > >>>>>
Re: [DISCUSS] [Contributing] (3) - Review Tooling
Hi Fabian, +1 for your proposal. For the downside, I think after adding the review process template, the pull request template would be high level into 3 parts: 1. Greeting and community guiding. 2. User completed template. 3. Reviewer complete template. If we can visually separate them, i.e., help a new contributor regard the whole template into 3 parts, I think this downside is not so critical. For some previous attempt, see also [1]. Best, tison. [1] https://github.com/apache/flink/pull/6722 vino yang 于2018年10月17日周三 上午9:57写道： > +1, > > Agree to use the PR template. > > Fabian Hueske 于2018年10月17日周三 上午12:48写道： > > > Hi everyone, > > > > Instead of manually adding the review progress template as a comment to > > every new PR, we could also append it to the PR description template. > > The benefits would be: > > + no need to add it manually since it is automatically added to each PR > > + the template is versioned in the Flink Git repository > > + contributors can learn about the review process before opening a PR > > > > On the downside, the template grows a bit at the end. > > > > What do you think? > > > > Best, Fabian > > > > Am Mo., 24. Sep. 2018 um 15:51 Uhr schrieb Fabian Hueske < > > fhue...@gmail.com > > >: > > > > > Hi, > > > > > > Coming back to the original topic of the thread: How to implement the > > > guided review process. > > > > > > I am in favor of starting with a low-tech solution. > > > We design a review template with a checkbox for the five questions (see > > > [1]) and a link to the detailed description of the review process ([1] > > will > > > be added to flink.apache.org). > > > Once a PR is opened, anybody (the PR author, a committer, any reviewer, > > > ...) can post the review template as a comment. Ideally this happens > > > shortly after the PR was opened. > > > If we find it necessary, we can later add a bot to automate posting the > > > template as comment. > > > > > > Once the template is posted, the PR can be reviewed by following the > > > process and answering the template questions. > > > When all boxes are ticked off, the PR can be merged. > > > > > > Best, > > > Fabian > > > > > > > > > > > > > > > > > > [1] > > > > > > https://docs.google.com/document/d/1yaX2b9LNh-6LxrAmE23U3D2cRbocGlGKCYnvJd9lVhk/ > > > > > > > > > Am Mo., 24. Sep. 2018 um 12:27 Uhr schrieb vino yang < > > > yanghua1...@gmail.com>: > > > > > >> Hi, > > >> > > >> About "valuable", I agree with @Aljoscha that there is no clear > standard > > >> of > > >> judgment about "valuable". > > >> But I think the priority may be a more specific indicator, because the > > >> JIRA > > >> issue also has a "Priority" attribute. > > >> Maybe we can tag the PR, for example: use the "Label" function of > > github, > > >> or add the "[Priority]" tag to the PR title? > > >> > > >> Regarding the closure of inactive PR, I feel that it is more cautious > to > > >> shut down artificially. > > >> Whether it is possible to explicitly assign a PR to a committer > familiar > > >> with the module, which will reduce the unnecessary ping operation of > > many > > >> contributors. > > >> Because some people don't know which committer is familiar with the > > module > > >> he changed. > > >> > > >> Thanks, vino. > > >> > > >> Aljoscha Krettek 于2018年9月24日周一 下午5:03写道： > > >> > > >> > In Beam, we have a bot that regularly nags people about inactive PRs > > and > > >> > also closes them after long inactivity. > > >> > > > >> > And we use the github feature for assigning reviewers in github. > > >> > > > >> > Sometimes it is hard for people to judge how "valuable" a PR is. > Maybe > > >> > some knowledgable people could mark PRs as valuable if they think > > it's a > > >> > good addition but if they don't have the review bandwith. Other > people > > >> can > > >> > then search for valuable PRs that don't yet a reviewer and > > review/merge > > >> > them. > > >> > > > >> > Aljoscha > > >> > > > >> > > On 22. Sep 2018, at 04:25, vino yang > wrote: > > >> > > > > >> > > Hi Jin Sun, > > >> > > > > >> > > Earlier this year, I also had these questions when I started > > >> contributing > > >> > > code to Flink. In fact, the timing of a PR being reviewed will be > > >> related > > >> > > to the priority of the problem solved by the PR. > > >> > > And when you indicate the module to which it belongs in the title > of > > >> the > > >> > > PR, like "[FLINK-][module] ", the person in charge of the > > >> > relevant > > >> > > module or the contributor who is familiar with it will find it > > easier. > > >> > > > > >> > > To Stephan: > > >> > > > > >> > > Maybe we can open a separate mail thread (after all, the current > > >> > discussion > > >> > > thread is about a specific topic) to hear the contributors about > PR > > >> > review > > >> > > related questions and doubts. Perhaps some of their feedback will > > help > > >> > the > > >> > > community improve the way they review. > > >> > > > > >> > > Thanks, vino. > > >> > > >
Re: Enable Slot Resource Profile for Resource Management
Hi Tony, I see the corresponding JIRA[1] and it looks like you don't attach it an mail list. I would do it for you and wonder if you ask for contributor bit to assign the JIRA to yourself. For the topic I give some comments on the JIRA and briefly, I am open if we can take advantage of current somehow ignored ResourceProfile APIs. Anyway, welcome on board! Best, tison. [1] https://issues.apache.org/jira/browse/FLINK-10640 宋辛童(五藏) 于2018年10月22日周一 下午6:39写道： > Hi all, > > We are planing to do some works related to > Flink’s resource management. Precisely, we are trying to enable > ResourceProfile-based resource management. > Here is a brief description of our key ideas. Please let me know how you > think about this. > > Thank You, > Tony Xintong Song >
Re: [DISCUSS] Enhancing the functionality and productivity of Table API
Hi jingchengm Thanks a lot for your proposal! I find it is a good start point for internal optimization works and help Flink to be more user-friendly. AFAIK, DataStream is the most popular API currently that Flink users should describe their logic with detailed logic. >From a more internal view the conversion from DataStream to JobGraph is quite mechanically and hard to be optimized. So when users program with DataStream, they have to learn more internals and spend a lot of time to tune for performance. With your proposal, we provide enhanced functionality of Table API, so that users can describe their job easily on Table aspect. This gives an opportunity to Flink developers to introduce an optimize phase while transforming user program(described by Table API) to internal representation. Given a user who want to start using Flink with simple ETL, pipelining or analytics, he would find it is most naturally described by SQL/Table API. Further, as mentioned by @hequn, SQL is a widely used language. It follows standards, is a > descriptive language, and is easy to use thus we could expect with the enhancement of SQL/Table API, Flink becomes more friendly to users. Looking forward to the design doc/FLIP! Best, tison. jincheng sun 于2018年11月2日周五 上午11:46写道： > Hi Hequn, > Thanks for your feedback! And also thanks for our offline discussion! > You are right, unification of batch and streaming is very important for > flink API. > We will provide more detailed design later, Please let me know if you have > further thoughts or feedback. > > Thanks, > Jincheng > > Hequn Cheng 于2018年11月2日周五 上午10:02写道： > > > Hi Jincheng, > > > > Thanks a lot for your proposal. It is very encouraging! > > > > As we all know, SQL is a widely used language. It follows standards, is a > > descriptive language, and is easy to use. A powerful feature of SQL is > that > > it supports optimization. Users only need to care about the logic of the > > program. The underlying optimizer will help users optimize the > performance > > of the program. However, in terms of functionality and ease of use, in > some > > scenarios sql will be limited, as described in Jincheng's proposal. > > > > Correspondingly, the DataStream/DataSet api can provide powerful > > functionalities. Users can write ProcessFunction/CoProcessFunction and > get > > the timer. Compared with SQL, it provides more functionalities and > > flexibilities. However, it does not support optimization like SQL. > > Meanwhile, DataStream/DataSet api has not been unified which means, for > the > > same logic, users need to write a job for each stream and batch. > > > > With TableApi, I think we can combine the advantages of both. Users can > > easily write relational operations and enjoy optimization. At the same > > time, it supports more functionality and ease of use. Looking forward to > > the detailed design/FLIP. > > > > Best, > > Hequn > > > > On Fri, Nov 2, 2018 at 9:48 AM Shaoxuan Wang > wrote: > > > > > Hi Aljoscha， > > > Glad that you like the proposal. We have completed the prototype of > most > > > new proposed functionalities. Once collect the feedback from community, > > we > > > will come up with a concrete FLIP/design doc. > > > > > > Regards, > > > Shaoxuan > > > > > > > > > On Thu, Nov 1, 2018 at 8:12 PM Aljoscha Krettek > > > wrote: > > > > > > > Hi Jincheng, > > > > > > > > these points sound very good! Are there any concrete proposals for > > > > changes? For example a FLIP/design document? > > > > > > > > See here for FLIPs: > > > > > > > > > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals > > > > > > > > Best, > > > > Aljoscha > > > > > > > > > On 1. Nov 2018, at 12:51, jincheng sun > > > wrote: > > > > > > > > > > *I am sorry for the formatting of the email content. I > > reformat > > > > > the **content** as follows---* > > > > > > > > > > *Hi ALL,* > > > > > > > > > > With the continuous efforts from the community, the Flink system > has > > > been > > > > > continuously improved, which has attracted more and more users. > Flink > > > SQL > > > > > is a canonical, widely used relational query language. However, > there > > > are > > > > > still some scenarios where Flink SQL failed to meet user needs in > > terms > > > > of > > > > > functionality and ease of use, such as: > > > > > > > > > > *1. In terms of functionality* > > > > >Iteration, user-defined window, user-defined join, user-defined > > > > > GroupReduce, etc. Users cannot express them with SQL; > > > > > > > > > > *2. In terms of ease of use* > > > > > > > > > > - Map - e.g. “dataStream.map(mapFun)”. Although > > “table.select(udf1(), > > > > > udf2(), udf3())” can be used to accomplish the same > function., > > > > with a > > > > > map() function returning 100 columns, one has to define or call > 100 > > > > UDFs > > > > > when using SQL, which is quite involved. > > > > > - FlatMap - e.g. “dataStrem.flatmap(flatMapFun)”. S
Re: [VOTE] Release 1.7.0, release candidate #1
Hi, Thanks Till for preparing the RC1 for Flink 1.7.0! I checked a few things, but there seem to be some issues with the release candidate. + Built Flink 1.7.0 from sources and ran all tests(On Darwin Kernel Version 17.7.0 Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64). + Checked checksums and GPG files match the corresponding release files. + Run following Local Setup Tutorial and verify no warnings/errors. - README.md contains a broken link [1]. Best, tison. [1] https://issues.apache.org/jira/browse/FLINK-10797
Re: [RESULT] [VOTE] Release 1.7.0, release candidate #3
Hi Till, Maybe wrongly announce the result in the same thread? Best, tison. Till Rohrmann 于2018年11月30日周五 上午1:28写道： > I'm happy to announce that we have unanimously approved the 1.7.0 release. > > There are 5 approving votes, 4 of which are binding: > - Chesnay (binding) > - Timo (binding) > - Till (binding) > - Gary (non-binding) > - Gordon (binding) > > There are no disapproving votes. > > Thanks everyone for the hard work and help making this release possible! > > Cheers, > Till >
Re: [RESULT] [VOTE] Release 1.7.0, release candidate #3
Yes it is my wrong. I checked the original e-mail and its subject was changed to "[RESULT] [VOTE]..". It should be something wrong in my mail manager. Sorry for the noise. Best, tison. Thomas Weise 于2018年11月30日周五 上午9:38写道： > Looks correct to me. The subject was changed to "[RESULT] [VOTE].." > > Thomas > > On Thu, Nov 29, 2018 at 4:48 PM Tzu-Li Chen wrote: > > > Hi Till, > > > > Maybe wrongly announce the result in the same thread? > > > > Best, > > tison. > > > > > > Till Rohrmann 于2018年11月30日周五 上午1:28写道： > > > > > I'm happy to announce that we have unanimously approved the 1.7.0 > > release. > > > > > > There are 5 approving votes, 4 of which are binding: > > > - Chesnay (binding) > > > - Timo (binding) > > > - Till (binding) > > > - Gary (non-binding) > > > - Gordon (binding) > > > > > > There are no disapproving votes. > > > > > > Thanks everyone for the hard work and help making this release > possible! > > > > > > Cheers, > > > Till > > > > > >
Re: [ANNOUNCE] Apache Flink 1.7.0 released
Thanks a lot for being the release manager Till! And thanks for the great work Flink community! Best, tison. vino yang 于2018年11月30日周五 下午8:19写道： > Thanks Till for your great work, also thanks to the whole community! > > Thanks, vino. > > Timo Walther 于2018年11月30日周五 下午7:42写道： > > > Thanks for being the release manager Till and thanks for the great work > > Flink community! > > > > Regards, > > Timo > > > > > > Am 30.11.18 um 10:39 schrieb Till Rohrmann: > > > The Apache Flink community is very happy to announce the release of > > Apache > > > Flink 1.7.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 available for download at: > > > https://flink.apache.org/downloads.html > > > > > > Please check out the release blog post for an overview of the new > > features > > > and improvements for this release: > > > https://flink.apache.org/news/2018/11/30/release-1.7.0.html > > > > > > The full release notes are available in Jira: > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12343585 > > > > > > We would like to thank all contributors of the Apache Flink community > who > > > made this release possible! > > > > > > Cheers, > > > Till > > > > > > > >
Thanks for hiding ASF GitHub Bot logs on JIRA
Not sure how we arrive here but comments a bit noisy made by ASF GitHub Bot are now hidden to Work Log. Thank you! Best, tison.
Re: Thanks for hiding ASF GitHub Bot logs on JIRA
hmm..then what is it Chesnay Schepler 于2018年12月14日周五 上午5:07写道： > ehhfrom what I can tell this is not the case. > > On 13.12.2018 22:00, Tzu-Li Chen wrote: > > Not sure how we arrive here but comments a bit noisy made by ASF GitHub > Bot > > are now hidden to Work Log. Thank you! > > > > Best, > > tison. > > > >
