+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
