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 (aljos...@apache.org) wrote:

Yes, there is a workaround, as mentioned in the other thread: 
https://lists.apache.org/thread.html/eb7e256146fbe069a4210e1690fac5d3453208fab61515ab1a2f6bf7@%3Cuser.flink.apache.org%3E
 
<https://lists.apache.org/thread.html/eb7e256146fbe069a4210e1690fac5d3453208fab61515ab1a2f6bf7@%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 <trohrm...@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 <aljos...@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 <rmetz...@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 <  
>> tzuli...@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 (n...@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  
>>>>  
>>>>  
>>  
>>  

Reply via email to