Sounds good to me. +1 from my side.
Regards,
Timo
Am 2/12/18 um 2:56 PM schrieb Aljoscha Krettek:
I agree with Chesnay: we should do a soft "feature freeze" first, were we agree
to not merge new features to master after that and then to the actual hard cutting of the
release branch a while later.
For actual dates, I'm proposing end of this week (16.02.2018) as soft feature
freeze and end of next week (23.02.2018) as the hard cut of the release branch?
What do you think?
--
Aljoscha
On 8. Feb 2018, at 10:15, Till Rohrmann <trohrm...@apache.org> wrote:
Local state recovery is almost completely done. Only some reviews and
merging of the final PRs is pending.
The network stack improvements are on a good way to be finished by the end
of this week or beginning of next week. To my knowledge we got recently
green Travis builds :-) The network stack changes will also include the
application level flow control and the back pressure based checkpoint
alignment. So only the last reviews and merging is missing.
Concerning Flip-6, I'm currently working on enabling Flip-6 by default.
There are still some smaller things left to be done but I'm confident that
we can resolve them quickly.
I agree that due to the big changes we should have a very thorough and
principled testing period where we put Flink through the paces.
Cheers,
Till
On Wed, Feb 7, 2018 at 10:55 AM, Chesnay Schepler <ches...@apache.org>
wrote:
As Aljoscha said we wanted to do 1.5 soon after 1.4 based on the
assumption that the 3 big features (FLIP-6, network stack changes, local
state recovery) are nearly done.
I'm unsure about local state recovery, but I still see open issues for
FLIP-6 and the network stack rework.
As such it doesn't make sense to release 1.5 now.
Given the large scope of these features I would very much prefer to have
them active on master for a while before a feature-freeze
to expose them to a wider audience.
IMO it will take at least another month before we can start the release
process for 1.5, i.e. the feature freeze.
(2 more weeks for implementation, 2 weeks on master for the dust to settle)
On 05.02.2018 22:39, Kostas Kloudas wrote:
Hi Aljoscha,
I believe that support for Broadcast State should also be in 1.5.
There is an open PR https://github.com/apache/flink/pull/5230 <
https://github.com/apache/flink/pull/5230> for that
and there are some pending issues related to scala api and documentation.
Thanks,
Kostas
On Feb 5, 2018, at 5:37 PM, Timo Walther <twal...@apache.org> wrote:
Hi Shuyi,
I will take a look at it again this week. I'm pretty sure it will be
part of 1.5.0.
Regards,
Timo
Am 2/5/18 um 5:25 PM schrieb Shuyi Chen:
Hi Aljoscha, can we get this feature in for 1.5.0? We have a lot of
internal users waiting for this feature.
[FLINK-7923 <https://issues.apache.org/jira/browse/FLINK-7923>] Support
accessing subfields of a Composite element in an Object Array type
column
Thanks a lot
Shuyi
On Mon, Feb 5, 2018 at 6:59 AM, Christophe Jolif <cjo...@gmail.com>
wrote:
Hi guys,
Sorry for jumping in, but I think
[FLINK-8101] Elasticsearch 6.X support
[FLINK-7386] Flink Elasticsearch 5 connector is not compatible with
Elasticsearch 5.2+ client
have long been awaited and there was one PR from me and from someone
else
showing the interest ;) So if you could consider it for 1.5 that would
be
great!
Thanks!
--
Christophe
On Mon, Feb 5, 2018 at 2:47 PM, Timo Walther <twal...@apache.org>
wrote:
Hi Aljoscha,
it would be great if we can include the first version of the SQL
client
(see FLIP-24, Implementation Plan 1). I will open a PR this week. I
think
we can merge this with explicit "experimental/alpha" status. It is far
away
from feature completeness but will be a great tool for Flink
beginners.
In order to use the SQL client we would need to also add some table
sources with the new unified table factories (FLINK-8535), but this is
optional because a user can implement own table factories at the
begining.
Regards,
Timo
Am 2/5/18 um 2:36 PM schrieb Tzu-Li (Gordon) Tai:
Hi Aljoscha,
Thanks for starting the discussion.
I think there’s a few connector related must-have improvements that
we
should get in before the feature freeze, since quite a few users have
been
asking for them:
[FLINK-6352] FlinkKafkaConsumer should support to use timestamp to
set
up
start offset
[FLINK-5479] Per-partition watermarks in FlinkKafkaConsumer should
consider idle partitions
[FLINK-8516] Pluggable shard-to-subtask partitioning for
FlinkKinesisConsumer
[FLINK-6109] Add a “checkpointed offset” metric to FlinkKafkaConsumer
These are still missing in the master branch. Only FLINK-5479 is
still
lacking a pull request.
Cheers,
Gordon
On 31 January 2018 at 10:38:43 AM, Aljoscha Krettek (
aljos...@apache.org)
wrote:
Hi Everyone,
When we decided to do the 1.4.0 release a while back we did that to
get
a
stable release out before putting in a couple of new features. Back
then,
some of those new features (FLIP-6, network stack changes, local state
recovery) were almost ready and we wanted to do a shortened 1.5.0
development cycle to allow for those features to become ready and
then
do
the next release.
We are now approaching the approximate time where we wanted to do the
Flink 1.5.0 release so I would like to gauge where we are and gather
opinions on how we should proceed now.
With this, I'd also like to propose myself as the release manager for
1.5.0 but I'm very happy to yield if someone else would be
interested in
doing that.
What do you think?
Best,
Aljoscha
--
Christophe
