flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Ewen <se...@apache.org>
Subject Re: [DISCUSS] Merging the FLIP-6 feature branch into the Master branch
Date Fri, 02 Dec 2016 18:18:36 GMT
Hi Greg!

Yes, originally I was arguing to merge Flip-6 after forking off the 1.2
branch. That would be the preferable solution, but since it seems that the
1.2 branch may still take a few weeks, I was thinking that we may want to
do that earlier.

Many flip-6 contributors would like to be active around the Christmas time,
and I almost expect the 1.2 branch will not be forked off by then.

Stephan


On Fri, Dec 2, 2016 at 6:16 PM, Greg Hogan <code@greghogan.com> wrote:

> 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