[DISCUSS] Release 1.12 Feature Freeze

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Release 1.12 Feature Freeze

Robert Metzger
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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Kurt Young
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Jingsong Li
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 <[hidden email]> 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 <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Danny Chan
+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 <[hidden email]>,写道:

> 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 <[hidden email]> 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 <[hidden email]>
> > 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Aljoscha Krettek-2
@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 <[hidden email]>,写道:
>> 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 <[hidden email]> 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 <[hidden email]>
>>> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Robert Metzger
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 <[hidden email]>
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 <[hidden email]>,写道:
> >> 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 <[hidden email]> 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 <[hidden email]>
> >>> 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
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Danny Chan
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 <[hidden email]>,写道:

> 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 <[hidden email]>
> 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 <[hidden email]>,写道:
> > > > 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 <[hidden email]> 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 <[hidden email]>
> > > > > 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
> > >
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Robert Metzger
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 <[hidden email]> 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 <[hidden email]>,写道:
> > 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 <[hidden email]>
> > 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 <[hidden email]>,写道:
> > > > > 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 <[hidden email]>
> 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 <
> [hidden email]>
> > > > > > 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
> > > >
> > >
> > >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Yu Li
+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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>,写道:
> > > 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 <[hidden email]
> >
> > > 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 <[hidden email]
> >,写道:
> > > > > > 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 <[hidden email]>
> > 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 <
> > [hidden email]>
> > > > > > > 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
> > > > >
> > > >
> > > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Jingsong Li
+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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>,写道:
> > > > 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 <
> [hidden email]
> > >
> > > > 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 <[hidden email]
> > >,写道:
> > > > > > > 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 <[hidden email]>
> > > 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 <
> > > [hidden email]>
> > > > > > > > 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 | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Leonard Xu
+1 for **Sunday night**.


Best
Leonard

> 在 2020年10月20日,19:03,Jingsong Li <[hidden email]> 写道:
>
> +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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>,写道:
>>>>> 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 <
>> [hidden email]
>>>>
>>>>> 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 <[hidden email]
>>>> ,写道:
>>>>>>>> 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 <[hidden email]>
>>>> 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 <
>>>> [hidden email]>
>>>>>>>>> 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 | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Xintong Song
+1 for Nov. 2nd.

Thank you~

Xintong Song



On Tue, Oct 20, 2020 at 8:56 PM Leonard Xu <[hidden email]> wrote:

> +1 for **Sunday night**.
>
>
> Best
> Leonard
>
> > 在 2020年10月20日,19:03,Jingsong Li <[hidden email]> 写道:
> >
> > +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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>,写道:
> >>>>> 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 <
> >> [hidden email]
> >>>>
> >>>>> 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 <[hidden email]
> >>>> ,写道:
> >>>>>>>> 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 <[hidden email]>
> >>>> 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 <
> >>>> [hidden email]>
> >>>>>>>>> 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 | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Zhu Zhu
+1 for November 2nd

Thanks,
Zhu

Xintong Song <[hidden email]> 于2020年10月20日周二 下午11:26写道:

> +1 for Nov. 2nd.
>
> Thank you~
>
> Xintong Song
>
>
>
> On Tue, Oct 20, 2020 at 8:56 PM Leonard Xu <[hidden email]> wrote:
>
> > +1 for **Sunday night**.
> >
> >
> > Best
> > Leonard
> >
> > > 在 2020年10月20日,19:03,Jingsong Li <[hidden email]> 写道:
> > >
> > > +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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > 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 <[hidden email]>,写道:
> > >>>>> 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 <
> > >> [hidden email]
> > >>>>
> > >>>>> 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 <[hidden email]
> > >>>> ,写道:
> > >>>>>>>> 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 <[hidden email]>
> > >>>> 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 <
> > >>>> [hidden email]>
> > >>>>>>>>> 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 | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Release 1.12 Feature Freeze

Yang Wang
+1 for Sunday night. This will help a lot for FLIP-144(Native Kubernetes HA
for Flink).

Best,
Yang

Zhu Zhu <[hidden email]> 于2020年10月23日周五 下午2:15写道:

> +1 for November 2nd
>
> Thanks,
> Zhu
>
> Xintong Song <[hidden email]> 于2020年10月20日周二 下午11:26写道:
>
> > +1 for Nov. 2nd.
> >
> > Thank you~
> >
> > Xintong Song
> >
> >
> >
> > On Tue, Oct 20, 2020 at 8:56 PM Leonard Xu <[hidden email]> wrote:
> >
> > > +1 for **Sunday night**.
> > >
> > >
> > > Best
> > > Leonard
> > >
> > > > 在 2020年10月20日,19:03,Jingsong Li <[hidden email]> 写道:
> > > >
> > > > +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 <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]>
> > > 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 <[hidden email]
> >,写道:
> > > >>>>> 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 <
> > > >> [hidden email]
> > > >>>>
> > > >>>>> 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 <[hidden email]
> > > >>>> ,写道:
> > > >>>>>>>> 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 <[hidden email]>
> > > >>>> 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 <
> > > >>>> [hidden email]>
> > > >>>>>>>>> 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
> > >
> > >
> >
>