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