Planning Flink release 0.7-incubating

[Robert Metzger]

Hi,

since we have our release infrastructure in place now, I would suggest to
aim for a 0.7-incubating release in the near future (say 3-5 weeks).
While 0.6-incubating was mainly about getting the release infra / legal
stuff sorted out, I think it would be nice to have a "feature" release soon.

The following new features would make a great 0.7-incubating release:
 - *Flink Streaming* "Beta Preview". I would suggest to ship the streaming,
but clearly mark it as a preview in the documentation.
 -* Java API Pojo improvements*: Code generation, key selection using a
string-expression: https://issues.apache.org/jira/browse/FLINK-1032
  - *Reworked Scala API*. Bring the Scala API in sync with the latest
developments in the Java API:
https://issues.apache.org/jira/browse/FLINK-641
  -* Akka-based RPC service*:
https://issues.apache.org/jira/browse/FLINK-1019
  - *Kryo-based serialization*. This feature has been requested by many
users. Mostly because they wanted to use Collections inside POJOs:
https://issues.apache.org/jira/browse/FLINK-610


Opinions?

[Stephan Ewen]

This is a nice list.

I would like to add:

 - Rework JobManager internals to support incremental program rollout &
execution
 - First parts of dynamic memory assignments





On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <[hidden email]> wrote:

> Hi,
>
> since we have our release infrastructure in place now, I would suggest to
> aim for a 0.7-incubating release in the near future (say 3-5 weeks).
> While 0.6-incubating was mainly about getting the release infra / legal
> stuff sorted out, I think it would be nice to have a "feature" release
> soon.
>
> The following new features would make a great 0.7-incubating release:
>  - *Flink Streaming* "Beta Preview". I would suggest to ship the streaming,
> but clearly mark it as a preview in the documentation.
>  -* Java API Pojo improvements*: Code generation, key selection using a
> string-expression: https://issues.apache.org/jira/browse/FLINK-1032
>   - *Reworked Scala API*. Bring the Scala API in sync with the latest
> developments in the Java API:
> https://issues.apache.org/jira/browse/FLINK-641
>   -* Akka-based RPC service*:
> https://issues.apache.org/jira/browse/FLINK-1019
>   - *Kryo-based serialization*. This feature has been requested by many
> users. Mostly because they wanted to use Collections inside POJOs:
> https://issues.apache.org/jira/browse/FLINK-610
>
>
> Opinions?
>

[Fabian Hueske]

I agree that these should be features to add soon, but I'm a bit doubtful
that we will have the next release in 5 weeks if we want to include all of
this.

I think we should either have a feature- or time-oriented release plan.
If we want to have a fixed release date, we could make a feature stop 1
week (or so) in advance, include what's in until then and continue to
release every n weeks.
Or we make a list of what should be in the next release and try to give a
reasonable time estimate for that (which didn't work out so well in the
past.... ;-) )

But having both, a close deadline and a long list of complex features will
not work out well, IMO.

Just my 2 cents, Fabian


2014-08-27 19:49 GMT+02:00 Stephan Ewen <[hidden email]>:

> This is a nice list.
>
> I would like to add:
>
>  - Rework JobManager internals to support incremental program rollout &
> execution
>  - First parts of dynamic memory assignments
>
>
>
>
>
> On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <[hidden email]>
> wrote:
>
> > Hi,
> >
> > since we have our release infrastructure in place now, I would suggest to
> > aim for a 0.7-incubating release in the near future (say 3-5 weeks).
> > While 0.6-incubating was mainly about getting the release infra / legal
> > stuff sorted out, I think it would be nice to have a "feature" release
> > soon.
> >
> > The following new features would make a great 0.7-incubating release:
> >  - *Flink Streaming* "Beta Preview". I would suggest to ship the
> streaming,
> > but clearly mark it as a preview in the documentation.
> >  -* Java API Pojo improvements*: Code generation, key selection using a
> > string-expression: https://issues.apache.org/jira/browse/FLINK-1032
> >   - *Reworked Scala API*. Bring the Scala API in sync with the latest
> > developments in the Java API:
> > https://issues.apache.org/jira/browse/FLINK-641
> >   -* Akka-based RPC service*:
> > https://issues.apache.org/jira/browse/FLINK-1019
> >   - *Kryo-based serialization*. This feature has been requested by many
> > users. Mostly because they wanted to use Collections inside POJOs:
> > https://issues.apache.org/jira/browse/FLINK-610
> >
> >
> > Opinions?
> >
>

[Robert Metzger]

Hi,
I agree with Fabian that the list of features is a lot of work. I would
prefer to have frequent regular major releases (say 3 months schedule).
This way, users can quickly access the latest features and we don't force
them to use SNAPSHOT versions.
Also, releases draw attention to our project.

I would suggest to do a feature freeze on September 24 (3 weeks from now)
and start the vote a few days afterwards. I assume that at least some of
the suggested 7 features of the release are ready.

Robert


On Wed, Aug 27, 2014 at 9:20 PM, Fabian Hueske <[hidden email]> wrote:

> I agree that these should be features to add soon, but I'm a bit doubtful
> that we will have the next release in 5 weeks if we want to include all of
> this.
>
> I think we should either have a feature- or time-oriented release plan.
> If we want to have a fixed release date, we could make a feature stop 1
> week (or so) in advance, include what's in until then and continue to
> release every n weeks.
> Or we make a list of what should be in the next release and try to give a
> reasonable time estimate for that (which didn't work out so well in the
> past.... ;-) )
>
> But having both, a close deadline and a long list of complex features will
> not work out well, IMO.
>
> Just my 2 cents, Fabian
>
>
> 2014-08-27 19:49 GMT+02:00 Stephan Ewen <[hidden email]>:
>
> > This is a nice list.
> >
> > I would like to add:
> >
> >  - Rework JobManager internals to support incremental program rollout &
> > execution
> >  - First parts of dynamic memory assignments
> >
> >
> >
> >
> >
> > On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <[hidden email]>
> > wrote:
> >
> > > Hi,
> > >
> > > since we have our release infrastructure in place now, I would suggest
> to
> > > aim for a 0.7-incubating release in the near future (say 3-5 weeks).
> > > While 0.6-incubating was mainly about getting the release infra / legal
> > > stuff sorted out, I think it would be nice to have a "feature" release
> > > soon.
> > >
> > > The following new features would make a great 0.7-incubating release:
> > >  - *Flink Streaming* "Beta Preview". I would suggest to ship the
> > streaming,
> > > but clearly mark it as a preview in the documentation.
> > >  -* Java API Pojo improvements*: Code generation, key selection using a
> > > string-expression: https://issues.apache.org/jira/browse/FLINK-1032
> > >   - *Reworked Scala API*. Bring the Scala API in sync with the latest
> > > developments in the Java API:
> > > https://issues.apache.org/jira/browse/FLINK-641
> > >   -* Akka-based RPC service*:
> > > https://issues.apache.org/jira/browse/FLINK-1019
> > >   - *Kryo-based serialization*. This feature has been requested by many
> > > users. Mostly because they wanted to use Collections inside POJOs:
> > > https://issues.apache.org/jira/browse/FLINK-610
> > >
> > >
> > > Opinions?
> > >
> >
>

[Ufuk Celebi-2]

Hey Robert,

+1 to frequent regular frequent major releases (I guess you meant 3 weeks
and not 3 months, right?).

Ufuk


On Tue, Sep 2, 2014 at 9:29 PM, Robert Metzger <[hidden email]> wrote:

> Hi,
> I agree with Fabian that the list of features is a lot of work. I would
> prefer to have frequent regular major releases (say 3 months schedule).
> This way, users can quickly access the latest features and we don't force
> them to use SNAPSHOT versions.
> Also, releases draw attention to our project.
>
> I would suggest to do a feature freeze on September 24 (3 weeks from now)
> and start the vote a few days afterwards. I assume that at least some of
> the suggested 7 features of the release are ready.
>
> Robert
>
>
> On Wed, Aug 27, 2014 at 9:20 PM, Fabian Hueske <[hidden email]> wrote:
>
> > I agree that these should be features to add soon, but I'm a bit doubtful
> > that we will have the next release in 5 weeks if we want to include all
> of
> > this.
> >
> > I think we should either have a feature- or time-oriented release plan.
> > If we want to have a fixed release date, we could make a feature stop 1
> > week (or so) in advance, include what's in until then and continue to
> > release every n weeks.
> > Or we make a list of what should be in the next release and try to give a
> > reasonable time estimate for that (which didn't work out so well in the
> > past.... ;-) )
> >
> > But having both, a close deadline and a long list of complex features
> will
> > not work out well, IMO.
> >
> > Just my 2 cents, Fabian
> >
> >
> > 2014-08-27 19:49 GMT+02:00 Stephan Ewen <[hidden email]>:
> >
> > > This is a nice list.
> > >
> > > I would like to add:
> > >
> > >  - Rework JobManager internals to support incremental program rollout &
> > > execution
> > >  - First parts of dynamic memory assignments
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <[hidden email]>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > since we have our release infrastructure in place now, I would
> suggest
> > to
> > > > aim for a 0.7-incubating release in the near future (say 3-5 weeks).
> > > > While 0.6-incubating was mainly about getting the release infra /
> legal
> > > > stuff sorted out, I think it would be nice to have a "feature"
> release
> > > > soon.
> > > >
> > > > The following new features would make a great 0.7-incubating release:
> > > >  - *Flink Streaming* "Beta Preview". I would suggest to ship the
> > > streaming,
> > > > but clearly mark it as a preview in the documentation.
> > > >  -* Java API Pojo improvements*: Code generation, key selection
> using a
> > > > string-expression: https://issues.apache.org/jira/browse/FLINK-1032
> > > >   - *Reworked Scala API*. Bring the Scala API in sync with the latest
> > > > developments in the Java API:
> > > > https://issues.apache.org/jira/browse/FLINK-641
> > > >   -* Akka-based RPC service*:
> > > > https://issues.apache.org/jira/browse/FLINK-1019
> > > >   - *Kryo-based serialization*. This feature has been requested by
> many
> > > > users. Mostly because they wanted to use Collections inside POJOs:
> > > > https://issues.apache.org/jira/browse/FLINK-610
> > > >
> > > >
> > > > Opinions?
> > > >
> > >
> >
>

[Robert Metzger]

Hi,

sorry, my previous message was confusing. I suggest to release a new Flink
version all 3 months.
BUT, the 0.7-incubating release is going to be feature freeze in 3 weeks
because 0.6-incubating was more about getting the release infra set up and
the apache rename out.
The last release that contained a lot of features was 0.5 and it was
released on May 29. So aiming for end of September for the next feature
release should be somehow in the schedule.


Robert


On Wed, Sep 3, 2014 at 11:47 AM, Ufuk Celebi <[hidden email]> wrote:

> Hey Robert,
>
> +1 to frequent regular frequent major releases (I guess you meant 3 weeks
> and not 3 months, right?).
>
> Ufuk
>
>
> On Tue, Sep 2, 2014 at 9:29 PM, Robert Metzger <[hidden email]>
> wrote:
>
> > Hi,
> > I agree with Fabian that the list of features is a lot of work. I would
> > prefer to have frequent regular major releases (say 3 months schedule).
> > This way, users can quickly access the latest features and we don't force
> > them to use SNAPSHOT versions.
> > Also, releases draw attention to our project.
> >
> > I would suggest to do a feature freeze on September 24 (3 weeks from now)
> > and start the vote a few days afterwards. I assume that at least some of
> > the suggested 7 features of the release are ready.
> >
> > Robert
> >
> >
> > On Wed, Aug 27, 2014 at 9:20 PM, Fabian Hueske <[hidden email]>
> wrote:
> >
> > > I agree that these should be features to add soon, but I'm a bit
> doubtful
> > > that we will have the next release in 5 weeks if we want to include all
> > of
> > > this.
> > >
> > > I think we should either have a feature- or time-oriented release plan.
> > > If we want to have a fixed release date, we could make a feature stop 1
> > > week (or so) in advance, include what's in until then and continue to
> > > release every n weeks.
> > > Or we make a list of what should be in the next release and try to
> give a
> > > reasonable time estimate for that (which didn't work out so well in the
> > > past.... ;-) )
> > >
> > > But having both, a close deadline and a long list of complex features
> > will
> > > not work out well, IMO.
> > >
> > > Just my 2 cents, Fabian
> > >
> > >
> > > 2014-08-27 19:49 GMT+02:00 Stephan Ewen <[hidden email]>:
> > >
> > > > This is a nice list.
> > > >
> > > > I would like to add:
> > > >
> > > >  - Rework JobManager internals to support incremental program
> rollout &
> > > > execution
> > > >  - First parts of dynamic memory assignments
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <[hidden email]
> >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > since we have our release infrastructure in place now, I would
> > suggest
> > > to
> > > > > aim for a 0.7-incubating release in the near future (say 3-5
> weeks).
> > > > > While 0.6-incubating was mainly about getting the release infra /
> > legal
> > > > > stuff sorted out, I think it would be nice to have a "feature"
> > release
> > > > > soon.
> > > > >
> > > > > The following new features would make a great 0.7-incubating
> release:
> > > > >  - *Flink Streaming* "Beta Preview". I would suggest to ship the
> > > > streaming,
> > > > > but clearly mark it as a preview in the documentation.
> > > > >  -* Java API Pojo improvements*: Code generation, key selection
> > using a
> > > > > string-expression:
> https://issues.apache.org/jira/browse/FLINK-1032
> > > > >   - *Reworked Scala API*. Bring the Scala API in sync with the
> latest
> > > > > developments in the Java API:
> > > > > https://issues.apache.org/jira/browse/FLINK-641
> > > > >   -* Akka-based RPC service*:
> > > > > https://issues.apache.org/jira/browse/FLINK-1019
> > > > >   - *Kryo-based serialization*. This feature has been requested by
> > many
> > > > > users. Mostly because they wanted to use Collections inside POJOs:
> > > > > https://issues.apache.org/jira/browse/FLINK-610
> > > > >
> > > > >
> > > > > Opinions?
> > > > >
> > > >
> > >
> >
>

[Till Rohrmann]

+1 Sounds good to me.


On Wed, Sep 3, 2014 at 1:58 PM, Robert Metzger <[hidden email]> wrote:

> Hi,
>
> sorry, my previous message was confusing. I suggest to release a new Flink
> version all 3 months.
> BUT, the 0.7-incubating release is going to be feature freeze in 3 weeks
> because 0.6-incubating was more about getting the release infra set up and
> the apache rename out.
> The last release that contained a lot of features was 0.5 and it was
> released on May 29. So aiming for end of September for the next feature
> release should be somehow in the schedule.
>
>
> Robert
>
>
> On Wed, Sep 3, 2014 at 11:47 AM, Ufuk Celebi <[hidden email]> wrote:
>
> > Hey Robert,
> >
> > +1 to frequent regular frequent major releases (I guess you meant 3 weeks
> > and not 3 months, right?).
> >
> > Ufuk
> >
> >
> > On Tue, Sep 2, 2014 at 9:29 PM, Robert Metzger <[hidden email]>
> > wrote:
> >
> > > Hi,
> > > I agree with Fabian that the list of features is a lot of work. I would
> > > prefer to have frequent regular major releases (say 3 months schedule).
> > > This way, users can quickly access the latest features and we don't
> force
> > > them to use SNAPSHOT versions.
> > > Also, releases draw attention to our project.
> > >
> > > I would suggest to do a feature freeze on September 24 (3 weeks from
> now)
> > > and start the vote a few days afterwards. I assume that at least some
> of
> > > the suggested 7 features of the release are ready.
> > >
> > > Robert
> > >
> > >
> > > On Wed, Aug 27, 2014 at 9:20 PM, Fabian Hueske <[hidden email]>
> > wrote:
> > >
> > > > I agree that these should be features to add soon, but I'm a bit
> > doubtful
> > > > that we will have the next release in 5 weeks if we want to include
> all
> > > of
> > > > this.
> > > >
> > > > I think we should either have a feature- or time-oriented release
> plan.
> > > > If we want to have a fixed release date, we could make a feature
> stop 1
> > > > week (or so) in advance, include what's in until then and continue to
> > > > release every n weeks.
> > > > Or we make a list of what should be in the next release and try to
> > give a
> > > > reasonable time estimate for that (which didn't work out so well in
> the
> > > > past.... ;-) )
> > > >
> > > > But having both, a close deadline and a long list of complex features
> > > will
> > > > not work out well, IMO.
> > > >
> > > > Just my 2 cents, Fabian
> > > >
> > > >
> > > > 2014-08-27 19:49 GMT+02:00 Stephan Ewen <[hidden email]>:
> > > >
> > > > > This is a nice list.
> > > > >
> > > > > I would like to add:
> > > > >
> > > > >  - Rework JobManager internals to support incremental program
> > rollout &
> > > > > execution
> > > > >  - First parts of dynamic memory assignments
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <
> [hidden email]
> > >
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > since we have our release infrastructure in place now, I would
> > > suggest
> > > > to
> > > > > > aim for a 0.7-incubating release in the near future (say 3-5
> > weeks).
> > > > > > While 0.6-incubating was mainly about getting the release infra /
> > > legal
> > > > > > stuff sorted out, I think it would be nice to have a "feature"
> > > release
> > > > > > soon.
> > > > > >
> > > > > > The following new features would make a great 0.7-incubating
> > release:
> > > > > >  - *Flink Streaming* "Beta Preview". I would suggest to ship the
> > > > > streaming,
> > > > > > but clearly mark it as a preview in the documentation.
> > > > > >  -* Java API Pojo improvements*: Code generation, key selection
> > > using a
> > > > > > string-expression:
> > https://issues.apache.org/jira/browse/FLINK-1032
> > > > > >   - *Reworked Scala API*. Bring the Scala API in sync with the
> > latest
> > > > > > developments in the Java API:
> > > > > > https://issues.apache.org/jira/browse/FLINK-641
> > > > > >   -* Akka-based RPC service*:
> > > > > > https://issues.apache.org/jira/browse/FLINK-1019
> > > > > >   - *Kryo-based serialization*. This feature has been requested
> by
> > > many
> > > > > > users. Mostly because they wanted to use Collections inside
> POJOs:
> > > > > > https://issues.apache.org/jira/browse/FLINK-610
> > > > > >
> > > > > >
> > > > > > Opinions?
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Márton Balassi]

+1


On Wed, Sep 3, 2014 at 9:54 PM, Till Rohrmann <[hidden email]> wrote:

> +1 Sounds good to me.
>
>
> On Wed, Sep 3, 2014 at 1:58 PM, Robert Metzger <[hidden email]>
> wrote:
>
> > Hi,
> >
> > sorry, my previous message was confusing. I suggest to release a new
> Flink
> > version all 3 months.
> > BUT, the 0.7-incubating release is going to be feature freeze in 3 weeks
> > because 0.6-incubating was more about getting the release infra set up
> and
> > the apache rename out.
> > The last release that contained a lot of features was 0.5 and it was
> > released on May 29. So aiming for end of September for the next feature
> > release should be somehow in the schedule.
> >
> >
> > Robert
> >
> >
> > On Wed, Sep 3, 2014 at 11:47 AM, Ufuk Celebi <[hidden email]> wrote:
> >
> > > Hey Robert,
> > >
> > > +1 to frequent regular frequent major releases (I guess you meant 3
> weeks
> > > and not 3 months, right?).
> > >
> > > Ufuk
> > >
> > >
> > > On Tue, Sep 2, 2014 at 9:29 PM, Robert Metzger <[hidden email]>
> > > wrote:
> > >
> > > > Hi,
> > > > I agree with Fabian that the list of features is a lot of work. I
> would
> > > > prefer to have frequent regular major releases (say 3 months
> schedule).
> > > > This way, users can quickly access the latest features and we don't
> > force
> > > > them to use SNAPSHOT versions.
> > > > Also, releases draw attention to our project.
> > > >
> > > > I would suggest to do a feature freeze on September 24 (3 weeks from
> > now)
> > > > and start the vote a few days afterwards. I assume that at least some
> > of
> > > > the suggested 7 features of the release are ready.
> > > >
> > > > Robert
> > > >
> > > >
> > > > On Wed, Aug 27, 2014 at 9:20 PM, Fabian Hueske <[hidden email]>
> > > wrote:
> > > >
> > > > > I agree that these should be features to add soon, but I'm a bit
> > > doubtful
> > > > > that we will have the next release in 5 weeks if we want to include
> > all
> > > > of
> > > > > this.
> > > > >
> > > > > I think we should either have a feature- or time-oriented release
> > plan.
> > > > > If we want to have a fixed release date, we could make a feature
> > stop 1
> > > > > week (or so) in advance, include what's in until then and continue
> to
> > > > > release every n weeks.
> > > > > Or we make a list of what should be in the next release and try to
> > > give a
> > > > > reasonable time estimate for that (which didn't work out so well in
> > the
> > > > > past.... ;-) )
> > > > >
> > > > > But having both, a close deadline and a long list of complex
> features
> > > > will
> > > > > not work out well, IMO.
> > > > >
> > > > > Just my 2 cents, Fabian
> > > > >
> > > > >
> > > > > 2014-08-27 19:49 GMT+02:00 Stephan Ewen <[hidden email]>:
> > > > >
> > > > > > This is a nice list.
> > > > > >
> > > > > > I would like to add:
> > > > > >
> > > > > >  - Rework JobManager internals to support incremental program
> > > rollout &
> > > > > > execution
> > > > > >  - First parts of dynamic memory assignments
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <
> > [hidden email]
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > since we have our release infrastructure in place now, I would
> > > > suggest
> > > > > to
> > > > > > > aim for a 0.7-incubating release in the near future (say 3-5
> > > weeks).
> > > > > > > While 0.6-incubating was mainly about getting the release
> infra /
> > > > legal
> > > > > > > stuff sorted out, I think it would be nice to have a "feature"
> > > > release
> > > > > > > soon.
> > > > > > >
> > > > > > > The following new features would make a great 0.7-incubating
> > > release:
> > > > > > >  - *Flink Streaming* "Beta Preview". I would suggest to ship
> the
> > > > > > streaming,
> > > > > > > but clearly mark it as a preview in the documentation.
> > > > > > >  -* Java API Pojo improvements*: Code generation, key selection
> > > > using a
> > > > > > > string-expression:
> > > https://issues.apache.org/jira/browse/FLINK-1032
> > > > > > >   - *Reworked Scala API*. Bring the Scala API in sync with the
> > > latest
> > > > > > > developments in the Java API:
> > > > > > > https://issues.apache.org/jira/browse/FLINK-641
> > > > > > >   -* Akka-based RPC service*:
> > > > > > > https://issues.apache.org/jira/browse/FLINK-1019
> > > > > > >   - *Kryo-based serialization*. This feature has been requested
> > by
> > > > many
> > > > > > > users. Mostly because they wanted to use Collections inside
> > POJOs:
> > > > > > > https://issues.apache.org/jira/browse/FLINK-610
> > > > > > >
> > > > > > >
> > > > > > > Opinions?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Kostas Tzoumas-2]

+1


On Wed, Sep 3, 2014 at 10:12 PM, Márton Balassi <[hidden email]>
wrote:

> +1
>
>
> On Wed, Sep 3, 2014 at 9:54 PM, Till Rohrmann <[hidden email]>
> wrote:
>
> > +1 Sounds good to me.
> >
> >
> > On Wed, Sep 3, 2014 at 1:58 PM, Robert Metzger <[hidden email]>
> > wrote:
> >
> > > Hi,
> > >
> > > sorry, my previous message was confusing. I suggest to release a new
> > Flink
> > > version all 3 months.
> > > BUT, the 0.7-incubating release is going to be feature freeze in 3
> weeks
> > > because 0.6-incubating was more about getting the release infra set up
> > and
> > > the apache rename out.
> > > The last release that contained a lot of features was 0.5 and it was
> > > released on May 29. So aiming for end of September for the next feature
> > > release should be somehow in the schedule.
> > >
> > >
> > > Robert
> > >
> > >
> > > On Wed, Sep 3, 2014 at 11:47 AM, Ufuk Celebi <[hidden email]> wrote:
> > >
> > > > Hey Robert,
> > > >
> > > > +1 to frequent regular frequent major releases (I guess you meant 3
> > weeks
> > > > and not 3 months, right?).
> > > >
> > > > Ufuk
> > > >
> > > >
> > > > On Tue, Sep 2, 2014 at 9:29 PM, Robert Metzger <[hidden email]>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > > I agree with Fabian that the list of features is a lot of work. I
> > would
> > > > > prefer to have frequent regular major releases (say 3 months
> > schedule).
> > > > > This way, users can quickly access the latest features and we don't
> > > force
> > > > > them to use SNAPSHOT versions.
> > > > > Also, releases draw attention to our project.
> > > > >
> > > > > I would suggest to do a feature freeze on September 24 (3 weeks
> from
> > > now)
> > > > > and start the vote a few days afterwards. I assume that at least
> some
> > > of
> > > > > the suggested 7 features of the release are ready.
> > > > >
> > > > > Robert
> > > > >
> > > > >
> > > > > On Wed, Aug 27, 2014 at 9:20 PM, Fabian Hueske <[hidden email]
> >
> > > > wrote:
> > > > >
> > > > > > I agree that these should be features to add soon, but I'm a bit
> > > > doubtful
> > > > > > that we will have the next release in 5 weeks if we want to
> include
> > > all
> > > > > of
> > > > > > this.
> > > > > >
> > > > > > I think we should either have a feature- or time-oriented release
> > > plan.
> > > > > > If we want to have a fixed release date, we could make a feature
> > > stop 1
> > > > > > week (or so) in advance, include what's in until then and
> continue
> > to
> > > > > > release every n weeks.
> > > > > > Or we make a list of what should be in the next release and try
> to
> > > > give a
> > > > > > reasonable time estimate for that (which didn't work out so well
> in
> > > the
> > > > > > past.... ;-) )
> > > > > >
> > > > > > But having both, a close deadline and a long list of complex
> > features
> > > > > will
> > > > > > not work out well, IMO.
> > > > > >
> > > > > > Just my 2 cents, Fabian
> > > > > >
> > > > > >
> > > > > > 2014-08-27 19:49 GMT+02:00 Stephan Ewen <[hidden email]>:
> > > > > >
> > > > > > > This is a nice list.
> > > > > > >
> > > > > > > I would like to add:
> > > > > > >
> > > > > > >  - Rework JobManager internals to support incremental program
> > > > rollout &
> > > > > > > execution
> > > > > > >  - First parts of dynamic memory assignments
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <
> > > [hidden email]
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > since we have our release infrastructure in place now, I
> would
> > > > > suggest
> > > > > > to
> > > > > > > > aim for a 0.7-incubating release in the near future (say 3-5
> > > > weeks).
> > > > > > > > While 0.6-incubating was mainly about getting the release
> > infra /
> > > > > legal
> > > > > > > > stuff sorted out, I think it would be nice to have a
> "feature"
> > > > > release
> > > > > > > > soon.
> > > > > > > >
> > > > > > > > The following new features would make a great 0.7-incubating
> > > > release:
> > > > > > > >  - *Flink Streaming* "Beta Preview". I would suggest to ship
> > the
> > > > > > > streaming,
> > > > > > > > but clearly mark it as a preview in the documentation.
> > > > > > > >  -* Java API Pojo improvements*: Code generation, key
> selection
> > > > > using a
> > > > > > > > string-expression:
> > > > https://issues.apache.org/jira/browse/FLINK-1032
> > > > > > > >   - *Reworked Scala API*. Bring the Scala API in sync with
> the
> > > > latest
> > > > > > > > developments in the Java API:
> > > > > > > > https://issues.apache.org/jira/browse/FLINK-641
> > > > > > > >   -* Akka-based RPC service*:
> > > > > > > > https://issues.apache.org/jira/browse/FLINK-1019
> > > > > > > >   - *Kryo-based serialization*. This feature has been
> requested
> > > by
> > > > > many
> > > > > > > > users. Mostly because they wanted to use Collections inside
> > > POJOs:
> > > > > > > > https://issues.apache.org/jira/browse/FLINK-610
> > > > > > > >
> > > > > > > >
> > > > > > > > Opinions?
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Fabian Hueske]

+1


2014-09-03 22:39 GMT+02:00 Kostas Tzoumas <[hidden email]>:

> +1
>
>
> On Wed, Sep 3, 2014 at 10:12 PM, Márton Balassi <[hidden email]>
> wrote:
>
> > +1
> >
> >
> > On Wed, Sep 3, 2014 at 9:54 PM, Till Rohrmann <[hidden email]>
> > wrote:
> >
> > > +1 Sounds good to me.
> > >
> > >
> > > On Wed, Sep 3, 2014 at 1:58 PM, Robert Metzger <[hidden email]>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > sorry, my previous message was confusing. I suggest to release a new
> > > Flink
> > > > version all 3 months.
> > > > BUT, the 0.7-incubating release is going to be feature freeze in 3
> > weeks
> > > > because 0.6-incubating was more about getting the release infra set
> up
> > > and
> > > > the apache rename out.
> > > > The last release that contained a lot of features was 0.5 and it was
> > > > released on May 29. So aiming for end of September for the next
> feature
> > > > release should be somehow in the schedule.
> > > >
> > > >
> > > > Robert
> > > >
> > > >
> > > > On Wed, Sep 3, 2014 at 11:47 AM, Ufuk Celebi <[hidden email]> wrote:
> > > >
> > > > > Hey Robert,
> > > > >
> > > > > +1 to frequent regular frequent major releases (I guess you meant 3
> > > weeks
> > > > > and not 3 months, right?).
> > > > >
> > > > > Ufuk
> > > > >
> > > > >
> > > > > On Tue, Sep 2, 2014 at 9:29 PM, Robert Metzger <
> [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > > I agree with Fabian that the list of features is a lot of work. I
> > > would
> > > > > > prefer to have frequent regular major releases (say 3 months
> > > schedule).
> > > > > > This way, users can quickly access the latest features and we
> don't
> > > > force
> > > > > > them to use SNAPSHOT versions.
> > > > > > Also, releases draw attention to our project.
> > > > > >
> > > > > > I would suggest to do a feature freeze on September 24 (3 weeks
> > from
> > > > now)
> > > > > > and start the vote a few days afterwards. I assume that at least
> > some
> > > > of
> > > > > > the suggested 7 features of the release are ready.
> > > > > >
> > > > > > Robert
> > > > > >
> > > > > >
> > > > > > On Wed, Aug 27, 2014 at 9:20 PM, Fabian Hueske <
> [hidden email]
> > >
> > > > > wrote:
> > > > > >
> > > > > > > I agree that these should be features to add soon, but I'm a
> bit
> > > > > doubtful
> > > > > > > that we will have the next release in 5 weeks if we want to
> > include
> > > > all
> > > > > > of
> > > > > > > this.
> > > > > > >
> > > > > > > I think we should either have a feature- or time-oriented
> release
> > > > plan.
> > > > > > > If we want to have a fixed release date, we could make a
> feature
> > > > stop 1
> > > > > > > week (or so) in advance, include what's in until then and
> > continue
> > > to
> > > > > > > release every n weeks.
> > > > > > > Or we make a list of what should be in the next release and try
> > to
> > > > > give a
> > > > > > > reasonable time estimate for that (which didn't work out so
> well
> > in
> > > > the
> > > > > > > past.... ;-) )
> > > > > > >
> > > > > > > But having both, a close deadline and a long list of complex
> > > features
> > > > > > will
> > > > > > > not work out well, IMO.
> > > > > > >
> > > > > > > Just my 2 cents, Fabian
> > > > > > >
> > > > > > >
> > > > > > > 2014-08-27 19:49 GMT+02:00 Stephan Ewen <[hidden email]>:
> > > > > > >
> > > > > > > > This is a nice list.
> > > > > > > >
> > > > > > > > I would like to add:
> > > > > > > >
> > > > > > > >  - Rework JobManager internals to support incremental program
> > > > > rollout &
> > > > > > > > execution
> > > > > > > >  - First parts of dynamic memory assignments
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <
> > > > [hidden email]
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > since we have our release infrastructure in place now, I
> > would
> > > > > > suggest
> > > > > > > to
> > > > > > > > > aim for a 0.7-incubating release in the near future (say
> 3-5
> > > > > weeks).
> > > > > > > > > While 0.6-incubating was mainly about getting the release
> > > infra /
> > > > > > legal
> > > > > > > > > stuff sorted out, I think it would be nice to have a
> > "feature"
> > > > > > release
> > > > > > > > > soon.
> > > > > > > > >
> > > > > > > > > The following new features would make a great
> 0.7-incubating
> > > > > release:
> > > > > > > > >  - *Flink Streaming* "Beta Preview". I would suggest to
> ship
> > > the
> > > > > > > > streaming,
> > > > > > > > > but clearly mark it as a preview in the documentation.
> > > > > > > > >  -* Java API Pojo improvements*: Code generation, key
> > selection
> > > > > > using a
> > > > > > > > > string-expression:
> > > > > https://issues.apache.org/jira/browse/FLINK-1032
> > > > > > > > >   - *Reworked Scala API*. Bring the Scala API in sync with
> > the
> > > > > latest
> > > > > > > > > developments in the Java API:
> > > > > > > > > https://issues.apache.org/jira/browse/FLINK-641
> > > > > > > > >   -* Akka-based RPC service*:
> > > > > > > > > https://issues.apache.org/jira/browse/FLINK-1019
> > > > > > > > >   - *Kryo-based serialization*. This feature has been
> > requested
> > > > by
> > > > > > many
> > > > > > > > > users. Mostly because they wanted to use Collections inside
> > > > POJOs:
> > > > > > > > > https://issues.apache.org/jira/browse/FLINK-610
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Opinions?
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Stephan Ewen]

+1
Am 04.09.2014 00:05 schrieb "Fabian Hueske" <[hidden email]>:

> +1
>
>
> 2014-09-03 22:39 GMT+02:00 Kostas Tzoumas <[hidden email]>:
>
> > +1
> >
> >
> > On Wed, Sep 3, 2014 at 10:12 PM, Márton Balassi <
> [hidden email]>
> > wrote:
> >
> > > +1
> > >
> > >
> > > On Wed, Sep 3, 2014 at 9:54 PM, Till Rohrmann <[hidden email]>
> > > wrote:
> > >
> > > > +1 Sounds good to me.
> > > >
> > > >
> > > > On Wed, Sep 3, 2014 at 1:58 PM, Robert Metzger <[hidden email]>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > sorry, my previous message was confusing. I suggest to release a
> new
> > > > Flink
> > > > > version all 3 months.
> > > > > BUT, the 0.7-incubating release is going to be feature freeze in 3
> > > weeks
> > > > > because 0.6-incubating was more about getting the release infra set
> > up
> > > > and
> > > > > the apache rename out.
> > > > > The last release that contained a lot of features was 0.5 and it
> was
> > > > > released on May 29. So aiming for end of September for the next
> > feature
> > > > > release should be somehow in the schedule.
> > > > >
> > > > >
> > > > > Robert
> > > > >
> > > > >
> > > > > On Wed, Sep 3, 2014 at 11:47 AM, Ufuk Celebi <[hidden email]>
> wrote:
> > > > >
> > > > > > Hey Robert,
> > > > > >
> > > > > > +1 to frequent regular frequent major releases (I guess you
> meant 3
> > > > weeks
> > > > > > and not 3 months, right?).
> > > > > >
> > > > > > Ufuk
> > > > > >
> > > > > >
> > > > > > On Tue, Sep 2, 2014 at 9:29 PM, Robert Metzger <
> > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > > I agree with Fabian that the list of features is a lot of
> work. I
> > > > would
> > > > > > > prefer to have frequent regular major releases (say 3 months
> > > > schedule).
> > > > > > > This way, users can quickly access the latest features and we
> > don't
> > > > > force
> > > > > > > them to use SNAPSHOT versions.
> > > > > > > Also, releases draw attention to our project.
> > > > > > >
> > > > > > > I would suggest to do a feature freeze on September 24 (3 weeks
> > > from
> > > > > now)
> > > > > > > and start the vote a few days afterwards. I assume that at
> least
> > > some
> > > > > of
> > > > > > > the suggested 7 features of the release are ready.
> > > > > > >
> > > > > > > Robert
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Aug 27, 2014 at 9:20 PM, Fabian Hueske <
> > [hidden email]
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > I agree that these should be features to add soon, but I'm a
> > bit
> > > > > > doubtful
> > > > > > > > that we will have the next release in 5 weeks if we want to
> > > include
> > > > > all
> > > > > > > of
> > > > > > > > this.
> > > > > > > >
> > > > > > > > I think we should either have a feature- or time-oriented
> > release
> > > > > plan.
> > > > > > > > If we want to have a fixed release date, we could make a
> > feature
> > > > > stop 1
> > > > > > > > week (or so) in advance, include what's in until then and
> > > continue
> > > > to
> > > > > > > > release every n weeks.
> > > > > > > > Or we make a list of what should be in the next release and
> try
> > > to
> > > > > > give a
> > > > > > > > reasonable time estimate for that (which didn't work out so
> > well
> > > in
> > > > > the
> > > > > > > > past.... ;-) )
> > > > > > > >
> > > > > > > > But having both, a close deadline and a long list of complex
> > > > features
> > > > > > > will
> > > > > > > > not work out well, IMO.
> > > > > > > >
> > > > > > > > Just my 2 cents, Fabian
> > > > > > > >
> > > > > > > >
> > > > > > > > 2014-08-27 19:49 GMT+02:00 Stephan Ewen <[hidden email]>:
> > > > > > > >
> > > > > > > > > This is a nice list.
> > > > > > > > >
> > > > > > > > > I would like to add:
> > > > > > > > >
> > > > > > > > >  - Rework JobManager internals to support incremental
> program
> > > > > > rollout &
> > > > > > > > > execution
> > > > > > > > >  - First parts of dynamic memory assignments
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <
> > > > > [hidden email]
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > since we have our release infrastructure in place now, I
> > > would
> > > > > > > suggest
> > > > > > > > to
> > > > > > > > > > aim for a 0.7-incubating release in the near future (say
> > 3-5
> > > > > > weeks).
> > > > > > > > > > While 0.6-incubating was mainly about getting the release
> > > > infra /
> > > > > > > legal
> > > > > > > > > > stuff sorted out, I think it would be nice to have a
> > > "feature"
> > > > > > > release
> > > > > > > > > > soon.
> > > > > > > > > >
> > > > > > > > > > The following new features would make a great
> > 0.7-incubating
> > > > > > release:
> > > > > > > > > >  - *Flink Streaming* "Beta Preview". I would suggest to
> > ship
> > > > the
> > > > > > > > > streaming,
> > > > > > > > > > but clearly mark it as a preview in the documentation.
> > > > > > > > > >  -* Java API Pojo improvements*: Code generation, key
> > > selection
> > > > > > > using a
> > > > > > > > > > string-expression:
> > > > > > https://issues.apache.org/jira/browse/FLINK-1032
> > > > > > > > > >   - *Reworked Scala API*. Bring the Scala API in sync
> with
> > > the
> > > > > > latest
> > > > > > > > > > developments in the Java API:
> > > > > > > > > > https://issues.apache.org/jira/browse/FLINK-641
> > > > > > > > > >   -* Akka-based RPC service*:
> > > > > > > > > > https://issues.apache.org/jira/browse/FLINK-1019
> > > > > > > > > >   - *Kryo-based serialization*. This feature has been
> > > requested
> > > > > by
> > > > > > > many
> > > > > > > > > > users. Mostly because they wanted to use Collections
> inside
> > > > > POJOs:
> > > > > > > > > > https://issues.apache.org/jira/browse/FLINK-610
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Opinions?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Gyula Fóra]

+1
2014.09.04. 11:52 ezt írta ("Stephan Ewen" <[hidden email]>):

> +1
> Am 04.09.2014 00:05 schrieb "Fabian Hueske" <[hidden email]>:
>
> > +1
> >
> >
> > 2014-09-03 22:39 GMT+02:00 Kostas Tzoumas <[hidden email]>:
> >
> > > +1
> > >
> > >
> > > On Wed, Sep 3, 2014 at 10:12 PM, Márton Balassi <
> > [hidden email]>
> > > wrote:
> > >
> > > > +1
> > > >
> > > >
> > > > On Wed, Sep 3, 2014 at 9:54 PM, Till Rohrmann <[hidden email]>
> > > > wrote:
> > > >
> > > > > +1 Sounds good to me.
> > > > >
> > > > >
> > > > > On Wed, Sep 3, 2014 at 1:58 PM, Robert Metzger <
> [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > sorry, my previous message was confusing. I suggest to release a
> > new
> > > > > Flink
> > > > > > version all 3 months.
> > > > > > BUT, the 0.7-incubating release is going to be feature freeze in
> 3
> > > > weeks
> > > > > > because 0.6-incubating was more about getting the release infra
> set
> > > up
> > > > > and
> > > > > > the apache rename out.
> > > > > > The last release that contained a lot of features was 0.5 and it
> > was
> > > > > > released on May 29. So aiming for end of September for the next
> > > feature
> > > > > > release should be somehow in the schedule.
> > > > > >
> > > > > >
> > > > > > Robert
> > > > > >
> > > > > >
> > > > > > On Wed, Sep 3, 2014 at 11:47 AM, Ufuk Celebi <[hidden email]>
> > wrote:
> > > > > >
> > > > > > > Hey Robert,
> > > > > > >
> > > > > > > +1 to frequent regular frequent major releases (I guess you
> > meant 3
> > > > > weeks
> > > > > > > and not 3 months, right?).
> > > > > > >
> > > > > > > Ufuk
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Sep 2, 2014 at 9:29 PM, Robert Metzger <
> > > [hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > > I agree with Fabian that the list of features is a lot of
> > work. I
> > > > > would
> > > > > > > > prefer to have frequent regular major releases (say 3 months
> > > > > schedule).
> > > > > > > > This way, users can quickly access the latest features and we
> > > don't
> > > > > > force
> > > > > > > > them to use SNAPSHOT versions.
> > > > > > > > Also, releases draw attention to our project.
> > > > > > > >
> > > > > > > > I would suggest to do a feature freeze on September 24 (3
> weeks
> > > > from
> > > > > > now)
> > > > > > > > and start the vote a few days afterwards. I assume that at
> > least
> > > > some
> > > > > > of
> > > > > > > > the suggested 7 features of the release are ready.
> > > > > > > >
> > > > > > > > Robert
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Aug 27, 2014 at 9:20 PM, Fabian Hueske <
> > > [hidden email]
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I agree that these should be features to add soon, but I'm
> a
> > > bit
> > > > > > > doubtful
> > > > > > > > > that we will have the next release in 5 weeks if we want to
> > > > include
> > > > > > all
> > > > > > > > of
> > > > > > > > > this.
> > > > > > > > >
> > > > > > > > > I think we should either have a feature- or time-oriented
> > > release
> > > > > > plan.
> > > > > > > > > If we want to have a fixed release date, we could make a
> > > feature
> > > > > > stop 1
> > > > > > > > > week (or so) in advance, include what's in until then and
> > > > continue
> > > > > to
> > > > > > > > > release every n weeks.
> > > > > > > > > Or we make a list of what should be in the next release and
> > try
> > > > to
> > > > > > > give a
> > > > > > > > > reasonable time estimate for that (which didn't work out so
> > > well
> > > > in
> > > > > > the
> > > > > > > > > past.... ;-) )
> > > > > > > > >
> > > > > > > > > But having both, a close deadline and a long list of
> complex
> > > > > features
> > > > > > > > will
> > > > > > > > > not work out well, IMO.
> > > > > > > > >
> > > > > > > > > Just my 2 cents, Fabian
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2014-08-27 19:49 GMT+02:00 Stephan Ewen <[hidden email]
> >:
> > > > > > > > >
> > > > > > > > > > This is a nice list.
> > > > > > > > > >
> > > > > > > > > > I would like to add:
> > > > > > > > > >
> > > > > > > > > >  - Rework JobManager internals to support incremental
> > program
> > > > > > > rollout &
> > > > > > > > > > execution
> > > > > > > > > >  - First parts of dynamic memory assignments
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <
> > > > > > [hidden email]
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > since we have our release infrastructure in place now,
> I
> > > > would
> > > > > > > > suggest
> > > > > > > > > to
> > > > > > > > > > > aim for a 0.7-incubating release in the near future
> (say
> > > 3-5
> > > > > > > weeks).
> > > > > > > > > > > While 0.6-incubating was mainly about getting the
> release
> > > > > infra /
> > > > > > > > legal
> > > > > > > > > > > stuff sorted out, I think it would be nice to have a
> > > > "feature"
> > > > > > > > release
> > > > > > > > > > > soon.
> > > > > > > > > > >
> > > > > > > > > > > The following new features would make a great
> > > 0.7-incubating
> > > > > > > release:
> > > > > > > > > > >  - *Flink Streaming* "Beta Preview". I would suggest to
> > > ship
> > > > > the
> > > > > > > > > > streaming,
> > > > > > > > > > > but clearly mark it as a preview in the documentation.
> > > > > > > > > > >  -* Java API Pojo improvements*: Code generation, key
> > > > selection
> > > > > > > > using a
> > > > > > > > > > > string-expression:
> > > > > > > https://issues.apache.org/jira/browse/FLINK-1032
> > > > > > > > > > >   - *Reworked Scala API*. Bring the Scala API in sync
> > with
> > > > the
> > > > > > > latest
> > > > > > > > > > > developments in the Java API:
> > > > > > > > > > > https://issues.apache.org/jira/browse/FLINK-641
> > > > > > > > > > >   -* Akka-based RPC service*:
> > > > > > > > > > > https://issues.apache.org/jira/browse/FLINK-1019
> > > > > > > > > > >   - *Kryo-based serialization*. This feature has been
> > > > requested
> > > > > > by
> > > > > > > > many
> > > > > > > > > > > users. Mostly because they wanted to use Collections
> > inside
> > > > > > POJOs:
> > > > > > > > > > > https://issues.apache.org/jira/browse/FLINK-610
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Opinions?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Kostas Tzoumas-2]

+1


On Thu, Sep 4, 2014 at 12:00 PM, Gyula Fóra <[hidden email]> wrote:

> +1
> 2014.09.04. 11:52 ezt írta ("Stephan Ewen" <[hidden email]>):
>
> > +1
> > Am 04.09.2014 00:05 schrieb "Fabian Hueske" <[hidden email]>:
> >
> > > +1
> > >
> > >
> > > 2014-09-03 22:39 GMT+02:00 Kostas Tzoumas <[hidden email]>:
> > >
> > > > +1
> > > >
> > > >
> > > > On Wed, Sep 3, 2014 at 10:12 PM, Márton Balassi <
> > > [hidden email]>
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > >
> > > > > On Wed, Sep 3, 2014 at 9:54 PM, Till Rohrmann <
> [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > +1 Sounds good to me.
> > > > > >
> > > > > >
> > > > > > On Wed, Sep 3, 2014 at 1:58 PM, Robert Metzger <
> > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > sorry, my previous message was confusing. I suggest to release
> a
> > > new
> > > > > > Flink
> > > > > > > version all 3 months.
> > > > > > > BUT, the 0.7-incubating release is going to be feature freeze
> in
> > 3
> > > > > weeks
> > > > > > > because 0.6-incubating was more about getting the release infra
> > set
> > > > up
> > > > > > and
> > > > > > > the apache rename out.
> > > > > > > The last release that contained a lot of features was 0.5 and
> it
> > > was
> > > > > > > released on May 29. So aiming for end of September for the next
> > > > feature
> > > > > > > release should be somehow in the schedule.
> > > > > > >
> > > > > > >
> > > > > > > Robert
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Sep 3, 2014 at 11:47 AM, Ufuk Celebi <[hidden email]>
> > > wrote:
> > > > > > >
> > > > > > > > Hey Robert,
> > > > > > > >
> > > > > > > > +1 to frequent regular frequent major releases (I guess you
> > > meant 3
> > > > > > weeks
> > > > > > > > and not 3 months, right?).
> > > > > > > >
> > > > > > > > Ufuk
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Sep 2, 2014 at 9:29 PM, Robert Metzger <
> > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > > I agree with Fabian that the list of features is a lot of
> > > work. I
> > > > > > would
> > > > > > > > > prefer to have frequent regular major releases (say 3
> months
> > > > > > schedule).
> > > > > > > > > This way, users can quickly access the latest features and
> we
> > > > don't
> > > > > > > force
> > > > > > > > > them to use SNAPSHOT versions.
> > > > > > > > > Also, releases draw attention to our project.
> > > > > > > > >
> > > > > > > > > I would suggest to do a feature freeze on September 24 (3
> > weeks
> > > > > from
> > > > > > > now)
> > > > > > > > > and start the vote a few days afterwards. I assume that at
> > > least
> > > > > some
> > > > > > > of
> > > > > > > > > the suggested 7 features of the release are ready.
> > > > > > > > >
> > > > > > > > > Robert
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Aug 27, 2014 at 9:20 PM, Fabian Hueske <
> > > > [hidden email]
> > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > I agree that these should be features to add soon, but
> I'm
> > a
> > > > bit
> > > > > > > > doubtful
> > > > > > > > > > that we will have the next release in 5 weeks if we want
> to
> > > > > include
> > > > > > > all
> > > > > > > > > of
> > > > > > > > > > this.
> > > > > > > > > >
> > > > > > > > > > I think we should either have a feature- or time-oriented
> > > > release
> > > > > > > plan.
> > > > > > > > > > If we want to have a fixed release date, we could make a
> > > > feature
> > > > > > > stop 1
> > > > > > > > > > week (or so) in advance, include what's in until then and
> > > > > continue
> > > > > > to
> > > > > > > > > > release every n weeks.
> > > > > > > > > > Or we make a list of what should be in the next release
> and
> > > try
> > > > > to
> > > > > > > > give a
> > > > > > > > > > reasonable time estimate for that (which didn't work out
> so
> > > > well
> > > > > in
> > > > > > > the
> > > > > > > > > > past.... ;-) )
> > > > > > > > > >
> > > > > > > > > > But having both, a close deadline and a long list of
> > complex
> > > > > > features
> > > > > > > > > will
> > > > > > > > > > not work out well, IMO.
> > > > > > > > > >
> > > > > > > > > > Just my 2 cents, Fabian
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 2014-08-27 19:49 GMT+02:00 Stephan Ewen <
> [hidden email]
> > >:
> > > > > > > > > >
> > > > > > > > > > > This is a nice list.
> > > > > > > > > > >
> > > > > > > > > > > I would like to add:
> > > > > > > > > > >
> > > > > > > > > > >  - Rework JobManager internals to support incremental
> > > program
> > > > > > > > rollout &
> > > > > > > > > > > execution
> > > > > > > > > > >  - First parts of dynamic memory assignments
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <
> > > > > > > [hidden email]
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > since we have our release infrastructure in place
> now,
> > I
> > > > > would
> > > > > > > > > suggest
> > > > > > > > > > to
> > > > > > > > > > > > aim for a 0.7-incubating release in the near future
> > (say
> > > > 3-5
> > > > > > > > weeks).
> > > > > > > > > > > > While 0.6-incubating was mainly about getting the
> > release
> > > > > > infra /
> > > > > > > > > legal
> > > > > > > > > > > > stuff sorted out, I think it would be nice to have a
> > > > > "feature"
> > > > > > > > > release
> > > > > > > > > > > > soon.
> > > > > > > > > > > >
> > > > > > > > > > > > The following new features would make a great
> > > > 0.7-incubating
> > > > > > > > release:
> > > > > > > > > > > >  - *Flink Streaming* "Beta Preview". I would suggest
> to
> > > > ship
> > > > > > the
> > > > > > > > > > > streaming,
> > > > > > > > > > > > but clearly mark it as a preview in the
> documentation.
> > > > > > > > > > > >  -* Java API Pojo improvements*: Code generation, key
> > > > > selection
> > > > > > > > > using a
> > > > > > > > > > > > string-expression:
> > > > > > > > https://issues.apache.org/jira/browse/FLINK-1032
> > > > > > > > > > > >   - *Reworked Scala API*. Bring the Scala API in sync
> > > with
> > > > > the
> > > > > > > > latest
> > > > > > > > > > > > developments in the Java API:
> > > > > > > > > > > > https://issues.apache.org/jira/browse/FLINK-641
> > > > > > > > > > > >   -* Akka-based RPC service*:
> > > > > > > > > > > > https://issues.apache.org/jira/browse/FLINK-1019
> > > > > > > > > > > >   - *Kryo-based serialization*. This feature has been
> > > > > requested
> > > > > > > by
> > > > > > > > > many
> > > > > > > > > > > > users. Mostly because they wanted to use Collections
> > > inside
> > > > > > > POJOs:
> > > > > > > > > > > > https://issues.apache.org/jira/browse/FLINK-610
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Opinions?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Robert Metzger]

Hey guys,

exactly 3 weeks ago, we discussed to do a feature freeze for the
0.7-incubating release today.

From our initial feature list:
 - *Flink Streaming* "Beta Preview". I would suggest to ship the streaming,
but clearly mark it as a preview in the documentation.
 -* Java API Pojo improvements*: Code generation, key selection using a
string-expression: https://issues.apache.org/jira/browse/FLINK-1032
  - *Reworked Scala API*. Bring the Scala API in sync with the latest
developments in the Java API:
https://issues.apache.org/jira/browse/FLINK-641
  -* Akka-based RPC service*:
https://issues.apache.org/jira/browse/FLINK-1019
  - *Kryo-based serialization*. This feature has been requested by many
users. Mostly because they wanted to use Collections inside POJOs:
https://issues.apache.org/jira/browse/FLINK-610
 - Rework JobManager internals to support incremental program rollout &
execution
 - First parts of dynamic memory assignments

The following features are in the master, as of today:
 - *Flink Streaming*
 - *Reworked Scala API*
 -* New Scheduler*

We certainly need some days to test everything until we can start the vote.
Based on our experience with the last major release, I would really like to
do the testing and bugfixing BEFORE the first release candidate. For the
0.6-incubating release, we had 6  candidates)

How do you guys feel about this? Should we wait a few more days for the
release so that a few more features make it into the release?

I'm undecided on this. On the one hand, its really nice to release on a
regular schedule, but it also eats up some time and causes overhead
(different branches etc.).
I would really like to have the Java API Pojo improvements in the release.
I think I can finish it until end of this week.

Opinions?


Cheers,
Robert




On Fri, Sep 5, 2014 at 8:55 AM, Kostas Tzoumas <[hidden email]> wrote:

> +1
>
>
> On Thu, Sep 4, 2014 at 12:00 PM, Gyula Fóra <[hidden email]> wrote:
>
> > +1
> > 2014.09.04. 11:52 ezt írta ("Stephan Ewen" <[hidden email]>):
> >
> > > +1
> > > Am 04.09.2014 00:05 schrieb "Fabian Hueske" <[hidden email]>:
> > >
> > > > +1
> > > >
> > > >
> > > > 2014-09-03 22:39 GMT+02:00 Kostas Tzoumas <[hidden email]>:
> > > >
> > > > > +1
> > > > >
> > > > >
> > > > > On Wed, Sep 3, 2014 at 10:12 PM, Márton Balassi <
> > > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > >
> > > > > > On Wed, Sep 3, 2014 at 9:54 PM, Till Rohrmann <
> > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > +1 Sounds good to me.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Sep 3, 2014 at 1:58 PM, Robert Metzger <
> > > [hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > sorry, my previous message was confusing. I suggest to
> release
> > a
> > > > new
> > > > > > > Flink
> > > > > > > > version all 3 months.
> > > > > > > > BUT, the 0.7-incubating release is going to be feature freeze
> > in
> > > 3
> > > > > > weeks
> > > > > > > > because 0.6-incubating was more about getting the release
> infra
> > > set
> > > > > up
> > > > > > > and
> > > > > > > > the apache rename out.
> > > > > > > > The last release that contained a lot of features was 0.5 and
> > it
> > > > was
> > > > > > > > released on May 29. So aiming for end of September for the
> next
> > > > > feature
> > > > > > > > release should be somehow in the schedule.
> > > > > > > >
> > > > > > > >
> > > > > > > > Robert
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Sep 3, 2014 at 11:47 AM, Ufuk Celebi <[hidden email]
> >
> > > > wrote:
> > > > > > > >
> > > > > > > > > Hey Robert,
> > > > > > > > >
> > > > > > > > > +1 to frequent regular frequent major releases (I guess you
> > > > meant 3
> > > > > > > weeks
> > > > > > > > > and not 3 months, right?).
> > > > > > > > >
> > > > > > > > > Ufuk
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Sep 2, 2014 at 9:29 PM, Robert Metzger <
> > > > > [hidden email]>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > > I agree with Fabian that the list of features is a lot of
> > > > work. I
> > > > > > > would
> > > > > > > > > > prefer to have frequent regular major releases (say 3
> > months
> > > > > > > schedule).
> > > > > > > > > > This way, users can quickly access the latest features
> and
> > we
> > > > > don't
> > > > > > > > force
> > > > > > > > > > them to use SNAPSHOT versions.
> > > > > > > > > > Also, releases draw attention to our project.
> > > > > > > > > >
> > > > > > > > > > I would suggest to do a feature freeze on September 24 (3
> > > weeks
> > > > > > from
> > > > > > > > now)
> > > > > > > > > > and start the vote a few days afterwards. I assume that
> at
> > > > least
> > > > > > some
> > > > > > > > of
> > > > > > > > > > the suggested 7 features of the release are ready.
> > > > > > > > > >
> > > > > > > > > > Robert
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Aug 27, 2014 at 9:20 PM, Fabian Hueske <
> > > > > [hidden email]
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > I agree that these should be features to add soon, but
> > I'm
> > > a
> > > > > bit
> > > > > > > > > doubtful
> > > > > > > > > > > that we will have the next release in 5 weeks if we
> want
> > to
> > > > > > include
> > > > > > > > all
> > > > > > > > > > of
> > > > > > > > > > > this.
> > > > > > > > > > >
> > > > > > > > > > > I think we should either have a feature- or
> time-oriented
> > > > > release
> > > > > > > > plan.
> > > > > > > > > > > If we want to have a fixed release date, we could make
> a
> > > > > feature
> > > > > > > > stop 1
> > > > > > > > > > > week (or so) in advance, include what's in until then
> and
> > > > > > continue
> > > > > > > to
> > > > > > > > > > > release every n weeks.
> > > > > > > > > > > Or we make a list of what should be in the next release
> > and
> > > > try
> > > > > > to
> > > > > > > > > give a
> > > > > > > > > > > reasonable time estimate for that (which didn't work
> out
> > so
> > > > > well
> > > > > > in
> > > > > > > > the
> > > > > > > > > > > past.... ;-) )
> > > > > > > > > > >
> > > > > > > > > > > But having both, a close deadline and a long list of
> > > complex
> > > > > > > features
> > > > > > > > > > will
> > > > > > > > > > > not work out well, IMO.
> > > > > > > > > > >
> > > > > > > > > > > Just my 2 cents, Fabian
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 2014-08-27 19:49 GMT+02:00 Stephan Ewen <
> > [hidden email]
> > > >:
> > > > > > > > > > >
> > > > > > > > > > > > This is a nice list.
> > > > > > > > > > > >
> > > > > > > > > > > > I would like to add:
> > > > > > > > > > > >
> > > > > > > > > > > >  - Rework JobManager internals to support incremental
> > > > program
> > > > > > > > > rollout &
> > > > > > > > > > > > execution
> > > > > > > > > > > >  - First parts of dynamic memory assignments
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Aug 27, 2014 at 7:21 PM, Robert Metzger <
> > > > > > > > [hidden email]
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > since we have our release infrastructure in place
> > now,
> > > I
> > > > > > would
> > > > > > > > > > suggest
> > > > > > > > > > > to
> > > > > > > > > > > > > aim for a 0.7-incubating release in the near future
> > > (say
> > > > > 3-5
> > > > > > > > > weeks).
> > > > > > > > > > > > > While 0.6-incubating was mainly about getting the
> > > release
> > > > > > > infra /
> > > > > > > > > > legal
> > > > > > > > > > > > > stuff sorted out, I think it would be nice to have
> a
> > > > > > "feature"
> > > > > > > > > > release
> > > > > > > > > > > > > soon.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The following new features would make a great
> > > > > 0.7-incubating
> > > > > > > > > release:
> > > > > > > > > > > > >  - *Flink Streaming* "Beta Preview". I would
> suggest
> > to
> > > > > ship
> > > > > > > the
> > > > > > > > > > > > streaming,
> > > > > > > > > > > > > but clearly mark it as a preview in the
> > documentation.
> > > > > > > > > > > > >  -* Java API Pojo improvements*: Code generation,
> key
> > > > > > selection
> > > > > > > > > > using a
> > > > > > > > > > > > > string-expression:
> > > > > > > > > https://issues.apache.org/jira/browse/FLINK-1032
> > > > > > > > > > > > >   - *Reworked Scala API*. Bring the Scala API in
> sync
> > > > with
> > > > > > the
> > > > > > > > > latest
> > > > > > > > > > > > > developments in the Java API:
> > > > > > > > > > > > > https://issues.apache.org/jira/browse/FLINK-641
> > > > > > > > > > > > >   -* Akka-based RPC service*:
> > > > > > > > > > > > > https://issues.apache.org/jira/browse/FLINK-1019
> > > > > > > > > > > > >   - *Kryo-based serialization*. This feature has
> been
> > > > > > requested
> > > > > > > > by
> > > > > > > > > > many
> > > > > > > > > > > > > users. Mostly because they wanted to use
> Collections
> > > > inside
> > > > > > > > POJOs:
> > > > > > > > > > > > > https://issues.apache.org/jira/browse/FLINK-610
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Opinions?
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Ufuk Celebi-2]

On 24 Sep 2014, at 18:37, Robert Metzger <[hidden email]> wrote:

> Hey guys,
>
> exactly 3 weeks ago, we discussed to do a feature freeze for the
> 0.7-incubating release today.
>
> From our initial feature list:
> - *Flink Streaming* "Beta Preview". I would suggest to ship the streaming,
> but clearly mark it as a preview in the documentation.
> -* Java API Pojo improvements*: Code generation, key selection using a
> string-expression: https://issues.apache.org/jira/browse/FLINK-1032
>  - *Reworked Scala API*. Bring the Scala API in sync with the latest
> developments in the Java API:
> https://issues.apache.org/jira/browse/FLINK-641
>  -* Akka-based RPC service*:
> https://issues.apache.org/jira/browse/FLINK-1019
>  - *Kryo-based serialization*. This feature has been requested by many
> users. Mostly because they wanted to use Collections inside POJOs:
> https://issues.apache.org/jira/browse/FLINK-610
> - Rework JobManager internals to support incremental program rollout &
> execution
> - First parts of dynamic memory assignments
>
> The following features are in the master, as of today:
> - *Flink Streaming*
> - *Reworked Scala API*
> -* New Scheduler*
>
> We certainly need some days to test everything until we can start the vote.
> Based on our experience with the last major release, I would really like to
> do the testing and bugfixing BEFORE the first release candidate. For the
> 0.6-incubating release, we had 6  candidates)
>
> How do you guys feel about this? Should we wait a few more days for the
> release so that a few more features make it into the release?
>
> I'm undecided on this. On the one hand, its really nice to release on a
> regular schedule, but it also eats up some time and causes overhead
> (different branches etc.).
> I would really like to have the Java API Pojo improvements in the release.
> I think I can finish it until end of this week.
>
> Opinions?

I agree that the finished features (especially the Scala API) are nice for a new release, but still I would like to wait a few more days.

Some of the missing features are on the brink of being finished (e.g. the Pojo improvements). I wouldn't want to invest a week in bug fixing and doing the release vote, when the new features are likely to be finished just a few days afterwards. And the upcoming features will definitely be worth a release, so users can work with them. ;)

[Márton Balassi]

As for the streaming team we're also getting ready for the release, but a
couple of days will be needed to finish the features that we would like to
include.

   - A little work is still needed for reduce operations and
   groups/connected streams (any comment on Gyula's recent e-mail is really
   appreciated :) )
   - The examples are being updated to match the standard, check out the
   WordCount. (
   https://github.com/mbalassi/incubator-flink/blob/streaming-new/flink-addons/flink-streaming/flink-streaming-examples/src/main/java/org/apache/flink/streaming/examples/wordcount/WordCount.java)
   Hopefully it gives you some deja vu. :)


On Wed, Sep 24, 2014 at 6:53 PM, Ufuk Celebi <[hidden email]> wrote:

>
> On 24 Sep 2014, at 18:37, Robert Metzger <[hidden email]> wrote:
>
> > Hey guys,
> >
> > exactly 3 weeks ago, we discussed to do a feature freeze for the
> > 0.7-incubating release today.
> >
> > From our initial feature list:
> > - *Flink Streaming* "Beta Preview". I would suggest to ship the
> streaming,
> > but clearly mark it as a preview in the documentation.
> > -* Java API Pojo improvements*: Code generation, key selection using a
> > string-expression: https://issues.apache.org/jira/browse/FLINK-1032
> >  - *Reworked Scala API*. Bring the Scala API in sync with the latest
> > developments in the Java API:
> > https://issues.apache.org/jira/browse/FLINK-641
> >  -* Akka-based RPC service*:
> > https://issues.apache.org/jira/browse/FLINK-1019
> >  - *Kryo-based serialization*. This feature has been requested by many
> > users. Mostly because they wanted to use Collections inside POJOs:
> > https://issues.apache.org/jira/browse/FLINK-610
> > - Rework JobManager internals to support incremental program rollout &
> > execution
> > - First parts of dynamic memory assignments
> >
> > The following features are in the master, as of today:
> > - *Flink Streaming*
> > - *Reworked Scala API*
> > -* New Scheduler*
> >
> > We certainly need some days to test everything until we can start the
> vote.
> > Based on our experience with the last major release, I would really like
> to
> > do the testing and bugfixing BEFORE the first release candidate. For the
> > 0.6-incubating release, we had 6  candidates)
> >
> > How do you guys feel about this? Should we wait a few more days for the
> > release so that a few more features make it into the release?
> >
> > I'm undecided on this. On the one hand, its really nice to release on a
> > regular schedule, but it also eats up some time and causes overhead
> > (different branches etc.).
> > I would really like to have the Java API Pojo improvements in the
> release.
> > I think I can finish it until end of this week.
> >
> > Opinions?
>
> I agree that the finished features (especially the Scala API) are nice for
> a new release, but still I would like to wait a few more days.
>
> Some of the missing features are on the brink of being finished (e.g. the
> Pojo improvements). I wouldn't want to invest a week in bug fixing and
> doing the release vote, when the new features are likely to be finished
> just a few days afterwards. And the upcoming features will definitely be
> worth a release, so users can work with them. ;)

[Fabian Hueske]

I agree, a hard feature stop deadline might not be the best practice.

How about the following procedure:
We decide two (or three) weeks before a targeted release date about which
JIRAs to include. JIRAs that are selected for a release should be completed
or really close to completion (via progress estimates in JIRA).
After we decided which JIRAs to include in a release, we can use JIRA to
track the progress and dedicate another week exclusively for testing after
the last feature was completed.


2014-09-24 19:10 GMT+02:00 Márton Balassi <[hidden email]>:

> As for the streaming team we're also getting ready for the release, but a
> couple of days will be needed to finish the features that we would like to
> include.
>
>    - A little work is still needed for reduce operations and
>    groups/connected streams (any comment on Gyula's recent e-mail is really
>    appreciated :) )
>    - The examples are being updated to match the standard, check out the
>    WordCount. (
>
> https://github.com/mbalassi/incubator-flink/blob/streaming-new/flink-addons/flink-streaming/flink-streaming-examples/src/main/java/org/apache/flink/streaming/examples/wordcount/WordCount.java
> )
>    Hopefully it gives you some deja vu. :)
>
>
> On Wed, Sep 24, 2014 at 6:53 PM, Ufuk Celebi <[hidden email]> wrote:
>
> >
> > On 24 Sep 2014, at 18:37, Robert Metzger <[hidden email]> wrote:
> >
> > > Hey guys,
> > >
> > > exactly 3 weeks ago, we discussed to do a feature freeze for the
> > > 0.7-incubating release today.
> > >
> > > From our initial feature list:
> > > - *Flink Streaming* "Beta Preview". I would suggest to ship the
> > streaming,
> > > but clearly mark it as a preview in the documentation.
> > > -* Java API Pojo improvements*: Code generation, key selection using a
> > > string-expression: https://issues.apache.org/jira/browse/FLINK-1032
> > >  - *Reworked Scala API*. Bring the Scala API in sync with the latest
> > > developments in the Java API:
> > > https://issues.apache.org/jira/browse/FLINK-641
> > >  -* Akka-based RPC service*:
> > > https://issues.apache.org/jira/browse/FLINK-1019
> > >  - *Kryo-based serialization*. This feature has been requested by many
> > > users. Mostly because they wanted to use Collections inside POJOs:
> > > https://issues.apache.org/jira/browse/FLINK-610
> > > - Rework JobManager internals to support incremental program rollout &
> > > execution
> > > - First parts of dynamic memory assignments
> > >
> > > The following features are in the master, as of today:
> > > - *Flink Streaming*
> > > - *Reworked Scala API*
> > > -* New Scheduler*
> > >
> > > We certainly need some days to test everything until we can start the
> > vote.
> > > Based on our experience with the last major release, I would really
> like
> > to
> > > do the testing and bugfixing BEFORE the first release candidate. For
> the
> > > 0.6-incubating release, we had 6  candidates)
> > >
> > > How do you guys feel about this? Should we wait a few more days for the
> > > release so that a few more features make it into the release?
> > >
> > > I'm undecided on this. On the one hand, its really nice to release on a
> > > regular schedule, but it also eats up some time and causes overhead
> > > (different branches etc.).
> > > I would really like to have the Java API Pojo improvements in the
> > release.
> > > I think I can finish it until end of this week.
> > >
> > > Opinions?
> >
> > I agree that the finished features (especially the Scala API) are nice
> for
> > a new release, but still I would like to wait a few more days.
> >
> > Some of the missing features are on the brink of being finished (e.g. the
> > Pojo improvements). I wouldn't want to invest a week in bug fixing and
> > doing the release vote, when the new features are likely to be finished
> > just a few days afterwards. And the upcoming features will definitely be
> > worth a release, so users can work with them. ;)
>

[Daniel Warneke]

Hi,

I like Fabian's idea. Is there a wiki page (or something similar) where
we can collect the proposed JIRAs?

Best regards,

     Daniel

Am 24.09.2014 23:03, schrieb Fabian Hueske:

> I agree, a hard feature stop deadline might not be the best practice.
>
> How about the following procedure:
> We decide two (or three) weeks before a targeted release date about which
> JIRAs to include. JIRAs that are selected for a release should be completed
> or really close to completion (via progress estimates in JIRA).
> After we decided which JIRAs to include in a release, we can use JIRA to
> track the progress and dedicate another week exclusively for testing after
> the last feature was completed.
>
>
> 2014-09-24 19:10 GMT+02:00 Márton Balassi <[hidden email]>:
>
>> As for the streaming team we're also getting ready for the release, but a
>> couple of days will be needed to finish the features that we would like to
>> include.
>>
>>     - A little work is still needed for reduce operations and
>>     groups/connected streams (any comment on Gyula's recent e-mail is really
>>     appreciated :) )
>>     - The examples are being updated to match the standard, check out the
>>     WordCount. (
>>
>> https://github.com/mbalassi/incubator-flink/blob/streaming-new/flink-addons/flink-streaming/flink-streaming-examples/src/main/java/org/apache/flink/streaming/examples/wordcount/WordCount.java
>> )
>>     Hopefully it gives you some deja vu. :)
>>
>>
>> On Wed, Sep 24, 2014 at 6:53 PM, Ufuk Celebi <[hidden email]> wrote:
>>
>>> On 24 Sep 2014, at 18:37, Robert Metzger <[hidden email]> wrote:
>>>
>>>> Hey guys,
>>>>
>>>> exactly 3 weeks ago, we discussed to do a feature freeze for the
>>>> 0.7-incubating release today.
>>>>
>>>>  From our initial feature list:
>>>> - *Flink Streaming* "Beta Preview". I would suggest to ship the
>>> streaming,
>>>> but clearly mark it as a preview in the documentation.
>>>> -* Java API Pojo improvements*: Code generation, key selection using a
>>>> string-expression: https://issues.apache.org/jira/browse/FLINK-1032
>>>>   - *Reworked Scala API*. Bring the Scala API in sync with the latest
>>>> developments in the Java API:
>>>> https://issues.apache.org/jira/browse/FLINK-641
>>>>   -* Akka-based RPC service*:
>>>> https://issues.apache.org/jira/browse/FLINK-1019
>>>>   - *Kryo-based serialization*. This feature has been requested by many
>>>> users. Mostly because they wanted to use Collections inside POJOs:
>>>> https://issues.apache.org/jira/browse/FLINK-610
>>>> - Rework JobManager internals to support incremental program rollout &
>>>> execution
>>>> - First parts of dynamic memory assignments
>>>>
>>>> The following features are in the master, as of today:
>>>> - *Flink Streaming*
>>>> - *Reworked Scala API*
>>>> -* New Scheduler*
>>>>
>>>> We certainly need some days to test everything until we can start the
>>> vote.
>>>> Based on our experience with the last major release, I would really
>> like
>>> to
>>>> do the testing and bugfixing BEFORE the first release candidate. For
>> the
>>>> 0.6-incubating release, we had 6  candidates)
>>>>
>>>> How do you guys feel about this? Should we wait a few more days for the
>>>> release so that a few more features make it into the release?
>>>>
>>>> I'm undecided on this. On the one hand, its really nice to release on a
>>>> regular schedule, but it also eats up some time and causes overhead
>>>> (different branches etc.).
>>>> I would really like to have the Java API Pojo improvements in the
>>> release.
>>>> I think I can finish it until end of this week.
>>>>
>>>> Opinions?
>>> I agree that the finished features (especially the Scala API) are nice
>> for
>>> a new release, but still I would like to wait a few more days.
>>>
>>> Some of the missing features are on the brink of being finished (e.g. the
>>> Pojo improvements). I wouldn't want to invest a week in bug fixing and
>>> doing the release vote, when the new features are likely to be finished
>>> just a few days afterwards. And the upcoming features will definitely be
>>> worth a release, so users can work with them. ;)

[Stephan Ewen]

I personally like the idea of SOFT time-based feature freezes. Otherwise,
releases will get delayed again and again, because of features that we try
to squeeze in.

Having reached the freeze point already, we could still include the
features that are pending ready state in the next days (streaming, blob
Manager, POJOs), but otherwise head for a release state.

We had a mail listing the issues to include into 0.7, but a wiki page would
probably be better. In that sense, we could start collecting the issues for
the next release from now on.
 Am 26.09.2014 09:17 schrieb "Daniel Warneke" <[hidden email]>:

> Hi,
>
> I like Fabian's idea. Is there a wiki page (or something similar) where we
> can collect the proposed JIRAs?
>
> Best regards,
>
>     Daniel
>
> Am 24.09.2014 23:03, schrieb Fabian Hueske:
>
>> I agree, a hard feature stop deadline might not be the best practice.
>>
>> How about the following procedure:
>> We decide two (or three) weeks before a targeted release date about which
>> JIRAs to include. JIRAs that are selected for a release should be
>> completed
>> or really close to completion (via progress estimates in JIRA).
>> After we decided which JIRAs to include in a release, we can use JIRA to
>> track the progress and dedicate another week exclusively for testing after
>> the last feature was completed.
>>
>>
>> 2014-09-24 19:10 GMT+02:00 Márton Balassi <[hidden email]>:
>>
>>  As for the streaming team we're also getting ready for the release, but a
>>> couple of days will be needed to finish the features that we would like
>>> to
>>> include.
>>>
>>>     - A little work is still needed for reduce operations and
>>>     groups/connected streams (any comment on Gyula's recent e-mail is
>>> really
>>>     appreciated :) )
>>>     - The examples are being updated to match the standard, check out the
>>>     WordCount. (
>>>
>>> https://github.com/mbalassi/incubator-flink/blob/
>>> streaming-new/flink-addons/flink-streaming/flink-
>>> streaming-examples/src/main/java/org/apache/flink/
>>> streaming/examples/wordcount/WordCount.java
>>> )
>>>     Hopefully it gives you some deja vu. :)
>>>
>>>
>>> On Wed, Sep 24, 2014 at 6:53 PM, Ufuk Celebi <[hidden email]> wrote:
>>>
>>>  On 24 Sep 2014, at 18:37, Robert Metzger <[hidden email]> wrote:
>>>>
>>>>  Hey guys,
>>>>>
>>>>> exactly 3 weeks ago, we discussed to do a feature freeze for the
>>>>> 0.7-incubating release today.
>>>>>
>>>>>  From our initial feature list:
>>>>> - *Flink Streaming* "Beta Preview". I would suggest to ship the
>>>>>
>>>> streaming,
>>>>
>>>>> but clearly mark it as a preview in the documentation.
>>>>> -* Java API Pojo improvements*: Code generation, key selection using a
>>>>> string-expression: https://issues.apache.org/jira/browse/FLINK-1032
>>>>>   - *Reworked Scala API*. Bring the Scala API in sync with the latest
>>>>> developments in the Java API:
>>>>> https://issues.apache.org/jira/browse/FLINK-641
>>>>>   -* Akka-based RPC service*:
>>>>> https://issues.apache.org/jira/browse/FLINK-1019
>>>>>   - *Kryo-based serialization*. This feature has been requested by many
>>>>> users. Mostly because they wanted to use Collections inside POJOs:
>>>>> https://issues.apache.org/jira/browse/FLINK-610
>>>>> - Rework JobManager internals to support incremental program rollout &
>>>>> execution
>>>>> - First parts of dynamic memory assignments
>>>>>
>>>>> The following features are in the master, as of today:
>>>>> - *Flink Streaming*
>>>>> - *Reworked Scala API*
>>>>> -* New Scheduler*
>>>>>
>>>>> We certainly need some days to test everything until we can start the
>>>>>
>>>> vote.
>>>>
>>>>> Based on our experience with the last major release, I would really
>>>>>
>>>> like
>>>
>>>> to
>>>>
>>>>> do the testing and bugfixing BEFORE the first release candidate. For
>>>>>
>>>> the
>>>
>>>> 0.6-incubating release, we had 6  candidates)
>>>>>
>>>>> How do you guys feel about this? Should we wait a few more days for the
>>>>> release so that a few more features make it into the release?
>>>>>
>>>>> I'm undecided on this. On the one hand, its really nice to release on a
>>>>> regular schedule, but it also eats up some time and causes overhead
>>>>> (different branches etc.).
>>>>> I would really like to have the Java API Pojo improvements in the
>>>>>
>>>> release.
>>>>
>>>>> I think I can finish it until end of this week.
>>>>>
>>>>> Opinions?
>>>>>
>>>> I agree that the finished features (especially the Scala API) are nice
>>>>
>>> for
>>>
>>>> a new release, but still I would like to wait a few more days.
>>>>
>>>> Some of the missing features are on the brink of being finished (e.g.
>>>> the
>>>> Pojo improvements). I wouldn't want to invest a week in bug fixing and
>>>> doing the release vote, when the new features are likely to be finished
>>>> just a few days afterwards. And the upcoming features will definitely be
>>>> worth a release, so users can work with them. ;)
>>>>
>>>
>

[Aljoscha Krettek-2]

Can we not manage this stuff on Jira?

On Fri, Sep 26, 2014 at 10:16 AM, Stephan Ewen <[hidden email]> wrote:

> I personally like the idea of SOFT time-based feature freezes. Otherwise,
> releases will get delayed again and again, because of features that we try
> to squeeze in.
>
> Having reached the freeze point already, we could still include the
> features that are pending ready state in the next days (streaming, blob
> Manager, POJOs), but otherwise head for a release state.
>
> We had a mail listing the issues to include into 0.7, but a wiki page would
> probably be better. In that sense, we could start collecting the issues for
> the next release from now on.
>  Am 26.09.2014 09:17 schrieb "Daniel Warneke" <[hidden email]>:
>
>> Hi,
>>
>> I like Fabian's idea. Is there a wiki page (or something similar) where we
>> can collect the proposed JIRAs?
>>
>> Best regards,
>>
>>     Daniel
>>
>> Am 24.09.2014 23:03, schrieb Fabian Hueske:
>>
>>> I agree, a hard feature stop deadline might not be the best practice.
>>>
>>> How about the following procedure:
>>> We decide two (or three) weeks before a targeted release date about which
>>> JIRAs to include. JIRAs that are selected for a release should be
>>> completed
>>> or really close to completion (via progress estimates in JIRA).
>>> After we decided which JIRAs to include in a release, we can use JIRA to
>>> track the progress and dedicate another week exclusively for testing after
>>> the last feature was completed.
>>>
>>>
>>> 2014-09-24 19:10 GMT+02:00 Márton Balassi <[hidden email]>:
>>>
>>>  As for the streaming team we're also getting ready for the release, but a
>>>> couple of days will be needed to finish the features that we would like
>>>> to
>>>> include.
>>>>
>>>>     - A little work is still needed for reduce operations and
>>>>     groups/connected streams (any comment on Gyula's recent e-mail is
>>>> really
>>>>     appreciated :) )
>>>>     - The examples are being updated to match the standard, check out the
>>>>     WordCount. (
>>>>
>>>> https://github.com/mbalassi/incubator-flink/blob/
>>>> streaming-new/flink-addons/flink-streaming/flink-
>>>> streaming-examples/src/main/java/org/apache/flink/
>>>> streaming/examples/wordcount/WordCount.java
>>>> )
>>>>     Hopefully it gives you some deja vu. :)
>>>>
>>>>
>>>> On Wed, Sep 24, 2014 at 6:53 PM, Ufuk Celebi <[hidden email]> wrote:
>>>>
>>>>  On 24 Sep 2014, at 18:37, Robert Metzger <[hidden email]> wrote:
>>>>>
>>>>>  Hey guys,
>>>>>>
>>>>>> exactly 3 weeks ago, we discussed to do a feature freeze for the
>>>>>> 0.7-incubating release today.
>>>>>>
>>>>>>  From our initial feature list:
>>>>>> - *Flink Streaming* "Beta Preview". I would suggest to ship the
>>>>>>
>>>>> streaming,
>>>>>
>>>>>> but clearly mark it as a preview in the documentation.
>>>>>> -* Java API Pojo improvements*: Code generation, key selection using a
>>>>>> string-expression: https://issues.apache.org/jira/browse/FLINK-1032
>>>>>>   - *Reworked Scala API*. Bring the Scala API in sync with the latest
>>>>>> developments in the Java API:
>>>>>> https://issues.apache.org/jira/browse/FLINK-641
>>>>>>   -* Akka-based RPC service*:
>>>>>> https://issues.apache.org/jira/browse/FLINK-1019
>>>>>>   - *Kryo-based serialization*. This feature has been requested by many
>>>>>> users. Mostly because they wanted to use Collections inside POJOs:
>>>>>> https://issues.apache.org/jira/browse/FLINK-610
>>>>>> - Rework JobManager internals to support incremental program rollout &
>>>>>> execution
>>>>>> - First parts of dynamic memory assignments
>>>>>>
>>>>>> The following features are in the master, as of today:
>>>>>> - *Flink Streaming*
>>>>>> - *Reworked Scala API*
>>>>>> -* New Scheduler*
>>>>>>
>>>>>> We certainly need some days to test everything until we can start the
>>>>>>
>>>>> vote.
>>>>>
>>>>>> Based on our experience with the last major release, I would really
>>>>>>
>>>>> like
>>>>
>>>>> to
>>>>>
>>>>>> do the testing and bugfixing BEFORE the first release candidate. For
>>>>>>
>>>>> the
>>>>
>>>>> 0.6-incubating release, we had 6  candidates)
>>>>>>
>>>>>> How do you guys feel about this? Should we wait a few more days for the
>>>>>> release so that a few more features make it into the release?
>>>>>>
>>>>>> I'm undecided on this. On the one hand, its really nice to release on a
>>>>>> regular schedule, but it also eats up some time and causes overhead
>>>>>> (different branches etc.).
>>>>>> I would really like to have the Java API Pojo improvements in the
>>>>>>
>>>>> release.
>>>>>
>>>>>> I think I can finish it until end of this week.
>>>>>>
>>>>>> Opinions?
>>>>>>
>>>>> I agree that the finished features (especially the Scala API) are nice
>>>>>
>>>> for
>>>>
>>>>> a new release, but still I would like to wait a few more days.
>>>>>
>>>>> Some of the missing features are on the brink of being finished (e.g.
>>>>> the
>>>>> Pojo improvements). I wouldn't want to invest a week in bug fixing and
>>>>> doing the release vote, when the new features are likely to be finished
>>>>> just a few days afterwards. And the upcoming features will definitely be
>>>>> worth a release, so users can work with them. ;)
>>>>>
>>>>
>>