+1 for that, as long we will be consistent with it :)
> On Aug 31, 2017, at 12:22 PM, Aljoscha Krettek <aljos...@apache.org> wrote:
>
> +1 On using "Fix Version" for that. I always try to use that already for
> things that need fixing in the next release. Also "Blocker" is a thing there.
>
>> On 30. Aug 2017, at 20:29, Eron Wright <eronwri...@gmail.com> wrote:
>>
>> 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
>>>
>>>
>
