[VOTE] Release 1.6.0, release candidate #2

[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],
* the official Apache source release and binary convenience releases to be
deployed to dist.apache.org [2], which are signed with the key with
fingerprint 1F302569A96CFFD5 [3],
* all artifacts to be deployed to the Maven Central Repository [4],
* source code tag "release-1.6.0-rc2" [5],

Please use this document for coordinating testing efforts: [6]

The vote will be open for at least 72 hours. It is adopted by majority
approval, with at least 3 PMC affirmative votes.

Thanks,
Your friendly Release Manager

[1]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12342760
[2] https://dist.apache.org/repos/dist/dev/flink/flink-1.6.0/
[3] https://dist.apache.org/repos/dist/release/flink/KEYS
[4] https://repository.apache.org/content/repositories/orgapacheflink-1175
[5] https://github.com/apache/flink/tree/release-1.6.0-rc2
[6]
https://docs.google.com/document/d/1oZ7kYz7RrZ17oBTzzBzq3UNx5FTGmVrCw8EhzY7xUok/edit?usp=sharing

Pro-tip: you can create a settings.xml file with these contents:

<settings>
<activeProfiles>
  <activeProfile>flink-1.6.0</activeProfile>
</activeProfiles>
<profiles>
  <profile>
    <id>flink-1.6.0</id>
    <repositories>
      <repository>
        <id>flink-1.6.0</id>
        <url>

https://repository.apache.org/content/repositories/orgapacheflink-1175/
        </url>
      </repository>
      <repository>
        <id>archetype</id>
        <url>

https://repository.apache.org/content/repositories/orgapacheflink-1175/
        </url>
      </repository>
    </repositories>
  </profile>
</profiles>
</settings>

And reference that in you maven commands via --settings
path/to/settings.xml. This is useful for creating a quickstart based on the
staged release and for building against the staged jars.

[Elias Levy]

On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <[hidden email]> 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&version=12342760


Shouldn't the release notes only include issues that have been closed, not
simple those that have a Fix Version equal to the release version?  There
are a lot of issues with an assigned Fix Version that are still open.

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

Thanks, vino.

2018-08-04 7:54 GMT+08:00 Elias Levy <[hidden email]>:

> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <[hidden email]> 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&version=12342760
>
>
> Shouldn't the release notes only include issues that have been closed, not
> simple those that have a Fix Version equal to the release version?  There
> are a lot of issues with an assigned Fix Version that are still open.
>

[Chesnay Schepler-3]

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 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.
>
> Thanks, vino.
>
> 2018-08-04 7:54 GMT+08:00 Elias Levy <[hidden email]>:
>
>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <[hidden email]> 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&version=12342760
>>
>>
>> Shouldn't the release notes only include issues that have been closed, not
>> simple those that have a Fix Version equal to the release version?  There
>> are a lot of issues with an assigned Fix Version that are still open.
>>

[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 confusing as long
as the RC is not released. Once we release, JIRA will bump all unresolved
issues with a fixVersion of the release version to the next minor release
version. Then the release notes should reflect the truth.

I think this we should clearly define how the community wants to handle
this situation and adhere to it with the next release.

Cheers,
Till

On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler <[hidden email]> wrote:

> 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 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.
> >
> > Thanks, vino.
> >
> > 2018-08-04 7:54 GMT+08:00 Elias Levy <[hidden email]>:
> >
> >> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <[hidden email]>
> 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&version=12342760
> >>
> >>
> >> Shouldn't the release notes only include issues that have been closed,
> not
> >> simple those that have a Fix Version equal to the release version?
> There
> >> are a lot of issues with an assigned Fix Version that are still open.
> >>
>
>

[Chesnay Schepler-3]

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 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 confusing as long
> as the RC is not released. Once we release, JIRA will bump all unresolved
> issues with a fixVersion of the release version to the next minor release
> version. Then the release notes should reflect the truth.
>
> I think this we should clearly define how the community wants to handle
> this situation and adhere to it with the next release.
>
> Cheers,
> Till
>
> On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler <[hidden email]> wrote:
>
>> 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 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.
>>>
>>> Thanks, vino.
>>>
>>> 2018-08-04 7:54 GMT+08:00 Elias Levy <[hidden email]>:
>>>
>>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <[hidden email]>
>> 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&version=12342760
>>>>
>>>>
>>>> Shouldn't the release notes only include issues that have been closed,
>> not
>>>> simple those that have a Fix Version equal to the release version?
>> There
>>>> are a lot of issues with an assigned Fix Version that are still open.
>>>>
>>

[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 Schepler <[hidden email]> wrote:

> 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 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 confusing as
> long
> > as the RC is not released. Once we release, JIRA will bump all unresolved
> > issues with a fixVersion of the release version to the next minor release
> > version. Then the release notes should reflect the truth.
> >
> > I think this we should clearly define how the community wants to handle
> > this situation and adhere to it with the next release.
> >
> > Cheers,
> > Till
> >
> > On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler <[hidden email]>
> wrote:
> >
> >> 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 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.
> >>>
> >>> Thanks, vino.
> >>>
> >>> 2018-08-04 7:54 GMT+08:00 Elias Levy <[hidden email]>:
> >>>
> >>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <[hidden email]>
> >> 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&version=12342760
> >>>>
> >>>>
> >>>> Shouldn't the release notes only include issues that have been closed,
> >> not
> >>>> simple those that have a Fix Version equal to the release version?
> >> There
> >>>> are a lot of issues with an assigned Fix Version that are still open.
> >>>>
> >>
>
>

[Aljoscha Krettek-2]

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 <[hidden email]> wrote:
>
> 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 Schepler <[hidden email]> wrote:
>
>> 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 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 confusing as
>> long
>>> as the RC is not released. Once we release, JIRA will bump all unresolved
>>> issues with a fixVersion of the release version to the next minor release
>>> version. Then the release notes should reflect the truth.
>>>
>>> I think this we should clearly define how the community wants to handle
>>> this situation and adhere to it with the next release.
>>>
>>> Cheers,
>>> Till
>>>
>>> On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler <[hidden email]>
>> wrote:
>>>
>>>> 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 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.
>>>>>
>>>>> Thanks, vino.
>>>>>
>>>>> 2018-08-04 7:54 GMT+08:00 Elias Levy <[hidden email]>:
>>>>>
>>>>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <[hidden email]>
>>>> 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&version=12342760
>>>>>>
>>>>>>
>>>>>> Shouldn't the release notes only include issues that have been closed,
>>>> not
>>>>>> simple those that have a Fix Version equal to the release version?
>>>> There
>>>>>> are a lot of issues with an assigned Fix Version that are still open.
>>>>>>
>>>>
>>
>>

[Till Rohrmann]

Sure, only bugs will be fixed in 1.6.1.

On Mon, Aug 6, 2018 at 10:34 AM Aljoscha Krettek <[hidden email]>
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 remove the fixVersion from them
> entirely.
>
> > On 6. Aug 2018, at 10:16, Till Rohrmann <[hidden email]> wrote:
> >
> > 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 Schepler <[hidden email]>
> wrote:
> >
> >> 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 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 confusing as
> >> long
> >>> as the RC is not released. Once we release, JIRA will bump all
> unresolved
> >>> issues with a fixVersion of the release version to the next minor
> release
> >>> version. Then the release notes should reflect the truth.
> >>>
> >>> I think this we should clearly define how the community wants to handle
> >>> this situation and adhere to it with the next release.
> >>>
> >>> Cheers,
> >>> Till
> >>>
> >>> On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler <[hidden email]>
> >> wrote:
> >>>
> >>>> 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 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.
> >>>>>
> >>>>> Thanks, vino.
> >>>>>
> >>>>> 2018-08-04 7:54 GMT+08:00 Elias Levy <[hidden email]>:
> >>>>>
> >>>>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <[hidden email]>
> >>>> 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&version=12342760
> >>>>>>
> >>>>>>
> >>>>>> Shouldn't the release notes only include issues that have been
> closed,
> >>>> not
> >>>>>> simple those that have a Fix Version equal to the release version?
> >>>> There
> >>>>>> are a lot of issues with an assigned Fix Version that are still
> open.
> >>>>>>
> >>>>
> >>
> >>
>
>

[Chesnay Schepler-3]

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 <[hidden email]
> <mailto:[hidden email]>> 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
>     remove the fixVersion from them entirely.
>
>     > On 6. Aug 2018, at 10:16, Till Rohrmann <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >
>     > 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 Schepler
>     <[hidden email] <mailto:[hidden email]>> wrote:
>     >
>     >> 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 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
>     confusing as
>     >> long
>     >>> as the RC is not released. Once we release, JIRA will bump all
>     unresolved
>     >>> issues with a fixVersion of the release version to the next
>     minor release
>     >>> version. Then the release notes should reflect the truth.
>     >>>
>     >>> I think this we should clearly define how the community wants
>     to handle
>     >>> this situation and adhere to it with the next release.
>     >>>
>     >>> Cheers,
>     >>> Till
>     >>>
>     >>> On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler
>     <[hidden email] <mailto:[hidden email]>>
>     >> wrote:
>     >>>
>     >>>> 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 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.
>     >>>>>
>     >>>>> Thanks, vino.
>     >>>>>
>     >>>>> 2018-08-04 7:54 GMT+08:00 Elias Levy
>     <[hidden email] <mailto:[hidden email]>>:
>     >>>>>
>     >>>>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann
>     <[hidden email] <mailto:[hidden email]>>
>     >>>> 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&version=12342760
>     >>>>>>
>     >>>>>>
>     >>>>>> Shouldn't the release notes only include issues that have
>     been closed,
>     >>>> not
>     >>>>>> simple those that have a Fix Version equal to the release
>     version?
>     >>>> There
>     >>>>>> are a lot of issues with an assigned Fix Version that are
>     still open.
>     >>>>>>
>     >>>>
>     >>
>     >>
>

[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 at the same time as this RC's voting period.

Cheers,
Till

On Mon, Aug 6, 2018 at 1:36 PM Chesnay Schepler <[hidden email]> wrote:

> 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 <[hidden email]>
> 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 remove the fixVersion from
>> them entirely.
>>
>> > On 6. Aug 2018, at 10:16, Till Rohrmann <[hidden email]> wrote:
>> >
>> > 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 Schepler <[hidden email]>
>> wrote:
>> >
>> >> 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 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 confusing as
>> >> long
>> >>> as the RC is not released. Once we release, JIRA will bump all
>> unresolved
>> >>> issues with a fixVersion of the release version to the next minor
>> release
>> >>> version. Then the release notes should reflect the truth.
>> >>>
>> >>> I think this we should clearly define how the community wants to
>> handle
>> >>> this situation and adhere to it with the next release.
>> >>>
>> >>> Cheers,
>> >>> Till
>> >>>
>> >>> On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler <[hidden email]>
>> >> wrote:
>> >>>
>> >>>> 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 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.
>> >>>>>
>> >>>>> Thanks, vino.
>> >>>>>
>> >>>>> 2018-08-04 7:54 GMT+08:00 Elias Levy <[hidden email]>:
>> >>>>>
>> >>>>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <[hidden email]
>> >
>> >>>> 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&version=12342760
>> >>>>>>
>> >>>>>>
>> >>>>>> Shouldn't the release notes only include issues that have been
>> closed,
>> >>>> not
>> >>>>>> simple those that have a Fix Version equal to the release version?
>> >>>> There
>> >>>>>> are a lot of issues with an assigned Fix Version that are still
>> open.
>> >>>>>>
>> >>>>
>> >>
>> >>
>>
>>
>

[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 <[hidden email]> 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 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 at the same time as this RC's voting period.
>
> Cheers,
> Till
>
> On Mon, Aug 6, 2018 at 1:36 PM Chesnay Schepler <[hidden email]>
> wrote:
>
>> 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 <[hidden email]>
>> 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 remove the fixVersion from
>>> them entirely.
>>>
>>> > On 6. Aug 2018, at 10:16, Till Rohrmann <[hidden email]> wrote:
>>> >
>>> > 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 Schepler <[hidden email]>
>>> wrote:
>>> >
>>> >> 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 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 confusing as
>>> >> long
>>> >>> as the RC is not released. Once we release, JIRA will bump all
>>> unresolved
>>> >>> issues with a fixVersion of the release version to the next minor
>>> release
>>> >>> version. Then the release notes should reflect the truth.
>>> >>>
>>> >>> I think this we should clearly define how the community wants to
>>> handle
>>> >>> this situation and adhere to it with the next release.
>>> >>>
>>> >>> Cheers,
>>> >>> Till
>>> >>>
>>> >>> On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>>> 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 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.
>>> >>>>>
>>> >>>>> Thanks, vino.
>>> >>>>>
>>> >>>>> 2018-08-04 7:54 GMT+08:00 Elias Levy <[hidden email]
>>> >:
>>> >>>>>
>>> >>>>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <
>>> [hidden email]>
>>> >>>> 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&version=12342760
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Shouldn't the release notes only include issues that have been
>>> closed,
>>> >>>> not
>>> >>>>>> simple those that have a Fix Version equal to the release version?
>>> >>>> There
>>> >>>>>> are a lot of issues with an assigned Fix Version that are still
>>> open.
>>> >>>>>>
>>> >>>>
>>> >>
>>> >>
>>>
>>>
>>

[Aljoscha Krettek-2]

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, Till Rohrmann <[hidden email]> wrote:
>
> 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 <[hidden email]> 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 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 at the same time as this RC's voting period.
>>
>> Cheers,
>> Till
>>
>> On Mon, Aug 6, 2018 at 1:36 PM Chesnay Schepler <[hidden email]>
>> wrote:
>>
>>> 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 <[hidden email]>
>>> 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 remove the fixVersion from
>>>> them entirely.
>>>>
>>>>> On 6. Aug 2018, at 10:16, Till Rohrmann <[hidden email]> wrote:
>>>>>
>>>>> 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 Schepler <[hidden email]>
>>>> wrote:
>>>>>
>>>>>> 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 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 confusing as
>>>>>> long
>>>>>>> as the RC is not released. Once we release, JIRA will bump all
>>>> unresolved
>>>>>>> issues with a fixVersion of the release version to the next minor
>>>> release
>>>>>>> version. Then the release notes should reflect the truth.
>>>>>>>
>>>>>>> I think this we should clearly define how the community wants to
>>>> handle
>>>>>>> this situation and adhere to it with the next release.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Till
>>>>>>>
>>>>>>> On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>>> 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 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.
>>>>>>>>>
>>>>>>>>> Thanks, vino.
>>>>>>>>>
>>>>>>>>> 2018-08-04 7:54 GMT+08:00 Elias Levy <[hidden email]
>>>>> :
>>>>>>>>>
>>>>>>>>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <
>>>> [hidden email]>
>>>>>>>> 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&version=12342760
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Shouldn't the release notes only include issues that have been
>>>> closed,
>>>>>>>> not
>>>>>>>>>> simple those that have a Fix Version equal to the release version?
>>>>>>>> There
>>>>>>>>>> are a lot of issues with an assigned Fix Version that are still
>>>> open.
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>

[till.rohrmann]

Yes, the next RC will also include FLINK-9938.

On Mon, Aug 6, 2018 at 5:03 PM Aljoscha Krettek <[hidden email]> 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, Till Rohrmann <[hidden email]> wrote:
> >
> > 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 <[hidden email]>
> 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 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 at the same time as this RC's voting period.
> >>
> >> Cheers,
> >> Till
> >>
> >> On Mon, Aug 6, 2018 at 1:36 PM Chesnay Schepler <[hidden email]>
> >> wrote:
> >>
> >>> 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 <[hidden email]>
> >>> 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 remove the fixVersion
> from
> >>>> them entirely.
> >>>>
> >>>>> On 6. Aug 2018, at 10:16, Till Rohrmann <[hidden email]>
> wrote:
> >>>>>
> >>>>> 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 Schepler <[hidden email]>
> >>>> wrote:
> >>>>>
> >>>>>> 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 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 confusing
> as
> >>>>>> long
> >>>>>>> as the RC is not released. Once we release, JIRA will bump all
> >>>> unresolved
> >>>>>>> issues with a fixVersion of the release version to the next minor
> >>>> release
> >>>>>>> version. Then the release notes should reflect the truth.
> >>>>>>>
> >>>>>>> I think this we should clearly define how the community wants to
> >>>> handle
> >>>>>>> this situation and adhere to it with the next release.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Till
> >>>>>>>
> >>>>>>> On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler <
> [hidden email]>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> 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 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.
> >>>>>>>>>
> >>>>>>>>> Thanks, vino.
> >>>>>>>>>
> >>>>>>>>> 2018-08-04 7:54 GMT+08:00 Elias Levy <
> [hidden email]
> >>>>> :
> >>>>>>>>>
> >>>>>>>>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <
> >>>> [hidden email]>
> >>>>>>>> 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&version=12342760
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Shouldn't the release notes only include issues that have been
> >>>> closed,
> >>>>>>>> not
> >>>>>>>>>> simple those that have a Fix Version equal to the release
> version?
> >>>>>>>> There
> >>>>>>>>>> are a lot of issues with an assigned Fix Version that are still
> >>>> open.
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
>
>

[Chesnay Schepler-3]

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.
>
> On Mon, Aug 6, 2018 at 5:03 PM Aljoscha Krettek <[hidden email]> 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, Till Rohrmann <[hidden email]> wrote:
>>>
>>> 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 <[hidden email]>
>> 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 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 at the same time as this RC's voting period.
>>>>
>>>> Cheers,
>>>> Till
>>>>
>>>> On Mon, Aug 6, 2018 at 1:36 PM Chesnay Schepler <[hidden email]>
>>>> wrote:
>>>>
>>>>> 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 <[hidden email]>
>>>>> 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 remove the fixVersion
>> from
>>>>>> them entirely.
>>>>>>
>>>>>>> On 6. Aug 2018, at 10:16, Till Rohrmann <[hidden email]>
>> wrote:
>>>>>>> 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 Schepler <[hidden email]>
>>>>>> wrote:
>>>>>>>> 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 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 confusing
>> as
>>>>>>>> long
>>>>>>>>> as the RC is not released. Once we release, JIRA will bump all
>>>>>> unresolved
>>>>>>>>> issues with a fixVersion of the release version to the next minor
>>>>>> release
>>>>>>>>> version. Then the release notes should reflect the truth.
>>>>>>>>>
>>>>>>>>> I think this we should clearly define how the community wants to
>>>>>> handle
>>>>>>>>> this situation and adhere to it with the next release.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Till
>>>>>>>>>
>>>>>>>>> On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler <
>> [hidden email]>
>>>>>>>> wrote:
>>>>>>>>>> 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 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.
>>>>>>>>>>> Thanks, vino.
>>>>>>>>>>>
>>>>>>>>>>> 2018-08-04 7:54 GMT+08:00 Elias Levy <
>> [hidden email]
>>>>>>> :
>>>>>>>>>>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <
>>>>>> [hidden email]>
>>>>>>>>>> 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&version=12342760
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Shouldn't the release notes only include issues that have been
>>>>>> closed,
>>>>>>>>>> not
>>>>>>>>>>>> simple those that have a Fix Version equal to the release
>> version?
>>>>>>>>>> There
>>>>>>>>>>>> are a lot of issues with an assigned Fix Version that are still
>>>>>> open.
>>>>>>>>
>>>>>>
>>

[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 strong objection.

On Mon, Aug 6, 2018 at 5:40 PM Chesnay Schepler <[hidden email]> wrote:

> 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.
> >
> > On Mon, Aug 6, 2018 at 5:03 PM Aljoscha Krettek <[hidden email]>
> 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, Till Rohrmann <[hidden email]> wrote:
> >>>
> >>> 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 <[hidden email]>
> >> 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 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 at the same time as this RC's voting period.
> >>>>
> >>>> Cheers,
> >>>> Till
> >>>>
> >>>> On Mon, Aug 6, 2018 at 1:36 PM Chesnay Schepler <[hidden email]>
> >>>> wrote:
> >>>>
> >>>>> 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 <
> [hidden email]>
> >>>>> 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 remove the fixVersion
> >> from
> >>>>>> them entirely.
> >>>>>>
> >>>>>>> On 6. Aug 2018, at 10:16, Till Rohrmann <[hidden email]>
> >> wrote:
> >>>>>>> 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 Schepler <
> [hidden email]>
> >>>>>> wrote:
> >>>>>>>> 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 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
> confusing
> >> as
> >>>>>>>> long
> >>>>>>>>> as the RC is not released. Once we release, JIRA will bump all
> >>>>>> unresolved
> >>>>>>>>> issues with a fixVersion of the release version to the next minor
> >>>>>> release
> >>>>>>>>> version. Then the release notes should reflect the truth.
> >>>>>>>>>
> >>>>>>>>> I think this we should clearly define how the community wants to
> >>>>>> handle
> >>>>>>>>> this situation and adhere to it with the next release.
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Till
> >>>>>>>>>
> >>>>>>>>> On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler <
> >> [hidden email]>
> >>>>>>>> wrote:
> >>>>>>>>>> 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 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.
> >>>>>>>>>>> Thanks, vino.
> >>>>>>>>>>>
> >>>>>>>>>>> 2018-08-04 7:54 GMT+08:00 Elias Levy <
> >> [hidden email]
> >>>>>>> :
> >>>>>>>>>>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann <
> >>>>>> [hidden email]>
> >>>>>>>>>> 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&version=12342760
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Shouldn't the release notes only include issues that have been
> >>>>>> closed,
> >>>>>>>>>> not
> >>>>>>>>>>>> simple those that have a Fix Version equal to the release
> >> version?
> >>>>>>>>>> There
> >>>>>>>>>>>> are a lot of issues with an assigned Fix Version that are
> still
> >>>>>> open.
> >>>>>>>>
> >>>>>>
> >>
>
>