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 <twal...@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 <trohrm...@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 <rmetz...@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 <rmetz...@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 <trohrm...@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 <c...@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 <rmetz...@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 ... >>>>>>>> >>>>>>> >>>>>>> >>>>> >
