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
