+1 for November 2nd Thanks, Zhu
Xintong Song <tonysong...@gmail.com> 于2020年10月20日周二 下午11:26写道: > +1 for Nov. 2nd. > > Thank you~ > > Xintong Song > > > > On Tue, Oct 20, 2020 at 8:56 PM Leonard Xu <xbjt...@gmail.com> wrote: > > > +1 for **Sunday night**. > > > > > > Best > > Leonard > > > > > 在 2020年10月20日,19:03,Jingsong Li <jingsongl...@gmail.com> 写道: > > > > > > +1 for Sunday night. This also helps Filesystem and Hive implementation > > for > > > FLIP-27 Source. And the implementation will block "Support Multiple > Input > > > for Blink Planner". Multiple input is very important for Batch > > performance. > > > > > > Best, > > > Jingsong > > > > > > On Tue, Oct 20, 2020 at 6:36 PM Yu Li <car...@gmail.com> wrote: > > > > > >> +1 for Sunday night. This also helps for more thorough testing of the > > >> RocksDB version bumping up job [1]. > > >> > > >> Thanks. > > >> > > >> Best Regards, > > >> Yu > > >> > > >> [1] https://issues.apache.org/jira/browse/FLINK-14482 > > >> > > >> On Tue, 20 Oct 2020 at 17:06, Robert Metzger <rmetz...@apache.org> > > wrote: > > >> > > >>> Thanks a lot. > > >>> > > >>> It seems that a few people are supportive of the idea of moving the > > >> feature > > >>> freeze to Friday. > > >>> I would actually propose to make it *Sunday night* then. We'll then > > >> create > > >>> the first release candidate on Monday morning, November 2nd. > > >>> > > >>> > > >>> On Mon, Oct 19, 2020 at 1:27 PM Danny Chan <yuzhao....@gmail.com> > > wrote: > > >>> > > >>>> Per FLIP-145, we have many runtime operators to implement and bridge > > it > > >>>> with the planner. > > >>>> > > >>>> Best, > > >>>> Danny Chan > > >>>> 在 2020年10月19日 +0800 PM6:59,Robert Metzger <rmetz...@apache.org>,写道: > > >>>>> Thank you for your responses so far. > > >>>>> > > >>>>> @Kurt, Jingsong, Danny: Which JIRAs/FLIPs are going to benefit from > > >> the > > >>>>> extension? > > >>>>> > > >>>>> On Mon, Oct 19, 2020 at 12:45 PM Aljoscha Krettek < > > >> aljos...@apache.org > > >>>> > > >>>>> wrote: > > >>>>> > > >>>>>> @Robert Your (and Dian's) suggestions sound good to me! I like > > >>> keeping > > >>>>>> to master frozen for a while since it will prevent a lot of > > >> duplicate > > >>>>>> merging efforts. > > >>>>>> > > >>>>>> Regarding the date: I'm fine with the proposed date but I can also > > >>> see > > >>>>>> that extending it to the end of the week could be helpful. > > >>>>>> > > >>>>>> Aljoscha > > >>>>>> > > >>>>>> On 19.10.20 12:24, Danny Chan wrote: > > >>>>>>> +1 for Kurt suggestion, there are many features for SQL yet, 2 > > >> more > > >>>> days > > >>>>>> are valuable. > > >>>>>>> > > >>>>>>> Best, > > >>>>>>> Danny Chan > > >>>>>>> 在 2020年10月19日 +0800 PM6:22,Jingsong Li <jingsongl...@gmail.com > > >>>> ,写道: > > >>>>>>>> Hi Robert, > > >>>>>>>> > > >>>>>>>> Thanks for your detailed explanation. > > >>>>>>>> > > >>>>>>>> At present, we are preparing or participating in Flink forward, > > >>> so > > >>>> +1 > > >>>>>> for > > >>>>>>>> appropriate extension of deadline. > > >>>>>>>> > > >>>>>>>> Best, > > >>>>>>>> Jingsong > > >>>>>>>> > > >>>>>>>> On Mon, Oct 19, 2020 at 5:36 PM Kurt Young <ykt...@gmail.com> > > >>>> wrote: > > >>>>>>>> > > >>>>>>>>> Can we change the freeze date to October 30th (Friday next > > >>>> week)? It > > >>>>>> would > > >>>>>>>>> be helpful > > >>>>>>>>> for us if we have 2 more days. > > >>>>>>>>> > > >>>>>>>>> Best, > > >>>>>>>>> Kurt > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On Mon, Oct 19, 2020 at 5:00 PM Robert Metzger < > > >>>> rmetz...@apache.org> > > >>>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>>> Hi all, > > >>>>>>>>>> > > >>>>>>>>>> Dian and I would like to discuss a few items regarding the > > >>>> upcoming > > >>>>>> Flink > > >>>>>>>>>> 1.12 feature freeze: > > >>>>>>>>>> > > >>>>>>>>>> *A) Exact feature freeze day* > > >>>>>>>>>> So far, we've always said "end of October > > >>>>>>>>>> < > > >>>> https://cwiki.apache.org/confluence/display/FLINK/1.12+Release>" > for > > >>>>>>>>> the > > >>>>>>>>>> freeze. We propose (end of day CEST) October 28th > > >> (Wednesday > > >>>> next > > >>>>>> week) > > >>>>>>>>> as > > >>>>>>>>>> the feature freeze time. > > >>>>>>>>>> We want to create RC0 on the day after the feature freeze, > > >> to > > >>>> make > > >>>>>> sure > > >>>>>>>>> the > > >>>>>>>>>> RC creation process is running smoothly, and to have a > > >> common > > >>>> testing > > >>>>>>>>>> reference point. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> *B) What does feature freeze mean?*After the feature > > >> freeze, > > >>>> no new > > >>>>>>>>>> features are allowed to be merged to master. Only bug fixes > > >>> and > > >>>>>>>>>> documentation improvements. > > >>>>>>>>>> The release managers will revert new feature commits after > > >>> the > > >>>> feature > > >>>>>>>>>> freeze. > > >>>>>>>>>> Rational: The goal of the feature freeze phase is to > > >> improve > > >>>> the > > >>>>>> system > > >>>>>>>>>> stability by addressing known bugs. New features tend to > > >>>> introduce new > > >>>>>>>>>> instabilities, which would prolong the release process. > > >>>>>>>>>> If you need to merge a new feature after the freeze, please > > >>>> open a > > >>>>>>>>>> discussion on the dev@ list. If there are no objections > > >> by a > > >>>> PMC > > >>>>>> member > > >>>>>>>>>> within 48 (workday)hours, the feature can be merged. > > >>>>>>>>>> > > >>>>>>>>>> *C) When to cut the "release-1.12" branch off master?* > > >>>>>>>>>> In the last feature freeze, we had a pretty lengthy phase > > >> of > > >>>>>> maintaining > > >>>>>>>>>> the "master" and "release-1.11" branches with the same > > >> fixes. > > >>>>>> Therefore, > > >>>>>>>>> I > > >>>>>>>>>> would like to propose an adjustment to the release process: > > >>> We > > >>>> will > > >>>>>> have > > >>>>>>>>> a > > >>>>>>>>>> stabilization phase on master, between the feature freeze > > >> and > > >>>> the > > >>>>>> branch > > >>>>>>>>>> cut. > > >>>>>>>>>> I expect this stabilization phase to last between 1 and 3 > > >>>> weeks, > > >>>>>>>>> depending > > >>>>>>>>>> on the issues we find. Once all blockers are resolved, and > > >> no > > >>>> new > > >>>>>>>>> blockers > > >>>>>>>>>> are surfacing, we can cut off the "release-1.12" branch and > > >>>> finalize > > >>>>>> the > > >>>>>>>>>> release. > > >>>>>>>>>> Is anybody in the community waiting for the cut off to > > >> happen > > >>>> sooner > > >>>>>> so > > >>>>>>>>>> that they can merge a big feature to Flink 1.13 ? (if that > > >>>> would be > > >>>>>> the > > >>>>>>>>>> case, then we can not have a stabilization phase) > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Let me know what you think! > > >>>>>>>>>> > > >>>>>>>>>> Best, > > >>>>>>>>>> Dian and Robert > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> -- > > >>>>>>>> Best, Jingsong Lee > > >>>>>>> > > >>>>>> > > >>>>>> > > >>>> > > >>> > > >> > > > > > > > > > -- > > > Best, Jingsong Lee > > > > >