You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Robert Metzger <rm...@apache.org> on 2017/05/26 16:58:58 UTC
[VOTE] Release Apache Flink 1.3.0 (RC3)
Hi all,
this is the second VOTEing release candidate for Flink 1.3.0
The commit to be voted on:
760eea8a <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>
(*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
<http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
Branch:
release-1.3.0-rc3
The release artifacts to be voted on can be found at:
http://people.apache.org/~rmetzger/flink-1.3.0-rc3
The release artifacts are signed with the key with fingerprint D9839159:
http://www.apache.org/dist/flink/KEYS
The staging repository for this release can be found at:
*https://repository.apache.org/content/repositories/orgapacheflink-1122
<https://repository.apache.org/content/repositories/orgapacheflink-1122>*
-------------------------------------------------------------
The vote ends on Tuesday (May 30th), 7pm CET.
[ ] +1 Release this package as Apache Flink 1.3.0
[ ] -1 Do not release this package, because ...
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by "Tzu-Li (Gordon) Tai" <tz...@apache.org>.
+1
Tests I did:
New features:
- Tested rescaling Kinesis Consumer + transparent shard discovery
- Tested topology changes on restore: changed chain orderings, added stateful / stateless operators, remove stateful / stateless operators
- Tested new Flink CEP features: loop states, quantifiers, NOT states, timeout handling
- Tested min / max network buffer size auto configuration
Checks on previous features / behavior:
- Kerberos authentication for Zookeeper, HDFS, Kafka, YARN
- Flink’s Kerberos authentication works nicely with MapR’s security
- Tested Flink on Mesos
- Tested backwards compatibility against Flink 1.2.1: empty 1.2 state, large 1.2 state, rescaled after the restore in 1.3
- Tested HA with YARN session mode + YARN cluster mode, works and no staged files dangling
- Ran random simple jobs with Kafka as source and sink + checkpoint in standalone / YARN session / per-job YARN
On 30 May 2017 at 11:39:14 AM, Aljoscha Krettek (aljoscha@apache.org) wrote:
+1
I did:
- manually check the release using the new end-to-end tests: https://github.com/apache/flink/pull/3911 <https://github.com/apache/flink/pull/3911>.
- verify that the source builds
- Check the (transitive) dependencies of flink-dist compared to 1.2.x. The new deps are: com.squareup.okio (ASL), com.squareup.okhttp3 (ASL) (due to shading this does not catch all dependencies, though)
> On 30. May 2017, at 10:58, Robert Metzger <rm...@apache.org> wrote:
>
> Thank you all for the +1 votes so far.
>
> As far as I see it, none of the issues mentioned in the thread are blockers.
>
> I've started putting together the blog post for the release announcement.
> It is ready to review here: https://github.com/apache/flink-web/pull/62
>
> On Mon, May 29, 2017 at 5:16 PM, jincheng sun <su...@gmail.com>
> wrote:
>
>> Hi Robert,
>>
>> +1 to release:
>>
>> Check items have been checked, as follows: (flink-table)
>>
>> 1.Check that the JAVA and SCALA logical plans are consistent.
>> 2.Check that the SQL and Table API logical plans are consistent.
>> 3.Check that UDF, UDTF, and UDAF are working properly in group-windows and
>> over-windows.
>> 4.Check that all built-in Agg on Batch and Stream are working properly.
>> 5.Let types such as Timestamp, BigDecimal or Pojo flow through UDF. UDTF,
>> UDAF (input and output types).
>>
>> Cheers,
>> SunJincheng
>>
>>
>> 2017-05-29 22:57 GMT+08:00 Gyula Fóra <gy...@gmail.com>:
>>
>>> Hi,
>>>
>>> I have found an issue with rescaling incremental checkpoints:
>>> https://issues.apache.org/jira/browse/FLINK-6762
>>>
>>> I am not sure if this is regarded as a blocker, it depends on our
>>> assumptions about externalized checkpoints.
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Gyula
>>>
>>> Robert Metzger <rm...@apache.org> ezt írta (időpont: 2017. máj. 29.,
>> H,
>>> 15:59):
>>>
>>>> +1 to release:
>>>>
>>>> - Tested building job against staging repository
>>>> - tested YARN session start and container recovery on YARN
>>>> - Validated HA on YARN (per job and session mode)
>>>> - Incremental checkpointing with rocksdb works
>>>> - FsStatebackend with async snapshots works
>>>>
>>>> - Flink builds from source on Linux (includes rat license header check)
>>>> - source doesn't contain binaries
>>>> - checked md5 / sha512 sum of source archive (assuming the other sums
>> are
>>>> valid as well)
>>>>
>>>>
>>>> I noticed one minor thing: the copyright in the NOTICE file is
>> 2014-2016.
>>>> I'll update it on master and the release branch.
>>>>
>>>>
>>>> On Mon, May 29, 2017 at 12:42 PM, Chesnay Schepler <chesnay@apache.org
>>>
>>>> wrote:
>>>>
>>>>> +1
>>>>>
>>>>> * Builds from source
>>>>> * start/stop scripts work
>>>>> * logs don't show anything suspicious on startup/shutdown
>>>>> * ran some example jobs
>>>>> * ran jobs on yarn with exactly-once & RocksDB
>>>>> o canceling with savepoint/resuming from savepoint
>>>>> o without/with rescaling
>>>>> * SideOutputs work
>>>>> * Metrics are properly transmitted & displayed in the webUI
>>>>>
>>>>>
>>>>> On 28.05.2017 20:33, Robert Metzger wrote:
>>>>>
>>>>>> @Shaoxuan, I don't think missing documentation is a release blocker,
>>> but
>>>>>> it's something we should fix asap and with high priority :)
>>>>>> Since the documentation is not bundled with the release, and the
>> docs
>>>> are
>>>>>> build off the "release-x.y" branch, we can always update them (even
>>>> after
>>>>>> the release).
>>>>>>
>>>>>> However, it makes sense to have the docs ready when we announce the
>>>>>> release
>>>>>> so that users can understand how to use the newly released features.
>>>>>>
>>>>>> On Sat, May 27, 2017 at 6:14 PM, Chesnay Schepler <
>> chesnay@apache.org
>>>>
>>>>>> wrote:
>>>>>>
>>>>>> I've responded in the JIRA. In my opinion isn't a functional issue,
>>> but
>>>>>>> more about improving
>>>>>>> error messages/documentation.
>>>>>>>
>>>>>>>
>>>>>>> On 27.05.2017 18:07, Gyula Fóra wrote:
>>>>>>>
>>>>>>> Hi!
>>>>>>>> I have found this issue: https://issues.apache.org/jira
>>>>>>>> /browse/FLINK-6742
>>>>>>>>
>>>>>>>> Not sure if it's a blocker or not (not even completely sure what
>>>> causes
>>>>>>>> it
>>>>>>>> at the moment)
>>>>>>>>
>>>>>>>> Gyula
>>>>>>>>
>>>>>>>> Shaoxuan Wang <ws...@gmail.com> ezt írta (időpont: 2017. máj.
>>>> 27.,
>>>>>>>> Szo,
>>>>>>>> 6:30):
>>>>>>>>
>>>>>>>> Hi Robert.
>>>>>>>>
>>>>>>>>> Will doc update be a blocker for release?
>>>>>>>>> Release 1.3 has many updates on tableAPI and SQL, and the docs
>> are
>>>> kind
>>>>>>>>> of
>>>>>>>>> lagging. We are trying the efforts to update the doc as much as
>>>>>>>>> possible
>>>>>>>>> before the release is officially published, but I am hoping this
>> is
>>>>>>>>> not a
>>>>>>>>> blocker for the release.
>>>>>>>>>
>>>>>>>>> Shaoxuan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, May 27, 2017 at 12:58 AM, Robert Metzger <
>>>> rmetzger@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>>> this is the second VOTEing release candidate for Flink 1.3.0
>>>>>>>>>>
>>>>>>>>>> The commit to be voted on:
>>>>>>>>>> 760eea8a <
>>>> http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8
>>>>>>>>>> a>
>>>>>>>>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
>>>>>>>>>> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
>>> *)
>>>>>>>>>>
>>>>>>>>>> Branch:
>>>>>>>>>> release-1.3.0-rc3
>>>>>>>>>>
>>>>>>>>>> The release artifacts to be voted on can be found at:
>>>>>>>>>> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The release artifacts are signed with the key with fingerprint
>>>>>>>>>> D9839159:
>>>>>>>>>> http://www.apache.org/dist/flink/KEYS
>>>>>>>>>>
>>>>>>>>>> The staging repository for this release can be found at:
>>>>>>>>>> *https://repository.apache.org/content/repositories/orgapach
>>>>>>>>>> eflink-1122
>>>>>>>>>> <https://repository.apache.org/content/repositories/orgapach
>>>>>>>>>> eflink-1122
>>>>>>>>>> *
>>>>>>>>>>
>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The vote ends on Tuesday (May 30th), 7pm CET.
>>>>>>>>>>
>>>>>>>>>> [ ] +1 Release this package as Apache Flink 1.3.0
>>>>>>>>>> [ ] -1 Do not release this package, because ...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>
>>>>
>>>
>>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Aljoscha Krettek <al...@apache.org>.
+1
I did:
- manually check the release using the new end-to-end tests: https://github.com/apache/flink/pull/3911 <https://github.com/apache/flink/pull/3911>.
- verify that the source builds
- Check the (transitive) dependencies of flink-dist compared to 1.2.x. The new deps are: com.squareup.okio (ASL), com.squareup.okhttp3 (ASL) (due to shading this does not catch all dependencies, though)
> On 30. May 2017, at 10:58, Robert Metzger <rm...@apache.org> wrote:
>
> Thank you all for the +1 votes so far.
>
> As far as I see it, none of the issues mentioned in the thread are blockers.
>
> I've started putting together the blog post for the release announcement.
> It is ready to review here: https://github.com/apache/flink-web/pull/62
>
> On Mon, May 29, 2017 at 5:16 PM, jincheng sun <su...@gmail.com>
> wrote:
>
>> Hi Robert,
>>
>> +1 to release:
>>
>> Check items have been checked, as follows: (flink-table)
>>
>> 1.Check that the JAVA and SCALA logical plans are consistent.
>> 2.Check that the SQL and Table API logical plans are consistent.
>> 3.Check that UDF, UDTF, and UDAF are working properly in group-windows and
>> over-windows.
>> 4.Check that all built-in Agg on Batch and Stream are working properly.
>> 5.Let types such as Timestamp, BigDecimal or Pojo flow through UDF. UDTF,
>> UDAF (input and output types).
>>
>> Cheers,
>> SunJincheng
>>
>>
>> 2017-05-29 22:57 GMT+08:00 Gyula Fóra <gy...@gmail.com>:
>>
>>> Hi,
>>>
>>> I have found an issue with rescaling incremental checkpoints:
>>> https://issues.apache.org/jira/browse/FLINK-6762
>>>
>>> I am not sure if this is regarded as a blocker, it depends on our
>>> assumptions about externalized checkpoints.
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Gyula
>>>
>>> Robert Metzger <rm...@apache.org> ezt írta (időpont: 2017. máj. 29.,
>> H,
>>> 15:59):
>>>
>>>> +1 to release:
>>>>
>>>> - Tested building job against staging repository
>>>> - tested YARN session start and container recovery on YARN
>>>> - Validated HA on YARN (per job and session mode)
>>>> - Incremental checkpointing with rocksdb works
>>>> - FsStatebackend with async snapshots works
>>>>
>>>> - Flink builds from source on Linux (includes rat license header check)
>>>> - source doesn't contain binaries
>>>> - checked md5 / sha512 sum of source archive (assuming the other sums
>> are
>>>> valid as well)
>>>>
>>>>
>>>> I noticed one minor thing: the copyright in the NOTICE file is
>> 2014-2016.
>>>> I'll update it on master and the release branch.
>>>>
>>>>
>>>> On Mon, May 29, 2017 at 12:42 PM, Chesnay Schepler <chesnay@apache.org
>>>
>>>> wrote:
>>>>
>>>>> +1
>>>>>
>>>>> * Builds from source
>>>>> * start/stop scripts work
>>>>> * logs don't show anything suspicious on startup/shutdown
>>>>> * ran some example jobs
>>>>> * ran jobs on yarn with exactly-once & RocksDB
>>>>> o canceling with savepoint/resuming from savepoint
>>>>> o without/with rescaling
>>>>> * SideOutputs work
>>>>> * Metrics are properly transmitted & displayed in the webUI
>>>>>
>>>>>
>>>>> On 28.05.2017 20:33, Robert Metzger wrote:
>>>>>
>>>>>> @Shaoxuan, I don't think missing documentation is a release blocker,
>>> but
>>>>>> it's something we should fix asap and with high priority :)
>>>>>> Since the documentation is not bundled with the release, and the
>> docs
>>>> are
>>>>>> build off the "release-x.y" branch, we can always update them (even
>>>> after
>>>>>> the release).
>>>>>>
>>>>>> However, it makes sense to have the docs ready when we announce the
>>>>>> release
>>>>>> so that users can understand how to use the newly released features.
>>>>>>
>>>>>> On Sat, May 27, 2017 at 6:14 PM, Chesnay Schepler <
>> chesnay@apache.org
>>>>
>>>>>> wrote:
>>>>>>
>>>>>> I've responded in the JIRA. In my opinion isn't a functional issue,
>>> but
>>>>>>> more about improving
>>>>>>> error messages/documentation.
>>>>>>>
>>>>>>>
>>>>>>> On 27.05.2017 18:07, Gyula Fóra wrote:
>>>>>>>
>>>>>>> Hi!
>>>>>>>> I have found this issue: https://issues.apache.org/jira
>>>>>>>> /browse/FLINK-6742
>>>>>>>>
>>>>>>>> Not sure if it's a blocker or not (not even completely sure what
>>>> causes
>>>>>>>> it
>>>>>>>> at the moment)
>>>>>>>>
>>>>>>>> Gyula
>>>>>>>>
>>>>>>>> Shaoxuan Wang <ws...@gmail.com> ezt írta (időpont: 2017. máj.
>>>> 27.,
>>>>>>>> Szo,
>>>>>>>> 6:30):
>>>>>>>>
>>>>>>>> Hi Robert.
>>>>>>>>
>>>>>>>>> Will doc update be a blocker for release?
>>>>>>>>> Release 1.3 has many updates on tableAPI and SQL, and the docs
>> are
>>>> kind
>>>>>>>>> of
>>>>>>>>> lagging. We are trying the efforts to update the doc as much as
>>>>>>>>> possible
>>>>>>>>> before the release is officially published, but I am hoping this
>> is
>>>>>>>>> not a
>>>>>>>>> blocker for the release.
>>>>>>>>>
>>>>>>>>> Shaoxuan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, May 27, 2017 at 12:58 AM, Robert Metzger <
>>>> rmetzger@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>>> this is the second VOTEing release candidate for Flink 1.3.0
>>>>>>>>>>
>>>>>>>>>> The commit to be voted on:
>>>>>>>>>> 760eea8a <
>>>> http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8
>>>>>>>>>> a>
>>>>>>>>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
>>>>>>>>>> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
>>> *)
>>>>>>>>>>
>>>>>>>>>> Branch:
>>>>>>>>>> release-1.3.0-rc3
>>>>>>>>>>
>>>>>>>>>> The release artifacts to be voted on can be found at:
>>>>>>>>>> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The release artifacts are signed with the key with fingerprint
>>>>>>>>>> D9839159:
>>>>>>>>>> http://www.apache.org/dist/flink/KEYS
>>>>>>>>>>
>>>>>>>>>> The staging repository for this release can be found at:
>>>>>>>>>> *https://repository.apache.org/content/repositories/orgapach
>>>>>>>>>> eflink-1122
>>>>>>>>>> <https://repository.apache.org/content/repositories/orgapach
>>>>>>>>>> eflink-1122
>>>>>>>>>> *
>>>>>>>>>>
>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The vote ends on Tuesday (May 30th), 7pm CET.
>>>>>>>>>>
>>>>>>>>>> [ ] +1 Release this package as Apache Flink 1.3.0
>>>>>>>>>> [ ] -1 Do not release this package, because ...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>
>>>>
>>>
>>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Robert Metzger <rm...@apache.org>.
Thank you all for the +1 votes so far.
As far as I see it, none of the issues mentioned in the thread are blockers.
I've started putting together the blog post for the release announcement.
It is ready to review here: https://github.com/apache/flink-web/pull/62
On Mon, May 29, 2017 at 5:16 PM, jincheng sun <su...@gmail.com>
wrote:
> Hi Robert,
>
> +1 to release:
>
> Check items have been checked, as follows: (flink-table)
>
> 1.Check that the JAVA and SCALA logical plans are consistent.
> 2.Check that the SQL and Table API logical plans are consistent.
> 3.Check that UDF, UDTF, and UDAF are working properly in group-windows and
> over-windows.
> 4.Check that all built-in Agg on Batch and Stream are working properly.
> 5.Let types such as Timestamp, BigDecimal or Pojo flow through UDF. UDTF,
> UDAF (input and output types).
>
> Cheers,
> SunJincheng
>
>
> 2017-05-29 22:57 GMT+08:00 Gyula Fóra <gy...@gmail.com>:
>
> > Hi,
> >
> > I have found an issue with rescaling incremental checkpoints:
> > https://issues.apache.org/jira/browse/FLINK-6762
> >
> > I am not sure if this is regarded as a blocker, it depends on our
> > assumptions about externalized checkpoints.
> >
> > What do you think?
> >
> > Cheers,
> > Gyula
> >
> > Robert Metzger <rm...@apache.org> ezt írta (időpont: 2017. máj. 29.,
> H,
> > 15:59):
> >
> > > +1 to release:
> > >
> > > - Tested building job against staging repository
> > > - tested YARN session start and container recovery on YARN
> > > - Validated HA on YARN (per job and session mode)
> > > - Incremental checkpointing with rocksdb works
> > > - FsStatebackend with async snapshots works
> > >
> > > - Flink builds from source on Linux (includes rat license header check)
> > > - source doesn't contain binaries
> > > - checked md5 / sha512 sum of source archive (assuming the other sums
> are
> > > valid as well)
> > >
> > >
> > > I noticed one minor thing: the copyright in the NOTICE file is
> 2014-2016.
> > > I'll update it on master and the release branch.
> > >
> > >
> > > On Mon, May 29, 2017 at 12:42 PM, Chesnay Schepler <chesnay@apache.org
> >
> > > wrote:
> > >
> > > > +1
> > > >
> > > > * Builds from source
> > > > * start/stop scripts work
> > > > * logs don't show anything suspicious on startup/shutdown
> > > > * ran some example jobs
> > > > * ran jobs on yarn with exactly-once & RocksDB
> > > > o canceling with savepoint/resuming from savepoint
> > > > o without/with rescaling
> > > > * SideOutputs work
> > > > * Metrics are properly transmitted & displayed in the webUI
> > > >
> > > >
> > > > On 28.05.2017 20:33, Robert Metzger wrote:
> > > >
> > > >> @Shaoxuan, I don't think missing documentation is a release blocker,
> > but
> > > >> it's something we should fix asap and with high priority :)
> > > >> Since the documentation is not bundled with the release, and the
> docs
> > > are
> > > >> build off the "release-x.y" branch, we can always update them (even
> > > after
> > > >> the release).
> > > >>
> > > >> However, it makes sense to have the docs ready when we announce the
> > > >> release
> > > >> so that users can understand how to use the newly released features.
> > > >>
> > > >> On Sat, May 27, 2017 at 6:14 PM, Chesnay Schepler <
> chesnay@apache.org
> > >
> > > >> wrote:
> > > >>
> > > >> I've responded in the JIRA. In my opinion isn't a functional issue,
> > but
> > > >>> more about improving
> > > >>> error messages/documentation.
> > > >>>
> > > >>>
> > > >>> On 27.05.2017 18:07, Gyula Fóra wrote:
> > > >>>
> > > >>> Hi!
> > > >>>> I have found this issue: https://issues.apache.org/jira
> > > >>>> /browse/FLINK-6742
> > > >>>>
> > > >>>> Not sure if it's a blocker or not (not even completely sure what
> > > causes
> > > >>>> it
> > > >>>> at the moment)
> > > >>>>
> > > >>>> Gyula
> > > >>>>
> > > >>>> Shaoxuan Wang <ws...@gmail.com> ezt írta (időpont: 2017. máj.
> > > 27.,
> > > >>>> Szo,
> > > >>>> 6:30):
> > > >>>>
> > > >>>> Hi Robert.
> > > >>>>
> > > >>>>> Will doc update be a blocker for release?
> > > >>>>> Release 1.3 has many updates on tableAPI and SQL, and the docs
> are
> > > kind
> > > >>>>> of
> > > >>>>> lagging. We are trying the efforts to update the doc as much as
> > > >>>>> possible
> > > >>>>> before the release is officially published, but I am hoping this
> is
> > > >>>>> not a
> > > >>>>> blocker for the release.
> > > >>>>>
> > > >>>>> Shaoxuan
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> On Sat, May 27, 2017 at 12:58 AM, Robert Metzger <
> > > rmetzger@apache.org>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>> Hi all,
> > > >>>>>
> > > >>>>>> this is the second VOTEing release candidate for Flink 1.3.0
> > > >>>>>>
> > > >>>>>> The commit to be voted on:
> > > >>>>>> 760eea8a <
> > > http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8
> > > >>>>>> a>
> > > >>>>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
> > > >>>>>> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
> >*)
> > > >>>>>>
> > > >>>>>> Branch:
> > > >>>>>> release-1.3.0-rc3
> > > >>>>>>
> > > >>>>>> The release artifacts to be voted on can be found at:
> > > >>>>>> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> The release artifacts are signed with the key with fingerprint
> > > >>>>>> D9839159:
> > > >>>>>> http://www.apache.org/dist/flink/KEYS
> > > >>>>>>
> > > >>>>>> The staging repository for this release can be found at:
> > > >>>>>> *https://repository.apache.org/content/repositories/orgapach
> > > >>>>>> eflink-1122
> > > >>>>>> <https://repository.apache.org/content/repositories/orgapach
> > > >>>>>> eflink-1122
> > > >>>>>> *
> > > >>>>>>
> > > >>>>>> -------------------------------------------------------------
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> The vote ends on Tuesday (May 30th), 7pm CET.
> > > >>>>>>
> > > >>>>>> [ ] +1 Release this package as Apache Flink 1.3.0
> > > >>>>>> [ ] -1 Do not release this package, because ...
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >
> > >
> >
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by jincheng sun <su...@gmail.com>.
Hi Robert,
+1 to release:
Check items have been checked, as follows: (flink-table)
1.Check that the JAVA and SCALA logical plans are consistent.
2.Check that the SQL and Table API logical plans are consistent.
3.Check that UDF, UDTF, and UDAF are working properly in group-windows and
over-windows.
4.Check that all built-in Agg on Batch and Stream are working properly.
5.Let types such as Timestamp, BigDecimal or Pojo flow through UDF. UDTF,
UDAF (input and output types).
Cheers,
SunJincheng
2017-05-29 22:57 GMT+08:00 Gyula Fóra <gy...@gmail.com>:
> Hi,
>
> I have found an issue with rescaling incremental checkpoints:
> https://issues.apache.org/jira/browse/FLINK-6762
>
> I am not sure if this is regarded as a blocker, it depends on our
> assumptions about externalized checkpoints.
>
> What do you think?
>
> Cheers,
> Gyula
>
> Robert Metzger <rm...@apache.org> ezt írta (időpont: 2017. máj. 29., H,
> 15:59):
>
> > +1 to release:
> >
> > - Tested building job against staging repository
> > - tested YARN session start and container recovery on YARN
> > - Validated HA on YARN (per job and session mode)
> > - Incremental checkpointing with rocksdb works
> > - FsStatebackend with async snapshots works
> >
> > - Flink builds from source on Linux (includes rat license header check)
> > - source doesn't contain binaries
> > - checked md5 / sha512 sum of source archive (assuming the other sums are
> > valid as well)
> >
> >
> > I noticed one minor thing: the copyright in the NOTICE file is 2014-2016.
> > I'll update it on master and the release branch.
> >
> >
> > On Mon, May 29, 2017 at 12:42 PM, Chesnay Schepler <ch...@apache.org>
> > wrote:
> >
> > > +1
> > >
> > > * Builds from source
> > > * start/stop scripts work
> > > * logs don't show anything suspicious on startup/shutdown
> > > * ran some example jobs
> > > * ran jobs on yarn with exactly-once & RocksDB
> > > o canceling with savepoint/resuming from savepoint
> > > o without/with rescaling
> > > * SideOutputs work
> > > * Metrics are properly transmitted & displayed in the webUI
> > >
> > >
> > > On 28.05.2017 20:33, Robert Metzger wrote:
> > >
> > >> @Shaoxuan, I don't think missing documentation is a release blocker,
> but
> > >> it's something we should fix asap and with high priority :)
> > >> Since the documentation is not bundled with the release, and the docs
> > are
> > >> build off the "release-x.y" branch, we can always update them (even
> > after
> > >> the release).
> > >>
> > >> However, it makes sense to have the docs ready when we announce the
> > >> release
> > >> so that users can understand how to use the newly released features.
> > >>
> > >> On Sat, May 27, 2017 at 6:14 PM, Chesnay Schepler <chesnay@apache.org
> >
> > >> wrote:
> > >>
> > >> I've responded in the JIRA. In my opinion isn't a functional issue,
> but
> > >>> more about improving
> > >>> error messages/documentation.
> > >>>
> > >>>
> > >>> On 27.05.2017 18:07, Gyula Fóra wrote:
> > >>>
> > >>> Hi!
> > >>>> I have found this issue: https://issues.apache.org/jira
> > >>>> /browse/FLINK-6742
> > >>>>
> > >>>> Not sure if it's a blocker or not (not even completely sure what
> > causes
> > >>>> it
> > >>>> at the moment)
> > >>>>
> > >>>> Gyula
> > >>>>
> > >>>> Shaoxuan Wang <ws...@gmail.com> ezt írta (időpont: 2017. máj.
> > 27.,
> > >>>> Szo,
> > >>>> 6:30):
> > >>>>
> > >>>> Hi Robert.
> > >>>>
> > >>>>> Will doc update be a blocker for release?
> > >>>>> Release 1.3 has many updates on tableAPI and SQL, and the docs are
> > kind
> > >>>>> of
> > >>>>> lagging. We are trying the efforts to update the doc as much as
> > >>>>> possible
> > >>>>> before the release is officially published, but I am hoping this is
> > >>>>> not a
> > >>>>> blocker for the release.
> > >>>>>
> > >>>>> Shaoxuan
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Sat, May 27, 2017 at 12:58 AM, Robert Metzger <
> > rmetzger@apache.org>
> > >>>>> wrote:
> > >>>>>
> > >>>>> Hi all,
> > >>>>>
> > >>>>>> this is the second VOTEing release candidate for Flink 1.3.0
> > >>>>>>
> > >>>>>> The commit to be voted on:
> > >>>>>> 760eea8a <
> > http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8
> > >>>>>> a>
> > >>>>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
> > >>>>>> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
> > >>>>>>
> > >>>>>> Branch:
> > >>>>>> release-1.3.0-rc3
> > >>>>>>
> > >>>>>> The release artifacts to be voted on can be found at:
> > >>>>>> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
> > >>>>>>
> > >>>>>>
> > >>>>>> The release artifacts are signed with the key with fingerprint
> > >>>>>> D9839159:
> > >>>>>> http://www.apache.org/dist/flink/KEYS
> > >>>>>>
> > >>>>>> The staging repository for this release can be found at:
> > >>>>>> *https://repository.apache.org/content/repositories/orgapach
> > >>>>>> eflink-1122
> > >>>>>> <https://repository.apache.org/content/repositories/orgapach
> > >>>>>> eflink-1122
> > >>>>>> *
> > >>>>>>
> > >>>>>> -------------------------------------------------------------
> > >>>>>>
> > >>>>>>
> > >>>>>> The vote ends on Tuesday (May 30th), 7pm CET.
> > >>>>>>
> > >>>>>> [ ] +1 Release this package as Apache Flink 1.3.0
> > >>>>>> [ ] -1 Do not release this package, because ...
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >
> >
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Stefan Richter <s....@data-artisans.com>.
Hi,
officially, we currently do not want to support rescaling from (incremental) checkpoints, but only from savepoints. For this reason, I would not consider this a blocking issue.
Unofficially, I think we are not too far away from supporting this, but there is a question mark behind the efficiency. The procedure will involve redundant data shuffling and reconstruction efforts because incremental checkpoints cannot track key-groups.
Best,
Stefan
> Am 29.05.2017 um 16:57 schrieb Gyula Fóra <gy...@gmail.com>:
>
> Hi,
>
> I have found an issue with rescaling incremental checkpoints:
> https://issues.apache.org/jira/browse/FLINK-6762
>
> I am not sure if this is regarded as a blocker, it depends on our
> assumptions about externalized checkpoints.
>
> What do you think?
>
> Cheers,
> Gyula
>
> Robert Metzger <rm...@apache.org> ezt írta (időpont: 2017. máj. 29., H,
> 15:59):
>
>> +1 to release:
>>
>> - Tested building job against staging repository
>> - tested YARN session start and container recovery on YARN
>> - Validated HA on YARN (per job and session mode)
>> - Incremental checkpointing with rocksdb works
>> - FsStatebackend with async snapshots works
>>
>> - Flink builds from source on Linux (includes rat license header check)
>> - source doesn't contain binaries
>> - checked md5 / sha512 sum of source archive (assuming the other sums are
>> valid as well)
>>
>>
>> I noticed one minor thing: the copyright in the NOTICE file is 2014-2016.
>> I'll update it on master and the release branch.
>>
>>
>> On Mon, May 29, 2017 at 12:42 PM, Chesnay Schepler <ch...@apache.org>
>> wrote:
>>
>>> +1
>>>
>>> * Builds from source
>>> * start/stop scripts work
>>> * logs don't show anything suspicious on startup/shutdown
>>> * ran some example jobs
>>> * ran jobs on yarn with exactly-once & RocksDB
>>> o canceling with savepoint/resuming from savepoint
>>> o without/with rescaling
>>> * SideOutputs work
>>> * Metrics are properly transmitted & displayed in the webUI
>>>
>>>
>>> On 28.05.2017 20:33, Robert Metzger wrote:
>>>
>>>> @Shaoxuan, I don't think missing documentation is a release blocker, but
>>>> it's something we should fix asap and with high priority :)
>>>> Since the documentation is not bundled with the release, and the docs
>> are
>>>> build off the "release-x.y" branch, we can always update them (even
>> after
>>>> the release).
>>>>
>>>> However, it makes sense to have the docs ready when we announce the
>>>> release
>>>> so that users can understand how to use the newly released features.
>>>>
>>>> On Sat, May 27, 2017 at 6:14 PM, Chesnay Schepler <ch...@apache.org>
>>>> wrote:
>>>>
>>>> I've responded in the JIRA. In my opinion isn't a functional issue, but
>>>>> more about improving
>>>>> error messages/documentation.
>>>>>
>>>>>
>>>>> On 27.05.2017 18:07, Gyula Fóra wrote:
>>>>>
>>>>> Hi!
>>>>>> I have found this issue: https://issues.apache.org/jira
>>>>>> /browse/FLINK-6742
>>>>>>
>>>>>> Not sure if it's a blocker or not (not even completely sure what
>> causes
>>>>>> it
>>>>>> at the moment)
>>>>>>
>>>>>> Gyula
>>>>>>
>>>>>> Shaoxuan Wang <ws...@gmail.com> ezt írta (időpont: 2017. máj.
>> 27.,
>>>>>> Szo,
>>>>>> 6:30):
>>>>>>
>>>>>> Hi Robert.
>>>>>>
>>>>>>> Will doc update be a blocker for release?
>>>>>>> Release 1.3 has many updates on tableAPI and SQL, and the docs are
>> kind
>>>>>>> of
>>>>>>> lagging. We are trying the efforts to update the doc as much as
>>>>>>> possible
>>>>>>> before the release is officially published, but I am hoping this is
>>>>>>> not a
>>>>>>> blocker for the release.
>>>>>>>
>>>>>>> Shaoxuan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, May 27, 2017 at 12:58 AM, Robert Metzger <
>> rmetzger@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>>> this is the second VOTEing release candidate for Flink 1.3.0
>>>>>>>>
>>>>>>>> The commit to be voted on:
>>>>>>>> 760eea8a <
>> http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8
>>>>>>>> a>
>>>>>>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
>>>>>>>> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
>>>>>>>>
>>>>>>>> Branch:
>>>>>>>> release-1.3.0-rc3
>>>>>>>>
>>>>>>>> The release artifacts to be voted on can be found at:
>>>>>>>> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
>>>>>>>>
>>>>>>>>
>>>>>>>> The release artifacts are signed with the key with fingerprint
>>>>>>>> D9839159:
>>>>>>>> http://www.apache.org/dist/flink/KEYS
>>>>>>>>
>>>>>>>> The staging repository for this release can be found at:
>>>>>>>> *https://repository.apache.org/content/repositories/orgapach
>>>>>>>> eflink-1122
>>>>>>>> <https://repository.apache.org/content/repositories/orgapach
>>>>>>>> eflink-1122
>>>>>>>> *
>>>>>>>>
>>>>>>>> -------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> The vote ends on Tuesday (May 30th), 7pm CET.
>>>>>>>>
>>>>>>>> [ ] +1 Release this package as Apache Flink 1.3.0
>>>>>>>> [ ] -1 Do not release this package, because ...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>
>>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Gyula Fóra <gy...@gmail.com>.
Hi,
I have found an issue with rescaling incremental checkpoints:
https://issues.apache.org/jira/browse/FLINK-6762
I am not sure if this is regarded as a blocker, it depends on our
assumptions about externalized checkpoints.
What do you think?
Cheers,
Gyula
Robert Metzger <rm...@apache.org> ezt írta (időpont: 2017. máj. 29., H,
15:59):
> +1 to release:
>
> - Tested building job against staging repository
> - tested YARN session start and container recovery on YARN
> - Validated HA on YARN (per job and session mode)
> - Incremental checkpointing with rocksdb works
> - FsStatebackend with async snapshots works
>
> - Flink builds from source on Linux (includes rat license header check)
> - source doesn't contain binaries
> - checked md5 / sha512 sum of source archive (assuming the other sums are
> valid as well)
>
>
> I noticed one minor thing: the copyright in the NOTICE file is 2014-2016.
> I'll update it on master and the release branch.
>
>
> On Mon, May 29, 2017 at 12:42 PM, Chesnay Schepler <ch...@apache.org>
> wrote:
>
> > +1
> >
> > * Builds from source
> > * start/stop scripts work
> > * logs don't show anything suspicious on startup/shutdown
> > * ran some example jobs
> > * ran jobs on yarn with exactly-once & RocksDB
> > o canceling with savepoint/resuming from savepoint
> > o without/with rescaling
> > * SideOutputs work
> > * Metrics are properly transmitted & displayed in the webUI
> >
> >
> > On 28.05.2017 20:33, Robert Metzger wrote:
> >
> >> @Shaoxuan, I don't think missing documentation is a release blocker, but
> >> it's something we should fix asap and with high priority :)
> >> Since the documentation is not bundled with the release, and the docs
> are
> >> build off the "release-x.y" branch, we can always update them (even
> after
> >> the release).
> >>
> >> However, it makes sense to have the docs ready when we announce the
> >> release
> >> so that users can understand how to use the newly released features.
> >>
> >> On Sat, May 27, 2017 at 6:14 PM, Chesnay Schepler <ch...@apache.org>
> >> wrote:
> >>
> >> I've responded in the JIRA. In my opinion isn't a functional issue, but
> >>> more about improving
> >>> error messages/documentation.
> >>>
> >>>
> >>> On 27.05.2017 18:07, Gyula Fóra wrote:
> >>>
> >>> Hi!
> >>>> I have found this issue: https://issues.apache.org/jira
> >>>> /browse/FLINK-6742
> >>>>
> >>>> Not sure if it's a blocker or not (not even completely sure what
> causes
> >>>> it
> >>>> at the moment)
> >>>>
> >>>> Gyula
> >>>>
> >>>> Shaoxuan Wang <ws...@gmail.com> ezt írta (időpont: 2017. máj.
> 27.,
> >>>> Szo,
> >>>> 6:30):
> >>>>
> >>>> Hi Robert.
> >>>>
> >>>>> Will doc update be a blocker for release?
> >>>>> Release 1.3 has many updates on tableAPI and SQL, and the docs are
> kind
> >>>>> of
> >>>>> lagging. We are trying the efforts to update the doc as much as
> >>>>> possible
> >>>>> before the release is officially published, but I am hoping this is
> >>>>> not a
> >>>>> blocker for the release.
> >>>>>
> >>>>> Shaoxuan
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sat, May 27, 2017 at 12:58 AM, Robert Metzger <
> rmetzger@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>>> this is the second VOTEing release candidate for Flink 1.3.0
> >>>>>>
> >>>>>> The commit to be voted on:
> >>>>>> 760eea8a <
> http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8
> >>>>>> a>
> >>>>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
> >>>>>> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
> >>>>>>
> >>>>>> Branch:
> >>>>>> release-1.3.0-rc3
> >>>>>>
> >>>>>> The release artifacts to be voted on can be found at:
> >>>>>> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
> >>>>>>
> >>>>>>
> >>>>>> The release artifacts are signed with the key with fingerprint
> >>>>>> D9839159:
> >>>>>> http://www.apache.org/dist/flink/KEYS
> >>>>>>
> >>>>>> The staging repository for this release can be found at:
> >>>>>> *https://repository.apache.org/content/repositories/orgapach
> >>>>>> eflink-1122
> >>>>>> <https://repository.apache.org/content/repositories/orgapach
> >>>>>> eflink-1122
> >>>>>> *
> >>>>>>
> >>>>>> -------------------------------------------------------------
> >>>>>>
> >>>>>>
> >>>>>> The vote ends on Tuesday (May 30th), 7pm CET.
> >>>>>>
> >>>>>> [ ] +1 Release this package as Apache Flink 1.3.0
> >>>>>> [ ] -1 Do not release this package, because ...
> >>>>>>
> >>>>>>
> >>>>>>
> >
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Robert Metzger <rm...@apache.org>.
+1 to release:
- Tested building job against staging repository
- tested YARN session start and container recovery on YARN
- Validated HA on YARN (per job and session mode)
- Incremental checkpointing with rocksdb works
- FsStatebackend with async snapshots works
- Flink builds from source on Linux (includes rat license header check)
- source doesn't contain binaries
- checked md5 / sha512 sum of source archive (assuming the other sums are
valid as well)
I noticed one minor thing: the copyright in the NOTICE file is 2014-2016.
I'll update it on master and the release branch.
On Mon, May 29, 2017 at 12:42 PM, Chesnay Schepler <ch...@apache.org>
wrote:
> +1
>
> * Builds from source
> * start/stop scripts work
> * logs don't show anything suspicious on startup/shutdown
> * ran some example jobs
> * ran jobs on yarn with exactly-once & RocksDB
> o canceling with savepoint/resuming from savepoint
> o without/with rescaling
> * SideOutputs work
> * Metrics are properly transmitted & displayed in the webUI
>
>
> On 28.05.2017 20:33, Robert Metzger wrote:
>
>> @Shaoxuan, I don't think missing documentation is a release blocker, but
>> it's something we should fix asap and with high priority :)
>> Since the documentation is not bundled with the release, and the docs are
>> build off the "release-x.y" branch, we can always update them (even after
>> the release).
>>
>> However, it makes sense to have the docs ready when we announce the
>> release
>> so that users can understand how to use the newly released features.
>>
>> On Sat, May 27, 2017 at 6:14 PM, Chesnay Schepler <ch...@apache.org>
>> wrote:
>>
>> I've responded in the JIRA. In my opinion isn't a functional issue, but
>>> more about improving
>>> error messages/documentation.
>>>
>>>
>>> On 27.05.2017 18:07, Gyula Fóra wrote:
>>>
>>> Hi!
>>>> I have found this issue: https://issues.apache.org/jira
>>>> /browse/FLINK-6742
>>>>
>>>> Not sure if it's a blocker or not (not even completely sure what causes
>>>> it
>>>> at the moment)
>>>>
>>>> Gyula
>>>>
>>>> Shaoxuan Wang <ws...@gmail.com> ezt írta (időpont: 2017. máj. 27.,
>>>> Szo,
>>>> 6:30):
>>>>
>>>> Hi Robert.
>>>>
>>>>> Will doc update be a blocker for release?
>>>>> Release 1.3 has many updates on tableAPI and SQL, and the docs are kind
>>>>> of
>>>>> lagging. We are trying the efforts to update the doc as much as
>>>>> possible
>>>>> before the release is officially published, but I am hoping this is
>>>>> not a
>>>>> blocker for the release.
>>>>>
>>>>> Shaoxuan
>>>>>
>>>>>
>>>>>
>>>>> On Sat, May 27, 2017 at 12:58 AM, Robert Metzger <rm...@apache.org>
>>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>>> this is the second VOTEing release candidate for Flink 1.3.0
>>>>>>
>>>>>> The commit to be voted on:
>>>>>> 760eea8a <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8
>>>>>> a>
>>>>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
>>>>>> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
>>>>>>
>>>>>> Branch:
>>>>>> release-1.3.0-rc3
>>>>>>
>>>>>> The release artifacts to be voted on can be found at:
>>>>>> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
>>>>>>
>>>>>>
>>>>>> The release artifacts are signed with the key with fingerprint
>>>>>> D9839159:
>>>>>> http://www.apache.org/dist/flink/KEYS
>>>>>>
>>>>>> The staging repository for this release can be found at:
>>>>>> *https://repository.apache.org/content/repositories/orgapach
>>>>>> eflink-1122
>>>>>> <https://repository.apache.org/content/repositories/orgapach
>>>>>> eflink-1122
>>>>>> *
>>>>>>
>>>>>> -------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> The vote ends on Tuesday (May 30th), 7pm CET.
>>>>>>
>>>>>> [ ] +1 Release this package as Apache Flink 1.3.0
>>>>>> [ ] -1 Do not release this package, because ...
>>>>>>
>>>>>>
>>>>>>
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Chesnay Schepler <ch...@apache.org>.
+1
* Builds from source
* start/stop scripts work
* logs don't show anything suspicious on startup/shutdown
* ran some example jobs
* ran jobs on yarn with exactly-once & RocksDB
o canceling with savepoint/resuming from savepoint
o without/with rescaling
* SideOutputs work
* Metrics are properly transmitted & displayed in the webUI
On 28.05.2017 20:33, Robert Metzger wrote:
> @Shaoxuan, I don't think missing documentation is a release blocker, but
> it's something we should fix asap and with high priority :)
> Since the documentation is not bundled with the release, and the docs are
> build off the "release-x.y" branch, we can always update them (even after
> the release).
>
> However, it makes sense to have the docs ready when we announce the release
> so that users can understand how to use the newly released features.
>
> On Sat, May 27, 2017 at 6:14 PM, Chesnay Schepler <ch...@apache.org>
> wrote:
>
>> I've responded in the JIRA. In my opinion isn't a functional issue, but
>> more about improving
>> error messages/documentation.
>>
>>
>> On 27.05.2017 18:07, Gyula Fóra wrote:
>>
>>> Hi!
>>> I have found this issue: https://issues.apache.org/jira/browse/FLINK-6742
>>>
>>> Not sure if it's a blocker or not (not even completely sure what causes it
>>> at the moment)
>>>
>>> Gyula
>>>
>>> Shaoxuan Wang <ws...@gmail.com> ezt írta (időpont: 2017. máj. 27.,
>>> Szo,
>>> 6:30):
>>>
>>> Hi Robert.
>>>> Will doc update be a blocker for release?
>>>> Release 1.3 has many updates on tableAPI and SQL, and the docs are kind
>>>> of
>>>> lagging. We are trying the efforts to update the doc as much as possible
>>>> before the release is officially published, but I am hoping this is not a
>>>> blocker for the release.
>>>>
>>>> Shaoxuan
>>>>
>>>>
>>>>
>>>> On Sat, May 27, 2017 at 12:58 AM, Robert Metzger <rm...@apache.org>
>>>> wrote:
>>>>
>>>> Hi all,
>>>>> this is the second VOTEing release candidate for Flink 1.3.0
>>>>>
>>>>> The commit to be voted on:
>>>>> 760eea8a <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>
>>>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
>>>>> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
>>>>>
>>>>> Branch:
>>>>> release-1.3.0-rc3
>>>>>
>>>>> The release artifacts to be voted on can be found at:
>>>>> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
>>>>>
>>>>>
>>>>> The release artifacts are signed with the key with fingerprint D9839159:
>>>>> http://www.apache.org/dist/flink/KEYS
>>>>>
>>>>> The staging repository for this release can be found at:
>>>>> *https://repository.apache.org/content/repositories/orgapacheflink-1122
>>>>> <https://repository.apache.org/content/repositories/orgapacheflink-1122
>>>>> *
>>>>>
>>>>> -------------------------------------------------------------
>>>>>
>>>>>
>>>>> The vote ends on Tuesday (May 30th), 7pm CET.
>>>>>
>>>>> [ ] +1 Release this package as Apache Flink 1.3.0
>>>>> [ ] -1 Do not release this package, because ...
>>>>>
>>>>>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Robert Metzger <rm...@apache.org>.
@Shaoxuan, I don't think missing documentation is a release blocker, but
it's something we should fix asap and with high priority :)
Since the documentation is not bundled with the release, and the docs are
build off the "release-x.y" branch, we can always update them (even after
the release).
However, it makes sense to have the docs ready when we announce the release
so that users can understand how to use the newly released features.
On Sat, May 27, 2017 at 6:14 PM, Chesnay Schepler <ch...@apache.org>
wrote:
> I've responded in the JIRA. In my opinion isn't a functional issue, but
> more about improving
> error messages/documentation.
>
>
> On 27.05.2017 18:07, Gyula Fóra wrote:
>
>> Hi!
>> I have found this issue: https://issues.apache.org/jira/browse/FLINK-6742
>>
>> Not sure if it's a blocker or not (not even completely sure what causes it
>> at the moment)
>>
>> Gyula
>>
>> Shaoxuan Wang <ws...@gmail.com> ezt írta (időpont: 2017. máj. 27.,
>> Szo,
>> 6:30):
>>
>> Hi Robert.
>>> Will doc update be a blocker for release?
>>> Release 1.3 has many updates on tableAPI and SQL, and the docs are kind
>>> of
>>> lagging. We are trying the efforts to update the doc as much as possible
>>> before the release is officially published, but I am hoping this is not a
>>> blocker for the release.
>>>
>>> Shaoxuan
>>>
>>>
>>>
>>> On Sat, May 27, 2017 at 12:58 AM, Robert Metzger <rm...@apache.org>
>>> wrote:
>>>
>>> Hi all,
>>>>
>>>> this is the second VOTEing release candidate for Flink 1.3.0
>>>>
>>>> The commit to be voted on:
>>>> 760eea8a <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>
>>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
>>>> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
>>>>
>>>> Branch:
>>>> release-1.3.0-rc3
>>>>
>>>> The release artifacts to be voted on can be found at:
>>>> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
>>>>
>>>>
>>>> The release artifacts are signed with the key with fingerprint D9839159:
>>>> http://www.apache.org/dist/flink/KEYS
>>>>
>>>> The staging repository for this release can be found at:
>>>> *https://repository.apache.org/content/repositories/orgapacheflink-1122
>>>> <https://repository.apache.org/content/repositories/orgapacheflink-1122
>>>> *
>>>>
>>>> -------------------------------------------------------------
>>>>
>>>>
>>>> The vote ends on Tuesday (May 30th), 7pm CET.
>>>>
>>>> [ ] +1 Release this package as Apache Flink 1.3.0
>>>> [ ] -1 Do not release this package, because ...
>>>>
>>>>
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Chesnay Schepler <ch...@apache.org>.
I've responded in the JIRA. In my opinion isn't a functional issue, but
more about improving
error messages/documentation.
On 27.05.2017 18:07, Gyula Fóra wrote:
> Hi!
> I have found this issue: https://issues.apache.org/jira/browse/FLINK-6742
>
> Not sure if it's a blocker or not (not even completely sure what causes it
> at the moment)
>
> Gyula
>
> Shaoxuan Wang <ws...@gmail.com> ezt írta (időpont: 2017. máj. 27., Szo,
> 6:30):
>
>> Hi Robert.
>> Will doc update be a blocker for release?
>> Release 1.3 has many updates on tableAPI and SQL, and the docs are kind of
>> lagging. We are trying the efforts to update the doc as much as possible
>> before the release is officially published, but I am hoping this is not a
>> blocker for the release.
>>
>> Shaoxuan
>>
>>
>>
>> On Sat, May 27, 2017 at 12:58 AM, Robert Metzger <rm...@apache.org>
>> wrote:
>>
>>> Hi all,
>>>
>>> this is the second VOTEing release candidate for Flink 1.3.0
>>>
>>> The commit to be voted on:
>>> 760eea8a <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>
>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
>>> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
>>>
>>> Branch:
>>> release-1.3.0-rc3
>>>
>>> The release artifacts to be voted on can be found at:
>>> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
>>>
>>>
>>> The release artifacts are signed with the key with fingerprint D9839159:
>>> http://www.apache.org/dist/flink/KEYS
>>>
>>> The staging repository for this release can be found at:
>>> *https://repository.apache.org/content/repositories/orgapacheflink-1122
>>> <https://repository.apache.org/content/repositories/orgapacheflink-1122
>>> *
>>>
>>> -------------------------------------------------------------
>>>
>>>
>>> The vote ends on Tuesday (May 30th), 7pm CET.
>>>
>>> [ ] +1 Release this package as Apache Flink 1.3.0
>>> [ ] -1 Do not release this package, because ...
>>>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Gyula Fóra <gy...@gmail.com>.
Hi!
I have found this issue: https://issues.apache.org/jira/browse/FLINK-6742
Not sure if it's a blocker or not (not even completely sure what causes it
at the moment)
Gyula
Shaoxuan Wang <ws...@gmail.com> ezt írta (időpont: 2017. máj. 27., Szo,
6:30):
> Hi Robert.
> Will doc update be a blocker for release?
> Release 1.3 has many updates on tableAPI and SQL, and the docs are kind of
> lagging. We are trying the efforts to update the doc as much as possible
> before the release is officially published, but I am hoping this is not a
> blocker for the release.
>
> Shaoxuan
>
>
>
> On Sat, May 27, 2017 at 12:58 AM, Robert Metzger <rm...@apache.org>
> wrote:
>
> > Hi all,
> >
> > this is the second VOTEing release candidate for Flink 1.3.0
> >
> > The commit to be voted on:
> > 760eea8a <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>
> > (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
> > <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
> >
> > Branch:
> > release-1.3.0-rc3
> >
> > The release artifacts to be voted on can be found at:
> > http://people.apache.org/~rmetzger/flink-1.3.0-rc3
> >
> >
> > The release artifacts are signed with the key with fingerprint D9839159:
> > http://www.apache.org/dist/flink/KEYS
> >
> > The staging repository for this release can be found at:
> > *https://repository.apache.org/content/repositories/orgapacheflink-1122
> > <https://repository.apache.org/content/repositories/orgapacheflink-1122
> >*
> >
> > -------------------------------------------------------------
> >
> >
> > The vote ends on Tuesday (May 30th), 7pm CET.
> >
> > [ ] +1 Release this package as Apache Flink 1.3.0
> > [ ] -1 Do not release this package, because ...
> >
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Shaoxuan Wang <ws...@gmail.com>.
Hi Robert.
Will doc update be a blocker for release?
Release 1.3 has many updates on tableAPI and SQL, and the docs are kind of
lagging. We are trying the efforts to update the doc as much as possible
before the release is officially published, but I am hoping this is not a
blocker for the release.
Shaoxuan
On Sat, May 27, 2017 at 12:58 AM, Robert Metzger <rm...@apache.org>
wrote:
> Hi all,
>
> this is the second VOTEing release candidate for Flink 1.3.0
>
> The commit to be voted on:
> 760eea8a <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>
> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
>
> Branch:
> release-1.3.0-rc3
>
> The release artifacts to be voted on can be found at:
> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
>
>
> The release artifacts are signed with the key with fingerprint D9839159:
> http://www.apache.org/dist/flink/KEYS
>
> The staging repository for this release can be found at:
> *https://repository.apache.org/content/repositories/orgapacheflink-1122
> <https://repository.apache.org/content/repositories/orgapacheflink-1122>*
>
> -------------------------------------------------------------
>
>
> The vote ends on Tuesday (May 30th), 7pm CET.
>
> [ ] +1 Release this package as Apache Flink 1.3.0
> [ ] -1 Do not release this package, because ...
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Robert Metzger <rm...@apache.org>.
Hi Timo,
I agree that not having the documentation available for the new features is
not good.
I'll do a pass over all the open documentation PRs and try to merge as many
as possible. If I have the feeling, that we have enough docs, I'll release
1.3.0.
For the table API, I can put a note into the release announcement.
On Wed, May 31, 2017 at 4:52 PM, Timo Walther <tw...@apache.org> wrote:
> What do you think about waiting with the release announcement for Flink
> 1.3.1 until next week.
>
> IMHO the documentation is not in a good shape for a release annoucement
> right now anyway.
>
> Most of the new features of the Table API are not documented. Docs for
> other features are missing as well or exist in open PR [1].
>
> Regards,
> Timo
>
> [1] https://issues.apache.org/jira/browse/FLINK-6674
>
>
> Am 31.05.17 um 15:03 schrieb Aljoscha Krettek:
>
> Yes, FLINK-6783 might even have been a release blocker…. It’s a new
>> feature that simply doesn’t work in most cases.
>>
>> On 31. May 2017, at 14:51, Timo Walther <tw...@apache.org> wrote:
>>>
>>> We should also include FLINK-6783. It seems that
>>> WindowedStream::aggregate is broken right now.
>>>
>>>
>>> Am 31.05.17 um 14:31 schrieb Timo Walther:
>>>
>>>> I merged all Table API related PRs.
>>>>
>>>> I'm also fine with a 1.3.1 release this or next week.
>>>>
>>>>
>>>> Am 31.05.17 um 14:08 schrieb Till Rohrmann:
>>>>
>>>>> I would be ok to quickly release 1.3.1 once the the respective PRs have
>>>>> been merged.
>>>>>
>>>>> Just for your information, I'm not yet through with the testing of the
>>>>> type
>>>>> serializer upgrade feature, though.
>>>>>
>>>>> Cheers,
>>>>> Till
>>>>>
>>>>> On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
>>>>> s.richter@data-artisans.com> wrote:
>>>>>
>>>>> +1 for releasing now and providing a 1.3.1 release soon.
>>>>>>
>>>>>> Am 31.05.2017 um 11:02 schrieb Gyula Fóra <gy...@gmail.com>:
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I also lean towards getting the release out as soon as possible given
>>>>>>>
>>>>>> that
>>>>>>
>>>>>>> it had been delayed quite a bit and there is no major issue without a
>>>>>>> straightforward workaround (agreeing with Nico and Kostas). I am sure
>>>>>>>
>>>>>> once
>>>>>>
>>>>>>> people will start using the new features we will see more issues that
>>>>>>> should be fixed asap in 1.3.1.
>>>>>>>
>>>>>>> Regarding the critical bug Till had found, we could add a line about
>>>>>>> it
>>>>>>>
>>>>>> to
>>>>>>
>>>>>>> the release notes so that people don't get blocked by it as there is
>>>>>>> a
>>>>>>> workaround possible.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Gyula
>>>>>>>
>>>>>>>
>>>>>>> Kostas Kloudas <k....@data-artisans.com> ezt írta (időpont:
>>>>>>> 2017.
>>>>>>>
>>>>>> máj.
>>>>>>
>>>>>>> 31., Sze, 10:53):
>>>>>>>
>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I also tend to agree with the argument that says a release should
>>>>>>>> be out
>>>>>>>> as soon as possible, given that 1) it improves
>>>>>>>> usability/functionality
>>>>>>>>
>>>>>>> and
>>>>>>
>>>>>>> 2) at a minimum, it does not include new known bugs. The arguments
>>>>>>>> are
>>>>>>>> more or less aligned with Nico’s response on the matter.
>>>>>>>>
>>>>>>>> Focusing on the bug that spiked the current discussion, I agree with
>>>>>>>>
>>>>>>> Till
>>>>>>
>>>>>>> that this is alarming, as it passed all previous testing efforts,
>>>>>>>> but I
>>>>>>>> have to
>>>>>>>> add that if nobody so far encountered it, we could release 1.3 now
>>>>>>>> and
>>>>>>>>
>>>>>>> fix
>>>>>>
>>>>>>> it in the upcoming 1.3.1.
>>>>>>>>
>>>>>>>> Kostas
>>>>>>>>
>>>>>>>> On May 31, 2017, at 10:20 AM, Nico Kruber <ni...@data-artisans.com>
>>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> IMHO, any release that improves things and does not break anything
>>>>>>>>> is
>>>>>>>>>
>>>>>>>> worth
>>>>>>>>
>>>>>>>>> releasing and should not be blocked on bugs that it did not cause.
>>>>>>>>> There will always be a next (minor/major) release that may fix
>>>>>>>>> this at
>>>>>>>>>
>>>>>>>> a
>>>>>>
>>>>>>> later
>>>>>>>>
>>>>>>>>> time, given that the time between releases is not too high.
>>>>>>>>>
>>>>>>>>> Consider someone waiting for a bugfix/feature that made it into
>>>>>>>>> 1.3.0
>>>>>>>>>
>>>>>>>> who--if
>>>>>>>>
>>>>>>>>> delayed--would have to wait even longer for "his" bugfix/feature.
>>>>>>>>> Any
>>>>>>>>>
>>>>>>>> new
>>>>>>
>>>>>>> bugfixes (and there will always be more) can wait a few more days or
>>>>>>>>>
>>>>>>>> even a few
>>>>>>>>
>>>>>>>>> weeks and may be fixed in 1.3.1 or so.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nico
>>>>>>>>>
>>>>>>>>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>>>>>>>>>
>>>>>>>>>> - Not sure whether it's a good argument to defer fixing major bugs
>>>>>>>>>>
>>>>>>>>> because
>>>>>>>>
>>>>>>>>> they have not been introduced with 1.3.0. It's actually alarming
>>>>>>>>>> that
>>>>>>>>>>
>>>>>>>>> these
>>>>>>>>
>>>>>>>>> things have not been found earlier given that we test our releases
>>>>>>>>>> thoroughly.
>>>>>>>>>>
>>>>>>>>>
>
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Timo Walther <tw...@apache.org>.
What do you think about waiting with the release announcement for Flink
1.3.1 until next week.
IMHO the documentation is not in a good shape for a release annoucement
right now anyway.
Most of the new features of the Table API are not documented. Docs for
other features are missing as well or exist in open PR [1].
Regards,
Timo
[1] https://issues.apache.org/jira/browse/FLINK-6674
Am 31.05.17 um 15:03 schrieb Aljoscha Krettek:
> Yes, FLINK-6783 might even have been a release blocker…. It’s a new feature that simply doesn’t work in most cases.
>
>> On 31. May 2017, at 14:51, Timo Walther <tw...@apache.org> wrote:
>>
>> We should also include FLINK-6783. It seems that WindowedStream::aggregate is broken right now.
>>
>>
>> Am 31.05.17 um 14:31 schrieb Timo Walther:
>>> I merged all Table API related PRs.
>>>
>>> I'm also fine with a 1.3.1 release this or next week.
>>>
>>>
>>> Am 31.05.17 um 14:08 schrieb Till Rohrmann:
>>>> I would be ok to quickly release 1.3.1 once the the respective PRs have
>>>> been merged.
>>>>
>>>> Just for your information, I'm not yet through with the testing of the type
>>>> serializer upgrade feature, though.
>>>>
>>>> Cheers,
>>>> Till
>>>>
>>>> On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
>>>> s.richter@data-artisans.com> wrote:
>>>>
>>>>> +1 for releasing now and providing a 1.3.1 release soon.
>>>>>
>>>>>> Am 31.05.2017 um 11:02 schrieb Gyula Fóra <gy...@gmail.com>:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I also lean towards getting the release out as soon as possible given
>>>>> that
>>>>>> it had been delayed quite a bit and there is no major issue without a
>>>>>> straightforward workaround (agreeing with Nico and Kostas). I am sure
>>>>> once
>>>>>> people will start using the new features we will see more issues that
>>>>>> should be fixed asap in 1.3.1.
>>>>>>
>>>>>> Regarding the critical bug Till had found, we could add a line about it
>>>>> to
>>>>>> the release notes so that people don't get blocked by it as there is a
>>>>>> workaround possible.
>>>>>>
>>>>>> Regards,
>>>>>> Gyula
>>>>>>
>>>>>>
>>>>>> Kostas Kloudas <k....@data-artisans.com> ezt írta (időpont: 2017.
>>>>> máj.
>>>>>> 31., Sze, 10:53):
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I also tend to agree with the argument that says a release should be out
>>>>>>> as soon as possible, given that 1) it improves usability/functionality
>>>>> and
>>>>>>> 2) at a minimum, it does not include new known bugs. The arguments are
>>>>>>> more or less aligned with Nico’s response on the matter.
>>>>>>>
>>>>>>> Focusing on the bug that spiked the current discussion, I agree with
>>>>> Till
>>>>>>> that this is alarming, as it passed all previous testing efforts, but I
>>>>>>> have to
>>>>>>> add that if nobody so far encountered it, we could release 1.3 now and
>>>>> fix
>>>>>>> it in the upcoming 1.3.1.
>>>>>>>
>>>>>>> Kostas
>>>>>>>
>>>>>>>> On May 31, 2017, at 10:20 AM, Nico Kruber <ni...@data-artisans.com>
>>>>>>> wrote:
>>>>>>>> IMHO, any release that improves things and does not break anything is
>>>>>>> worth
>>>>>>>> releasing and should not be blocked on bugs that it did not cause.
>>>>>>>> There will always be a next (minor/major) release that may fix this at
>>>>> a
>>>>>>> later
>>>>>>>> time, given that the time between releases is not too high.
>>>>>>>>
>>>>>>>> Consider someone waiting for a bugfix/feature that made it into 1.3.0
>>>>>>> who--if
>>>>>>>> delayed--would have to wait even longer for "his" bugfix/feature. Any
>>>>> new
>>>>>>>> bugfixes (and there will always be more) can wait a few more days or
>>>>>>> even a few
>>>>>>>> weeks and may be fixed in 1.3.1 or so.
>>>>>>>>
>>>>>>>>
>>>>>>>> Nico
>>>>>>>>
>>>>>>>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>>>>>>>>> - Not sure whether it's a good argument to defer fixing major bugs
>>>>>>> because
>>>>>>>>> they have not been introduced with 1.3.0. It's actually alarming that
>>>>>>> these
>>>>>>>>> things have not been found earlier given that we test our releases
>>>>>>>>> thoroughly.
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Aljoscha Krettek <al...@apache.org>.
Yes, FLINK-6783 might even have been a release blocker…. It’s a new feature that simply doesn’t work in most cases.
> On 31. May 2017, at 14:51, Timo Walther <tw...@apache.org> wrote:
>
> We should also include FLINK-6783. It seems that WindowedStream::aggregate is broken right now.
>
>
> Am 31.05.17 um 14:31 schrieb Timo Walther:
>> I merged all Table API related PRs.
>>
>> I'm also fine with a 1.3.1 release this or next week.
>>
>>
>> Am 31.05.17 um 14:08 schrieb Till Rohrmann:
>>> I would be ok to quickly release 1.3.1 once the the respective PRs have
>>> been merged.
>>>
>>> Just for your information, I'm not yet through with the testing of the type
>>> serializer upgrade feature, though.
>>>
>>> Cheers,
>>> Till
>>>
>>> On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
>>> s.richter@data-artisans.com> wrote:
>>>
>>>> +1 for releasing now and providing a 1.3.1 release soon.
>>>>
>>>>> Am 31.05.2017 um 11:02 schrieb Gyula Fóra <gy...@gmail.com>:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I also lean towards getting the release out as soon as possible given
>>>> that
>>>>> it had been delayed quite a bit and there is no major issue without a
>>>>> straightforward workaround (agreeing with Nico and Kostas). I am sure
>>>> once
>>>>> people will start using the new features we will see more issues that
>>>>> should be fixed asap in 1.3.1.
>>>>>
>>>>> Regarding the critical bug Till had found, we could add a line about it
>>>> to
>>>>> the release notes so that people don't get blocked by it as there is a
>>>>> workaround possible.
>>>>>
>>>>> Regards,
>>>>> Gyula
>>>>>
>>>>>
>>>>> Kostas Kloudas <k....@data-artisans.com> ezt írta (időpont: 2017.
>>>> máj.
>>>>> 31., Sze, 10:53):
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I also tend to agree with the argument that says a release should be out
>>>>>> as soon as possible, given that 1) it improves usability/functionality
>>>> and
>>>>>> 2) at a minimum, it does not include new known bugs. The arguments are
>>>>>> more or less aligned with Nico’s response on the matter.
>>>>>>
>>>>>> Focusing on the bug that spiked the current discussion, I agree with
>>>> Till
>>>>>> that this is alarming, as it passed all previous testing efforts, but I
>>>>>> have to
>>>>>> add that if nobody so far encountered it, we could release 1.3 now and
>>>> fix
>>>>>> it in the upcoming 1.3.1.
>>>>>>
>>>>>> Kostas
>>>>>>
>>>>>>> On May 31, 2017, at 10:20 AM, Nico Kruber <ni...@data-artisans.com>
>>>>>> wrote:
>>>>>>> IMHO, any release that improves things and does not break anything is
>>>>>> worth
>>>>>>> releasing and should not be blocked on bugs that it did not cause.
>>>>>>> There will always be a next (minor/major) release that may fix this at
>>>> a
>>>>>> later
>>>>>>> time, given that the time between releases is not too high.
>>>>>>>
>>>>>>> Consider someone waiting for a bugfix/feature that made it into 1.3.0
>>>>>> who--if
>>>>>>> delayed--would have to wait even longer for "his" bugfix/feature. Any
>>>> new
>>>>>>> bugfixes (and there will always be more) can wait a few more days or
>>>>>> even a few
>>>>>>> weeks and may be fixed in 1.3.1 or so.
>>>>>>>
>>>>>>>
>>>>>>> Nico
>>>>>>>
>>>>>>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>>>>>>>> - Not sure whether it's a good argument to defer fixing major bugs
>>>>>> because
>>>>>>>> they have not been introduced with 1.3.0. It's actually alarming that
>>>>>> these
>>>>>>>> things have not been found earlier given that we test our releases
>>>>>>>> thoroughly.
>>>>>>
>>>>
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Timo Walther <tw...@apache.org>.
We should also include FLINK-6783. It seems that
WindowedStream::aggregate is broken right now.
Am 31.05.17 um 14:31 schrieb Timo Walther:
> I merged all Table API related PRs.
>
> I'm also fine with a 1.3.1 release this or next week.
>
>
> Am 31.05.17 um 14:08 schrieb Till Rohrmann:
>> I would be ok to quickly release 1.3.1 once the the respective PRs have
>> been merged.
>>
>> Just for your information, I'm not yet through with the testing of
>> the type
>> serializer upgrade feature, though.
>>
>> Cheers,
>> Till
>>
>> On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
>> s.richter@data-artisans.com> wrote:
>>
>>> +1 for releasing now and providing a 1.3.1 release soon.
>>>
>>>> Am 31.05.2017 um 11:02 schrieb Gyula Fóra <gy...@gmail.com>:
>>>>
>>>> Hi All,
>>>>
>>>> I also lean towards getting the release out as soon as possible given
>>> that
>>>> it had been delayed quite a bit and there is no major issue without a
>>>> straightforward workaround (agreeing with Nico and Kostas). I am sure
>>> once
>>>> people will start using the new features we will see more issues that
>>>> should be fixed asap in 1.3.1.
>>>>
>>>> Regarding the critical bug Till had found, we could add a line
>>>> about it
>>> to
>>>> the release notes so that people don't get blocked by it as there is a
>>>> workaround possible.
>>>>
>>>> Regards,
>>>> Gyula
>>>>
>>>>
>>>> Kostas Kloudas <k....@data-artisans.com> ezt írta (időpont: 2017.
>>> máj.
>>>> 31., Sze, 10:53):
>>>>
>>>>> Hi all,
>>>>>
>>>>> I also tend to agree with the argument that says a release should
>>>>> be out
>>>>> as soon as possible, given that 1) it improves
>>>>> usability/functionality
>>> and
>>>>> 2) at a minimum, it does not include new known bugs. The arguments
>>>>> are
>>>>> more or less aligned with Nico’s response on the matter.
>>>>>
>>>>> Focusing on the bug that spiked the current discussion, I agree with
>>> Till
>>>>> that this is alarming, as it passed all previous testing efforts,
>>>>> but I
>>>>> have to
>>>>> add that if nobody so far encountered it, we could release 1.3 now
>>>>> and
>>> fix
>>>>> it in the upcoming 1.3.1.
>>>>>
>>>>> Kostas
>>>>>
>>>>>> On May 31, 2017, at 10:20 AM, Nico Kruber <ni...@data-artisans.com>
>>>>> wrote:
>>>>>> IMHO, any release that improves things and does not break
>>>>>> anything is
>>>>> worth
>>>>>> releasing and should not be blocked on bugs that it did not cause.
>>>>>> There will always be a next (minor/major) release that may fix
>>>>>> this at
>>> a
>>>>> later
>>>>>> time, given that the time between releases is not too high.
>>>>>>
>>>>>> Consider someone waiting for a bugfix/feature that made it into
>>>>>> 1.3.0
>>>>> who--if
>>>>>> delayed--would have to wait even longer for "his" bugfix/feature.
>>>>>> Any
>>> new
>>>>>> bugfixes (and there will always be more) can wait a few more days or
>>>>> even a few
>>>>>> weeks and may be fixed in 1.3.1 or so.
>>>>>>
>>>>>>
>>>>>> Nico
>>>>>>
>>>>>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>>>>>>> - Not sure whether it's a good argument to defer fixing major bugs
>>>>> because
>>>>>>> they have not been introduced with 1.3.0. It's actually alarming
>>>>>>> that
>>>>> these
>>>>>>> things have not been found earlier given that we test our releases
>>>>>>> thoroughly.
>>>>>
>>>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Timo Walther <tw...@apache.org>.
I merged all Table API related PRs.
I'm also fine with a 1.3.1 release this or next week.
Am 31.05.17 um 14:08 schrieb Till Rohrmann:
> I would be ok to quickly release 1.3.1 once the the respective PRs have
> been merged.
>
> Just for your information, I'm not yet through with the testing of the type
> serializer upgrade feature, though.
>
> Cheers,
> Till
>
> On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
> s.richter@data-artisans.com> wrote:
>
>> +1 for releasing now and providing a 1.3.1 release soon.
>>
>>> Am 31.05.2017 um 11:02 schrieb Gyula Fóra <gy...@gmail.com>:
>>>
>>> Hi All,
>>>
>>> I also lean towards getting the release out as soon as possible given
>> that
>>> it had been delayed quite a bit and there is no major issue without a
>>> straightforward workaround (agreeing with Nico and Kostas). I am sure
>> once
>>> people will start using the new features we will see more issues that
>>> should be fixed asap in 1.3.1.
>>>
>>> Regarding the critical bug Till had found, we could add a line about it
>> to
>>> the release notes so that people don't get blocked by it as there is a
>>> workaround possible.
>>>
>>> Regards,
>>> Gyula
>>>
>>>
>>> Kostas Kloudas <k....@data-artisans.com> ezt írta (időpont: 2017.
>> máj.
>>> 31., Sze, 10:53):
>>>
>>>> Hi all,
>>>>
>>>> I also tend to agree with the argument that says a release should be out
>>>> as soon as possible, given that 1) it improves usability/functionality
>> and
>>>> 2) at a minimum, it does not include new known bugs. The arguments are
>>>> more or less aligned with Nico’s response on the matter.
>>>>
>>>> Focusing on the bug that spiked the current discussion, I agree with
>> Till
>>>> that this is alarming, as it passed all previous testing efforts, but I
>>>> have to
>>>> add that if nobody so far encountered it, we could release 1.3 now and
>> fix
>>>> it in the upcoming 1.3.1.
>>>>
>>>> Kostas
>>>>
>>>>> On May 31, 2017, at 10:20 AM, Nico Kruber <ni...@data-artisans.com>
>>>> wrote:
>>>>> IMHO, any release that improves things and does not break anything is
>>>> worth
>>>>> releasing and should not be blocked on bugs that it did not cause.
>>>>> There will always be a next (minor/major) release that may fix this at
>> a
>>>> later
>>>>> time, given that the time between releases is not too high.
>>>>>
>>>>> Consider someone waiting for a bugfix/feature that made it into 1.3.0
>>>> who--if
>>>>> delayed--would have to wait even longer for "his" bugfix/feature. Any
>> new
>>>>> bugfixes (and there will always be more) can wait a few more days or
>>>> even a few
>>>>> weeks and may be fixed in 1.3.1 or so.
>>>>>
>>>>>
>>>>> Nico
>>>>>
>>>>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>>>>>> - Not sure whether it's a good argument to defer fixing major bugs
>>>> because
>>>>>> they have not been introduced with 1.3.0. It's actually alarming that
>>>> these
>>>>>> things have not been found earlier given that we test our releases
>>>>>> thoroughly.
>>>>
>>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Till Rohrmann <tr...@apache.org>.
I would be ok to quickly release 1.3.1 once the the respective PRs have
been merged.
Just for your information, I'm not yet through with the testing of the type
serializer upgrade feature, though.
Cheers,
Till
On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
s.richter@data-artisans.com> wrote:
> +1 for releasing now and providing a 1.3.1 release soon.
>
> > Am 31.05.2017 um 11:02 schrieb Gyula Fóra <gy...@gmail.com>:
> >
> > Hi All,
> >
> > I also lean towards getting the release out as soon as possible given
> that
> > it had been delayed quite a bit and there is no major issue without a
> > straightforward workaround (agreeing with Nico and Kostas). I am sure
> once
> > people will start using the new features we will see more issues that
> > should be fixed asap in 1.3.1.
> >
> > Regarding the critical bug Till had found, we could add a line about it
> to
> > the release notes so that people don't get blocked by it as there is a
> > workaround possible.
> >
> > Regards,
> > Gyula
> >
> >
> > Kostas Kloudas <k....@data-artisans.com> ezt írta (időpont: 2017.
> máj.
> > 31., Sze, 10:53):
> >
> >> Hi all,
> >>
> >> I also tend to agree with the argument that says a release should be out
> >> as soon as possible, given that 1) it improves usability/functionality
> and
> >> 2) at a minimum, it does not include new known bugs. The arguments are
> >> more or less aligned with Nico’s response on the matter.
> >>
> >> Focusing on the bug that spiked the current discussion, I agree with
> Till
> >> that this is alarming, as it passed all previous testing efforts, but I
> >> have to
> >> add that if nobody so far encountered it, we could release 1.3 now and
> fix
> >> it in the upcoming 1.3.1.
> >>
> >> Kostas
> >>
> >>> On May 31, 2017, at 10:20 AM, Nico Kruber <ni...@data-artisans.com>
> >> wrote:
> >>>
> >>> IMHO, any release that improves things and does not break anything is
> >> worth
> >>> releasing and should not be blocked on bugs that it did not cause.
> >>> There will always be a next (minor/major) release that may fix this at
> a
> >> later
> >>> time, given that the time between releases is not too high.
> >>>
> >>> Consider someone waiting for a bugfix/feature that made it into 1.3.0
> >> who--if
> >>> delayed--would have to wait even longer for "his" bugfix/feature. Any
> new
> >>> bugfixes (and there will always be more) can wait a few more days or
> >> even a few
> >>> weeks and may be fixed in 1.3.1 or so.
> >>>
> >>>
> >>> Nico
> >>>
> >>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
> >>>> - Not sure whether it's a good argument to defer fixing major bugs
> >> because
> >>>> they have not been introduced with 1.3.0. It's actually alarming that
> >> these
> >>>> things have not been found earlier given that we test our releases
> >>>> thoroughly.
> >>>
> >>
> >>
>
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Stefan Richter <s....@data-artisans.com>.
+1 for releasing now and providing a 1.3.1 release soon.
> Am 31.05.2017 um 11:02 schrieb Gyula Fóra <gy...@gmail.com>:
>
> Hi All,
>
> I also lean towards getting the release out as soon as possible given that
> it had been delayed quite a bit and there is no major issue without a
> straightforward workaround (agreeing with Nico and Kostas). I am sure once
> people will start using the new features we will see more issues that
> should be fixed asap in 1.3.1.
>
> Regarding the critical bug Till had found, we could add a line about it to
> the release notes so that people don't get blocked by it as there is a
> workaround possible.
>
> Regards,
> Gyula
>
>
> Kostas Kloudas <k....@data-artisans.com> ezt írta (időpont: 2017. máj.
> 31., Sze, 10:53):
>
>> Hi all,
>>
>> I also tend to agree with the argument that says a release should be out
>> as soon as possible, given that 1) it improves usability/functionality and
>> 2) at a minimum, it does not include new known bugs. The arguments are
>> more or less aligned with Nico’s response on the matter.
>>
>> Focusing on the bug that spiked the current discussion, I agree with Till
>> that this is alarming, as it passed all previous testing efforts, but I
>> have to
>> add that if nobody so far encountered it, we could release 1.3 now and fix
>> it in the upcoming 1.3.1.
>>
>> Kostas
>>
>>> On May 31, 2017, at 10:20 AM, Nico Kruber <ni...@data-artisans.com>
>> wrote:
>>>
>>> IMHO, any release that improves things and does not break anything is
>> worth
>>> releasing and should not be blocked on bugs that it did not cause.
>>> There will always be a next (minor/major) release that may fix this at a
>> later
>>> time, given that the time between releases is not too high.
>>>
>>> Consider someone waiting for a bugfix/feature that made it into 1.3.0
>> who--if
>>> delayed--would have to wait even longer for "his" bugfix/feature. Any new
>>> bugfixes (and there will always be more) can wait a few more days or
>> even a few
>>> weeks and may be fixed in 1.3.1 or so.
>>>
>>>
>>> Nico
>>>
>>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>>>> - Not sure whether it's a good argument to defer fixing major bugs
>> because
>>>> they have not been introduced with 1.3.0. It's actually alarming that
>> these
>>>> things have not been found earlier given that we test our releases
>>>> thoroughly.
>>>
>>
>>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Gyula Fóra <gy...@gmail.com>.
Hi All,
I also lean towards getting the release out as soon as possible given that
it had been delayed quite a bit and there is no major issue without a
straightforward workaround (agreeing with Nico and Kostas). I am sure once
people will start using the new features we will see more issues that
should be fixed asap in 1.3.1.
Regarding the critical bug Till had found, we could add a line about it to
the release notes so that people don't get blocked by it as there is a
workaround possible.
Regards,
Gyula
Kostas Kloudas <k....@data-artisans.com> ezt írta (időpont: 2017. máj.
31., Sze, 10:53):
> Hi all,
>
> I also tend to agree with the argument that says a release should be out
> as soon as possible, given that 1) it improves usability/functionality and
> 2) at a minimum, it does not include new known bugs. The arguments are
> more or less aligned with Nico’s response on the matter.
>
> Focusing on the bug that spiked the current discussion, I agree with Till
> that this is alarming, as it passed all previous testing efforts, but I
> have to
> add that if nobody so far encountered it, we could release 1.3 now and fix
> it in the upcoming 1.3.1.
>
> Kostas
>
> > On May 31, 2017, at 10:20 AM, Nico Kruber <ni...@data-artisans.com>
> wrote:
> >
> > IMHO, any release that improves things and does not break anything is
> worth
> > releasing and should not be blocked on bugs that it did not cause.
> > There will always be a next (minor/major) release that may fix this at a
> later
> > time, given that the time between releases is not too high.
> >
> > Consider someone waiting for a bugfix/feature that made it into 1.3.0
> who--if
> > delayed--would have to wait even longer for "his" bugfix/feature. Any new
> > bugfixes (and there will always be more) can wait a few more days or
> even a few
> > weeks and may be fixed in 1.3.1 or so.
> >
> >
> > Nico
> >
> > On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
> >> - Not sure whether it's a good argument to defer fixing major bugs
> because
> >> they have not been introduced with 1.3.0. It's actually alarming that
> these
> >> things have not been found earlier given that we test our releases
> >> thoroughly.
> >
>
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Kostas Kloudas <k....@data-artisans.com>.
Hi all,
I also tend to agree with the argument that says a release should be out
as soon as possible, given that 1) it improves usability/functionality and
2) at a minimum, it does not include new known bugs. The arguments are
more or less aligned with Nico’s response on the matter.
Focusing on the bug that spiked the current discussion, I agree with Till
that this is alarming, as it passed all previous testing efforts, but I have to
add that if nobody so far encountered it, we could release 1.3 now and fix
it in the upcoming 1.3.1.
Kostas
> On May 31, 2017, at 10:20 AM, Nico Kruber <ni...@data-artisans.com> wrote:
>
> IMHO, any release that improves things and does not break anything is worth
> releasing and should not be blocked on bugs that it did not cause.
> There will always be a next (minor/major) release that may fix this at a later
> time, given that the time between releases is not too high.
>
> Consider someone waiting for a bugfix/feature that made it into 1.3.0 who--if
> delayed--would have to wait even longer for "his" bugfix/feature. Any new
> bugfixes (and there will always be more) can wait a few more days or even a few
> weeks and may be fixed in 1.3.1 or so.
>
>
> Nico
>
> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>> - Not sure whether it's a good argument to defer fixing major bugs because
>> they have not been introduced with 1.3.0. It's actually alarming that these
>> things have not been found earlier given that we test our releases
>> thoroughly.
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Ufuk Celebi <uc...@apache.org>.
I agree with Robert that this could be fixed in a bugfix release, but
I really don't like immediately starting a new 1.3.1 vote a day after
the 1.3.0 vote ends. I think it potentially gives a bad/sloppy
impression to our users.
Therefore, I lean towards cancelling this RC and creating a new one
with the fixes included. If there are no objections, I would reduce
the voting time to 48 hours (Fri assuming that a new RC is created
today) instead of 72 -or- keeping it at 72 and counting the weekend.
Best,
Ufuk
On Wed, May 31, 2017 at 10:20 AM, Nico Kruber <ni...@data-artisans.com> wrote:
> IMHO, any release that improves things and does not break anything is worth
> releasing and should not be blocked on bugs that it did not cause.
> There will always be a next (minor/major) release that may fix this at a later
> time, given that the time between releases is not too high.
>
> Consider someone waiting for a bugfix/feature that made it into 1.3.0 who--if
> delayed--would have to wait even longer for "his" bugfix/feature. Any new
> bugfixes (and there will always be more) can wait a few more days or even a few
> weeks and may be fixed in 1.3.1 or so.
>
>
> Nico
>
> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>> - Not sure whether it's a good argument to defer fixing major bugs because
>> they have not been introduced with 1.3.0. It's actually alarming that these
>> things have not been found earlier given that we test our releases
>> thoroughly.
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Nico Kruber <ni...@data-artisans.com>.
IMHO, any release that improves things and does not break anything is worth
releasing and should not be blocked on bugs that it did not cause.
There will always be a next (minor/major) release that may fix this at a later
time, given that the time between releases is not too high.
Consider someone waiting for a bugfix/feature that made it into 1.3.0 who--if
delayed--would have to wait even longer for "his" bugfix/feature. Any new
bugfixes (and there will always be more) can wait a few more days or even a few
weeks and may be fixed in 1.3.1 or so.
Nico
On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
> - Not sure whether it's a good argument to defer fixing major bugs because
> they have not been introduced with 1.3.0. It's actually alarming that these
> things have not been found earlier given that we test our releases
> thoroughly.
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Fabian Hueske <fh...@gmail.com>.
Moreover it looks to me as if FLINK-6780 can be fixed without touching the
API, i.e., it can be fixed in 1.3.1.
Haohui, do you think that's correct?
Thanks, Fabian
2017-05-31 8:56 GMT+02:00 Timo Walther <tw...@apache.org>:
> I don't think that FLINK-6780 is a blocker, because the Table API is still
> a new feature. FLINK-6736 was also a hard bug. However, if there will be a
> RC4, a fix should be included.
>
> Regards,
> Timo
>
>
> Am 31.05.17 um 02:55 schrieb Haohui Mai:
>
> Hi,
>>
>> We have discovered https://issues.apache.org/jira/browse/FLINK-6780 which
>> effectively makes external catalogs in the table API very difficult to
>> use.
>>
>> It may not be a show stopper but in my opinion it is worth a fix before
>> the
>> release.
>>
>> Regards,
>> Haohui
>>
>> On Tue, May 30, 2017 at 11:22 AM Till Rohrmann <tr...@apache.org>
>> wrote:
>>
>> Just some thoughts concerning the cons for cancelling RC3:
>>>
>>> - Technically, the release is already delayed since the official release
>>> date was the 26th of May
>>> - Not sure whether it's a good argument to defer fixing major bugs
>>> because
>>> they have not been introduced with 1.3.0. It's actually alarming that
>>> these
>>> things have not been found earlier given that we test our releases
>>> thoroughly.
>>> - The shared serializer surfaced in the form of a cryptic
>>> ArrayIndexOutOfBoundsException. Only if you realize that this is
>>> related to
>>> a shared StateDescriptor you can look for a workaround. It took me 2h to
>>> realize that.
>>>
>>> Cheers,
>>> Till
>>>
>>> On Tue, May 30, 2017 at 7:02 PM, Robert Metzger <rm...@apache.org>
>>> wrote:
>>>
>>> The vote time is over, but I'll keep it open for a bit longer until we've
>>>> decided regarding Till's issue.
>>>>
>>>> On Tue, May 30, 2017 at 6:10 PM, Robert Metzger <rm...@apache.org>
>>>> wrote:
>>>>
>>>> Hi Till,
>>>>> good catch! That is definitively a severe issue. Probably it didn't
>>>>> surface yet, because
>>>>> a) the code example in the documentation is using a new instance for
>>>>>
>>>> each
>>>
>>>> state descriptor
>>>>> b) people are using stateless serializers?
>>>>> c) don't have the same state descriptor on the same machine
>>>>>
>>>>> I see two options how to handle the situation
>>>>> 1) Cancel RC3 and do another vote (potentially with a 24 hrs vote time)
>>>>> 2) Release RC3 as 1.3.0 and start the vote for 1.3.1 right afterwards.
>>>>>
>>>>>
>>>>> + Pros and - cons for cancelling RC3
>>>>> - The release would be delayed (not sure who's expecting the 1.3.0 to
>>>>>
>>>> be
>>>
>>>> available on time)
>>>>> - The bug has been there since many releases, probably no user is
>>>>>
>>>> affected
>>>>
>>>>> and it was not introduced during the rel 1.3.0 cycle.
>>>>> - There is a workaround for the issue
>>>>> + We would have a better feeling for the 1.3.0 release because there
>>>>>
>>>> are
>>>
>>>> no known critical issues.
>>>>>
>>>>> + pro and - cons for releasing RC3:
>>>>> + there are some other "minor" issues that showed up during the 1.3.0
>>>>> testing that could go into 1.3.1 (FLINK-6763
>>>>> <https://issues.apache.org/jira/browse/FLINK-6763>, FLINK-6764
>>>>> <https://issues.apache.org/jira/browse/FLINK-6764>) without too much
>>>>> time-pressure (I'm happy to manage the 1.3.1 release and start it
>>>>>
>>>> tomorrow)
>>>>
>>>>>
>>>>> I'm undecided between both options and more than happy to hear your
>>>>> opinion.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 30, 2017 at 4:18 PM, Till Rohrmann <tr...@apache.org>
>>>>> wrote:
>>>>>
>>>>> I might have found a blocking issue [1]. The problem is that a
>>>>>> StateDescriptor cannot be shared by multiple subtasks because they
>>>>>>
>>>>> don't
>>>
>>>> duplicate their serializer. As a consequence, things break if you
>>>>>>
>>>>> have a
>>>
>>>> stateful serializer. The problem exists since 1.0. However, given that
>>>>>> this
>>>>>> issue is really hard to debug for the user and one can easily fall
>>>>>>
>>>>> into
>>>
>>>> this trap, I would like to fix it for the release.
>>>>>>
>>>>>> [1] https://issues.apache.org/jira/browse/FLINK-6775
>>>>>>
>>>>>> Cheers,
>>>>>> Till
>>>>>>
>>>>>> On Tue, May 30, 2017 at 4:01 PM, Greg Hogan <co...@greghogan.com>
>>>>>>
>>>>> wrote:
>>>
>>>> +1 (binding)
>>>>>>>
>>>>>>> - verified source and binary signatures
>>>>>>> - verified source and binary checksums
>>>>>>> - verified LICENSEs
>>>>>>> - verified NOTICEs
>>>>>>> - built from source
>>>>>>>
>>>>>>> Greg
>>>>>>>
>>>>>>>
>>>>>>> On May 26, 2017, at 12:58 PM, Robert Metzger <rmetzger@apache.org
>>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> this is the second VOTEing release candidate for Flink 1.3.0
>>>>>>>>
>>>>>>>> The commit to be voted on:
>>>>>>>> 760eea8a <http://git-wip-us.apache.org/
>>>>>>>>
>>>>>>> repos/asf/flink/commit/760eea8
>>>>
>>>>> a>
>>>>>>
>>>>>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
>>>>>>>> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
>>>>>>>>
>>>>>>>> Branch:
>>>>>>>> release-1.3.0-rc3
>>>>>>>>
>>>>>>>> The release artifacts to be voted on can be found at:
>>>>>>>> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
>>>>>>>>
>>>>>>>>
>>>>>>>> The release artifacts are signed with the key with fingerprint
>>>>>>>>
>>>>>>> D9839159:
>>>>>>
>>>>>>> http://www.apache.org/dist/flink/KEYS
>>>>>>>>
>>>>>>>> The staging repository for this release can be found at:
>>>>>>>> *https://repository.apache.org/content/repositories/orgapach
>>>>>>>>
>>>>>>> eflink-1122
>>>>>>
>>>>>>> <https://repository.apache.org/content/repositories/orgapach
>>>>>>>>
>>>>>>> eflink-1122
>>>>>>
>>>>>>> *
>>>>>>>>
>>>>>>>> -------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> The vote ends on Tuesday (May 30th), 7pm CET.
>>>>>>>>
>>>>>>>> [ ] +1 Release this package as Apache Flink 1.3.0
>>>>>>>> [ ] -1 Do not release this package, because ...
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Timo Walther <tw...@apache.org>.
I don't think that FLINK-6780 is a blocker, because the Table API is
still a new feature. FLINK-6736 was also a hard bug. However, if there
will be a RC4, a fix should be included.
Regards,
Timo
Am 31.05.17 um 02:55 schrieb Haohui Mai:
> Hi,
>
> We have discovered https://issues.apache.org/jira/browse/FLINK-6780 which
> effectively makes external catalogs in the table API very difficult to use.
>
> It may not be a show stopper but in my opinion it is worth a fix before the
> release.
>
> Regards,
> Haohui
>
> On Tue, May 30, 2017 at 11:22 AM Till Rohrmann <tr...@apache.org> wrote:
>
>> Just some thoughts concerning the cons for cancelling RC3:
>>
>> - Technically, the release is already delayed since the official release
>> date was the 26th of May
>> - Not sure whether it's a good argument to defer fixing major bugs because
>> they have not been introduced with 1.3.0. It's actually alarming that these
>> things have not been found earlier given that we test our releases
>> thoroughly.
>> - The shared serializer surfaced in the form of a cryptic
>> ArrayIndexOutOfBoundsException. Only if you realize that this is related to
>> a shared StateDescriptor you can look for a workaround. It took me 2h to
>> realize that.
>>
>> Cheers,
>> Till
>>
>> On Tue, May 30, 2017 at 7:02 PM, Robert Metzger <rm...@apache.org>
>> wrote:
>>
>>> The vote time is over, but I'll keep it open for a bit longer until we've
>>> decided regarding Till's issue.
>>>
>>> On Tue, May 30, 2017 at 6:10 PM, Robert Metzger <rm...@apache.org>
>>> wrote:
>>>
>>>> Hi Till,
>>>> good catch! That is definitively a severe issue. Probably it didn't
>>>> surface yet, because
>>>> a) the code example in the documentation is using a new instance for
>> each
>>>> state descriptor
>>>> b) people are using stateless serializers?
>>>> c) don't have the same state descriptor on the same machine
>>>>
>>>> I see two options how to handle the situation
>>>> 1) Cancel RC3 and do another vote (potentially with a 24 hrs vote time)
>>>> 2) Release RC3 as 1.3.0 and start the vote for 1.3.1 right afterwards.
>>>>
>>>>
>>>> + Pros and - cons for cancelling RC3
>>>> - The release would be delayed (not sure who's expecting the 1.3.0 to
>> be
>>>> available on time)
>>>> - The bug has been there since many releases, probably no user is
>>> affected
>>>> and it was not introduced during the rel 1.3.0 cycle.
>>>> - There is a workaround for the issue
>>>> + We would have a better feeling for the 1.3.0 release because there
>> are
>>>> no known critical issues.
>>>>
>>>> + pro and - cons for releasing RC3:
>>>> + there are some other "minor" issues that showed up during the 1.3.0
>>>> testing that could go into 1.3.1 (FLINK-6763
>>>> <https://issues.apache.org/jira/browse/FLINK-6763>, FLINK-6764
>>>> <https://issues.apache.org/jira/browse/FLINK-6764>) without too much
>>>> time-pressure (I'm happy to manage the 1.3.1 release and start it
>>> tomorrow)
>>>>
>>>> I'm undecided between both options and more than happy to hear your
>>>> opinion.
>>>>
>>>>
>>>>
>>>> On Tue, May 30, 2017 at 4:18 PM, Till Rohrmann <tr...@apache.org>
>>>> wrote:
>>>>
>>>>> I might have found a blocking issue [1]. The problem is that a
>>>>> StateDescriptor cannot be shared by multiple subtasks because they
>> don't
>>>>> duplicate their serializer. As a consequence, things break if you
>> have a
>>>>> stateful serializer. The problem exists since 1.0. However, given that
>>>>> this
>>>>> issue is really hard to debug for the user and one can easily fall
>> into
>>>>> this trap, I would like to fix it for the release.
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/FLINK-6775
>>>>>
>>>>> Cheers,
>>>>> Till
>>>>>
>>>>> On Tue, May 30, 2017 at 4:01 PM, Greg Hogan <co...@greghogan.com>
>> wrote:
>>>>>> +1 (binding)
>>>>>>
>>>>>> - verified source and binary signatures
>>>>>> - verified source and binary checksums
>>>>>> - verified LICENSEs
>>>>>> - verified NOTICEs
>>>>>> - built from source
>>>>>>
>>>>>> Greg
>>>>>>
>>>>>>
>>>>>>> On May 26, 2017, at 12:58 PM, Robert Metzger <rmetzger@apache.org
>>>>>> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> this is the second VOTEing release candidate for Flink 1.3.0
>>>>>>>
>>>>>>> The commit to be voted on:
>>>>>>> 760eea8a <http://git-wip-us.apache.org/
>>> repos/asf/flink/commit/760eea8
>>>>> a>
>>>>>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
>>>>>>> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
>>>>>>>
>>>>>>> Branch:
>>>>>>> release-1.3.0-rc3
>>>>>>>
>>>>>>> The release artifacts to be voted on can be found at:
>>>>>>> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
>>>>>>>
>>>>>>>
>>>>>>> The release artifacts are signed with the key with fingerprint
>>>>> D9839159:
>>>>>>> http://www.apache.org/dist/flink/KEYS
>>>>>>>
>>>>>>> The staging repository for this release can be found at:
>>>>>>> *https://repository.apache.org/content/repositories/orgapach
>>>>> eflink-1122
>>>>>>> <https://repository.apache.org/content/repositories/orgapach
>>>>> eflink-1122
>>>>>>> *
>>>>>>>
>>>>>>> -------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> The vote ends on Tuesday (May 30th), 7pm CET.
>>>>>>>
>>>>>>> [ ] +1 Release this package as Apache Flink 1.3.0
>>>>>>> [ ] -1 Do not release this package, because ...
>>>>>>
>>>>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Haohui Mai <ri...@gmail.com>.
Hi,
We have discovered https://issues.apache.org/jira/browse/FLINK-6780 which
effectively makes external catalogs in the table API very difficult to use.
It may not be a show stopper but in my opinion it is worth a fix before the
release.
Regards,
Haohui
On Tue, May 30, 2017 at 11:22 AM Till Rohrmann <tr...@apache.org> wrote:
> Just some thoughts concerning the cons for cancelling RC3:
>
> - Technically, the release is already delayed since the official release
> date was the 26th of May
> - Not sure whether it's a good argument to defer fixing major bugs because
> they have not been introduced with 1.3.0. It's actually alarming that these
> things have not been found earlier given that we test our releases
> thoroughly.
> - The shared serializer surfaced in the form of a cryptic
> ArrayIndexOutOfBoundsException. Only if you realize that this is related to
> a shared StateDescriptor you can look for a workaround. It took me 2h to
> realize that.
>
> Cheers,
> Till
>
> On Tue, May 30, 2017 at 7:02 PM, Robert Metzger <rm...@apache.org>
> wrote:
>
> > The vote time is over, but I'll keep it open for a bit longer until we've
> > decided regarding Till's issue.
> >
> > On Tue, May 30, 2017 at 6:10 PM, Robert Metzger <rm...@apache.org>
> > wrote:
> >
> > > Hi Till,
> > > good catch! That is definitively a severe issue. Probably it didn't
> > > surface yet, because
> > > a) the code example in the documentation is using a new instance for
> each
> > > state descriptor
> > > b) people are using stateless serializers?
> > > c) don't have the same state descriptor on the same machine
> > >
> > > I see two options how to handle the situation
> > > 1) Cancel RC3 and do another vote (potentially with a 24 hrs vote time)
> > > 2) Release RC3 as 1.3.0 and start the vote for 1.3.1 right afterwards.
> > >
> > >
> > > + Pros and - cons for cancelling RC3
> > > - The release would be delayed (not sure who's expecting the 1.3.0 to
> be
> > > available on time)
> > > - The bug has been there since many releases, probably no user is
> > affected
> > > and it was not introduced during the rel 1.3.0 cycle.
> > > - There is a workaround for the issue
> > > + We would have a better feeling for the 1.3.0 release because there
> are
> > > no known critical issues.
> > >
> > > + pro and - cons for releasing RC3:
> > > + there are some other "minor" issues that showed up during the 1.3.0
> > > testing that could go into 1.3.1 (FLINK-6763
> > > <https://issues.apache.org/jira/browse/FLINK-6763>, FLINK-6764
> > > <https://issues.apache.org/jira/browse/FLINK-6764>) without too much
> > > time-pressure (I'm happy to manage the 1.3.1 release and start it
> > tomorrow)
> > >
> > >
> > > I'm undecided between both options and more than happy to hear your
> > > opinion.
> > >
> > >
> > >
> > > On Tue, May 30, 2017 at 4:18 PM, Till Rohrmann <tr...@apache.org>
> > > wrote:
> > >
> > >> I might have found a blocking issue [1]. The problem is that a
> > >> StateDescriptor cannot be shared by multiple subtasks because they
> don't
> > >> duplicate their serializer. As a consequence, things break if you
> have a
> > >> stateful serializer. The problem exists since 1.0. However, given that
> > >> this
> > >> issue is really hard to debug for the user and one can easily fall
> into
> > >> this trap, I would like to fix it for the release.
> > >>
> > >> [1] https://issues.apache.org/jira/browse/FLINK-6775
> > >>
> > >> Cheers,
> > >> Till
> > >>
> > >> On Tue, May 30, 2017 at 4:01 PM, Greg Hogan <co...@greghogan.com>
> wrote:
> > >>
> > >> > +1 (binding)
> > >> >
> > >> > - verified source and binary signatures
> > >> > - verified source and binary checksums
> > >> > - verified LICENSEs
> > >> > - verified NOTICEs
> > >> > - built from source
> > >> >
> > >> > Greg
> > >> >
> > >> >
> > >> > > On May 26, 2017, at 12:58 PM, Robert Metzger <rmetzger@apache.org
> >
> > >> > wrote:
> > >> > >
> > >> > > Hi all,
> > >> > >
> > >> > > this is the second VOTEing release candidate for Flink 1.3.0
> > >> > >
> > >> > > The commit to be voted on:
> > >> > > 760eea8a <http://git-wip-us.apache.org/
> > repos/asf/flink/commit/760eea8
> > >> a>
> > >> > > (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
> > >> > > <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
> > >> > >
> > >> > > Branch:
> > >> > > release-1.3.0-rc3
> > >> > >
> > >> > > The release artifacts to be voted on can be found at:
> > >> > > http://people.apache.org/~rmetzger/flink-1.3.0-rc3
> > >> > >
> > >> > >
> > >> > > The release artifacts are signed with the key with fingerprint
> > >> D9839159:
> > >> > > http://www.apache.org/dist/flink/KEYS
> > >> > >
> > >> > > The staging repository for this release can be found at:
> > >> > > *https://repository.apache.org/content/repositories/orgapach
> > >> eflink-1122
> > >> > > <https://repository.apache.org/content/repositories/orgapach
> > >> eflink-1122
> > >> > >*
> > >> > >
> > >> > > -------------------------------------------------------------
> > >> > >
> > >> > >
> > >> > > The vote ends on Tuesday (May 30th), 7pm CET.
> > >> > >
> > >> > > [ ] +1 Release this package as Apache Flink 1.3.0
> > >> > > [ ] -1 Do not release this package, because ...
> > >> >
> > >> >
> > >>
> > >
> > >
> >
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Till Rohrmann <tr...@apache.org>.
Just some thoughts concerning the cons for cancelling RC3:
- Technically, the release is already delayed since the official release
date was the 26th of May
- Not sure whether it's a good argument to defer fixing major bugs because
they have not been introduced with 1.3.0. It's actually alarming that these
things have not been found earlier given that we test our releases
thoroughly.
- The shared serializer surfaced in the form of a cryptic
ArrayIndexOutOfBoundsException. Only if you realize that this is related to
a shared StateDescriptor you can look for a workaround. It took me 2h to
realize that.
Cheers,
Till
On Tue, May 30, 2017 at 7:02 PM, Robert Metzger <rm...@apache.org> wrote:
> The vote time is over, but I'll keep it open for a bit longer until we've
> decided regarding Till's issue.
>
> On Tue, May 30, 2017 at 6:10 PM, Robert Metzger <rm...@apache.org>
> wrote:
>
> > Hi Till,
> > good catch! That is definitively a severe issue. Probably it didn't
> > surface yet, because
> > a) the code example in the documentation is using a new instance for each
> > state descriptor
> > b) people are using stateless serializers?
> > c) don't have the same state descriptor on the same machine
> >
> > I see two options how to handle the situation
> > 1) Cancel RC3 and do another vote (potentially with a 24 hrs vote time)
> > 2) Release RC3 as 1.3.0 and start the vote for 1.3.1 right afterwards.
> >
> >
> > + Pros and - cons for cancelling RC3
> > - The release would be delayed (not sure who's expecting the 1.3.0 to be
> > available on time)
> > - The bug has been there since many releases, probably no user is
> affected
> > and it was not introduced during the rel 1.3.0 cycle.
> > - There is a workaround for the issue
> > + We would have a better feeling for the 1.3.0 release because there are
> > no known critical issues.
> >
> > + pro and - cons for releasing RC3:
> > + there are some other "minor" issues that showed up during the 1.3.0
> > testing that could go into 1.3.1 (FLINK-6763
> > <https://issues.apache.org/jira/browse/FLINK-6763>, FLINK-6764
> > <https://issues.apache.org/jira/browse/FLINK-6764>) without too much
> > time-pressure (I'm happy to manage the 1.3.1 release and start it
> tomorrow)
> >
> >
> > I'm undecided between both options and more than happy to hear your
> > opinion.
> >
> >
> >
> > On Tue, May 30, 2017 at 4:18 PM, Till Rohrmann <tr...@apache.org>
> > wrote:
> >
> >> I might have found a blocking issue [1]. The problem is that a
> >> StateDescriptor cannot be shared by multiple subtasks because they don't
> >> duplicate their serializer. As a consequence, things break if you have a
> >> stateful serializer. The problem exists since 1.0. However, given that
> >> this
> >> issue is really hard to debug for the user and one can easily fall into
> >> this trap, I would like to fix it for the release.
> >>
> >> [1] https://issues.apache.org/jira/browse/FLINK-6775
> >>
> >> Cheers,
> >> Till
> >>
> >> On Tue, May 30, 2017 at 4:01 PM, Greg Hogan <co...@greghogan.com> wrote:
> >>
> >> > +1 (binding)
> >> >
> >> > - verified source and binary signatures
> >> > - verified source and binary checksums
> >> > - verified LICENSEs
> >> > - verified NOTICEs
> >> > - built from source
> >> >
> >> > Greg
> >> >
> >> >
> >> > > On May 26, 2017, at 12:58 PM, Robert Metzger <rm...@apache.org>
> >> > wrote:
> >> > >
> >> > > Hi all,
> >> > >
> >> > > this is the second VOTEing release candidate for Flink 1.3.0
> >> > >
> >> > > The commit to be voted on:
> >> > > 760eea8a <http://git-wip-us.apache.org/
> repos/asf/flink/commit/760eea8
> >> a>
> >> > > (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
> >> > > <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
> >> > >
> >> > > Branch:
> >> > > release-1.3.0-rc3
> >> > >
> >> > > The release artifacts to be voted on can be found at:
> >> > > http://people.apache.org/~rmetzger/flink-1.3.0-rc3
> >> > >
> >> > >
> >> > > The release artifacts are signed with the key with fingerprint
> >> D9839159:
> >> > > http://www.apache.org/dist/flink/KEYS
> >> > >
> >> > > The staging repository for this release can be found at:
> >> > > *https://repository.apache.org/content/repositories/orgapach
> >> eflink-1122
> >> > > <https://repository.apache.org/content/repositories/orgapach
> >> eflink-1122
> >> > >*
> >> > >
> >> > > -------------------------------------------------------------
> >> > >
> >> > >
> >> > > The vote ends on Tuesday (May 30th), 7pm CET.
> >> > >
> >> > > [ ] +1 Release this package as Apache Flink 1.3.0
> >> > > [ ] -1 Do not release this package, because ...
> >> >
> >> >
> >>
> >
> >
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Robert Metzger <rm...@apache.org>.
The vote time is over, but I'll keep it open for a bit longer until we've
decided regarding Till's issue.
On Tue, May 30, 2017 at 6:10 PM, Robert Metzger <rm...@apache.org> wrote:
> Hi Till,
> good catch! That is definitively a severe issue. Probably it didn't
> surface yet, because
> a) the code example in the documentation is using a new instance for each
> state descriptor
> b) people are using stateless serializers?
> c) don't have the same state descriptor on the same machine
>
> I see two options how to handle the situation
> 1) Cancel RC3 and do another vote (potentially with a 24 hrs vote time)
> 2) Release RC3 as 1.3.0 and start the vote for 1.3.1 right afterwards.
>
>
> + Pros and - cons for cancelling RC3
> - The release would be delayed (not sure who's expecting the 1.3.0 to be
> available on time)
> - The bug has been there since many releases, probably no user is affected
> and it was not introduced during the rel 1.3.0 cycle.
> - There is a workaround for the issue
> + We would have a better feeling for the 1.3.0 release because there are
> no known critical issues.
>
> + pro and - cons for releasing RC3:
> + there are some other "minor" issues that showed up during the 1.3.0
> testing that could go into 1.3.1 (FLINK-6763
> <https://issues.apache.org/jira/browse/FLINK-6763>, FLINK-6764
> <https://issues.apache.org/jira/browse/FLINK-6764>) without too much
> time-pressure (I'm happy to manage the 1.3.1 release and start it tomorrow)
>
>
> I'm undecided between both options and more than happy to hear your
> opinion.
>
>
>
> On Tue, May 30, 2017 at 4:18 PM, Till Rohrmann <tr...@apache.org>
> wrote:
>
>> I might have found a blocking issue [1]. The problem is that a
>> StateDescriptor cannot be shared by multiple subtasks because they don't
>> duplicate their serializer. As a consequence, things break if you have a
>> stateful serializer. The problem exists since 1.0. However, given that
>> this
>> issue is really hard to debug for the user and one can easily fall into
>> this trap, I would like to fix it for the release.
>>
>> [1] https://issues.apache.org/jira/browse/FLINK-6775
>>
>> Cheers,
>> Till
>>
>> On Tue, May 30, 2017 at 4:01 PM, Greg Hogan <co...@greghogan.com> wrote:
>>
>> > +1 (binding)
>> >
>> > - verified source and binary signatures
>> > - verified source and binary checksums
>> > - verified LICENSEs
>> > - verified NOTICEs
>> > - built from source
>> >
>> > Greg
>> >
>> >
>> > > On May 26, 2017, at 12:58 PM, Robert Metzger <rm...@apache.org>
>> > wrote:
>> > >
>> > > Hi all,
>> > >
>> > > this is the second VOTEing release candidate for Flink 1.3.0
>> > >
>> > > The commit to be voted on:
>> > > 760eea8a <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8
>> a>
>> > > (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
>> > > <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
>> > >
>> > > Branch:
>> > > release-1.3.0-rc3
>> > >
>> > > The release artifacts to be voted on can be found at:
>> > > http://people.apache.org/~rmetzger/flink-1.3.0-rc3
>> > >
>> > >
>> > > The release artifacts are signed with the key with fingerprint
>> D9839159:
>> > > http://www.apache.org/dist/flink/KEYS
>> > >
>> > > The staging repository for this release can be found at:
>> > > *https://repository.apache.org/content/repositories/orgapach
>> eflink-1122
>> > > <https://repository.apache.org/content/repositories/orgapach
>> eflink-1122
>> > >*
>> > >
>> > > -------------------------------------------------------------
>> > >
>> > >
>> > > The vote ends on Tuesday (May 30th), 7pm CET.
>> > >
>> > > [ ] +1 Release this package as Apache Flink 1.3.0
>> > > [ ] -1 Do not release this package, because ...
>> >
>> >
>>
>
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Robert Metzger <rm...@apache.org>.
Hi Till,
good catch! That is definitively a severe issue. Probably it didn't surface
yet, because
a) the code example in the documentation is using a new instance for each
state descriptor
b) people are using stateless serializers?
c) don't have the same state descriptor on the same machine
I see two options how to handle the situation
1) Cancel RC3 and do another vote (potentially with a 24 hrs vote time)
2) Release RC3 as 1.3.0 and start the vote for 1.3.1 right afterwards.
+ Pros and - cons for cancelling RC3
- The release would be delayed (not sure who's expecting the 1.3.0 to be
available on time)
- The bug has been there since many releases, probably no user is affected
and it was not introduced during the rel 1.3.0 cycle.
- There is a workaround for the issue
+ We would have a better feeling for the 1.3.0 release because there are no
known critical issues.
+ pro and - cons for releasing RC3:
+ there are some other "minor" issues that showed up during the 1.3.0
testing that could go into 1.3.1 (FLINK-6763
<https://issues.apache.org/jira/browse/FLINK-6763>, FLINK-6764
<https://issues.apache.org/jira/browse/FLINK-6764>) without too much
time-pressure (I'm happy to manage the 1.3.1 release and start it tomorrow)
I'm undecided between both options and more than happy to hear your opinion.
On Tue, May 30, 2017 at 4:18 PM, Till Rohrmann <tr...@apache.org> wrote:
> I might have found a blocking issue [1]. The problem is that a
> StateDescriptor cannot be shared by multiple subtasks because they don't
> duplicate their serializer. As a consequence, things break if you have a
> stateful serializer. The problem exists since 1.0. However, given that this
> issue is really hard to debug for the user and one can easily fall into
> this trap, I would like to fix it for the release.
>
> [1] https://issues.apache.org/jira/browse/FLINK-6775
>
> Cheers,
> Till
>
> On Tue, May 30, 2017 at 4:01 PM, Greg Hogan <co...@greghogan.com> wrote:
>
> > +1 (binding)
> >
> > - verified source and binary signatures
> > - verified source and binary checksums
> > - verified LICENSEs
> > - verified NOTICEs
> > - built from source
> >
> > Greg
> >
> >
> > > On May 26, 2017, at 12:58 PM, Robert Metzger <rm...@apache.org>
> > wrote:
> > >
> > > Hi all,
> > >
> > > this is the second VOTEing release candidate for Flink 1.3.0
> > >
> > > The commit to be voted on:
> > > 760eea8a <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
> >
> > > (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
> > > <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
> > >
> > > Branch:
> > > release-1.3.0-rc3
> > >
> > > The release artifacts to be voted on can be found at:
> > > http://people.apache.org/~rmetzger/flink-1.3.0-rc3
> > >
> > >
> > > The release artifacts are signed with the key with fingerprint
> D9839159:
> > > http://www.apache.org/dist/flink/KEYS
> > >
> > > The staging repository for this release can be found at:
> > > *https://repository.apache.org/content/repositories/orgapach
> eflink-1122
> > > <https://repository.apache.org/content/repositories/orgapach
> eflink-1122
> > >*
> > >
> > > -------------------------------------------------------------
> > >
> > >
> > > The vote ends on Tuesday (May 30th), 7pm CET.
> > >
> > > [ ] +1 Release this package as Apache Flink 1.3.0
> > > [ ] -1 Do not release this package, because ...
> >
> >
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Till Rohrmann <tr...@apache.org>.
I might have found a blocking issue [1]. The problem is that a
StateDescriptor cannot be shared by multiple subtasks because they don't
duplicate their serializer. As a consequence, things break if you have a
stateful serializer. The problem exists since 1.0. However, given that this
issue is really hard to debug for the user and one can easily fall into
this trap, I would like to fix it for the release.
[1] https://issues.apache.org/jira/browse/FLINK-6775
Cheers,
Till
On Tue, May 30, 2017 at 4:01 PM, Greg Hogan <co...@greghogan.com> wrote:
> +1 (binding)
>
> - verified source and binary signatures
> - verified source and binary checksums
> - verified LICENSEs
> - verified NOTICEs
> - built from source
>
> Greg
>
>
> > On May 26, 2017, at 12:58 PM, Robert Metzger <rm...@apache.org>
> wrote:
> >
> > Hi all,
> >
> > this is the second VOTEing release candidate for Flink 1.3.0
> >
> > The commit to be voted on:
> > 760eea8a <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>
> > (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
> > <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
> >
> > Branch:
> > release-1.3.0-rc3
> >
> > The release artifacts to be voted on can be found at:
> > http://people.apache.org/~rmetzger/flink-1.3.0-rc3
> >
> >
> > The release artifacts are signed with the key with fingerprint D9839159:
> > http://www.apache.org/dist/flink/KEYS
> >
> > The staging repository for this release can be found at:
> > *https://repository.apache.org/content/repositories/orgapacheflink-1122
> > <https://repository.apache.org/content/repositories/orgapacheflink-1122
> >*
> >
> > -------------------------------------------------------------
> >
> >
> > The vote ends on Tuesday (May 30th), 7pm CET.
> >
> > [ ] +1 Release this package as Apache Flink 1.3.0
> > [ ] -1 Do not release this package, because ...
>
>
Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Posted by Greg Hogan <co...@greghogan.com>.
+1 (binding)
- verified source and binary signatures
- verified source and binary checksums
- verified LICENSEs
- verified NOTICEs
- built from source
Greg
> On May 26, 2017, at 12:58 PM, Robert Metzger <rm...@apache.org> wrote:
>
> Hi all,
>
> this is the second VOTEing release candidate for Flink 1.3.0
>
> The commit to be voted on:
> 760eea8a <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>
> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
> <http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a>*)
>
> Branch:
> release-1.3.0-rc3
>
> The release artifacts to be voted on can be found at:
> http://people.apache.org/~rmetzger/flink-1.3.0-rc3
>
>
> The release artifacts are signed with the key with fingerprint D9839159:
> http://www.apache.org/dist/flink/KEYS
>
> The staging repository for this release can be found at:
> *https://repository.apache.org/content/repositories/orgapacheflink-1122
> <https://repository.apache.org/content/repositories/orgapacheflink-1122>*
>
> -------------------------------------------------------------
>
>
> The vote ends on Tuesday (May 30th), 7pm CET.
>
> [ ] +1 Release this package as Apache Flink 1.3.0
> [ ] -1 Do not release this package, because ...