Hi Kurt,
I posted my opinion around this particular example in FLINK-13225.
Regarding the definition of "feature freeze": I think it is good to
write down more of the implicit processes that we had in the past. The
bylaws, coding guidelines, and a better FLIP process are very good steps
towards the right direction. However, not everything can be written down
and formulized. We should also remind ourselves of basic software
engineering principles. Merging a feature shortly before the actual
release is always dangerous. A feature needs time to settle down and be
tested for side-effects etc. Merging a feature with a lot of spaghetti
code, reflection magic, and a single IT case is not a complete feature
that is worth merging.
I hope we can improve here for the next release. Thanks for the open
discussion.
Regards,
Timo
Am 08.08.19 um 11:11 schrieb Kurt Young:
Hi Stephan,
Thanks for bringing this up. I think it's important and a good time to
discuss what
does *feature freeze* really means. At least to me, seems I have some
misunderstandings with this comparing to other community members. But as
you
pointed out in the jira and also in this mail, I think your understanding
makes sense
to me.
Maybe we can have a conclusion in the thread and put this into the project
bylaws
which are under discussion?
Regarding to FLINK-13225, I would like to hear other's opinion since I
merged it. But
I would like to revert it if someone voted for reverting it.
Sorry for the inconvenience I caused.
Best,
Kurt
On Thu, Aug 8, 2019 at 4:46 PM Stephan Ewen <se...@apache.org> wrote:
Hi all!
I would like to bring this topic up, because we saw quite a few "secret"
post-feature-freeze feature merges.
The latest example was https://issues.apache.org/jira/browse/FLINK-13225
I would like to make sure that we are all on the same page on what a
feature freeze means and how to handle possible additions after the feature
freeze.
My understanding was the following, and I assume that this was also the
understanding of the community when we started establishing the release
practice:
- Feature freeze is the date until new features can be merged.
- After the feature freeze, we only merge bug fixes, release relevant
tests (end to end tests), and documentation.
- Features should already be stable and have tests. It is not okay to
"get a foot in the door" before feature freeze by merging something that is
not ready (as a placeholder) and then fixing it post feature freeze.
- Extending functionality to new components is not a bug fix, it is a
feature.
- If someone wants to add a minor feature after the feature freeze, and
there is a good reason for that, it should be explicitly discussed. If
there is no objection, it can be merged.
Please let me know if you have a different understanding of what feature
freeze means.
Regarding the issue of FLINK-13225
<https://issues.apache.org/jira/browse/FLINK-13225>?
- Should we keep it?
- Should we revert it in the release-1.9 branch and only keep it for
master?
Best,
Stephan
