[DISCUSSION] Release current master as 0.9.1 (mod few changes)

[Stephan Ewen]

Hi all!

I have started to try and backport some of the bugfixes on the latest
master to the 0.9 branch, to be part of the 0.9.1 bugfixing release.

While doing this, I came across so many places where critical bugs were
fixed as parts of larger refactorings. It is very hard to backport these
bug fixes without applying the refactorings as well.
These bug fixes include deadlocks in co-tasks (streaming), deadlocks in the
checkpointing, error handling and canceling of streaming programs. In
general, the cleanup work in the streaming API has been very intensive.

I was wondering whether we should not fork the 0.9.1 release from the
current master. There have been few API breaking changes so far, which
would be easier to undo than to backport all the fixes.

We could do the following:

  - Fork off 0.9.1 off master and continue with all high-availability work
in the master

  - Remove all code related to the new webfrontend from the 0.9.1 branch

  - Undo the few API breaking changes, such as Gelly and Scala API
modifications, to keep major version compatibility.


Concerning the question "why not release master as 0.10": We have had a set
of announcements concerning streaming graduation and HA in 0.10, which we
would break if we release the current state as 0.10.

Greetings,
Stephan

[Liang Chen]

CONTENTS DELETED

The author has deleted this message.

[Ufuk Celebi-2]

I think you are the best one to assess this at the moment since you are
doing the hard work of back porting the changes.

Are you suggesting this, because it is a) less error-prone/easier or b)
faster to do?

For those that haven't followed the discussion: Stephan is back porting
fixes for the streaming fault tolerance. There is consensus that the
changes need to be in the bug fix release. So it's definitely not an option
to skip it.

In general I would like to keep our established process of back porting
fixes to the release-X branch. But given the importance of the to be back
ported fixes and the difficulty of back porting it, I think your suggestion
is reasonable. We have to be very careful to not change behaviour between
minor releases though.

We also have to think about the following points if we fork off from master:
- The startup script behaviour has changed
- HA ZooKeeper setup needs to be removed

[Stephan Ewen]

We can also try and "rebase" a fork of the maser to the "0.9" branch, where
we select something like 70%-80% of the commits (all fixes and reworks) and
drop the API beaking ones.

Let me try this and see how feasible it is...

On Wed, Aug 26, 2015 at 9:52 AM, Ufuk Celebi <[hidden email]> wrote:

> I think you are the best one to assess this at the moment since you are
> doing the hard work of back porting the changes.
>
> Are you suggesting this, because it is a) less error-prone/easier or b)
> faster to do?
>
> For those that haven't followed the discussion: Stephan is back porting
> fixes for the streaming fault tolerance. There is consensus that the
> changes need to be in the bug fix release. So it's definitely not an option
> to skip it.
>
> In general I would like to keep our established process of back porting
> fixes to the release-X branch. But given the importance of the to be back
> ported fixes and the difficulty of back porting it, I think your suggestion
> is reasonable. We have to be very careful to not change behaviour between
> minor releases though.
>
> We also have to think about the following points if we fork off from
> master:
> - The startup script behaviour has changed
> - HA ZooKeeper setup needs to be removed
>

[Fabian Hueske-2]

I am a bit skeptical about this proposal. A bug fix release should not
change the interface and semantics of the API.
It might be possible to catch the interface changes, but it will be really
hard to ensure that the semantics are not touched.

I see that there are many important fixes in the current master, but I
think it is not a good idea to sacrifice API stability for fixes in a minor
release.
If we can ensure that the API interface and semantics remain stable, I
would be OK with using the master.

Even though it does not help with the current issue, we should pay more
attention to backporting fixes in the future.

2015-08-26 10:24 GMT+02:00 Stephan Ewen <[hidden email]>:

> We can also try and "rebase" a fork of the maser to the "0.9" branch, where
> we select something like 70%-80% of the commits (all fixes and reworks) and
> drop the API beaking ones.
>
> Let me try this and see how feasible it is...
>
> On Wed, Aug 26, 2015 at 9:52 AM, Ufuk Celebi <[hidden email]> wrote:
>
> > I think you are the best one to assess this at the moment since you are
> > doing the hard work of back porting the changes.
> >
> > Are you suggesting this, because it is a) less error-prone/easier or b)
> > faster to do?
> >
> > For those that haven't followed the discussion: Stephan is back porting
> > fixes for the streaming fault tolerance. There is consensus that the
> > changes need to be in the bug fix release. So it's definitely not an
> option
> > to skip it.
> >
> > In general I would like to keep our established process of back porting
> > fixes to the release-X branch. But given the importance of the to be back
> > ported fixes and the difficulty of back porting it, I think your
> suggestion
> > is reasonable. We have to be very careful to not change behaviour between
> > minor releases though.
> >
> > We also have to think about the following points if we fork off from
> > master:
> > - The startup script behaviour has changed
> > - HA ZooKeeper setup needs to be removed
> >
>

[Aljoscha Krettek-2]

I don't think we had to many API breaking changes. If everyone was careful,
maybe these are even it:
https://cwiki.apache.org/confluence/display/FLINK/0.10+Release

I added my breaking stuff there. And of course the whole Timestamp thing is
a change, but it does not affect the normal source interface.

On Wed, 26 Aug 2015 at 10:24 Stephan Ewen <[hidden email]> wrote:

> We can also try and "rebase" a fork of the maser to the "0.9" branch, where
> we select something like 70%-80% of the commits (all fixes and reworks) and
> drop the API beaking ones.
>
> Let me try this and see how feasible it is...
>
> On Wed, Aug 26, 2015 at 9:52 AM, Ufuk Celebi <[hidden email]> wrote:
>
> > I think you are the best one to assess this at the moment since you are
> > doing the hard work of back porting the changes.
> >
> > Are you suggesting this, because it is a) less error-prone/easier or b)
> > faster to do?
> >
> > For those that haven't followed the discussion: Stephan is back porting
> > fixes for the streaming fault tolerance. There is consensus that the
> > changes need to be in the bug fix release. So it's definitely not an
> option
> > to skip it.
> >
> > In general I would like to keep our established process of back porting
> > fixes to the release-X branch. But given the importance of the to be back
> > ported fixes and the difficulty of back porting it, I think your
> suggestion
> > is reasonable. We have to be very careful to not change behaviour between
> > minor releases though.
> >
> > We also have to think about the following points if we fork off from
> > master:
> > - The startup script behaviour has changed
> > - HA ZooKeeper setup needs to be removed
> >
>

[Stephan Ewen]

The timestamp thing is one of the biggest questions.

The fixes that came as part of that pull request are crucial and hard to
pull out of the change.

On Wed, Aug 26, 2015 at 10:44 AM, Aljoscha Krettek <[hidden email]>
wrote:

> I don't think we had to many API breaking changes. If everyone was careful,
> maybe these are even it:
> https://cwiki.apache.org/confluence/display/FLINK/0.10+Release
>
> I added my breaking stuff there. And of course the whole Timestamp thing is
> a change, but it does not affect the normal source interface.
>
> On Wed, 26 Aug 2015 at 10:24 Stephan Ewen <[hidden email]> wrote:
>
> > We can also try and "rebase" a fork of the maser to the "0.9" branch,
> where
> > we select something like 70%-80% of the commits (all fixes and reworks)
> and
> > drop the API beaking ones.
> >
> > Let me try this and see how feasible it is...
> >
> > On Wed, Aug 26, 2015 at 9:52 AM, Ufuk Celebi <[hidden email]> wrote:
> >
> > > I think you are the best one to assess this at the moment since you are
> > > doing the hard work of back porting the changes.
> > >
> > > Are you suggesting this, because it is a) less error-prone/easier or b)
> > > faster to do?
> > >
> > > For those that haven't followed the discussion: Stephan is back porting
> > > fixes for the streaming fault tolerance. There is consensus that the
> > > changes need to be in the bug fix release. So it's definitely not an
> > option
> > > to skip it.
> > >
> > > In general I would like to keep our established process of back porting
> > > fixes to the release-X branch. But given the importance of the to be
> back
> > > ported fixes and the difficulty of back porting it, I think your
> > suggestion
> > > is reasonable. We have to be very careful to not change behaviour
> between
> > > minor releases though.
> > >
> > > We also have to think about the following points if we fork off from
> > > master:
> > > - The startup script behaviour has changed
> > > - HA ZooKeeper setup needs to be removed
> > >
> >
>

[Stephan Ewen]

@Aljoscha: Correct me if I am wrong, but did the change actually break
anything user facing?

The source function and source context interface look still the same. The
underlying changes to introduce watermarks should not be visible to any
user anyways at this point (if we remove the additional source contexts)

On Wed, Aug 26, 2015 at 10:46 AM, Stephan Ewen <[hidden email]> wrote:

> The timestamp thing is one of the biggest questions.
>
> The fixes that came as part of that pull request are crucial and hard to
> pull out of the change.
>
> On Wed, Aug 26, 2015 at 10:44 AM, Aljoscha Krettek <[hidden email]>
> wrote:
>
>> I don't think we had to many API breaking changes. If everyone was
>> careful,
>> maybe these are even it:
>> https://cwiki.apache.org/confluence/display/FLINK/0.10+Release
>>
>> I added my breaking stuff there. And of course the whole Timestamp thing
>> is
>> a change, but it does not affect the normal source interface.
>>
>> On Wed, 26 Aug 2015 at 10:24 Stephan Ewen <[hidden email]> wrote:
>>
>> > We can also try and "rebase" a fork of the maser to the "0.9" branch,
>> where
>> > we select something like 70%-80% of the commits (all fixes and reworks)
>> and
>> > drop the API beaking ones.
>> >
>> > Let me try this and see how feasible it is...
>> >
>> > On Wed, Aug 26, 2015 at 9:52 AM, Ufuk Celebi <[hidden email]> wrote:
>> >
>> > > I think you are the best one to assess this at the moment since you
>> are
>> > > doing the hard work of back porting the changes.
>> > >
>> > > Are you suggesting this, because it is a) less error-prone/easier or
>> b)
>> > > faster to do?
>> > >
>> > > For those that haven't followed the discussion: Stephan is back
>> porting
>> > > fixes for the streaming fault tolerance. There is consensus that the
>> > > changes need to be in the bug fix release. So it's definitely not an
>> > option
>> > > to skip it.
>> > >
>> > > In general I would like to keep our established process of back
>> porting
>> > > fixes to the release-X branch. But given the importance of the to be
>> back
>> > > ported fixes and the difficulty of back porting it, I think your
>> > suggestion
>> > > is reasonable. We have to be very careful to not change behaviour
>> between
>> > > minor releases though.
>> > >
>> > > We also have to think about the following points if we fork off from
>> > > master:
>> > > - The startup script behaviour has changed
>> > > - HA ZooKeeper setup needs to be removed
>> > >
>> >
>>
>
>

[mxm]

A bugfix release should not be forked from the current master. It is
very hard to asses whether we don't break the API because there are
many small fixes going in almost daily. However, I can see applying a
subset of carefully selected commits from the master branch as an
option. Only those commits should be cherry-picked which are required
to fix the streaming issues.

On Wed, Aug 26, 2015 at 10:50 AM, Stephan Ewen <[hidden email]> wrote:

> @Aljoscha: Correct me if I am wrong, but did the change actually break
> anything user facing?
>
> The source function and source context interface look still the same. The
> underlying changes to introduce watermarks should not be visible to any
> user anyways at this point (if we remove the additional source contexts)
>
> On Wed, Aug 26, 2015 at 10:46 AM, Stephan Ewen <[hidden email]> wrote:
>
>> The timestamp thing is one of the biggest questions.
>>
>> The fixes that came as part of that pull request are crucial and hard to
>> pull out of the change.
>>
>> On Wed, Aug 26, 2015 at 10:44 AM, Aljoscha Krettek <[hidden email]>
>> wrote:
>>
>>> I don't think we had to many API breaking changes. If everyone was
>>> careful,
>>> maybe these are even it:
>>> https://cwiki.apache.org/confluence/display/FLINK/0.10+Release
>>>
>>> I added my breaking stuff there. And of course the whole Timestamp thing
>>> is
>>> a change, but it does not affect the normal source interface.
>>>
>>> On Wed, 26 Aug 2015 at 10:24 Stephan Ewen <[hidden email]> wrote:
>>>
>>> > We can also try and "rebase" a fork of the maser to the "0.9" branch,
>>> where
>>> > we select something like 70%-80% of the commits (all fixes and reworks)
>>> and
>>> > drop the API beaking ones.
>>> >
>>> > Let me try this and see how feasible it is...
>>> >
>>> > On Wed, Aug 26, 2015 at 9:52 AM, Ufuk Celebi <[hidden email]> wrote:
>>> >
>>> > > I think you are the best one to assess this at the moment since you
>>> are
>>> > > doing the hard work of back porting the changes.
>>> > >
>>> > > Are you suggesting this, because it is a) less error-prone/easier or
>>> b)
>>> > > faster to do?
>>> > >
>>> > > For those that haven't followed the discussion: Stephan is back
>>> porting
>>> > > fixes for the streaming fault tolerance. There is consensus that the
>>> > > changes need to be in the bug fix release. So it's definitely not an
>>> > option
>>> > > to skip it.
>>> > >
>>> > > In general I would like to keep our established process of back
>>> porting
>>> > > fixes to the release-X branch. But given the importance of the to be
>>> back
>>> > > ported fixes and the difficulty of back porting it, I think your
>>> > suggestion
>>> > > is reasonable. We have to be very careful to not change behaviour
>>> between
>>> > > minor releases though.
>>> > >
>>> > > We also have to think about the following points if we fork off from
>>> > > master:
>>> > > - The startup script behaviour has changed
>>> > > - HA ZooKeeper setup needs to be removed
>>> > >
>>> >
>>>
>>
>>

[Stephan Ewen]

@mxm: I know the textbook theory ;-)

The whole point here is that it is not possible to do that. Fixes and major
reworks changes go together so tightly that you can get none or both.

Not having the fixes voids the purpose of the bugfix release. Having both
means it is hard to guarantee all changes are non-breaking.

On Wed, Aug 26, 2015 at 11:08 AM, Maximilian Michels <[hidden email]> wrote:

> A bugfix release should not be forked from the current master. It is
> very hard to asses whether we don't break the API because there are
> many small fixes going in almost daily. However, I can see applying a
> subset of carefully selected commits from the master branch as an
> option. Only those commits should be cherry-picked which are required
> to fix the streaming issues.
>
> On Wed, Aug 26, 2015 at 10:50 AM, Stephan Ewen <[hidden email]> wrote:
> > @Aljoscha: Correct me if I am wrong, but did the change actually break
> > anything user facing?
> >
> > The source function and source context interface look still the same. The
> > underlying changes to introduce watermarks should not be visible to any
> > user anyways at this point (if we remove the additional source contexts)
> >
> > On Wed, Aug 26, 2015 at 10:46 AM, Stephan Ewen <[hidden email]> wrote:
> >
> >> The timestamp thing is one of the biggest questions.
> >>
> >> The fixes that came as part of that pull request are crucial and hard to
> >> pull out of the change.
> >>
> >> On Wed, Aug 26, 2015 at 10:44 AM, Aljoscha Krettek <[hidden email]
> >
> >> wrote:
> >>
> >>> I don't think we had to many API breaking changes. If everyone was
> >>> careful,
> >>> maybe these are even it:
> >>> https://cwiki.apache.org/confluence/display/FLINK/0.10+Release
> >>>
> >>> I added my breaking stuff there. And of course the whole Timestamp
> thing
> >>> is
> >>> a change, but it does not affect the normal source interface.
> >>>
> >>> On Wed, 26 Aug 2015 at 10:24 Stephan Ewen <[hidden email]> wrote:
> >>>
> >>> > We can also try and "rebase" a fork of the maser to the "0.9" branch,
> >>> where
> >>> > we select something like 70%-80% of the commits (all fixes and
> reworks)
> >>> and
> >>> > drop the API beaking ones.
> >>> >
> >>> > Let me try this and see how feasible it is...
> >>> >
> >>> > On Wed, Aug 26, 2015 at 9:52 AM, Ufuk Celebi <[hidden email]> wrote:
> >>> >
> >>> > > I think you are the best one to assess this at the moment since you
> >>> are
> >>> > > doing the hard work of back porting the changes.
> >>> > >
> >>> > > Are you suggesting this, because it is a) less error-prone/easier
> or
> >>> b)
> >>> > > faster to do?
> >>> > >
> >>> > > For those that haven't followed the discussion: Stephan is back
> >>> porting
> >>> > > fixes for the streaming fault tolerance. There is consensus that
> the
> >>> > > changes need to be in the bug fix release. So it's definitely not
> an
> >>> > option
> >>> > > to skip it.
> >>> > >
> >>> > > In general I would like to keep our established process of back
> >>> porting
> >>> > > fixes to the release-X branch. But given the importance of the to
> be
> >>> back
> >>> > > ported fixes and the difficulty of back porting it, I think your
> >>> > suggestion
> >>> > > is reasonable. We have to be very careful to not change behaviour
> >>> between
> >>> > > minor releases though.
> >>> > >
> >>> > > We also have to think about the following points if we fork off
> from
> >>> > > master:
> >>> > > - The startup script behaviour has changed
> >>> > > - HA ZooKeeper setup needs to be removed
> >>> > >
> >>> >
> >>>
> >>
> >>
>

[mxm]

I might not have made my point clear but I wrote:

>However, I can see applying a subset of carefully selected commits from the
>master branch as an option.

And you wrote:

>We can also try and "rebase" a fork of the maser to the "0.9" branch, where
>we select something like 70%-80% of the commits (all fixes and reworks) and
>drop the API beaking ones.

So we essentially agree on this issue. Or not?

Forking the entire branch is not an option for me for the 0.9.1
release. I think we could do an 0.10 release since we never decided
0.10 would freeze the streaming API. These are just statements by
individual committers and do not represent the community's opinion.



On Wed, Aug 26, 2015 at 11:12 AM, Stephan Ewen <[hidden email]> wrote:

> @mxm: I know the textbook theory ;-)
>
> The whole point here is that it is not possible to do that. Fixes and major
> reworks changes go together so tightly that you can get none or both.
>
> Not having the fixes voids the purpose of the bugfix release. Having both
> means it is hard to guarantee all changes are non-breaking.
>
> On Wed, Aug 26, 2015 at 11:08 AM, Maximilian Michels <[hidden email]> wrote:
>
>> A bugfix release should not be forked from the current master. It is
>> very hard to asses whether we don't break the API because there are
>> many small fixes going in almost daily. However, I can see applying a
>> subset of carefully selected commits from the master branch as an
>> option. Only those commits should be cherry-picked which are required
>> to fix the streaming issues.
>>
>> On Wed, Aug 26, 2015 at 10:50 AM, Stephan Ewen <[hidden email]> wrote:
>> > @Aljoscha: Correct me if I am wrong, but did the change actually break
>> > anything user facing?
>> >
>> > The source function and source context interface look still the same. The
>> > underlying changes to introduce watermarks should not be visible to any
>> > user anyways at this point (if we remove the additional source contexts)
>> >
>> > On Wed, Aug 26, 2015 at 10:46 AM, Stephan Ewen <[hidden email]> wrote:
>> >
>> >> The timestamp thing is one of the biggest questions.
>> >>
>> >> The fixes that came as part of that pull request are crucial and hard to
>> >> pull out of the change.
>> >>
>> >> On Wed, Aug 26, 2015 at 10:44 AM, Aljoscha Krettek <[hidden email]
>> >
>> >> wrote:
>> >>
>> >>> I don't think we had to many API breaking changes. If everyone was
>> >>> careful,
>> >>> maybe these are even it:
>> >>> https://cwiki.apache.org/confluence/display/FLINK/0.10+Release
>> >>>
>> >>> I added my breaking stuff there. And of course the whole Timestamp
>> thing
>> >>> is
>> >>> a change, but it does not affect the normal source interface.
>> >>>
>> >>> On Wed, 26 Aug 2015 at 10:24 Stephan Ewen <[hidden email]> wrote:
>> >>>
>> >>> > We can also try and "rebase" a fork of the maser to the "0.9" branch,
>> >>> where
>> >>> > we select something like 70%-80% of the commits (all fixes and
>> reworks)
>> >>> and
>> >>> > drop the API beaking ones.
>> >>> >
>> >>> > Let me try this and see how feasible it is...
>> >>> >
>> >>> > On Wed, Aug 26, 2015 at 9:52 AM, Ufuk Celebi <[hidden email]> wrote:
>> >>> >
>> >>> > > I think you are the best one to assess this at the moment since you
>> >>> are
>> >>> > > doing the hard work of back porting the changes.
>> >>> > >
>> >>> > > Are you suggesting this, because it is a) less error-prone/easier
>> or
>> >>> b)
>> >>> > > faster to do?
>> >>> > >
>> >>> > > For those that haven't followed the discussion: Stephan is back
>> >>> porting
>> >>> > > fixes for the streaming fault tolerance. There is consensus that
>> the
>> >>> > > changes need to be in the bug fix release. So it's definitely not
>> an
>> >>> > option
>> >>> > > to skip it.
>> >>> > >
>> >>> > > In general I would like to keep our established process of back
>> >>> porting
>> >>> > > fixes to the release-X branch. But given the importance of the to
>> be
>> >>> back
>> >>> > > ported fixes and the difficulty of back porting it, I think your
>> >>> > suggestion
>> >>> > > is reasonable. We have to be very careful to not change behaviour
>> >>> between
>> >>> > > minor releases though.
>> >>> > >
>> >>> > > We also have to think about the following points if we fork off
>> from
>> >>> > > master:
>> >>> > > - The startup script behaviour has changed
>> >>> > > - HA ZooKeeper setup needs to be removed
>> >>> > >
>> >>> >
>> >>>
>> >>
>> >>
>>

[Robert Metzger]

I'm against using the current master for 0.9.1.
It contains too many changes, posing the risk of changing APIs/semantics/...
I agree with Max that there was no consensus or discussion regarding the
scope of the 0.10 release.

How about we release a 0.9.1 version containing all fixes we can easily
apply to the release-0.9 branch and a 0.10-milestone1 off our current
"master".

Ideally we release 0.10-milestone1 before merging new major changes such as
master high availablilty.





On Wed, Aug 26, 2015 at 11:42 AM, Maximilian Michels <[hidden email]> wrote:

> I might not have made my point clear but I wrote:
>
> >However, I can see applying a subset of carefully selected commits from
> the
> >master branch as an option.
>
> And you wrote:
>
> >We can also try and "rebase" a fork of the maser to the "0.9" branch,
> where
> >we select something like 70%-80% of the commits (all fixes and reworks)
> and
> >drop the API beaking ones.
>
> So we essentially agree on this issue. Or not?
>
> Forking the entire branch is not an option for me for the 0.9.1
> release. I think we could do an 0.10 release since we never decided
> 0.10 would freeze the streaming API. These are just statements by
> individual committers and do not represent the community's opinion.
>
>
>
> On Wed, Aug 26, 2015 at 11:12 AM, Stephan Ewen <[hidden email]> wrote:
> > @mxm: I know the textbook theory ;-)
> >
> > The whole point here is that it is not possible to do that. Fixes and
> major
> > reworks changes go together so tightly that you can get none or both.
> >
> > Not having the fixes voids the purpose of the bugfix release. Having both
> > means it is hard to guarantee all changes are non-breaking.
> >
> > On Wed, Aug 26, 2015 at 11:08 AM, Maximilian Michels <[hidden email]>
> wrote:
> >
> >> A bugfix release should not be forked from the current master. It is
> >> very hard to asses whether we don't break the API because there are
> >> many small fixes going in almost daily. However, I can see applying a
> >> subset of carefully selected commits from the master branch as an
> >> option. Only those commits should be cherry-picked which are required
> >> to fix the streaming issues.
> >>
> >> On Wed, Aug 26, 2015 at 10:50 AM, Stephan Ewen <[hidden email]>
> wrote:
> >> > @Aljoscha: Correct me if I am wrong, but did the change actually break
> >> > anything user facing?
> >> >
> >> > The source function and source context interface look still the same.
> The
> >> > underlying changes to introduce watermarks should not be visible to
> any
> >> > user anyways at this point (if we remove the additional source
> contexts)
> >> >
> >> > On Wed, Aug 26, 2015 at 10:46 AM, Stephan Ewen <[hidden email]>
> wrote:
> >> >
> >> >> The timestamp thing is one of the biggest questions.
> >> >>
> >> >> The fixes that came as part of that pull request are crucial and
> hard to
> >> >> pull out of the change.
> >> >>
> >> >> On Wed, Aug 26, 2015 at 10:44 AM, Aljoscha Krettek <
> [hidden email]
> >> >
> >> >> wrote:
> >> >>
> >> >>> I don't think we had to many API breaking changes. If everyone was
> >> >>> careful,
> >> >>> maybe these are even it:
> >> >>> https://cwiki.apache.org/confluence/display/FLINK/0.10+Release
> >> >>>
> >> >>> I added my breaking stuff there. And of course the whole Timestamp
> >> thing
> >> >>> is
> >> >>> a change, but it does not affect the normal source interface.
> >> >>>
> >> >>> On Wed, 26 Aug 2015 at 10:24 Stephan Ewen <[hidden email]> wrote:
> >> >>>
> >> >>> > We can also try and "rebase" a fork of the maser to the "0.9"
> branch,
> >> >>> where
> >> >>> > we select something like 70%-80% of the commits (all fixes and
> >> reworks)
> >> >>> and
> >> >>> > drop the API beaking ones.
> >> >>> >
> >> >>> > Let me try this and see how feasible it is...
> >> >>> >
> >> >>> > On Wed, Aug 26, 2015 at 9:52 AM, Ufuk Celebi <[hidden email]>
> wrote:
> >> >>> >
> >> >>> > > I think you are the best one to assess this at the moment since
> you
> >> >>> are
> >> >>> > > doing the hard work of back porting the changes.
> >> >>> > >
> >> >>> > > Are you suggesting this, because it is a) less
> error-prone/easier
> >> or
> >> >>> b)
> >> >>> > > faster to do?
> >> >>> > >
> >> >>> > > For those that haven't followed the discussion: Stephan is back
> >> >>> porting
> >> >>> > > fixes for the streaming fault tolerance. There is consensus that
> >> the
> >> >>> > > changes need to be in the bug fix release. So it's definitely
> not
> >> an
> >> >>> > option
> >> >>> > > to skip it.
> >> >>> > >
> >> >>> > > In general I would like to keep our established process of back
> >> >>> porting
> >> >>> > > fixes to the release-X branch. But given the importance of the
> to
> >> be
> >> >>> back
> >> >>> > > ported fixes and the difficulty of back porting it, I think your
> >> >>> > suggestion
> >> >>> > > is reasonable. We have to be very careful to not change
> behaviour
> >> >>> between
> >> >>> > > minor releases though.
> >> >>> > >
> >> >>> > > We also have to think about the following points if we fork off
> >> from
> >> >>> > > master:
> >> >>> > > - The startup script behaviour has changed
> >> >>> > > - HA ZooKeeper setup needs to be removed
> >> >>> > >
> >> >>> >
> >> >>>
> >> >>
> >> >>
> >>
>

[Ufuk Celebi-2]

+1

I very much like Robert's suggestion. This way we can proceed with the
0.9.1 release as planned for the remaining part and have 0.10-milestone1
with the fix.

What about the others? Please give feedback early to allow me to proceed
with the release.

[Fabian Hueske-2]

I'm +1 for Robert's proposal as well.

2015-08-26 14:46 GMT+02:00 Ufuk Celebi <[hidden email]>:

> +1
>
> I very much like Robert's suggestion. This way we can proceed with the
> 0.9.1 release as planned for the remaining part and have 0.10-milestone1
> with the fix.
>
> What about the others? Please give feedback early to allow me to proceed
> with the release.
>

[Kostas Tzoumas-2]

+1 for Robert's proposal


On Wed, Aug 26, 2015 at 2:48 PM, Fabian Hueske <[hidden email]> wrote:

> I'm +1 for Robert's proposal as well.
>
> 2015-08-26 14:46 GMT+02:00 Ufuk Celebi <[hidden email]>:
>
> > +1
> >
> > I very much like Robert's suggestion. This way we can proceed with the
> > 0.9.1 release as planned for the remaining part and have 0.10-milestone1
> > with the fix.
> >
> > What about the others? Please give feedback early to allow me to proceed
> > with the release.
> >
>

[Stephan Ewen]

That sounds like a very good compromise.

+1

On Wed, Aug 26, 2015 at 2:48 PM, Fabian Hueske <[hidden email]> wrote:

> I'm +1 for Robert's proposal as well.
>
> 2015-08-26 14:46 GMT+02:00 Ufuk Celebi <[hidden email]>:
>
> > +1
> >
> > I very much like Robert's suggestion. This way we can proceed with the
> > 0.9.1 release as planned for the remaining part and have 0.10-milestone1
> > with the fix.
> >
> > What about the others? Please give feedback early to allow me to proceed
> > with the release.
> >
>

[Aljoscha Krettek-2]

+1 seems to be a viable solution

On Wed, 26 Aug 2015 at 14:51 Stephan Ewen <[hidden email]> wrote:

> That sounds like a very good compromise.
>
> +1
>
> On Wed, Aug 26, 2015 at 2:48 PM, Fabian Hueske <[hidden email]> wrote:
>
> > I'm +1 for Robert's proposal as well.
> >
> > 2015-08-26 14:46 GMT+02:00 Ufuk Celebi <[hidden email]>:
> >
> > > +1
> > >
> > > I very much like Robert's suggestion. This way we can proceed with the
> > > 0.9.1 release as planned for the remaining part and have
> 0.10-milestone1
> > > with the fix.
> > >
> > > What about the others? Please give feedback early to allow me to
> proceed
> > > with the release.
> > >
> >
>

[Chiwan Park]

Robert's suggestion looks good. +1

Sent from my iPhone

> On Aug 26, 2015, at 9:55 PM, Aljoscha Krettek <[hidden email]> wrote:
>
> +1 seems to be a viable solution
>
>> On Wed, 26 Aug 2015 at 14:51 Stephan Ewen <[hidden email]> wrote:
>>
>> That sounds like a very good compromise.
>>
>> +1
>>
>>> On Wed, Aug 26, 2015 at 2:48 PM, Fabian Hueske <[hidden email]> wrote:
>>>
>>> I'm +1 for Robert's proposal as well.
>>>
>>> 2015-08-26 14:46 GMT+02:00 Ufuk Celebi <[hidden email]>:
>>>
>>>> +1
>>>>
>>>> I very much like Robert's suggestion. This way we can proceed with the
>>>> 0.9.1 release as planned for the remaining part and have
>> 0.10-milestone1
>>>> with the fix.
>>>>
>>>> What about the others? Please give feedback early to allow me to
>> proceed
>>>> with the release.
>>>>
>>>
>>

[mxm]

We will have a proper minor release and a preview of 0.10. After all,
a good compromise.

+1

On Wed, Aug 26, 2015 at 2:57 PM, Chiwan Park <[hidden email]> wrote:

> Robert's suggestion looks good. +1
>
> Sent from my iPhone
>
>> On Aug 26, 2015, at 9:55 PM, Aljoscha Krettek <[hidden email]> wrote:
>>
>> +1 seems to be a viable solution
>>
>>> On Wed, 26 Aug 2015 at 14:51 Stephan Ewen <[hidden email]> wrote:
>>>
>>> That sounds like a very good compromise.
>>>
>>> +1
>>>
>>>> On Wed, Aug 26, 2015 at 2:48 PM, Fabian Hueske <[hidden email]> wrote:
>>>>
>>>> I'm +1 for Robert's proposal as well.
>>>>
>>>> 2015-08-26 14:46 GMT+02:00 Ufuk Celebi <[hidden email]>:
>>>>
>>>>> +1
>>>>>
>>>>> I very much like Robert's suggestion. This way we can proceed with the
>>>>> 0.9.1 release as planned for the remaining part and have
>>> 0.10-milestone1
>>>>> with the fix.
>>>>>
>>>>> What about the others? Please give feedback early to allow me to
>>> proceed
>>>>> with the release.
>>>>>
>>>>
>>>

[Márton Balassi]

+1

On Wed, Aug 26, 2015 at 3:11 PM, Maximilian Michels <[hidden email]> wrote:

> We will have a proper minor release and a preview of 0.10. After all,
> a good compromise.
>
> +1
>
> On Wed, Aug 26, 2015 at 2:57 PM, Chiwan Park <[hidden email]>
> wrote:
> > Robert's suggestion looks good. +1
> >
> > Sent from my iPhone
> >
> >> On Aug 26, 2015, at 9:55 PM, Aljoscha Krettek <[hidden email]>
> wrote:
> >>
> >> +1 seems to be a viable solution
> >>
> >>> On Wed, 26 Aug 2015 at 14:51 Stephan Ewen <[hidden email]> wrote:
> >>>
> >>> That sounds like a very good compromise.
> >>>
> >>> +1
> >>>
> >>>> On Wed, Aug 26, 2015 at 2:48 PM, Fabian Hueske <[hidden email]>
> wrote:
> >>>>
> >>>> I'm +1 for Robert's proposal as well.
> >>>>
> >>>> 2015-08-26 14:46 GMT+02:00 Ufuk Celebi <[hidden email]>:
> >>>>
> >>>>> +1
> >>>>>
> >>>>> I very much like Robert's suggestion. This way we can proceed with
> the
> >>>>> 0.9.1 release as planned for the remaining part and have
> >>> 0.10-milestone1
> >>>>> with the fix.
> >>>>>
> >>>>> What about the others? Please give feedback early to allow me to
> >>> proceed
> >>>>> with the release.
> >>>>>
> >>>>
> >>>
>