I've reactivated the 1.2 release thread and the actual list of release blockers is quite short as it seems. We could actually manage to fork off a branch for the 1.2 release next week (this really depends on how fast we get the blockers down) Would it be okay for the people working on "flip-6" to wait until next week to make the final decision here?
On Fri, Dec 2, 2016 at 7:18 PM, Stephan Ewen <se...@apache.org> wrote: > 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 > > > > > >
