I've just merged the fix for this blocker (FLINK-6685).

On Tue, Jun 13, 2017 at 11:21 AM, Aljoscha Krettek <aljos...@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 <ches...@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 <tzuli...@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 (aljos...@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 <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