+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 <twal...@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 <guowei....@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 <trohrm...@apache.org > <mailto:trohrm...@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 <rmetz...@apache.org > <mailto:rmetz...@apache.org>> wrote: > >> > >>> +1 for March 31st for the feature freeze. > >>> > >>> > >>> > >>> On Fri, Mar 26, 2021 at 3:39 PM Dawid Wysakowicz < > dwysakow...@apache.org <mailto:dwysakow...@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 < > >>> dwysakow...@apache.org <mailto:dwysakow...@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 > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >>> > > > > > >
