flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jincheng sun <sunjincheng...@gmail.com>
Subject Re: [DISCUSS] Release Apache Flink 1.3.1
Date Mon, 19 Jun 2017 15:00:55 GMT
Thanks @Timo!

2017-06-19 22:02 GMT+08:00 Timo Walther <twalthr@apache.org>:

> I'm working on https://issues.apache.org/jira/browse/FLINK-6896 and
> https://issues.apache.org/jira/browse/FLINK-6881. I try to open a PR for
> both today.
>
> Timo
>
>
> Am 19.06.17 um 14:54 schrieb Robert Metzger:
>
> Fabian and SunJincheng, it looks like we are cancelling the 1.3.1 RC1.
>> So there is the opportunity to get the two mentioned JIRAs in.
>>
>> On Wed, Jun 14, 2017 at 4:16 PM, Robert Metzger <rmetzger@apache.org>
>> wrote:
>>
>> I've closed my emails, so I didn't see your messages anymore Fabian.
>>> The RC1 for 1.3.1 is out now. I personally think we should not cancel it
>>> because of these two issues.
>>> If we find more stuff we can do it, but I would like to push out 1.3.1
>>> soon to make the ES5 connector and the fixes to the state descriptors
>>> available.
>>>
>>> On Wed, Jun 14, 2017 at 11:22 AM, jincheng sun <sunjincheng121@gmail.com
>>> >
>>> wrote:
>>>
>>> Hi @Robert,
>>>> I agree with @Fabian.
>>>> And thanks for review those PRs. @Fabian.
>>>>
>>>> Cheers,
>>>> SunJincheng
>>>>
>>>> 2017-06-14 16:53 GMT+08:00 Fabian Hueske <fhueske@gmail.com>:
>>>>
>>>> I don't think that
>>>>>
>>>>> https://issues.apache.org/jira/browse/FLINK-6886
>>>>> https://issues.apache.org/jira/browse/FLINK-6896
>>>>>
>>>>> are blockers but it would be good to include them.
>>>>> I'll try to review the PRs today and merge them.
>>>>>
>>>>> Cheers, Fabian
>>>>>
>>>>> 2017-06-13 11:48 GMT+02:00 Till Rohrmann <trohrmann@apache.org>:
>>>>>
>>>>> I've just merged the fix for this blocker (FLINK-6685).
>>>>>>
>>>>>> On Tue, Jun 13, 2017 at 11:21 AM, Aljoscha Krettek <
>>>>>>
>>>>> aljoscha@apache.org>
>>>>
>>>>> wrote:
>>>>>>
>>>>>> A quick Jira search reveals one blocker: https://issues.apache.org/
>>>>>>> jira/browse/FLINK-6685?filter=12334772&jql=project%20%3D%
>>>>>>> 20FLINK%20AND%20priority%20%3D%20Blocker%20AND%20resolution%20%3D%
>>>>>>> 20Unresolved%20AND%20affectedVersion%20%3D%201.3.0 <
>>>>>>> https://issues.apache.org/jira/browse/FLINK-6685?filter=
>>>>>>> 12334772&jql=project%20=%20FLINK%20AND%20priority%20=%
>>>>>>> 20Blocker%20AND%20resolution%20=%20Unresolved%20AND%
>>>>>>> 20affectedVersion%20=%201.3.0>
>>>>>>>
>>>>>>> On 13. Jun 2017, at 10:12, Chesnay Schepler <chesnay@apache.org>
>>>>>>>>
>>>>>>> wrote:
>>>>>>
>>>>>>> I would like to include FLINK-6898 and FLINK-6900 in 1.3.1.
>>>>>>>>
>>>>>>>> They are related to the metric system, and limit the size
of
>>>>>>>>
>>>>>>> individual
>>>>>
>>>>>> metric name components
>>>>>>>
>>>>>>>> as the default window operator names are so long they were
causing
>>>>>>>>
>>>>>>> issues with file-system based
>>>>>>>
>>>>>>>> storages because the components exceeded 255 characters.
>>>>>>>>
>>>>>>>> They both have open PRs and change 1 and 3 lines respectively,
so
>>>>>>>>
>>>>>>> it's
>>>>>
>>>>>> very fast to review.
>>>>>>>
>>>>>>>> On 13.06.2017 09:33, jincheng sun wrote:
>>>>>>>>
>>>>>>>>> Hi Robert,
>>>>>>>>>   From user mail-list I find 2 bugs as follows:
>>>>>>>>>
>>>>>>>>>   https://issues.apache.org/jira/browse/FLINK-6886
>>>>>>>>>   https://issues.apache.org/jira/browse/FLINK-6896
>>>>>>>>>
>>>>>>>>> I'm not sure if they are as the release blocker. But
I think is
>>>>>>>>>
>>>>>>>> better
>>>>>
>>>>>> to
>>>>>>>
>>>>>>>> merged those two PR. into 1.3.1 release.
>>>>>>>>> What do you think? @Fabian, @Timo, @Robert
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> SunJincheng
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017-06-13 14:03 GMT+08:00 Tzu-Li (Gordon) Tai <
>>>>>>>>>
>>>>>>>> tzulitai@apache.org
>>>>
>>>>> :
>>>>>>
>>>>>>> I’ve just merged the last blockers for 1.3.1. IMO, the release
>>>>>>>>>>
>>>>>>>>> process
>>>>>>
>>>>>>> for
>>>>>>>
>>>>>>>> 1.3.1 is ready for kick off.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 8 June 2017 at 10:32:47 AM, Aljoscha Krettek (
>>>>>>>>>>
>>>>>>>>> aljoscha@apache.org
>>>>>
>>>>>> )
>>>>>>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Yes, there is a workaround, as mentioned in the other
thread:
>>>>>>>>>> https://lists.apache.org/thread.html/
>>>>>>>>>>
>>>>>>>>> eb7e256146fbe069a4210e1690fac5
>>>>>
>>>>>> d3453208fab61515ab1a2f6bf7@%3Cuser.flink.apache.org%3E <
>>>>>>>>>> https://lists.apache.org/thread.html/
>>>>>>>>>>
>>>>>>>>> eb7e256146fbe069a4210e1690fac5
>>>>>
>>>>>> d3453208fab61515ab1a2f6bf7@%3Cuser.flink.apache.org%3E>. It’s
>>>>>>>>>>
>>>>>>>>> just a
>>>>>
>>>>>> bit
>>>>>>>
>>>>>>>> cumbersome but I agree that it’s not a blocker now.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Aljoscha
>>>>>>>>>>
>>>>>>>>>>> On 8. Jun 2017, at 09:47, Till Rohrmann <trohrmann@apache.org>
>>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>
>>>>>>> There should be an easy work-around for this problem. Start a
>>>>>>>>>>>
>>>>>>>>>> standalone
>>>>>>>
>>>>>>>> cluster and run the queries against this cluster. But I also
>>>>>>>>>>>
>>>>>>>>>> see
>>>>
>>>>> that
>>>>>>
>>>>>>> it
>>>>>>>
>>>>>>>> might be annoying for users who used to do it differently.
The
>>>>>>>>>>>
>>>>>>>>>> basic
>>>>>
>>>>>> question here should be whether we want the users to use the
>>>>>>>>>>> LocalFlinkMiniCluster in a remote setting (running
queries
>>>>>>>>>>>
>>>>>>>>>> against
>>>>
>>>>> it
>>>>>>
>>>>>>> from
>>>>>>>>>>
>>>>>>>>>>> a different process).
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Till
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jun 7, 2017 at 4:59 PM, Aljoscha Krettek
<
>>>>>>>>>>>
>>>>>>>>>> aljoscha@apache.org
>>>>>>
>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I would also like to raise another potential
blocker: it’s
>>>>>>>>>>>>
>>>>>>>>>>> currently
>>>>>>
>>>>>>> not
>>>>>>>
>>>>>>>> easily possible for users to start a job in local mode in
the
>>>>>>>>>>>>
>>>>>>>>>>> IDE
>>>>
>>>>> and to
>>>>>>>
>>>>>>>> then interact with that cluster, say for experimenting with
>>>>>>>>>>>>
>>>>>>>>>>> queryable
>>>>>>
>>>>>>> state. At least one user walked into this problem already with
>>>>>>>>>>>>
>>>>>>>>>>> the
>>>>>
>>>>>> 1.3.0
>>>>>>>
>>>>>>>> RC: https://lists.apache.org/thread.html/
>>>>>>>>>>>>
>>>>>>>>>>> eb7e256146fbe069a4210e1690fac5
>>>>>>>
>>>>>>>> d3453208fab61515ab1a2f6bf7@%3Cuser.flink.apache.org%3E <
>>>>>>>>>>>> https://lists.apache.org/thread.html/
>>>>>>>>>>>>
>>>>>>>>>>> eb7e256146fbe069a4210e1690fac5
>>>>>>
>>>>>>> d3453208fab61515ab1a2f6bf7@%3Cuser.flink.apache.org%3E>
>>>>>>>>>>>>
>>>>>>>>>>>> The reasons I have so far analysed are:
>>>>>>>>>>>> * the local flink cluster starts with HAServices
that don’t
>>>>>>>>>>>>
>>>>>>>>>>> allow
>>>>
>>>>> external querying, by default. (Broadly spoken)
>>>>>>>>>>>> * the queryable state server is not started
in the local flink
>>>>>>>>>>>>
>>>>>>>>>>> mini
>>>>>
>>>>>> cluster anymore and it cannot be configured to do so easily
>>>>>>>>>>>>
>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>> Aljoscha
>>>>>>>>>>>>
>>>>>>>>>>>>> On 7. Jun 2017, at 11:54, Robert Metzger
<
>>>>>>>>>>>>>
>>>>>>>>>>>> rmetzger@apache.org>
>>>>
>>>>> wrote:
>>>>>>>
>>>>>>>>  From the list [1], not many of the JIRAs have been fixed.
>>>>>>>>>>>>> I think it would be nice to put the RC
for 1.3.1 out this
>>>>>>>>>>>>>
>>>>>>>>>>>> week,
>>>>
>>>>> given
>>>>>>>
>>>>>>>> that
>>>>>>>>>>>>
>>>>>>>>>>>>> multiple users have complained about
some issues in the 1.3.0
>>>>>>>>>>>>>
>>>>>>>>>>>> release.
>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1]
>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=labels%20%3D%
>>>>>>>>>>>>>
>>>>>>>>>>>> 20flink-rel-1.3.1-blockers
>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Jun 6, 2017 at 10:58 AM, Tzu-Li
(Gordon) Tai <
>>>>>>>>>>>>>
>>>>>>>>>>>> tzulitai@apache.org>
>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> After an offline discussion with Till,
we decided to not
>>>>>>>>>>>>>>
>>>>>>>>>>>>> include
>>>>>
>>>>>> FLINK-6763 and FLINK-6764 as blockers for 1.3.1, and only
>>>>>>>>>>>>>>
>>>>>>>>>>>>> merge
>>>>
>>>>> them
>>>>>>>
>>>>>>>> for
>>>>>>>>>>
>>>>>>>>>>> 1.4.0 since they change serialization formats
for
>>>>>>>>>>>>>>
>>>>>>>>>>>>> checkpoints.
>>>>
>>>>> In turn, I’ve included https://issues.apache.org/
>>>>>>>>>>>>>>
>>>>>>>>>>>>> jira/browse/FLINK-6804
>>>>>>>>>>
>>>>>>>>>>> as
>>>>>>>>>>>>
>>>>>>>>>>>>> a 1.3.1 blocker.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2 June 2017 at 5:27:18 PM, Nico
Kruber (
>>>>>>>>>>>>>>
>>>>>>>>>>>>> nico@data-artisans.com)
>>>>>>
>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> while fixing build issues - what about
FLINK-6654?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Friday, 2 June 2017 11:05:34 CEST
Robert Metzger wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi devs,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would like to release Apache
Flink 1.3.1 with the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> following
>>>>
>>>>> fixes:
>>>>>>>
>>>>>>>> - FLINK-6812 Elasticsearch 5 release artifacts not
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> published
>>>>
>>>>> to
>>>>>
>>>>>> Maven
>>>>>>>
>>>>>>>> central
>>>>>>>>>>>>>>> - FLINK-6783 Wrongly extracted
TypeInformations for
>>>>>>>>>>>>>>> WindowedStream::aggregate
>>>>>>>>>>>>>>> - FLINK-6780 ExternalTableSource
should add time
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> attributes in
>>>>
>>>>> the
>>>>>>
>>>>>>> row
>>>>>>>>>>
>>>>>>>>>>> type
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - FLINK-6775 StateDescriptor
cannot be shared by multiple
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> subtasks
>>>>>>
>>>>>>> - FLINK-6763 Inefficient PojoSerializerConfigSnapshot
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> serialization
>>>>>>>
>>>>>>>> format
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - FLINK-6764 Deduplicate stateless
TypeSerializers when
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> serializing
>>>>>>>
>>>>>>>> composite TypeSerializers
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is there anything else that we
need to wait for before we
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> vote
>>>>
>>>>> on
>>>>>>
>>>>>>> the
>>>>>>>
>>>>>>>> first
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> RC?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message