Thanks Stephan, The entire plan makes sense to me.
Regarding the branch name, how about using "blink-flink-1.5" wich meant that the branche is based on flink-1.5. If the name is "blink-1.5", some users will think that this is the version number of the internal Blink of alibaba, and will not associate with the branch of flink-1.5. This is only one of my concerns. Wrt Offering Jars for Blink, from the points of my view, if we do not Release the Blink code, we can write the blog documentation to detail how to build and deploy Blink from source code. I think after we push the blink branch, we also some bug fix and small function development（which urgently needed by users). So telling users how to build a release package from source is very important。 Something like current "Building Flionk from Source" section of flink doc. In this way we are both user-friendly and avoid any liability issues. Wrt the "Docs for Flink", if we expect users to take advantage of the functionality of blink, and the blink branch will also make bugfix changes, I suggest adding an address same as ” https://ci.apache.org/projects/flink/flink-docs-master“, e.g.: "https :// ci.apache.org/projects/flink/flink-docs-blink", so users can have a complete user experience, just like every version published by flink " https://ci.apache.org/projects /flink/flink-docs-release-XX", the difference is that we do not declare release, do not assume the quality and responsibility of the release. So, I agree with @Shaoxuan Wang <wshaox...@gmail.com> 's suggestion. If I misunderstood what you mean, please correct me. @Shaoxuan Wang <wshaox...@gmail.com> Regards, Jincheng Stephan Ewen <se...@apache.org> 于2019年1月22日周二 上午3:46写道： > Dear Flink Community! > > Some of you may have heard it already from announcements or from a Flink > Forward talk: > Alibaba has decided to open source its in-house improvements to Flink, > called Blink! > First of all, big thanks to team that developed these improvements and made > this > contribution possible! > > Blink has some very exciting enhancements, most prominently on the Table > API/SQL side > and the unified execution of these programs. For batch (bounded) data, the > SQL execution > has full TPC-DS coverage (which is a big deal), and the execution is more > than 10x faster > than the current SQL runtime in Flink. Blink has also added support for > catalogs, > improved the failover speed of batch queries and the resource management. > It also > makes some good steps in the direction of more deeply unifying the batch > and streaming > execution. > > The proposal is to merge Blink's enhancements into Flink, to give Flink's > SQL/Table API and > execution a big boost in usability and performance. > > Just to avoid any confusion: This is not a suggested change of focus to > batch processing, > nor would this break with any of the streaming architecture and vision of > Flink. > This contribution follows very much the principle of "batch is a special > case of streaming". > As a special case, batch makes special optimizations possible. In its > current state, > Flink does not exploit many of these optimizations. This contribution adds > exactly these > optimizations and makes the streaming model of Flink applicable to harder > batch use cases. > > Assuming that the community is excited about this as well, and in favor of > these enhancements > to Flink's capabilities, below are some thoughts on how this contribution > and integration > could work. > > --- Making the code available --- > > At the moment, the Blink code is in the form of a big Flink fork (rather > than isolated > patches on top of Flink), so the integration is unfortunately not as easy > as merging a > few patches or pull requests. > > To support a non-disruptive merge of such a big contribution, I believe it > make sense to make > the code of the fork available in the Flink project first. > From there on, we can start to work on the details for merging the > enhancements, including > the refactoring of the necessary parts in the Flink master and the Blink > code to make a > merge possible without repeatedly breaking compatibility. > > The first question is where do we put the code of the Blink fork during the > merging procedure? > My first thought was to temporarily add a repository (like > "flink-blink-staging"), but we could > also put it into a special branch in the main Flink repository. > > > I will start a separate thread about discussing a possible strategy to > handle and merge > such a big contribution. > > Best, > Stephan >
