[DISCUSS] Feature freeze date for 1.13

Posted by Dawid Wysakowicz-2 on
URL: http://deprecated-apache-flink-user-mailing-list-archive.369.s1.nabble.com/DISCUSS-Feature-freeze-date-for-1-13-tp42472.html

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