flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Hogan <c...@greghogan.com>
Subject Re: [DISCUSS] Merging the FLIP-6 feature branch into the Master branch
Date Fri, 02 Dec 2016 17:16:54 GMT
Hi Stephan,

How soon are you expecting the "release-1.2" fork? I am sure you have
considered merging the FLIP-6 branch after the fork.

Do we anticipate the new tests pushing Flink over Travis CI's new 50 minute
limit? This might be a good opportunity to rebalance the test ranges as the
most recent passing master build (
https://travis-ci.org/apache/flink/builds/180504091) shows up to a 10
minute difference in runtime.

Greg

On Fri, Dec 2, 2016 at 11:37 AM, Stephan Ewen <sewen@apache.org> wrote:

> Hi all!
>
> I want to start a discussion about merging the FLIP-6 feature branch into
> the master branch.
>
> The feature branch implements the following:
>   - A new RPC abstraction
>   - A new High-Availability Services Abstraction
>   - New JobManager / TaskManager / ResourceManager with dynamic slot
> allocation
>   - Re-designed runners to instantiate them
>   - A new MiniCluster
>
> The feature branch still needs quite a bit of work, but it does not
> interfere with the current state of the master branch. All new components
> are implemented as separate components with separate tests.
>
> The branch builds fully, all tests pass, and when setting up Flink by any
> of the means supported in the Master, the same code is used and none of the
> feature branch code is active.
>
>
> At the same time, it becomes harder for the feature branch to chase the
> master branch.
> Also, the feature branch starts to contain cleanups that are valuable in
> the master branch as well, for example around reusable parts like the "high
> availability services".
>
>
> *My suggestion is the following:*
>
>   - Let's merge the feature branch in the near future, i.e., quite soon.
>
>   - When we fork off the "release-1.2" branch, we delete the new components
> form that branch. That way we avoid having seemingly dead code in the
> source release.
>
>   - The feature branch classes are mostly in some subpackages, so it should
> be quite straight forward to remove them.
>
>
> What do you think about this?
>
>
> Greetings,
> Stephan
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message