End of last week was the day where we wanted to to the cut of the release 
branch. There are still a bunch of open blocker issues about bugs in our Jira: 
[1]. So I'm wondering whether we should actually cut the branch now because 
some commits would have to be merged on release-1.4, release-1.5, and master. 
What do you think?

Regarding managing the release: I will have two weeks in mid march where I 
won't have time and this could be the hot release phase. I think that because 
of this, it would be better to have a release manager other than me and I think 
Till would be a good candidate for that since he's the lead of FLIP-6 which is 
the prime new feature of the next release. What do you think about that?

[1] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLINK%20and%20priority%20%3D%20blocker%20and%20fixVersion%20%3D%201.5.0%20and%20resolution%20%3D%20unresolved

> On 13. Feb 2018, at 10:00, Till Rohrmann <trohrm...@apache.org> wrote:
> 
> +1 from my side.
> 
> Cheers,
> Till
> 
> On Tue, Feb 13, 2018 at 9:52 AM, Piotr Nowojski <pi...@data-artisans.com>
> wrote:
> 
>> +0.95 from my side.
>> 
>> Network changes are mostly reviewed and should be merged by the end of
>> this week.
>> 
>> Piotrek
>> 
>>> On 12 Feb 2018, at 17:41, Stephan Ewen <se...@apache.org> wrote:
>>> 
>>> I agree with the basic idea. I think there is no need to call it "soft
>>> feature freeze" though - it is a feature freeze (no new features get
>>> merged) ;-)
>>> 
>>> What you are suggesting is to delay forking of the release-1.5 branch to
>>> avoid applying the bug fixes to too many branches. That makes sense.
>>> In effect, there is a period of one week (next week) where no post 1.5
>>> features can be merged (feature freeze but release branch not forked),
>>> which should be okay.
>>> 
>>> Best,
>>> Stephan
>>> 
>>> 
>>> On Mon, Feb 12, 2018 at 3:00 PM, Kostas Kloudas <
>> k.klou...@data-artisans.com
>>>> wrote:
>>> 
>>>> For me as well +1.
>>>> 
>>>> Cheers,
>>>> Kostas
>>>> 
>>>>> On Feb 12, 2018, at 2:59 PM, Timo Walther <twal...@apache.org> wrote:
>>>>> 
>>>>> Sounds good to me. +1 from my side.
>>>>> 
>>>>> Regards,
>>>>> Timo
>>>>> 
>>>>> 
>>>>> Am 2/12/18 um 2:56 PM schrieb Aljoscha Krettek:
>>>>>> I agree with Chesnay: we should do a soft "feature freeze" first, were
>>>> we agree to not merge new features to master after that and then to the
>>>> actual hard cutting of the release branch a while later.
>>>>>> 
>>>>>> For actual dates, I'm proposing end of this week (16.02.2018) as soft
>>>> feature freeze and end of next week (23.02.2018) as the hard cut of the
>>>> release branch?
>>>>>> 
>>>>>> What do you think?
>>>>>> 
>>>>>> --
>>>>>> Aljoscha
>>>>>> 
>>>>>>> On 8. Feb 2018, at 10:15, Till Rohrmann <trohrm...@apache.org>
>> wrote:
>>>>>>> 
>>>>>>> Local state recovery is almost completely done. Only some reviews and
>>>>>>> merging of the final PRs is pending.
>>>>>>> 
>>>>>>> The network stack improvements are on a good way to be finished by
>> the
>>>> end
>>>>>>> of this week or beginning of next week. To my knowledge we got
>> recently
>>>>>>> green Travis builds :-) The network stack changes will also include
>> the
>>>>>>> application level flow control and the back pressure based checkpoint
>>>>>>> alignment. So only the last reviews and merging is missing.
>>>>>>> 
>>>>>>> Concerning Flip-6, I'm currently working on enabling Flip-6 by
>> default.
>>>>>>> There are still some smaller things left to be done but I'm confident
>>>> that
>>>>>>> we can resolve them quickly.
>>>>>>> 
>>>>>>> I agree that due to the big changes we should have a very thorough
>> and
>>>>>>> principled testing period where we put Flink through the paces.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Till
>>>>>>> 
>>>>>>> On Wed, Feb 7, 2018 at 10:55 AM, Chesnay Schepler <
>> ches...@apache.org>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> As Aljoscha said we wanted to do 1.5 soon after 1.4 based on the
>>>>>>>> assumption that the 3 big features (FLIP-6, network stack changes,
>>>> local
>>>>>>>> state recovery) are nearly done.
>>>>>>>> 
>>>>>>>> I'm unsure about local state recovery, but I still see open issues
>> for
>>>>>>>> FLIP-6 and the network stack rework.
>>>>>>>> As such it doesn't make sense to release 1.5 now.
>>>>>>>> 
>>>>>>>> Given the large scope of these features I would very much prefer to
>>>> have
>>>>>>>> them active on master for a while before a feature-freeze
>>>>>>>> to expose them to a wider audience.
>>>>>>>> 
>>>>>>>> IMO it will take at least another month before we can start the
>>>> release
>>>>>>>> process for 1.5, i.e. the feature freeze.
>>>>>>>> (2 more weeks for implementation, 2 weeks on master for the dust to
>>>> settle)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 05.02.2018 22:39, Kostas Kloudas wrote:
>>>>>>>> 
>>>>>>>>> Hi Aljoscha,
>>>>>>>>> 
>>>>>>>>> I believe that support for Broadcast State should also be in 1.5.
>>>>>>>>> There is an open PR https://github.com/apache/flink/pull/5230 <
>>>>>>>>> https://github.com/apache/flink/pull/5230> for that
>>>>>>>>> and there are some pending issues related to scala api and
>>>> documentation.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Kostas
>>>>>>>>> 
>>>>>>>>> On Feb 5, 2018, at 5:37 PM, Timo Walther <twal...@apache.org>
>> wrote:
>>>>>>>>>> Hi Shuyi,
>>>>>>>>>> 
>>>>>>>>>> I will take a look at it again this week. I'm pretty sure it will
>> be
>>>>>>>>>> part of 1.5.0.
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Timo
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Am 2/5/18 um 5:25 PM schrieb Shuyi Chen:
>>>>>>>>>> 
>>>>>>>>>>> Hi Aljoscha, can we get this feature in for 1.5.0? We have a lot
>> of
>>>>>>>>>>> internal users waiting for this feature.
>>>>>>>>>>> 
>>>>>>>>>>> [FLINK-7923 <https://issues.apache.org/jira/browse/FLINK-7923>]
>>>> Support
>>>>>>>>>>> accessing subfields of a Composite element in an Object Array
>> type
>>>>>>>>>>> column
>>>>>>>>>>> 
>>>>>>>>>>> Thanks a lot
>>>>>>>>>>> Shuyi
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Mon, Feb 5, 2018 at 6:59 AM, Christophe Jolif <
>> cjo...@gmail.com
>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi guys,
>>>>>>>>>>>> Sorry for jumping in, but I think
>>>>>>>>>>>> 
>>>>>>>>>>>> [FLINK-8101] Elasticsearch 6.X support
>>>>>>>>>>>> [FLINK-7386]  Flink Elasticsearch 5 connector is not compatible
>>>> with
>>>>>>>>>>>> Elasticsearch 5.2+ client
>>>>>>>>>>>> 
>>>>>>>>>>>> have long been awaited and there was one PR from me and from
>>>> someone
>>>>>>>>>>>> else
>>>>>>>>>>>> showing the interest ;) So if you could consider it for 1.5 that
>>>> would
>>>>>>>>>>>> be
>>>>>>>>>>>> great!
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> --
>>>>>>>>>>>> Christophe
>>>>>>>>>>>> 
>>>>>>>>>>>> On Mon, Feb 5, 2018 at 2:47 PM, Timo Walther <
>> twal...@apache.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Aljoscha,
>>>>>>>>>>>>> it would be great if we can include the first version of the
>> SQL
>>>>>>>>>>>>> client
>>>>>>>>>>>>> (see FLIP-24, Implementation Plan 1). I will open a PR this
>>>> week. I
>>>>>>>>>>>>> think
>>>>>>>>>>>>> we can merge this with explicit "experimental/alpha" status. It
>>>> is far
>>>>>>>>>>>>> 
>>>>>>>>>>>> away
>>>>>>>>>>>> 
>>>>>>>>>>>>> from feature completeness but will be a great tool for Flink
>>>>>>>>>>>>> beginners.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In order to use the SQL client we would need to also add some
>>>> table
>>>>>>>>>>>>> sources with the new unified table factories (FLINK-8535), but
>>>> this is
>>>>>>>>>>>>> optional because a user can implement own table factories at
>> the
>>>>>>>>>>>>> 
>>>>>>>>>>>> begining.
>>>>>>>>>>>> 
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Timo
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Am 2/5/18 um 2:36 PM schrieb Tzu-Li (Gordon) Tai:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Aljoscha,
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks for starting the discussion.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I think there’s a few connector related must-have improvements
>>>> that
>>>>>>>>>>>>>> we
>>>>>>>>>>>>>> should get in before the feature freeze, since quite a few
>>>> users have
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> been
>>>>>>>>>>>>> asking for them:
>>>>>>>>>>>>>> [FLINK-6352] FlinkKafkaConsumer should support to use
>> timestamp
>>>> to
>>>>>>>>>>>>>> set
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> up
>>>>>>>>>>>>> start offset
>>>>>>>>>>>>>> [FLINK-5479] Per-partition watermarks in FlinkKafkaConsumer
>>>> should
>>>>>>>>>>>>>> consider idle partitions
>>>>>>>>>>>>>> [FLINK-8516] Pluggable shard-to-subtask partitioning for
>>>>>>>>>>>>>> FlinkKinesisConsumer
>>>>>>>>>>>>>> [FLINK-6109] Add a “checkpointed offset” metric to
>>>> FlinkKafkaConsumer
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> These are still missing in the master branch. Only FLINK-5479
>> is
>>>>>>>>>>>>>> still
>>>>>>>>>>>>>> lacking a pull request.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Gordon
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 31 January 2018 at 10:38:43 AM, Aljoscha Krettek (
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> aljos...@apache.org)
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> When we decided to do the 1.4.0 release a while back we did
>>>> that to
>>>>>>>>>>>>>> get
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> a
>>>>>>>>>>>>> stable release out before putting in a couple of new features.
>>>> Back
>>>>>>>>>>>>> then,
>>>>>>>>>>>>> some of those new features (FLIP-6, network stack changes,
>> local
>>>> state
>>>>>>>>>>>>>> recovery) were almost ready and we wanted to do a shortened
>>>> 1.5.0
>>>>>>>>>>>>>> development cycle to allow for those features to become ready
>>>> and
>>>>>>>>>>>>>> then
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> do
>>>>>>>>>>>>> the next release.
>>>>>>>>>>>>>> We are now approaching the approximate time where we wanted to
>>>> do the
>>>>>>>>>>>>>> Flink 1.5.0 release so I would like to gauge where we are and
>>>> gather
>>>>>>>>>>>>>> opinions on how we should proceed now.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> With this, I'd also like to propose myself as the release
>>>> manager for
>>>>>>>>>>>>>> 1.5.0 but I'm very happy to yield if someone else would be
>>>>>>>>>>>>>> interested in
>>>>>>>>>>>>>> doing that.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>> Aljoscha
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>> Christophe
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>> 

Reply via email to