Re: 0.7.1 maintenance release

[Robert Metzger <rm...@apache.org>]

I looked through the commits since the last release and there is a huge
amount of improvements we could include.
I was thinking about limiting the commits for the bugfix release to a
absolute minimum. Only those issues users complained about or cause the
system not to work at all should be included in my opinion.
I would not include issues that cause bad performance, fix testcases or
code-style. I would rather prefer to aim for a 0.8 release soon (maybe a
Christmas or new year release ;) )

These are my candidates:

[FLINK-1154] Quickfix to kill TaskManagers in YARN mode.
 e46d14b4c7507b23f2c80e0d893cfff6f6c49bae
[runtime] CaseClassSerializer correctly treated as stateful
f66892d46d80d453a55fd0ae14095ee06275a55d
[runtime] Quick fix for error with unsupported ship strategy
87497b7235088b2220aa356a14cbff9d43d5dffb
[FLINK-1265] Fix user classloader bug for registerInputOutput() method
4a74f3281bd04ed76b911d2038ea8e3d9c0b7963
[FLINK-1252] Add support for serializing Date and Enums in the Java API
591f16dd8f80cc2a5b2fdc6654c3c2d625119faa
[FLINK-1251] Enums are now handled properly by the collection input format
8081ddc530e6c7b720da09ac0fca2095d70fdd36
[FLINK-1254] [compiler] Fix compiler bug for pipeline breaker placement
ce822bf7f5ec80df5d5a749b1439320af3fb8b18
[streaming] StreamExecutionEnvironment rework + user class loader fix for
cluster deployment 6867f9b93ec1ad9a627450c4fbd0b5ff98ef6148
[FLINK-1235] Compiler accepts iterations referenced from the static path of
other iterations 21b1b975ccb50e1831172894bde96c6d3269dc57



On Tue, Nov 25, 2014 at 3:32 PM, Kostas Tzoumas <kt...@apache.org> wrote:

> +1, thanks Marton!
>
> On Mon, Nov 24, 2014 at 11:51 PM, Till Rohrmann <tr...@apache.org>
> wrote:
>
> > +1 for Marton and the maintenance release.
> >
> > On Mon, Nov 24, 2014 at 6:52 PM, Henry Saputra <he...@gmail.com>
> > wrote:
> > > +1
> > >
> > > Would be good to have different RM to give feedback how existing
> > > process working.
> > >
> > > Thanks for volunteering.
> > >
> > > - Henry
> > >
> > > On Mon, Nov 24, 2014 at 1:51 AM, Márton Balassi
> > > <ba...@gmail.com> wrote:
> > >> +1 There are a couple of streaming bugfix commits that I'd like to
> push
> > >> there.
> > >>
> > >> I would also like to volunteer as release manager.
> > >>
> > >> Best,
> > >>
> > >> Marton
> > >>
> > >> On Mon, Nov 24, 2014 at 10:39 AM, Ufuk Celebi <uc...@apache.org> wrote:
> > >>
> > >>> Hey all,
> > >>>
> > >>> I would like to discuss your view on having a 0.7.1 maintenance
> > release.
> > >>>
> > >>> Although there are no commits in the respective branches (except
> > >>> documentation updates), I think we already have a set of
> issues/fixes,
> > >>> which would be beneficial to have in a release.
> > >>>
> > >>> I vote to start collecting/cherry-picking issues to the respective
> > branch.
> > >>>
> > >>> – Ufuk
> > >>>
> >
>

Re: 0.7.1 maintenance release

[Márton Balassi <ba...@gmail.com>]

+1 for sticking to the absolute minimum number of bugfix commits
+1 for pushing out 0.8.0 soon

As for streaming including only the one commit you mentioned [1] seems
sufficient.

[1] [streaming] StreamExecutionEnvironment rework + user class loader fix
for
cluster deployment 6867f9b93ec1ad9a627450c4fbd0b5ff98ef6148

On Mon, Dec 1, 2014 at 12:15 PM, Robert Metzger <rm...@apache.org> wrote:

> I looked through the commits since the last release and there is a huge
> amount of improvements we could include.
> I was thinking about limiting the commits for the bugfix release to a
> absolute minimum. Only those issues users complained about or cause the
> system not to work at all should be included in my opinion.
> I would not include issues that cause bad performance, fix testcases or
> code-style. I would rather prefer to aim for a 0.8 release soon (maybe a
> Christmas or new year release ;) )
>
> These are my candidates:
>
> [FLINK-1154] Quickfix to kill TaskManagers in YARN mode.
>  e46d14b4c7507b23f2c80e0d893cfff6f6c49bae
> [runtime] CaseClassSerializer correctly treated as stateful
> f66892d46d80d453a55fd0ae14095ee06275a55d
> [runtime] Quick fix for error with unsupported ship strategy
> 87497b7235088b2220aa356a14cbff9d43d5dffb
> [FLINK-1265] Fix user classloader bug for registerInputOutput() method
> 4a74f3281bd04ed76b911d2038ea8e3d9c0b7963
> [FLINK-1252] Add support for serializing Date and Enums in the Java API
> 591f16dd8f80cc2a5b2fdc6654c3c2d625119faa
> [FLINK-1251] Enums are now handled properly by the collection input format
> 8081ddc530e6c7b720da09ac0fca2095d70fdd36
> [FLINK-1254] [compiler] Fix compiler bug for pipeline breaker placement
> ce822bf7f5ec80df5d5a749b1439320af3fb8b18
> [streaming] StreamExecutionEnvironment rework + user class loader fix for
> cluster deployment 6867f9b93ec1ad9a627450c4fbd0b5ff98ef6148
> [FLINK-1235] Compiler accepts iterations referenced from the static path of
> other iterations 21b1b975ccb50e1831172894bde96c6d3269dc57
>
>
>
> On Tue, Nov 25, 2014 at 3:32 PM, Kostas Tzoumas <kt...@apache.org>
> wrote:
>
> > +1, thanks Marton!
> >
> > On Mon, Nov 24, 2014 at 11:51 PM, Till Rohrmann <tr...@apache.org>
> > wrote:
> >
> > > +1 for Marton and the maintenance release.
> > >
> > > On Mon, Nov 24, 2014 at 6:52 PM, Henry Saputra <
> henry.saputra@gmail.com>
> > > wrote:
> > > > +1
> > > >
> > > > Would be good to have different RM to give feedback how existing
> > > > process working.
> > > >
> > > > Thanks for volunteering.
> > > >
> > > > - Henry
> > > >
> > > > On Mon, Nov 24, 2014 at 1:51 AM, Márton Balassi
> > > > <ba...@gmail.com> wrote:
> > > >> +1 There are a couple of streaming bugfix commits that I'd like to
> > push
> > > >> there.
> > > >>
> > > >> I would also like to volunteer as release manager.
> > > >>
> > > >> Best,
> > > >>
> > > >> Marton
> > > >>
> > > >> On Mon, Nov 24, 2014 at 10:39 AM, Ufuk Celebi <uc...@apache.org>
> wrote:
> > > >>
> > > >>> Hey all,
> > > >>>
> > > >>> I would like to discuss your view on having a 0.7.1 maintenance
> > > release.
> > > >>>
> > > >>> Although there are no commits in the respective branches (except
> > > >>> documentation updates), I think we already have a set of
> > issues/fixes,
> > > >>> which would be beneficial to have in a release.
> > > >>>
> > > >>> I vote to start collecting/cherry-picking issues to the respective
> > > branch.
> > > >>>
> > > >>> – Ufuk
> > > >>>
> > >
> >
>

Re: 0.7.1 maintenance release

[Márton Balassi <ba...@gmail.com>]

It is a bit unclear for me how to proceed with this issue. If I understand
it correctly the votes were more for a smaller bugfix release than for
adding most of the code since 0.7.0, but correct me if I'm wrong.

Robert and Till assembled the following list fot commits to be included
then:

[FLINK-1154] Quickfix to kill TaskManagers in YARN mode.
 e46d14b4c7507b23f2c80e0d893cfff6f6c49bae
[runtime] CaseClassSerializer correctly treated as stateful
f66892d46d80d453a55fd0ae14095ee06275a55d
[runtime] Quick fix for error with unsupported ship strategy
87497b7235088b2220aa356a14cbff9d43d5dffb
[FLINK-1265] Fix user classloader bug for registerInputOutput() method
4a74f3281bd04ed76b911d2038ea8e3d9c0b7963
[FLINK-1252] Add support for serializing Date and Enums in the Java API
591f16dd8f80cc2a5b2fdc6654c3c2d625119faa
[FLINK-1251] Enums are now handled properly by the collection input format
8081ddc530e6c7b720da09ac0fca2095d70fdd36
[FLINK-1254] [compiler] Fix compiler bug for pipeline breaker placement
ce822bf7f5ec80df5d5a749b1439320af3fb8b18
[streaming] StreamExecutionEnvironment rework + user class loader fix for
cluster deployment 6867f9b93ec1ad9a627450c4fbd0b5ff98ef6148
[FLINK-1235] Compiler accepts iterations referenced from the static path of
other iterations 21b1b975ccb50e1831172894bde96c6d3269dc57
Removed TypeSerializerFactory from ScalaCsvInputFormat. The TypeSerializer
is now serialized directly. 3d242fd7aea6add18465d628a258be11def2d0af

And of course the doc fixes that are alredy on the release-0.7 branch. I'd
like to push these to the release-0.7 branch and fork release-0.7.1 from it
then.

Cheers,

Marton


On Mon, Dec 1, 2014 at 5:35 PM, Fabian Hueske <fh...@apache.org> wrote:

> I agree with Ufuk.
>
> +1 for putting this out as a minor release (0.7.1).
>
> 2014-12-01 17:27 GMT+01:00 Ufuk Celebi <uc...@apache.org>:
>
> > On Mon, Dec 1, 2014 at 4:45 PM, Robert Metzger <rm...@apache.org>
> > wrote:
> >
> > > If the bugfix release is going to include almost all commits of the
> > current
> > > 0.8-SNAPSHOT version, we should consider releasing it as Flink 0.8.0.
> > >
> >
> > I think it is reasonable to have new major versions for new major
> features.
> > Since we don't have any new major features, we should stick to 0.7.1.
> >
> >
> > The amount of required work for making a bugfix or a major release is
> > > basically the same.
> > >
> >
> > I would actually say that a bugfix release requires more work. ;-)
> >
>

Re: 0.7.1 maintenance release

[Fabian Hueske <fh...@apache.org>]

I agree with Ufuk.

+1 for putting this out as a minor release (0.7.1).

2014-12-01 17:27 GMT+01:00 Ufuk Celebi <uc...@apache.org>:

> On Mon, Dec 1, 2014 at 4:45 PM, Robert Metzger <rm...@apache.org>
> wrote:
>
> > If the bugfix release is going to include almost all commits of the
> current
> > 0.8-SNAPSHOT version, we should consider releasing it as Flink 0.8.0.
> >
>
> I think it is reasonable to have new major versions for new major features.
> Since we don't have any new major features, we should stick to 0.7.1.
>
>
> The amount of required work for making a bugfix or a major release is
> > basically the same.
> >
>
> I would actually say that a bugfix release requires more work. ;-)
>

Re: 0.7.1 maintenance release

[Ufuk Celebi <uc...@apache.org>]

On Mon, Dec 1, 2014 at 4:45 PM, Robert Metzger <rm...@apache.org> wrote:

> If the bugfix release is going to include almost all commits of the current
> 0.8-SNAPSHOT version, we should consider releasing it as Flink 0.8.0.
>

I think it is reasonable to have new major versions for new major features.
Since we don't have any new major features, we should stick to 0.7.1.


The amount of required work for making a bugfix or a major release is
> basically the same.
>

I would actually say that a bugfix release requires more work. ;-)

Re: 0.7.1 maintenance release

[Robert Metzger <rm...@apache.org>]

If the bugfix release is going to include almost all commits of the current
0.8-SNAPSHOT version, we should consider releasing it as Flink 0.8.0.

The amount of required work for making a bugfix or a major release is
basically the same.

On Mon, Dec 1, 2014 at 3:57 PM, Stephan Ewen <se...@apache.org> wrote:

> Would it be simpler to list what we not include? I think most of the stuff
> added since then is fixes, not fundamental features. I would include almost
> all of it, also the closure cleaner, the type fixes, ...
>
> On Mon, Dec 1, 2014 at 1:59 PM, Till Rohrmann <ti...@gmail.com>
> wrote:
>
> > If we include the commit
> >
> > [runtime] CaseClassSerializer correctly treated as stateful
> > f66892d46d80d453a55fd0ae14095ee06275a55d
> >
> > then we also have to include
> >
> > 3d242fd7aea6add18465d628a258be11def2d0af
> >
> > because the ScalaCsvInputFormat using the CaseClassSerializer won't work
> > properly anymore with the CaseClassSerializer set to be stateful.
> >
> >
> > On Mon, Dec 1, 2014 at 12:50 PM, Ufuk Celebi <uc...@apache.org> wrote:
> >
> > > On Mon, Dec 1, 2014 at 12:15 PM, Robert Metzger <rm...@apache.org>
> > > wrote:
> > >
> > > > I would not include issues that cause bad performance, fix testcases
> or
> > > > code-style. I would rather prefer to aim for a 0.8 release soon
> (maybe
> > a
> > > > Christmas or new year release ;) )
> > > >
> > >
> > >
> > > Is there a performance-critical commit, which would be *more* work to
> > back
> > > port than the other commits? If not, I don't see any reason to exclude
> > > them.
> > >
> >
>

Re: 0.7.1 maintenance release

[Stephan Ewen <se...@apache.org>]

Would it be simpler to list what we not include? I think most of the stuff
added since then is fixes, not fundamental features. I would include almost
all of it, also the closure cleaner, the type fixes, ...

On Mon, Dec 1, 2014 at 1:59 PM, Till Rohrmann <ti...@gmail.com>
wrote:

> If we include the commit
>
> [runtime] CaseClassSerializer correctly treated as stateful
> f66892d46d80d453a55fd0ae14095ee06275a55d
>
> then we also have to include
>
> 3d242fd7aea6add18465d628a258be11def2d0af
>
> because the ScalaCsvInputFormat using the CaseClassSerializer won't work
> properly anymore with the CaseClassSerializer set to be stateful.
>
>
> On Mon, Dec 1, 2014 at 12:50 PM, Ufuk Celebi <uc...@apache.org> wrote:
>
> > On Mon, Dec 1, 2014 at 12:15 PM, Robert Metzger <rm...@apache.org>
> > wrote:
> >
> > > I would not include issues that cause bad performance, fix testcases or
> > > code-style. I would rather prefer to aim for a 0.8 release soon (maybe
> a
> > > Christmas or new year release ;) )
> > >
> >
> >
> > Is there a performance-critical commit, which would be *more* work to
> back
> > port than the other commits? If not, I don't see any reason to exclude
> > them.
> >
>

Re: 0.7.1 maintenance release

[Till Rohrmann <ti...@gmail.com>]

If we include the commit

[runtime] CaseClassSerializer correctly treated as stateful
f66892d46d80d453a55fd0ae14095ee06275a55d

then we also have to include

3d242fd7aea6add18465d628a258be11def2d0af

because the ScalaCsvInputFormat using the CaseClassSerializer won't work
properly anymore with the CaseClassSerializer set to be stateful.


On Mon, Dec 1, 2014 at 12:50 PM, Ufuk Celebi <uc...@apache.org> wrote:

> On Mon, Dec 1, 2014 at 12:15 PM, Robert Metzger <rm...@apache.org>
> wrote:
>
> > I would not include issues that cause bad performance, fix testcases or
> > code-style. I would rather prefer to aim for a 0.8 release soon (maybe a
> > Christmas or new year release ;) )
> >
>
>
> Is there a performance-critical commit, which would be *more* work to back
> port than the other commits? If not, I don't see any reason to exclude
> them.
>

Re: 0.7.1 maintenance release

[Ufuk Celebi <uc...@apache.org>]

On Mon, Dec 1, 2014 at 12:15 PM, Robert Metzger <rm...@apache.org> wrote:

> I would not include issues that cause bad performance, fix testcases or
> code-style. I would rather prefer to aim for a 0.8 release soon (maybe a
> Christmas or new year release ;) )
>


Is there a performance-critical commit, which would be *more* work to back
port than the other commits? If not, I don't see any reason to exclude them.