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 <c...@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 <se...@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 > > >
