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