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
>
>

Reply via email to