+1 for cutting the release branch now. I'm also happy to volunteer as the release manager for Flink 1.5.
Cheers, Till On Mon, Feb 26, 2018 at 3:45 PM, Aljoscha Krettek <aljos...@apache.org> wrote: > 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 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>> > >>>> > >>>> > >> > >> > >
