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