Hi,
I agree with others in this thread that everyone should be focused on
making the release happen and not push their own agenda. It is generally
difficult to manage releases with so many interests and moving parts. Many
feel the urgency to complete what they were originally hoping to complete.
Thanks all for sharing thoughts. I agree with Tzu-li that release schedule
deserves a separate discussion. For the PR in question, I'd concur with
Till that we keep it due to its limited scope of impact. However, it would
be okay to me revert it if it's found to pose a big risk to the stability
I can only second Stephan's, Timo's, Piotr's and Gordon's points.
I also want to re-emphasize the importance of sticking to the agreed
processes for the community. If people merge features at free will after
the feature freeze, then they willingly put the release and with that the
work of the
Hi,
Just as a reminder, I think we should not focus here on discussing whether
or not time-based releases is a suitable release model for us.
That doesn’t seem to be the original intent of this thread, and is
therefore more suited for a separate discussion with the community,
especially taking
Hi Xuefu,
As others have mentioned, time based releases were decided because of some good
reasons (more predictability for users so that they can take that into account
for planning next upgrades). That doesn’t mean we can not allow for some
flexibility: we do, we have already postponed this
Hi Timo,
Thanks for sharing your opinion. By wastefulness, I meant we had planned
and done much work ending up with not being useful in the released product.
Instead of making many partial features, we'd rather make fewer but
complete features. We expected a good integration with Hive in 1.9, but
Again, feature freeze is not about "what was planned", it is a about what
is ready. Otherwise, it is completely unplannable when a release would come.
Everyone has a pet feature they want to see in. If everyone just makes
decisions by themselves and pushes, we can never get anywhere.
Disagreement
Hi all,
I understand the merged PR is a feature, but it's something we had planned
and requested for a long time. In fact, at Hive connector side, we have
done a lot of work (supporting hive udf). Without this PR, all those work
would be wasted and Hive feature itself in 1.9 would also be close
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
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
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
11 matches
Mail list logo
