I definitely think the conversation must happen in the context of the expected feature-set. JIRA is our friend here. I like the idea of using the "Fix Version" to identify the set from which the leadership can formulate an estimate. I would suggest that folks update their tasks accordingly. WDTY?
On Wed, Aug 30, 2017 at 10:21 AM, Greg Hogan <c...@greghogan.com> wrote: > Haven’t seen much discussion here. I see the benefit of time-based > deadlines but also of focussing on release functionality and stability. > > I like the idea to keep the structure of time-based releases but soften > the deadlines. The schedule would not be open-ended but we could wait on > the completion and stability of major new features and also schedule around > events like the upcoming Flink Forward. I would like to still fork the > release branch as late as possible. > > Greg > > > On Aug 23, 2017, at 5:07 AM, Timo Walther <twal...@apache.org> wrote: > > > > I also think we shouldn't publish releases regularly, just to have a > release regularly. > > > > Maybe we can do time-based releases more flexible: Instead of > feature-freeze after 3 months, 1 month testing. We could do it like > feature-freeze 3 months after the last release, unlimited testing. This > would limit us in not adding too many features, but enables for proper > testing for robust releases. What do you think? > > > > Regards, > > Timo > > > > Am 23.08.17 um 10:26 schrieb Till Rohrmann: > >> Thanks for starting the discussion Stephan. I agree with you that the > last > >> release was probably a bit hasty due to the constraints we put on > ourselves > >> with the strict time based release. Therefore and because of some of the > >> incomplete features, I would be in favour of loosening the strict > deadline > >> such that we have more time finishing our work and properly testing the > >> release. Hard to tell, however, how much more time is needed. > >> > >> Cheers, > >> Till > >> > >> On Tue, Aug 22, 2017 at 6:56 PM, Chen Qin <qinnc...@gmail.com> wrote: > >> > >>> I would be great to avoid immediate 1.x1 bug fixing release. It cause > >>> confusion and raise quality concerns. > >>> > >>> Also, is there already way to communicate with Amazon EMR for latest > >>> release speedy available? I may try to find someone work there is > needed. > >>> > >>> Thanks > >>> Chen > >>> > >>>> On Aug 22, 2017, at 9:32 AM, Stephan Ewen <se...@apache.org> wrote: > >>>> > >>>> Hi all! > >>>> > >>>> I want to bring up this discussion because we are approaching the date > >>> when > >>>> there would be a feature freeze following the time based release > >>> schedule. > >>>> To make it short, I would suggest to not follow the time-based > schedule > >>> for > >>>> that release. There are a bunch of reasons bringing me to that view: > >>>> > >>>> - 1.3.0, which was very much pushed by the time-based schedule was > not > >>>> the best release we ever made. In fact, it had quite a few open issues > >>> that > >>>> required an immediate 1.3.1 followup and only 1.3.2 fixed some of > them. > >>>> > >>>> - 1.3.2, which is in some sense what 1.3.0 should have been is only 2 > >>>> weeks back > >>>> > >>>> - The delta since the last release is still quite small. One could > argue > >>>> to make a quick release and then soon another release after that, but > >>>> releases still tie up quite a good amount of resources, so that would > >>>> introduce a delay for much of the ongoing work. I am doubtful if this > is > >>> a > >>>> good idea at this point. > >>>> > >>>> - The current master has still quite a bit of "ongoing work" that is > not > >>>> in perfect shape for a release, but could use some more weeks to > provide > >>>> real value to users. Examples are the dependency reworking, network > stack > >>>> enhancements, speedier state restore efforts, flip-6, exactly-once > >>>> sinks/side-effects, and others. > >>>> > >>>> > >>>> Alternatively, we could do what we did for 1.1 and 1.2, which is > making > >>> now > >>>> a list of features we want in the release, and then projecting based > on > >>>> that when we fork off the 1.4 release branch. > >>>> > >>>> > >>>> What do you think? > >>>> > >>>> > >>>> Cheers, > >>>> Stephan > >
