Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-06 Thread Till Rohrmann
I think so far, we did not do much manual testing with respect to TTL. There is also an end-to-end test covering this area. We actually intended to include in the second RC but it was merged just after starting the creation procedure was started. Therefore I would like to include it if there is no

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-06 Thread Chesnay Schepler
TBH I would prefer if we'd only include fixes for release blocking issues in follow-up RCs. If you now include state TTL improvemements we effectively invalidate any testing done so far in this area. On 06.08.2018 17:17, Till Rohrmann wrote: Yes, the next RC will also include FLINK-9938.

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-06 Thread Till Rohrmann
Yes, the next RC will also include FLINK-9938. On Mon, Aug 6, 2018 at 5:03 PM Aljoscha Krettek wrote: > Does this mean https://issues.apache.org/jira/browse/FLINK-9938 < > https://issues.apache.org/jira/browse/FLINK-9938> can move to 1.6.0 from > 1.6.1 as well? > > > On 6. Aug 2018, at 17:00,

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-06 Thread Aljoscha Krettek
Does this mean https://issues.apache.org/jira/browse/FLINK-9938 can move to 1.6.0 from 1.6.1 as well? > On 6. Aug 2018, at 17:00, Till Rohrmann wrote: > > Officially cancelling this RC in order to fix FLINK-10070. I will publish > the next RC

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-06 Thread Till Rohrmann
Officially cancelling this RC in order to fix FLINK-10070. I will publish the next RC later today. Cheers, Till On Mon, Aug 6, 2018 at 3:50 PM Till Rohrmann wrote: > I agree with Chesnay and think that we should fix FLINK-10070 for 1.6. A > PR fixing this issue is already open and can be

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-06 Thread Till Rohrmann
I agree with Chesnay and think that we should fix FLINK-10070 for 1.6. A PR fixing this issue is already open and can be merged in half an hour. Since this change only affects the build, I would like to create a new RC with a shortened voting period until Wednesday evening (CET) which would end

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-06 Thread Chesnay Schepler
Potential release blocked: Flink cannot be compiled with maven 3.0.X https://issues.apache.org/jira/browse/FLINK-10070 On 06.08.2018 11:21, Till Rohrmann wrote: Sure, only bugs will be fixed in 1.6.1. On Mon, Aug 6, 2018 at 10:34 AM Aljoscha Krettek > wrote:

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-06 Thread Till Rohrmann
Sure, only bugs will be fixed in 1.6.1. On Mon, Aug 6, 2018 at 10:34 AM Aljoscha Krettek wrote: > I don't think the fixVersion of all unresolved issues should be updated to > 1.6.1. If they are not bugs they will not be fixed in 1.6.1 anyways so they > should be updated to 1.7.0 or we can also

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-06 Thread Aljoscha Krettek
I don't think the fixVersion of all unresolved issues should be updated to 1.6.1. If they are not bugs they will not be fixed in 1.6.1 anyways so they should be updated to 1.7.0 or we can also remove the fixVersion from them entirely. > On 6. Aug 2018, at 10:16, Till Rohrmann wrote: > > I

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-06 Thread Till Rohrmann
I think you're right that it is better to change the fixVersion otherwise some issue might get wrongly attributed when they are merged in the release branch after creating the RC. I will update the fixVersion of all unresolved issues to 1.6.1. Cheers, Till On Mon, Aug 6, 2018 at 9:56 AM Chesnay

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-06 Thread Chesnay Schepler
Actually, this is defined in the release guide. https://cwiki.apache.org/confluence/display/FLINK/Creating+a+Flink+Release#CreatingaFlinkRelease-ReviewReleaseNotesinJIRA On 06.08.2018 09:11, Till Rohrmann wrote: I'm not strictly sure whether there must not be any issues with a fixVersion of

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-06 Thread Till Rohrmann
I'm not strictly sure whether there must not be any issues with a fixVersion of the current RC. At least in the past, we did not do it like this. Moreover, if a RC is canceled some of these issues might still go in the actual release. However, I also see the point that the release notes are

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-04 Thread Chesnay Schepler
Elias is correct, when a RC is out no more open issuen should exist that has a fixVersion for that version. (An uncommon exception is the first RC which can be released for testing purposes.) On 04.08.2018 04:34, vino yang wrote: Hi Elias, Usually in order to make the release note clear and

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-03 Thread vino yang
Hi Elias, Usually in order to make the release note clear and brief. It will only contain issues that have been fixed before the pre-release branch is cut. For issues that are scheduled to be processed in this version but not processed, they will be postponed to the next minor or major version.

Re: [VOTE] Release 1.6.0, release candidate #2

2018-08-03 Thread Elias Levy
On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann wrote: > The complete staging area is available for your review, which includes: > * JIRA release notes [1], > [1] > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522=12342760 Shouldn't the release notes only include issues

[VOTE] Release 1.6.0, release candidate #2

2018-08-03 Thread Till Rohrmann
Hi everyone, Please review and vote on the release candidate #2 for the version 1.6.0, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) The complete staging area is available for your review, which includes: * JIRA release notes [1], *