Re: [RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)

[Kostas Kloudas]

+1 for Gordon’s suggestion.

> On Jun 6, 2017, at 2:52 PM, Ted Yu  wrote:
> 
> +1
> 
> bq. we can collect this list on the wiki
> 
> Or utilize the Release Note field of JIRA for each such change.
> 
> On Tue, Jun 6, 2017 at 5:45 AM, Till Rohrmann  wrote:
> 
>> +1 for your suggestions Tzu-Li.
>> 
>> On Tue, Jun 6, 2017 at 9:47 AM, Tzu-Li (Gordon) Tai 
>> wrote:
>> 
>>> One suggestion for future major release announcements:
>>> 
>>> I propose that we add a list of deprecated / breaking API changes in the
>>> announcement of major releases.
>>> Although @PublicEnvolving API is not guaranteed to not change across
>>> releases, it would still be nice that there’s a proper announcement when
>>> changing or deprecating them.
>>> Ideally, to avoid collecting the whole list during the release which most
>>> likely wouldn’t work, we can collect this list on the wiki during the
>>> development cycle.
>>> 
>>> 
>>> On 31 May 2017 at 2:22:34 PM, Robert Metzger (rmetz...@apache.org)
>> wrote:
>>> 
>>> Thanks a lot for all your responses on the point Till raised.
>>> It seems that we have an agreement to release this RC as Flink 1.3.0.
>>> I'll include a note into the release announcement regarding the state
>>> descriptor issue.
>>> 
>>> 
>>> Thanks also for all the release testing and the votes.
>>> 
>>> +1 votes:
>>> - Chesnay
>>> - Robert (binding)
>>> - jincheng sun
>>> - Aljoscha (binding)
>>> - Gordon
>>> - Greg (binding)
>>> 
>>> That's 6 votes, out of which 3 are binding.
>>> Therefore, I'll release RC3 as Flink 1.3.0!
>>> 
>>> 
>>> 
>>> On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann 
>>> wrote:
>>> 
 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.rich...@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 :
>> 
>> 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  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 <
>> n...@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: [RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)

[Ted Yu]

+1

bq. we can collect this list on the wiki

Or utilize the Release Note field of JIRA for each such change.

On Tue, Jun 6, 2017 at 5:45 AM, Till Rohrmann  wrote:

> +1 for your suggestions Tzu-Li.
>
> On Tue, Jun 6, 2017 at 9:47 AM, Tzu-Li (Gordon) Tai 
> wrote:
>
> > One suggestion for future major release announcements:
> >
> > I propose that we add a list of deprecated / breaking API changes in the
> > announcement of major releases.
> > Although @PublicEnvolving API is not guaranteed to not change across
> > releases, it would still be nice that there’s a proper announcement when
> > changing or deprecating them.
> > Ideally, to avoid collecting the whole list during the release which most
> > likely wouldn’t work, we can collect this list on the wiki during the
> > development cycle.
> >
> >
> > On 31 May 2017 at 2:22:34 PM, Robert Metzger (rmetz...@apache.org)
> wrote:
> >
> > Thanks a lot for all your responses on the point Till raised.
> > It seems that we have an agreement to release this RC as Flink 1.3.0.
> > I'll include a note into the release announcement regarding the state
> > descriptor issue.
> >
> >
> > Thanks also for all the release testing and the votes.
> >
> > +1 votes:
> > - Chesnay
> > - Robert (binding)
> > - jincheng sun
> > - Aljoscha (binding)
> > - Gordon
> > - Greg (binding)
> >
> > That's 6 votes, out of which 3 are binding.
> > Therefore, I'll release RC3 as Flink 1.3.0!
> >
> >
> >
> > On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann 
> > wrote:
> >
> > > 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.rich...@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 :
> > > > >
> > > > > 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  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 <
> n...@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

Re: [RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)

[Till Rohrmann]

+1 for your suggestions Tzu-Li.

On Tue, Jun 6, 2017 at 9:47 AM, Tzu-Li (Gordon) Tai 
wrote:

> One suggestion for future major release announcements:
>
> I propose that we add a list of deprecated / breaking API changes in the
> announcement of major releases.
> Although @PublicEnvolving API is not guaranteed to not change across
> releases, it would still be nice that there’s a proper announcement when
> changing or deprecating them.
> Ideally, to avoid collecting the whole list during the release which most
> likely wouldn’t work, we can collect this list on the wiki during the
> development cycle.
>
>
> On 31 May 2017 at 2:22:34 PM, Robert Metzger (rmetz...@apache.org) wrote:
>
> Thanks a lot for all your responses on the point Till raised.
> It seems that we have an agreement to release this RC as Flink 1.3.0.
> I'll include a note into the release announcement regarding the state
> descriptor issue.
>
>
> Thanks also for all the release testing and the votes.
>
> +1 votes:
> - Chesnay
> - Robert (binding)
> - jincheng sun
> - Aljoscha (binding)
> - Gordon
> - Greg (binding)
>
> That's 6 votes, out of which 3 are binding.
> Therefore, I'll release RC3 as Flink 1.3.0!
>
>
>
> On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann 
> wrote:
>
> > 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.rich...@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 :
> > > >
> > > > 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  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 
> > > >> 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: [RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)

[Tzu-Li (Gordon) Tai]

One suggestion for future major release announcements:

I propose that we add a list of deprecated / breaking API changes in the 
announcement of major releases.
Although @PublicEnvolving API is not guaranteed to not change across releases, 
it would still be nice that there’s a proper announcement when changing or 
deprecating them.
Ideally, to avoid collecting the whole list during the release which most 
likely wouldn’t work, we can collect this list on the wiki during the 
development cycle.


On 31 May 2017 at 2:22:34 PM, Robert Metzger (rmetz...@apache.org) wrote:

Thanks a lot for all your responses on the point Till raised.  
It seems that we have an agreement to release this RC as Flink 1.3.0.  
I'll include a note into the release announcement regarding the state  
descriptor issue.  


Thanks also for all the release testing and the votes.  

+1 votes:  
- Chesnay  
- Robert (binding)  
- jincheng sun  
- Aljoscha (binding)  
- Gordon  
- Greg (binding)  

That's 6 votes, out of which 3 are binding.  
Therefore, I'll release RC3 as Flink 1.3.0!  



On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann  wrote:  

> 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.rich...@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 :  
> > >  
> > > 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  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   
> > >> 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)

[Robert Metzger]

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  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  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.rich...@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 :
>>>
>>> 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  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 
>
 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)

[Timo Walther]

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  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.rich...@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 :

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  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 

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)

[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  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.rich...@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 :
> 
> 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  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 
>> 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)

[Timo Walther]

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.rich...@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 :

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  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 

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)

[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.rich...@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 :

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  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 

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.

[RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)

[Robert Metzger]

Thanks a lot for all your responses on the point Till raised.
It seems that we have an agreement to release this RC as Flink 1.3.0.
I'll include a note into the release announcement regarding the state
descriptor issue.


Thanks also for all the release testing and the votes.

+1 votes:
- Chesnay
- Robert (binding)
- jincheng sun
- Aljoscha (binding)
- Gordon
- Greg (binding)

That's 6 votes, out of which 3 are binding.
Therefore, I'll release RC3 as Flink 1.3.0!



On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann  wrote:

> 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.rich...@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 :
> > >
> > > 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  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 
> > >> 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)

[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.rich...@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 :
> >
> > 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  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 
> >> 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)

[Stefan Richter]

+1 for releasing now and providing a 1.3.1 release soon.

> Am 31.05.2017 um 11:02 schrieb Gyula Fóra :
> 
> 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  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 
>> 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)

[Gyula Fóra]

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  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 
> 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)

[Kostas Kloudas]

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  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)

[Ufuk Celebi]

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  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)

[Nico Kruber]

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.



signature.asc
Description: This is a digitally signed message part.

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Fabian Hueske]

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 :

> 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 
>> 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 
>>> 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 
 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
> , 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 
> 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 
>>
> 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 >> wrote:
>>>
 Hi all,

 this is the second VOTEing release candidate for Flink 1.3.0

 The commit to be voted on:
 760eea8a >> repos/asf/flink/commit/760eea8

> a>
>>
>>> (*http://git-wip-us.apache.org/repos/asf/flink/commit/760eea8a
 

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Timo Walther]

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  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 
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 
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
, 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 
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 

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 

(*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

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[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  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 
> 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 
> > 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
> > > , 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 
> > > 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 
> 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  >
> > >> > wrote:
> > >> > >
> > >> > > Hi all,
> > >> > >
> > >> > > this is the second VOTEing release candidate for Flink 1.3.0
> > >> > >
> > >> > > The commit to be voted on:
> > >> > > 760eea8a  > repos/asf/flink/commit/760eea8
> > >> a>
> > >> > > (*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
> > >> > >  > >> eflink-1122
> > >> > >*
> > >> > >
> > >> > > 

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Till Rohrmann]

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  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 
> 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
> > , 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 
> > 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  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 
> >> > wrote:
> >> > >
> >> > > Hi all,
> >> > >
> >> > > this is the second VOTEing release candidate for Flink 1.3.0
> >> > >
> >> > > The commit to be voted on:
> >> > > 760eea8a  repos/asf/flink/commit/760eea8
> >> a>
> >> > > (*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
> >> > >  >> 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)

[Robert Metzger]

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  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
> , 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 
> 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  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 
>> > wrote:
>> > >
>> > > Hi all,
>> > >
>> > > this is the second VOTEing release candidate for Flink 1.3.0
>> > >
>> > > The commit to be voted on:
>> > > 760eea8a > a>
>> > > (*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
>> > > > 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)

[Robert Metzger]

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
, 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  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  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 
> > 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
> > > *)
> > >
> > > 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
> > >  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)

[Till Rohrmann]

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  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 
> 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
> > *)
> >
> > 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
> >  >*
> >
> > -
> >
> >
> > 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)

[Greg Hogan]

+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  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
> *)
> 
> 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
> *
> 
> -
> 
> 
> 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)

[Tzu-Li (Gordon) Tai]

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

+1  

I did:  
- manually check the release using the new end-to-end tests: 
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  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   
> 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 :  
>>  
>>> 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  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 >>  
 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 <  
>> ches...@apache.org  
  
>> wrote:  
>>  
>> I've responded in the JIRA. In my opinion 

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Aljoscha Krettek]

+1

I did:
 - manually check the release using the new end-to-end tests: 
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  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 
> 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 :
>> 
>>> 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  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 >> 
 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 <
>> ches...@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  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 <
 rmetz...@apache.org>
> wrote:
> 

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Robert Metzger]

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 
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 :
>
> > 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  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  >
> > > 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 <
> ches...@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  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 <
> > > 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
> > > >> 

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[jincheng sun]

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 :

> 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  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 
> > 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  >
> > >> 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  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 <
> > 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
> > >> *)
> > >>
> > >> 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
> > >>  > >> 

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Stefan Richter]

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 :
> 
> 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  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 
>> 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 
 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  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 <
>> 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
 *)
 
 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
 

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Gyula Fóra]

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  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 
> 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 
> >> 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  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 <
> 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
> >> *)
> >>
> >> 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
> >>  >> 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)

[Robert Metzger]

+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 
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 
>> 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  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 
> wrote:
>
> Hi all,
>
>> this is the second VOTEing release candidate for Flink 1.3.0
>>
>> The commit to be voted on:
>> 760eea8a > a>
>> (*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
>> > 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)

[Chesnay Schepler]

+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 
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  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 
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
*)

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

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Robert Metzger]

@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 
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  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 
>>> 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
 *)

 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
 

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Chesnay Schepler]

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  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 
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
*)

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

Re: [VOTE] Release Apache Flink 1.3.0 (RC3)

[Gyula Fóra]

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  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 
> 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
> > *)
> >
> > 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
> >  >*
> >
> > -
> >
> >
> > 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)

[Shaoxuan Wang]

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 
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
> *)
>
> 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
> *
>
> -
>
>
> 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 ...
>

[VOTE] Release Apache Flink 1.3.0 (RC3)

[Robert Metzger]

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
*)

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
*

-


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 ...