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

Reply via email to