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.
B
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
of
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 whol
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 int
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 fe
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 Xuefu,
I disagree with "all those work would be wasted/useless", it would just
take effect 3 months later.
Regarding "I don't see eye to eye on how and when we had decided a
feature freeze", there was an official [ANNOUNCE] email that targeted
June 28 [1]. I think nobody is super strict a
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 t
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
towar
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 handle
12 matches
Mail list logo
