You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Leonard Xu <xb...@gmail.com> on 2021/03/31 15:56:50 UTC
Apply external 3 days for FLINK-20387 after feature freeze
Hi, Dawid & Guowei
Sorry to apply the extension, I want to apply 3 days for ticket [FLINK-20387] Support column of TIMESTAMP WITH LOCAL ZONE TIME type as rowtime[1], it is the last ticket of FLIP-162[2] which aims to solve various time zone issues and offer a consistent time function behavior. We experienced a long discussion for this FLIP and I took some efforts to resolve the tricky daylight saving time problem. In fact, I have been working hard to promote this FLIP recently.
But I really hope that this feature can join 1.13. The motivation is not because I want to complete this FLIP personally, but from the user's perspective that we can provide them a consistent time behavior and resolves the time zone issues naturally, we believe this will greatly improve the user experience, thus I’m asking to apply 3 days for only this ticket FLINK-20387.
Best,
Leonard
[1] https://issues.apache.org/jira/browse/FLINK-20387
[2] https://cwiki.apache.org/confluence/display/FLINK/FLIP-162%3A+Consistent+Flink+SQL+time+function+behavior
> 在 2021年3月31日，17:54，Guowei Ma <gu...@gmail.com> 写道：
>
> Hi, community:
>
> Friendly reminder that today (3.31) is the last day of feature development. Under normal circumstances, you will not be able to submit new features from tomorrow (4.1). Tomorrow we will create 1.13.0-rc0 for testing, welcome to help test together.
> After the test is relatively stable, we will cut the release-1.13 branch.
>
> Best,
> Dawid & Guowei
>
>
> On Mon, Mar 29, 2021 at 5:17 PM Till Rohrmann <trohrmann@apache.org <ma...@apache.org>> wrote:
> +1 for the 31st of March for the feature freeze.
>
> Cheers,
> Till
>
> On Mon, Mar 29, 2021 at 10:12 AM Robert Metzger <rmetzger@apache.org <ma...@apache.org>> wrote:
>
> > +1 for March 31st for the feature freeze.
> >
> >
> >
> > On Fri, Mar 26, 2021 at 3:39 PM Dawid Wysakowicz <dwysakowicz@apache.org <ma...@apache.org>>
> > wrote:
> >
> > > Thank you Thomas! I'll definitely check the issue you linked.
> > >
> > > Best,
> > >
> > > Dawid
> > >
> > > On 23/03/2021 20:35, Thomas Weise wrote:
> > > > Hi Dawid,
> > > >
> > > > Thanks for the heads up.
> > > >
> > > > Regarding the "Rebase and merge" button. I find that merge option
> > useful,
> > > > especially for small simple changes and for backports. The following
> > > should
> > > > help to safeguard from the issue encountered previously:
> > > > https://github.com/jazzband/pip-tools/issues/1085 <https://github.com/jazzband/pip-tools/issues/1085>
> > > >
> > > > Thanks,
> > > > Thomas
> > > >
> > > >
> > > > On Tue, Mar 23, 2021 at 4:58 AM Dawid Wysakowicz <
> > dwysakowicz@apache.org <ma...@apache.org>
> > > >
> > > > wrote:
> > > >
> > > >> Hi devs, users!
> > > >>
> > > >> 1. *Feature freeze date*
> > > >>
> > > >> We are approaching the end of March which we agreed would be the time
> > > for
> > > >> a Feature Freeze. From the knowledge I've gather so far it still seems
> > > to
> > > >> be a viable plan. I think it is a good time to agree on a particular
> > > date,
> > > >> when it should happen. We suggest *(end of day CEST) March 31st*
> > > >> (Wednesday next week) as the feature freeze time.
> > > >>
> > > >> Similarly as last 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.
> > > >>
> > > >> Having said that let us remind after Robert & Dian from the previous
> > > >> release what it a Feature Freeze means:
> > > >>
> > > >> *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.
> > > >>
> > > >> 2. *Merge PRs from the command line*
> > > >>
> > > >> In the past releases it was quite frequent around the Feature Freeze
> > > date
> > > >> that we ended up with a broken main branch that either did not compile
> > > or
> > > >> there were failing tests. It was often due to concurrent merges to the
> > > main
> > > >> branch via the "Rebase and merge" button. To overcome the problem we
> > > would
> > > >> like to suggest only ever merging PRs from a command line. Thank you
> > > >> Stephan for the idea! The suggested workflow would look as follows:
> > > >>
> > > >> 1. Pull the change and rebase on the current main branch
> > > >> 2. Build the project (e.g. from IDE, which should be faster than
> > > >> building entire project from cmd) -> this should ensure the project
> > > compiles
> > > >> 3. Run the tests in the module that the change affects -> this
> > should
> > > >> greatly minimize the chances of failling tests
> > > >> 4. Push the change to the main branch
> > > >>
> > > >> Let us know what you think!
> > > >>
> > > >> Best,
> > > >>
> > > >> Guowei & Dawid
> > > >>
> > > >>
> > > >>
> > >
> > >
> >
Re: Apply external 3 days for FLINK-20387 after feature freeze
Posted by Jark Wu <im...@gmail.com>.
+1 for more days for this FLIP.
Changing data type is a massive work, and supporting windowing on
timestamp_ltz is also
a very complex job when considering DST. Would be great if we can have
more days to
finalize this work.
Best,
Jark
On Thu, 1 Apr 2021 at 03:46, Timo Walther <tw...@apache.org> wrote:
> Hi everyone,
>
> I support Leonard's request. It was foreseeable that the changes of
> FLIP-162 will be massive and will take some time. By looking at PRs such as
>
> https://github.com/apache/flink/pull/15280
>
> I would also vote for giving a bit more time for proper reviews and
> finalizing this story for consistency.
>
> Regards,
> Timo
>
>
>
> On 31.03.21 17:56, Leonard Xu wrote:
> > Hi, Dawid & Guowei
> >
> > Sorry to apply the extension, I want to apply 3 days for ticket
> [FLINK-20387] Support column of TIMESTAMP WITH LOCAL ZONE TIME type as
> rowtime[1], it is the last ticket of FLIP-162[2] which aims to solve
> various time zone issues and offer a consistent time function behavior. We
> experienced a long discussion for this FLIP and I took some efforts to
> resolve the tricky daylight saving time problem. In fact, I have been
> working hard to promote this FLIP recently.
> >
> > But I really hope that this feature can join 1.13. The motivation is not
> because I want to complete this FLIP personally, but from the user's
> perspective that we can provide them a consistent time behavior and
> resolves the time zone issues naturally, we believe this will greatly
> improve the user experience, thus I’m asking to apply 3 days for only this
> ticket FLINK-20387.
> >
> > Best,
> > Leonard
> >
> > [1] https://issues.apache.org/jira/browse/FLINK-20387
> > [2]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-162%3A+Consistent+Flink+SQL+time+function+behavior
> >
> >
> >> 在 2021年3月31日，17:54，Guowei Ma <gu...@gmail.com> 写道：
> >>
> >> Hi, community:
> >>
> >> Friendly reminder that today (3.31) is the last day of feature
> development. Under normal circumstances, you will not be able to submit new
> features from tomorrow (4.1). Tomorrow we will create 1.13.0-rc0 for
> testing, welcome to help test together.
> >> After the test is relatively stable, we will cut the release-1.13
> branch.
> >>
> >> Best,
> >> Dawid & Guowei
> >>
> >>
> >> On Mon, Mar 29, 2021 at 5:17 PM Till Rohrmann <trohrmann@apache.org
> <ma...@apache.org>> wrote:
> >> +1 for the 31st of March for the feature freeze.
> >>
> >> Cheers,
> >> Till
> >>
> >> On Mon, Mar 29, 2021 at 10:12 AM Robert Metzger <rmetzger@apache.org
> <ma...@apache.org>> wrote:
> >>
> >>> +1 for March 31st for the feature freeze.
> >>>
> >>>
> >>>
> >>> On Fri, Mar 26, 2021 at 3:39 PM Dawid Wysakowicz <
> dwysakowicz@apache.org <ma...@apache.org>>
> >>> wrote:
> >>>
> >>>> Thank you Thomas! I'll definitely check the issue you linked.
> >>>>
> >>>> Best,
> >>>>
> >>>> Dawid
> >>>>
> >>>> On 23/03/2021 20:35, Thomas Weise wrote:
> >>>>> Hi Dawid,
> >>>>>
> >>>>> Thanks for the heads up.
> >>>>>
> >>>>> Regarding the "Rebase and merge" button. I find that merge option
> >>> useful,
> >>>>> especially for small simple changes and for backports. The following
> >>>> should
> >>>>> help to safeguard from the issue encountered previously:
> >>>>> https://github.com/jazzband/pip-tools/issues/1085 <
> https://github.com/jazzband/pip-tools/issues/1085>
> >>>>>
> >>>>> Thanks,
> >>>>> Thomas
> >>>>>
> >>>>>
> >>>>> On Tue, Mar 23, 2021 at 4:58 AM Dawid Wysakowicz <
> >>> dwysakowicz@apache.org <ma...@apache.org>
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi devs, users!
> >>>>>>
> >>>>>> 1. *Feature freeze date*
> >>>>>>
> >>>>>> We are approaching the end of March which we agreed would be the
> time
> >>>> for
> >>>>>> a Feature Freeze. From the knowledge I've gather so far it still
> seems
> >>>> to
> >>>>>> be a viable plan. I think it is a good time to agree on a particular
> >>>> date,
> >>>>>> when it should happen. We suggest *(end of day CEST) March 31st*
> >>>>>> (Wednesday next week) as the feature freeze time.
> >>>>>>
> >>>>>> Similarly as last 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.
> >>>>>>
> >>>>>> Having said that let us remind after Robert & Dian from the previous
> >>>>>> release what it a Feature Freeze means:
> >>>>>>
> >>>>>> *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.
> >>>>>>
> >>>>>> 2. *Merge PRs from the command line*
> >>>>>>
> >>>>>> In the past releases it was quite frequent around the Feature Freeze
> >>>> date
> >>>>>> that we ended up with a broken main branch that either did not
> compile
> >>>> or
> >>>>>> there were failing tests. It was often due to concurrent merges to
> the
> >>>> main
> >>>>>> branch via the "Rebase and merge" button. To overcome the problem we
> >>>> would
> >>>>>> like to suggest only ever merging PRs from a command line. Thank you
> >>>>>> Stephan for the idea! The suggested workflow would look as follows:
> >>>>>>
> >>>>>> 1. Pull the change and rebase on the current main branch
> >>>>>> 2. Build the project (e.g. from IDE, which should be faster than
> >>>>>> building entire project from cmd) -> this should ensure the
> project
> >>>> compiles
> >>>>>> 3. Run the tests in the module that the change affects -> this
> >>> should
> >>>>>> greatly minimize the chances of failling tests
> >>>>>> 4. Push the change to the main branch
> >>>>>>
> >>>>>> Let us know what you think!
> >>>>>>
> >>>>>> Best,
> >>>>>>
> >>>>>> Guowei & Dawid
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >
> >
>
>
Re: Apply external 3 days for FLINK-20387 after feature freeze
Posted by Timo Walther <tw...@apache.org>.
Hi everyone,
I support Leonard's request. It was foreseeable that the changes of
FLIP-162 will be massive and will take some time. By looking at PRs such as
https://github.com/apache/flink/pull/15280
I would also vote for giving a bit more time for proper reviews and
finalizing this story for consistency.
Regards,
Timo
On 31.03.21 17:56, Leonard Xu wrote:
> Hi, Dawid & Guowei
>
> Sorry to apply the extension, I want to apply 3 days for ticket [FLINK-20387] Support column of TIMESTAMP WITH LOCAL ZONE TIME type as rowtime[1], it is the last ticket of FLIP-162[2] which aims to solve various time zone issues and offer a consistent time function behavior. We experienced a long discussion for this FLIP and I took some efforts to resolve the tricky daylight saving time problem. In fact, I have been working hard to promote this FLIP recently.
>
> But I really hope that this feature can join 1.13. The motivation is not because I want to complete this FLIP personally, but from the user's perspective that we can provide them a consistent time behavior and resolves the time zone issues naturally, we believe this will greatly improve the user experience, thus I’m asking to apply 3 days for only this ticket FLINK-20387.
>
> Best,
> Leonard
>
> [1] https://issues.apache.org/jira/browse/FLINK-20387
> [2] https://cwiki.apache.org/confluence/display/FLINK/FLIP-162%3A+Consistent+Flink+SQL+time+function+behavior
>
>
>> 在 2021年3月31日，17:54，Guowei Ma <gu...@gmail.com> 写道：
>>
>> Hi, community:
>>
>> Friendly reminder that today (3.31) is the last day of feature development. Under normal circumstances, you will not be able to submit new features from tomorrow (4.1). Tomorrow we will create 1.13.0-rc0 for testing, welcome to help test together.
>> After the test is relatively stable, we will cut the release-1.13 branch.
>>
>> Best,
>> Dawid & Guowei
>>
>>
>> On Mon, Mar 29, 2021 at 5:17 PM Till Rohrmann <trohrmann@apache.org <ma...@apache.org>> wrote:
>> +1 for the 31st of March for the feature freeze.
>>
>> Cheers,
>> Till
>>
>> On Mon, Mar 29, 2021 at 10:12 AM Robert Metzger <rmetzger@apache.org <ma...@apache.org>> wrote:
>>
>>> +1 for March 31st for the feature freeze.
>>>
>>>
>>>
>>> On Fri, Mar 26, 2021 at 3:39 PM Dawid Wysakowicz <dwysakowicz@apache.org <ma...@apache.org>>
>>> wrote:
>>>
>>>> Thank you Thomas! I'll definitely check the issue you linked.
>>>>
>>>> Best,
>>>>
>>>> Dawid
>>>>
>>>> On 23/03/2021 20:35, Thomas Weise wrote:
>>>>> Hi Dawid,
>>>>>
>>>>> Thanks for the heads up.
>>>>>
>>>>> Regarding the "Rebase and merge" button. I find that merge option
>>> useful,
>>>>> especially for small simple changes and for backports. The following
>>>> should
>>>>> help to safeguard from the issue encountered previously:
>>>>> https://github.com/jazzband/pip-tools/issues/1085 <https://github.com/jazzband/pip-tools/issues/1085>
>>>>>
>>>>> Thanks,
>>>>> Thomas
>>>>>
>>>>>
>>>>> On Tue, Mar 23, 2021 at 4:58 AM Dawid Wysakowicz <
>>> dwysakowicz@apache.org <ma...@apache.org>
>>>>>
>>>>> wrote:
>>>>>
>>>>>> Hi devs, users!
>>>>>>
>>>>>> 1. *Feature freeze date*
>>>>>>
>>>>>> We are approaching the end of March which we agreed would be the time
>>>> for
>>>>>> a Feature Freeze. From the knowledge I've gather so far it still seems
>>>> to
>>>>>> be a viable plan. I think it is a good time to agree on a particular
>>>> date,
>>>>>> when it should happen. We suggest *(end of day CEST) March 31st*
>>>>>> (Wednesday next week) as the feature freeze time.
>>>>>>
>>>>>> Similarly as last 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.
>>>>>>
>>>>>> Having said that let us remind after Robert & Dian from the previous
>>>>>> release what it a Feature Freeze means:
>>>>>>
>>>>>> *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.
>>>>>>
>>>>>> 2. *Merge PRs from the command line*
>>>>>>
>>>>>> In the past releases it was quite frequent around the Feature Freeze
>>>> date
>>>>>> that we ended up with a broken main branch that either did not compile
>>>> or
>>>>>> there were failing tests. It was often due to concurrent merges to the
>>>> main
>>>>>> branch via the "Rebase and merge" button. To overcome the problem we
>>>> would
>>>>>> like to suggest only ever merging PRs from a command line. Thank you
>>>>>> Stephan for the idea! The suggested workflow would look as follows:
>>>>>>
>>>>>> 1. Pull the change and rebase on the current main branch
>>>>>> 2. Build the project (e.g. from IDE, which should be faster than
>>>>>> building entire project from cmd) -> this should ensure the project
>>>> compiles
>>>>>> 3. Run the tests in the module that the change affects -> this
>>> should
>>>>>> greatly minimize the chances of failling tests
>>>>>> 4. Push the change to the main branch
>>>>>>
>>>>>> Let us know what you think!
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Guowei & Dawid
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>
>