[DISCUSS] Time-based releases in Flink

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[DISCUSS] Time-based releases in Flink

Robert Metzger
Hi all!

Since the 1.2.0 release is about to come out, I would like to propose a
change in the way we do releases in the Flink community.

In my opinion, the current model leads to dissatisfaction among users and
contributors, because releases are really not predictable. A recent example
for the issues with our current model are the FLIP-6 changes we wanted to
merge to master, a few weeks before the first RC for 1.2.0. Also, there
were some emails on the mailing lists asking for a release date.

In order to change that, I’m proposing to follow a strictly time-based
release model. Other open source projects like Ubuntu, Cassandra, Spark or
Kafka are following that model as well, and I think we should try it out as
an experiment for the 1.3.0 release.

I’m proposing to:

   -

   Do a Flink release every 4 months
   -

   Cycle:
   -

      3 months development
      -

      1 month before the release: Feature freeze. Create release branch
      with RC0, start testing. Only fixes, tests and minor improvements are
      allowed in.
      -

      2 weeks before the release: Code freeze. Start voting. Only fixes for
      blockers are allowed in.
      -

   Forbid blocking a release because a feature is not done yet.
   -

   Features are merged to master, when they are tested and documented, to
   have an always stable master
   -

   Bugfix releases are done as needed.
   -

   Old releases are supported for 6 months by the Flink community with
   critical bug fixes


This means, that we would have the following release dates:

(Flink 1.3.0 by end of January 2017)

 Flink 1.4.0 by end of May 2017

 Flink 1.5.0 by end of September 2017

 Flink 1.6.0 by end of January 2018

I’ve put some more details including some pro’s and con’s into our wiki.
The page is based on Kafka’s time-based release wiki page (Kafka also
recently started following a strictly time-based model)

https://cwiki.apache.org/confluence/display/FLINK/Time-based+releases


Once we’ve agreed on following that model, I’ll update the release plan
page accordingly:
https://cwiki.apache.org/confluence/display/FLINK/Flink+Release+and+Feature+Plan


Please let me know what you think about this idea!

Regards,

Robert
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Time-based releases in Flink

Fabian Hueske-2
In general, I like the idea of time-based releases.
For the development process this would mean, that we would need to fork off
feature branches and work on those until the feature can be merged back
into master.
We did that already in the past when porting the Table API to Apache
Calcite and for the FLIP-6 development.
For the Table API (where I was involved) that worked quite well, IMO.

@Robert, I think your release plan is off by 1 ;-)

Cheers, Fabian

2017-01-18 9:19 GMT+01:00 Robert Metzger <[hidden email]>:

> Hi all!
>
> Since the 1.2.0 release is about to come out, I would like to propose a
> change in the way we do releases in the Flink community.
>
> In my opinion, the current model leads to dissatisfaction among users and
> contributors, because releases are really not predictable. A recent example
> for the issues with our current model are the FLIP-6 changes we wanted to
> merge to master, a few weeks before the first RC for 1.2.0. Also, there
> were some emails on the mailing lists asking for a release date.
>
> In order to change that, I’m proposing to follow a strictly time-based
> release model. Other open source projects like Ubuntu, Cassandra, Spark or
> Kafka are following that model as well, and I think we should try it out as
> an experiment for the 1.3.0 release.
>
> I’m proposing to:
>
>    -
>
>    Do a Flink release every 4 months
>    -
>
>    Cycle:
>    -
>
>       3 months development
>       -
>
>       1 month before the release: Feature freeze. Create release branch
>       with RC0, start testing. Only fixes, tests and minor improvements are
>       allowed in.
>       -
>
>       2 weeks before the release: Code freeze. Start voting. Only fixes for
>       blockers are allowed in.
>       -
>
>    Forbid blocking a release because a feature is not done yet.
>    -
>
>    Features are merged to master, when they are tested and documented, to
>    have an always stable master
>    -
>
>    Bugfix releases are done as needed.
>    -
>
>    Old releases are supported for 6 months by the Flink community with
>    critical bug fixes
>
>
> This means, that we would have the following release dates:
>
> (Flink 1.3.0 by end of January 2017)
>
>  Flink 1.4.0 by end of May 2017
>
>  Flink 1.5.0 by end of September 2017
>
>  Flink 1.6.0 by end of January 2018
>
> I’ve put some more details including some pro’s and con’s into our wiki.
> The page is based on Kafka’s time-based release wiki page (Kafka also
> recently started following a strictly time-based model)
>
> https://cwiki.apache.org/confluence/display/FLINK/Time-based+releases
>
>
> Once we’ve agreed on following that model, I’ll update the release plan
> page accordingly:
> https://cwiki.apache.org/confluence/display/FLINK/Flink+
> Release+and+Feature+Plan
>
>
> Please let me know what you think about this idea!
>
> Regards,
>
> Robert
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Time-based releases in Flink

Tzu-Li (Gordon) Tai
In reply to this post by Robert Metzger
Hi Robert,

Thanks for bringing up the discussion. I like the proposal.

Regarding some of the downsides mentioned in the wiki:

1. Features that don’t make it in time with the feature freeze:
I think that’s ok, as long as we’re consistent with the schedules for the next release. This way users waiting for that particular features will still be able to rely on the fact that the feature will be included in 4 months.

2. Frequent releases mean bug fix releases for older branches:
You mentioned in the email that “old releases are supported for 6 months by the community”, but not in the wiki. If this is strictly followed, that means we’ll at most be supporting 2 previous major release versions (ex. as soon as 1.4.0 comes out, we’ll still be supporting bugfixes for 1.3.0, as well as 1.2.0 for another 2 months).
This might seem a bit odd, so perhaps we can stick to something like “support bugfixes for the previous 2 major releases”? Ex. Once 1.4.0 comes out, we’ll continue to support only 1.4.0 and 1.3.0.
Supporting bugfixes for 2 major versions seems workable, and this way users can also have a “buffer” that they should not fall behind releases for more than 2 major versions (8 months) and preplan upgrades.

- Gordon

On January 18, 2017 at 9:19:41 AM, Robert Metzger ([hidden email]) wrote:

Hi all!  

Since the 1.2.0 release is about to come out, I would like to propose a  
change in the way we do releases in the Flink community.  

In my opinion, the current model leads to dissatisfaction among users and  
contributors, because releases are really not predictable. A recent example  
for the issues with our current model are the FLIP-6 changes we wanted to  
merge to master, a few weeks before the first RC for 1.2.0. Also, there  
were some emails on the mailing lists asking for a release date.  

In order to change that, I’m proposing to follow a strictly time-based  
release model. Other open source projects like Ubuntu, Cassandra, Spark or  
Kafka are following that model as well, and I think we should try it out as  
an experiment for the 1.3.0 release.  

I’m proposing to:  

-  

Do a Flink release every 4 months  
-  

Cycle:  
-  

3 months development  
-  

1 month before the release: Feature freeze. Create release branch  
with RC0, start testing. Only fixes, tests and minor improvements are  
allowed in.  
-  

2 weeks before the release: Code freeze. Start voting. Only fixes for  
blockers are allowed in.  
-  

Forbid blocking a release because a feature is not done yet.  
-  

Features are merged to master, when they are tested and documented, to  
have an always stable master  
-  

Bugfix releases are done as needed.  
-  

Old releases are supported for 6 months by the Flink community with  
critical bug fixes  


This means, that we would have the following release dates:  

(Flink 1.3.0 by end of January 2017)  

Flink 1.4.0 by end of May 2017  

Flink 1.5.0 by end of September 2017  

Flink 1.6.0 by end of January 2018  

I’ve put some more details including some pro’s and con’s into our wiki.  
The page is based on Kafka’s time-based release wiki page (Kafka also  
recently started following a strictly time-based model)  

https://cwiki.apache.org/confluence/display/FLINK/Time-based+releases 


Once we’ve agreed on following that model, I’ll update the release plan  
page accordingly:  
https://cwiki.apache.org/confluence/display/FLINK/Flink+Release+and+Feature+Plan 


Please let me know what you think about this idea!  

Regards,  

Robert  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Time-based releases in Flink

Vasiliki Kalavri
Hi Robert,

thanks a lot for starting this discussion and for putting together the wiki
pages.
This proposal makes a lot of sense to me.

Big +1 for merging only features which are tested and *documented*.

I believe that having a clear timeline will not only make users happier but
also contributors more engaged. With the current unpredictability, it is
hard to book time aside to help with testing a release candidate. I hope
that knowing exactly when that needs to happen will help us plan our own
time better and help out more.

Cheers,
-Vasia.

On 18 January 2017 at 09:57, Tzu-Li (Gordon) Tai <[hidden email]>
wrote:

> Hi Robert,
>
> Thanks for bringing up the discussion. I like the proposal.
>
> Regarding some of the downsides mentioned in the wiki:
>
> 1. Features that don’t make it in time with the feature freeze:
> I think that’s ok, as long as we’re consistent with the schedules for the
> next release. This way users waiting for that particular features will
> still be able to rely on the fact that the feature will be included in 4
> months.
>
> 2. Frequent releases mean bug fix releases for older branches:
> You mentioned in the email that “old releases are supported for 6 months
> by the community”, but not in the wiki. If this is strictly followed, that
> means we’ll at most be supporting 2 previous major release versions (ex. as
> soon as 1.4.0 comes out, we’ll still be supporting bugfixes for 1.3.0, as
> well as 1.2.0 for another 2 months).
> This might seem a bit odd, so perhaps we can stick to something like
> “support bugfixes for the previous 2 major releases”? Ex. Once 1.4.0 comes
> out, we’ll continue to support only 1.4.0 and 1.3.0.
> Supporting bugfixes for 2 major versions seems workable, and this way
> users can also have a “buffer” that they should not fall behind releases
> for more than 2 major versions (8 months) and preplan upgrades.
>
> - Gordon
>
> On January 18, 2017 at 9:19:41 AM, Robert Metzger ([hidden email])
> wrote:
>
> Hi all!
>
> Since the 1.2.0 release is about to come out, I would like to propose a
> change in the way we do releases in the Flink community.
>
> In my opinion, the current model leads to dissatisfaction among users and
> contributors, because releases are really not predictable. A recent example
> for the issues with our current model are the FLIP-6 changes we wanted to
> merge to master, a few weeks before the first RC for 1.2.0. Also, there
> were some emails on the mailing lists asking for a release date.
>
> In order to change that, I’m proposing to follow a strictly time-based
> release model. Other open source projects like Ubuntu, Cassandra, Spark or
> Kafka are following that model as well, and I think we should try it out as
> an experiment for the 1.3.0 release.
>
> I’m proposing to:
>
> -
>
> Do a Flink release every 4 months
> -
>
> Cycle:
> -
>
> 3 months development
> -
>
> 1 month before the release: Feature freeze. Create release branch
> with RC0, start testing. Only fixes, tests and minor improvements are
> allowed in.
> -
>
> 2 weeks before the release: Code freeze. Start voting. Only fixes for
> blockers are allowed in.
> -
>
> Forbid blocking a release because a feature is not done yet.
> -
>
> Features are merged to master, when they are tested and documented, to
> have an always stable master
> -
>
> Bugfix releases are done as needed.
> -
>
> Old releases are supported for 6 months by the Flink community with
> critical bug fixes
>
>
> This means, that we would have the following release dates:
>
> (Flink 1.3.0 by end of January 2017)
>
> Flink 1.4.0 by end of May 2017
>
> Flink 1.5.0 by end of September 2017
>
> Flink 1.6.0 by end of January 2018
>
> I’ve put some more details including some pro’s and con’s into our wiki.
> The page is based on Kafka’s time-based release wiki page (Kafka also
> recently started following a strictly time-based model)
>
> https://cwiki.apache.org/confluence/display/FLINK/Time-based+releases
>
>
> Once we’ve agreed on following that model, I’ll update the release plan
> page accordingly:
> https://cwiki.apache.org/confluence/display/FLINK/
> Flink+Release+and+Feature+Plan
>
>
> Please let me know what you think about this idea!
>
> Regards,
>
> Robert
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Time-based releases in Flink

Robert Metzger
Thanks a lot for the positive feedback so far.

Thank you Fabian for spotting the off by one error in my email.
"There are two hard things in computer science: cache invalidation, naming
things, and off-by-one errors." (https://twitter.com/codinghorror/status/
506010907021828096?lang=en)

I agree with Fabian that this model could potentially lead to more feature
branches in our repository. However, I think we should only do that for
major features where many contributors are collaborating on. Using private
development branches works equally well for smaller groups.
I found that the frequent "flip6" branch rebases caused a lot of noise on
the commits@flink list.

Regarding the "bugfix guarantees":
I agree that my proposal doesn't make so much sense. I actually got the
same feedback from a draft of my email but forgot to change it before
sending it out. I think supporting the current (1.1) and previous (1.0)
major release is a doable guarantee.




On Wed, Jan 18, 2017 at 10:25 AM, Vasiliki Kalavri <
[hidden email]> wrote:

> Hi Robert,
>
> thanks a lot for starting this discussion and for putting together the wiki
> pages.
> This proposal makes a lot of sense to me.
>
> Big +1 for merging only features which are tested and *documented*.
>
> I believe that having a clear timeline will not only make users happier but
> also contributors more engaged. With the current unpredictability, it is
> hard to book time aside to help with testing a release candidate. I hope
> that knowing exactly when that needs to happen will help us plan our own
> time better and help out more.
>
> Cheers,
> -Vasia.
>
> On 18 January 2017 at 09:57, Tzu-Li (Gordon) Tai <[hidden email]>
> wrote:
>
> > Hi Robert,
> >
> > Thanks for bringing up the discussion. I like the proposal.
> >
> > Regarding some of the downsides mentioned in the wiki:
> >
> > 1. Features that don’t make it in time with the feature freeze:
> > I think that’s ok, as long as we’re consistent with the schedules for the
> > next release. This way users waiting for that particular features will
> > still be able to rely on the fact that the feature will be included in 4
> > months.
> >
> > 2. Frequent releases mean bug fix releases for older branches:
> > You mentioned in the email that “old releases are supported for 6 months
> > by the community”, but not in the wiki. If this is strictly followed,
> that
> > means we’ll at most be supporting 2 previous major release versions (ex.
> as
> > soon as 1.4.0 comes out, we’ll still be supporting bugfixes for 1.3.0, as
> > well as 1.2.0 for another 2 months).
> > This might seem a bit odd, so perhaps we can stick to something like
> > “support bugfixes for the previous 2 major releases”? Ex. Once 1.4.0
> comes
> > out, we’ll continue to support only 1.4.0 and 1.3.0.
> > Supporting bugfixes for 2 major versions seems workable, and this way
> > users can also have a “buffer” that they should not fall behind releases
> > for more than 2 major versions (8 months) and preplan upgrades.
> >
> > - Gordon
> >
> > On January 18, 2017 at 9:19:41 AM, Robert Metzger ([hidden email])
> > wrote:
> >
> > Hi all!
> >
> > Since the 1.2.0 release is about to come out, I would like to propose a
> > change in the way we do releases in the Flink community.
> >
> > In my opinion, the current model leads to dissatisfaction among users and
> > contributors, because releases are really not predictable. A recent
> example
> > for the issues with our current model are the FLIP-6 changes we wanted to
> > merge to master, a few weeks before the first RC for 1.2.0. Also, there
> > were some emails on the mailing lists asking for a release date.
> >
> > In order to change that, I’m proposing to follow a strictly time-based
> > release model. Other open source projects like Ubuntu, Cassandra, Spark
> or
> > Kafka are following that model as well, and I think we should try it out
> as
> > an experiment for the 1.3.0 release.
> >
> > I’m proposing to:
> >
> > -
> >
> > Do a Flink release every 4 months
> > -
> >
> > Cycle:
> > -
> >
> > 3 months development
> > -
> >
> > 1 month before the release: Feature freeze. Create release branch
> > with RC0, start testing. Only fixes, tests and minor improvements are
> > allowed in.
> > -
> >
> > 2 weeks before the release: Code freeze. Start voting. Only fixes for
> > blockers are allowed in.
> > -
> >
> > Forbid blocking a release because a feature is not done yet.
> > -
> >
> > Features are merged to master, when they are tested and documented, to
> > have an always stable master
> > -
> >
> > Bugfix releases are done as needed.
> > -
> >
> > Old releases are supported for 6 months by the Flink community with
> > critical bug fixes
> >
> >
> > This means, that we would have the following release dates:
> >
> > (Flink 1.3.0 by end of January 2017)
> >
> > Flink 1.4.0 by end of May 2017
> >
> > Flink 1.5.0 by end of September 2017
> >
> > Flink 1.6.0 by end of January 2018
> >
> > I’ve put some more details including some pro’s and con’s into our wiki.
> > The page is based on Kafka’s time-based release wiki page (Kafka also
> > recently started following a strictly time-based model)
> >
> > https://cwiki.apache.org/confluence/display/FLINK/Time-based+releases
> >
> >
> > Once we’ve agreed on following that model, I’ll update the release plan
> > page accordingly:
> > https://cwiki.apache.org/confluence/display/FLINK/
> > Flink+Release+and+Feature+Plan
> >
> >
> > Please let me know what you think about this idea!
> >
> > Regards,
> >
> > Robert
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Time-based releases in Flink

Ufuk Celebi-2
In reply to this post by Tzu-Li (Gordon) Tai
@Robert: I really like this. +1 to implement this after 1.2.0 is released. Small note about your release dates: you started with 1.3.0 but probably meant 1.2.0 right?

On 18 January 2017 at 09:57:31, Tzu-Li (Gordon) Tai ([hidden email]) wrote:

> Hi Robert,
>  
> Thanks for bringing up the discussion. I like the proposal.
>  
> Regarding some of the downsides mentioned in the wiki:
>  
> 1. Features that don’t make it in time with the feature freeze:
> I think that’s ok, as long as we’re consistent with the schedules for the next release.  
> This way users waiting for that particular features will still be able to rely on the fact  
> that the feature will be included in 4 months.
>  
> 2. Frequent releases mean bug fix releases for older branches:
> You mentioned in the email that “old releases are supported for 6 months by the community”,  
> but not in the wiki. If this is strictly followed, that means we’ll at most be supporting  
> 2 previous major release versions (ex. as soon as 1.4.0 comes out, we’ll still be supporting  
> bugfixes for 1.3.0, as well as 1.2.0 for another 2 months).
> This might seem a bit odd, so perhaps we can stick to something like “support bugfixes  
> for the previous 2 major releases”? Ex. Once 1.4.0 comes out, we’ll continue to support  
> only 1.4.0 and 1.3.0.
> Supporting bugfixes for 2 major versions seems workable, and this way users can also  
> have a “buffer” that they should not fall behind releases for more than 2 major versions  
> (8 months) and preplan upgrades.
>  
> - Gordon
>  
> On January 18, 2017 at 9:19:41 AM, Robert Metzger ([hidden email]) wrote:
>  
> Hi all!
>  
> Since the 1.2.0 release is about to come out, I would like to propose a
> change in the way we do releases in the Flink community.
>  
> In my opinion, the current model leads to dissatisfaction among users and
> contributors, because releases are really not predictable. A recent example
> for the issues with our current model are the FLIP-6 changes we wanted to
> merge to master, a few weeks before the first RC for 1.2.0. Also, there
> were some emails on the mailing lists asking for a release date.
>  
> In order to change that, I’m proposing to follow a strictly time-based
> release model. Other open source projects like Ubuntu, Cassandra, Spark or
> Kafka are following that model as well, and I think we should try it out as
> an experiment for the 1.3.0 release.
>  
> I’m proposing to:
>  
> -
>  
> Do a Flink release every 4 months
> -
>  
> Cycle:
> -
>  
> 3 months development
> -
>  
> 1 month before the release: Feature freeze. Create release branch
> with RC0, start testing. Only fixes, tests and minor improvements are
> allowed in.
> -
>  
> 2 weeks before the release: Code freeze. Start voting. Only fixes for
> blockers are allowed in.
> -
>  
> Forbid blocking a release because a feature is not done yet.
> -
>  
> Features are merged to master, when they are tested and documented, to
> have an always stable master
> -
>  
> Bugfix releases are done as needed.
> -
>  
> Old releases are supported for 6 months by the Flink community with
> critical bug fixes
>  
>  
> This means, that we would have the following release dates:
>  
> (Flink 1.3.0 by end of January 2017)
>  
> Flink 1.4.0 by end of May 2017
>  
> Flink 1.5.0 by end of September 2017
>  
> Flink 1.6.0 by end of January 2018
>  
> I’ve put some more details including some pro’s and con’s into our wiki.
> The page is based on Kafka’s time-based release wiki page (Kafka also
> recently started following a strictly time-based model)
>  
> https://cwiki.apache.org/confluence/display/FLINK/Time-based+releases
>  
>  
> Once we’ve agreed on following that model, I’ll update the release plan
> page accordingly:
> https://cwiki.apache.org/confluence/display/FLINK/Flink+Release+and+Feature+Plan 
>  
>  
> Please let me know what you think about this idea!
>  
> Regards,
>  
> Robert
>  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Time-based releases in Flink

Paris Carbone
�&����-�ǖy�Z�_5�^��m5�2�1(���n��ձ�!knzp��^w�ޕ�^u��}�����;ߎ��`-^D�����n>�,�X�ݸ�*�D�����%���d�J��y�Cjבy��zw���z�rN� ���,���*C,�QN��5J�� <�;u����\�����Y��"s�8F������f�����������I��U ��b�����O���(H�LA�j��/�,{�@��īt��Q�g�E����~�&{[�[���l{_vׯ7�]uo'�u�5� -�ǵ�mz�}��\"�"r�,��R13�z�ޭ2҉�y�]y륞w_ j}�׽u׽��Mt��z+�u���]oMn�Ka��}�^��muռ������$��ݵ����]p��fj��w^t�]y�M4Y�u��M{�]{���M���j�� �ۢw�j��rKa���u�ߖ)�j����+�ׯ~X���Zr���n7���! �I$��ڱ�kzW���"�Yb�D��N�bp2 D�N)�m�v��y��)Ŗ)�N�i�'u�@@t�]�g�;�M�PF5��� �jזy�|%���^��^���4�C�Ơx��ӟ�O�@x-��Q<����� d�E�ޭ��z���i�;F^�
>Ls�i�1Wr-�yS���E��Y���B�����f���&z�ڟ�;g_׾��G��W�Zr���=�����G6m�}�m�ݶ�i�^�����$�z�ڟ�;�4sf�����m�j����+�z�Kjx.j��D��!�{^��ڞ ���Q%�Hv��Zr�I3D*+��Z���DZr��鞲Ơzǧ������ا�ܩ{\f��\���z�ڞ�h���g��+r��z��םƊ�)ڶ)���}�]:�¢{^����^��镨�r�����
��z{HN9�5��8�q8�@�m����E�$�
��z{S���}�ĝ��xjǺ�� W��*'�B�&�&W'@РХfW'�&�fW76������Ɩ�R��6��7F&�R�7FW"'&�6�W2&R�V6�&V6�FVB�РУ������#r�B�B�VgV�6V�V&��V6T6�R��&s�w&�FS�У�У�&�&W'C��&V�ǒƖ�RF��2��F����V�V�BF��2gFW"�"��2&V�V6VB�6�����FR&�WB��W"&V�V6RFFW3���R7F'FVBv�F��2�'WB&�&&ǒ�V�B�"�&�v�C�У�У������V'�#rB��Ss�3�G�R�ƒ�v�&F��F��G�VƗF�6�R��&r�w&�FS�У����&�&W'B�У��У��F��2f�"'&��v��rWF�RF�67W76�����Ɩ�RF�R&��6��У��У��&Vv&F��r6��R�bF�RF�v�6�FW2�V�F���VB��F�Rv����У��У���fVGW&W2F�BF��( �B��R�B��F��Rv�F�F�RfVGW&Rg&VW�S�У���F���F�N( �2���2���r2v^( �&R6��6�7FV�Bv�F�F�R66�VGV�W2f�"F�R�W�B&V�V6R�У��F��2v�W6W'2v�F��rf�"F�B'F�7V�"fVGW&W2v���7F���&R&�RF�&Vǒ��F�Rf7BУ��F�BF�RfVGW&Rv���&R��6�VFVB��B���F�2�У��У��"�g&WVV�B&V�V6W2�V�'Vrf��&V�V6W2f�"��FW"'&�6�W3�У����R�V�F���VB��F�RV���F�B( ���B&V�V6W2&R7W�'FVBf�"b���F�2'�F�R6���V�G�( ��У��'WB��B��F�Rv�����bF��2�27G&�7Fǒf����vVB�F�B�V�2v^( ���B��7B&R7W�'F��rУ��"&Wf��W2���"&V�V6RfW'6���2�W��26���2�B�6��W2�WB�v^( ���7F���&R7W�'F��rУ��'Vvf��W2f�"�2��2vV��2�"�f�"��F�W""���F�2��У��F��2֖v�B6VV�&�B�FB�6�W&�2vR6�7F�6�F�6��WF���rƖ�R( �7W�'B'Vvf��W2У��f�"F�R&Wf��W2"���"&V�V6W>( ��W����6R�B�6��W2�WB�v^( ���6��F��VRF�7W�'BУ����ǒ�B��B�2��У��7W�'F��r'Vvf��W2f�""���"fW'6���26VV�2v�&�&�R��BF��2v�W6W'26��6�У���fR( �'VffW.( �F�BF�W�6��V�B��Bf��&V���B&V�V6W2f�"��&RF��"���"fW'6���2У�������F�2��B&W��Ww&FW2�У��У���v�&F��У��У������V'���#rB����C��&�&W'B�WG�vW"�&�WG�vW$6�R��&r�w&�FS�У��У������У��У��6��6RF�R�"�&V�V6R�2&�WBF�6��R�WB��v�V�BƖ�RF�&��6RУ��6��vR��F�Rv�vRF�&V�V6W2��F�RfƖ�6���V�G��У��У����ג������F�R7W'&V�B��FV��VG2F�F�76F�6f7F������rW6W'2�@У��6��G&�'WF�'2�&V6W6R&V�V6W2&R&V�ǒ��B&VF�7F&�R�&V6V�BW���PУ��f�"F�R�77VW2v�F��W"7W'&V�B��FV�&RF�Rdĕ�b6��vW2vRv�FVBF�У���W&vRF��7FW"�fWrvVV�2&Vf�&RF�Rf�'7B$2f�"�"���6��F�W&PУ��vW&R6��RV���2��F�R��Ɩ�rƗ7G26���rf�"&V�V6RFFR�У��У�����&FW"F�6��vRF�B��( ��&��6��rF�f����r7G&�7FǒF��R�&6V@У��&V�V6R��FV���F�W"�V�6�W&6R&��V7G2Ɩ�RV'V�GR�676�G&�7&�� У���f�&Rf����v��rF�B��FV�2vV����B�F���vR6��V�BG'��B�WB0У���W�W&��V�Bf�"F�R�2�&V�V6R�У��У���( ��&��6��rF�У��У���У��У��F�fƖ�&V�V6RWfW'�B���F�0У���У��У��7�6�S�У���У��У��2���F�2FWfV���V�@У���У��У�����F�&Vf�&RF�R&V�V6S�fVGW&Rg&VW�R�7&VFR&V�V6R'&�6�У��v�F�$3�7F'BFW7F��r���ǒf��W2�FW7G2�B֖��"��&�fV�V�G2&PУ�����vVB���У���У��У��"vVV�2&Vf�&RF�R&V�V6S�6�FRg&VW�R�7F'Bf�F��r���ǒf��W2f� У��&��6�W'2&R���vVB���У���У��У��f�&&�B&��6���r&V�V6R&V6W6RfVGW&R�2��BF��R�WB�У���У��У��fVGW&W2&R�W&vVBF��7FW"�v�V�F�W�&RFW7FVB�BF�7V�V�FVB�F�У���fR��v�27F&�R�7FW У���У��У��'Vvf��&V�V6W2&RF��R2�VVFVB�У���У��У����B&V�V6W2&R7W�'FVBf�"b���F�2'�F�RfƖ�6���V�G�v�F�У��7&�F�6�'Vrf��W0У��У��У��F��2�V�2�F�BvRv�V�B�fRF�Rf����v��r&V�V6RFFW3�У��У���fƖ��2�'�V�B�b��V'�#r�У��У��fƖ��B�'�V�B�b��#pУ��У��fƖ��R�'�V�B�b6WFV�&W"#pУ��У��fƖ��b�'�V�B�b��V'�#�У��У���( �fRWB6��R��&RFWF��2��6�VF��r6��R&�( �2�B6��( �2��F��W"v����У��F�RvR�2&6VB���f�( �2F��R�&6VB&V�V6Rv���vR��f��6�У��&V6V�Fǒ7F'FVBf����v��r7G&�7FǒF��R�&6VB��FVУ��У���GG3���7v����6�R��&r�6��f�VV�6R�F�7���dĔ��F��R�&6VB�&V�V6W0У��У��У����6Rv^( �fRw&VVB��f����v��rF�B��FV���( ���WFFRF�R&V�V6R��У��vR66�&F��vǓ�У���GG3���7v����6�R��&r�6��f�VV�6R�F�7���dĔ��fƖ沵&V�V6R��B�fVGW&R���У��У��У���V6R�WB�R���rv�B��RF���&�WBF��2�FVУ��У��&Vv&G2�У��У��&�&W'@У��У�РР
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Time-based releases in Flink

Greg Hogan
In reply to this post by Robert Metzger
I'm +0 on switching to a pre-determined schedule. It may be that the Flink
codebase has reached a level of maturity allowing for a time-based release
schedule, and I'm hopeful that a known schedule will improve communication
about and expectations for new features.

I'd like to hear a retrospective on the duration of the 1.2 release cycle.

As noted recently within the Flink community, the number of outstanding
pull requests and tickets has steadily increased. I'm concerned that with
fixed deadlines committer priorities will take precedence and community
contributions will be deferred indefinitely.

I'm concerned that only blockers are fixed for a .0 release, and that
exactly two weeks are allotted. Will any desirable fix simply become a
blocker or will we potentially release with a list of known bugs?

I think it would be worthwhile to identity upgradeable dependencies at the
beginning of each release cycle which would allow the most time for testing
during development.

There are 130 open tickets scheduled for 1.2.0 [1]. Targeting "inbox zero"
(without simply bulk-migrating tickets to another release) would be
preferable to tracking tickets through email chains on the mailing list.
The number of open GitHub pull requests isn't so much as issue since PRs
are simply listed by date, but it would be helpful to keep Jira tickets
up-to-date. It seems that "Fix Version" is often a wish rather than a plan.

Greg

[1]
https://issues.apache.org/jira/browse/FLINK?selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel

On Wed, Jan 18, 2017 at 5:13 AM, Robert Metzger <[hidden email]> wrote:

> Thanks a lot for the positive feedback so far.
>
> Thank you Fabian for spotting the off by one error in my email.
> "There are two hard things in computer science: cache invalidation, naming
> things, and off-by-one errors." (https://twitter.com/codinghorror/status/
> 506010907021828096?lang=en)
>
> I agree with Fabian that this model could potentially lead to more feature
> branches in our repository. However, I think we should only do that for
> major features where many contributors are collaborating on. Using private
> development branches works equally well for smaller groups.
> I found that the frequent "flip6" branch rebases caused a lot of noise on
> the commits@flink list.
>
> Regarding the "bugfix guarantees":
> I agree that my proposal doesn't make so much sense. I actually got the
> same feedback from a draft of my email but forgot to change it before
> sending it out. I think supporting the current (1.1) and previous (1.0)
> major release is a doable guarantee.
>
>
>
>
> On Wed, Jan 18, 2017 at 10:25 AM, Vasiliki Kalavri <
> [hidden email]> wrote:
>
> > Hi Robert,
> >
> > thanks a lot for starting this discussion and for putting together the
> wiki
> > pages.
> > This proposal makes a lot of sense to me.
> >
> > Big +1 for merging only features which are tested and *documented*.
> >
> > I believe that having a clear timeline will not only make users happier
> but
> > also contributors more engaged. With the current unpredictability, it is
> > hard to book time aside to help with testing a release candidate. I hope
> > that knowing exactly when that needs to happen will help us plan our own
> > time better and help out more.
> >
> > Cheers,
> > -Vasia.
> >
> > On 18 January 2017 at 09:57, Tzu-Li (Gordon) Tai <[hidden email]>
> > wrote:
> >
> > > Hi Robert,
> > >
> > > Thanks for bringing up the discussion. I like the proposal.
> > >
> > > Regarding some of the downsides mentioned in the wiki:
> > >
> > > 1. Features that don’t make it in time with the feature freeze:
> > > I think that’s ok, as long as we’re consistent with the schedules for
> the
> > > next release. This way users waiting for that particular features will
> > > still be able to rely on the fact that the feature will be included in
> 4
> > > months.
> > >
> > > 2. Frequent releases mean bug fix releases for older branches:
> > > You mentioned in the email that “old releases are supported for 6
> months
> > > by the community”, but not in the wiki. If this is strictly followed,
> > that
> > > means we’ll at most be supporting 2 previous major release versions
> (ex.
> > as
> > > soon as 1.4.0 comes out, we’ll still be supporting bugfixes for 1.3.0,
> as
> > > well as 1.2.0 for another 2 months).
> > > This might seem a bit odd, so perhaps we can stick to something like
> > > “support bugfixes for the previous 2 major releases”? Ex. Once 1.4.0
> > comes
> > > out, we’ll continue to support only 1.4.0 and 1.3.0.
> > > Supporting bugfixes for 2 major versions seems workable, and this way
> > > users can also have a “buffer” that they should not fall behind
> releases
> > > for more than 2 major versions (8 months) and preplan upgrades.
> > >
> > > - Gordon
> > >
> > > On January 18, 2017 at 9:19:41 AM, Robert Metzger ([hidden email]
> )
> > > wrote:
> > >
> > > Hi all!
> > >
> > > Since the 1.2.0 release is about to come out, I would like to propose a
> > > change in the way we do releases in the Flink community.
> > >
> > > In my opinion, the current model leads to dissatisfaction among users
> and
> > > contributors, because releases are really not predictable. A recent
> > example
> > > for the issues with our current model are the FLIP-6 changes we wanted
> to
> > > merge to master, a few weeks before the first RC for 1.2.0. Also, there
> > > were some emails on the mailing lists asking for a release date.
> > >
> > > In order to change that, I’m proposing to follow a strictly time-based
> > > release model. Other open source projects like Ubuntu, Cassandra, Spark
> > or
> > > Kafka are following that model as well, and I think we should try it
> out
> > as
> > > an experiment for the 1.3.0 release.
> > >
> > > I’m proposing to:
> > >
> > > -
> > >
> > > Do a Flink release every 4 months
> > > -
> > >
> > > Cycle:
> > > -
> > >
> > > 3 months development
> > > -
> > >
> > > 1 month before the release: Feature freeze. Create release branch
> > > with RC0, start testing. Only fixes, tests and minor improvements are
> > > allowed in.
> > > -
> > >
> > > 2 weeks before the release: Code freeze. Start voting. Only fixes for
> > > blockers are allowed in.
> > > -
> > >
> > > Forbid blocking a release because a feature is not done yet.
> > > -
> > >
> > > Features are merged to master, when they are tested and documented, to
> > > have an always stable master
> > > -
> > >
> > > Bugfix releases are done as needed.
> > > -
> > >
> > > Old releases are supported for 6 months by the Flink community with
> > > critical bug fixes
> > >
> > >
> > > This means, that we would have the following release dates:
> > >
> > > (Flink 1.3.0 by end of January 2017)
> > >
> > > Flink 1.4.0 by end of May 2017
> > >
> > > Flink 1.5.0 by end of September 2017
> > >
> > > Flink 1.6.0 by end of January 2018
> > >
> > > I’ve put some more details including some pro’s and con’s into our
> wiki.
> > > The page is based on Kafka’s time-based release wiki page (Kafka also
> > > recently started following a strictly time-based model)
> > >
> > > https://cwiki.apache.org/confluence/display/FLINK/Time-based+releases
> > >
> > >
> > > Once we’ve agreed on following that model, I’ll update the release plan
> > > page accordingly:
> > > https://cwiki.apache.org/confluence/display/FLINK/
> > > Flink+Release+and+Feature+Plan
> > >
> > >
> > > Please let me know what you think about this idea!
> > >
> > > Regards,
> > >
> > > Robert
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Time-based releases in Flink

Robert Metzger
Thanks a lot for your response Greg!

I'd like to hear a retrospective on the duration of the 1.2 release cycle.


164 days, or 5 months and 11 days have passed since the 1.1 release. The
other release cycles are listed here:
https://cwiki.apache.org/confluence/display/FLINK/Flink+Release+and+Feature+Plan

I would like to increase the release frequency a bit to 4 months, because
I'm often seeing a lot of interest from our users for the latest features.
The stream processing space is still quickly evolving, so I would like to
bring the latest new features out as fast as possible (without compromising
quality of course).

As noted recently within the Flink community, the number of outstanding
> pull requests and tickets has steadily increased. I'm concerned that with
> fixed deadlines committer priorities will take precedence and community
> contributions will be deferred indefinitely.


You are raising a very valid point: Community work hasn't been as good as
it was a few months ago, and we should fix that as soon as possible.

However, I don't think that time-based releases will change much on that
situation. Both models can potentially draw all the attention to the
release deadline vs working on community contributions.
If you look back at the emails regarding the 1.2.0 release, it was first
brought up by Fabian in mid October. Early December, I was starting to
track the progress on the release on the ML. From that time (almost two
months ago) the committers were focusing a lot on getting their stuff into
the release. I think that's part of the reason why the community work
hasn't been that great recently.

Maybe it would make sense to start a separate thread to discuss how we can
fix the situation with the number of open pull requests?


I'm concerned that only blockers are fixed for a .0 release, and that
> exactly two weeks are allotted. Will any desirable fix simply become a
> blocker or will we potentially release with a list of known bugs?


I hope neither will happen too much, if we enforce that big features don't
get merged in the last minute and thus get enough testing exposure before
the merge-window closes.
I have to admit that I don't have a lot of experience with a strictly
time-based release model, but we should definitively review the process
after the 1.3.0 release (and of course ensure that the master is getting
stable before the release branch is forked off)

The good thing about the time-based release model is, that everybody knows
well in advance what the dates for feature freeze and code freeze are.
So the code freeze should not come as a surprise and people should test and
fix their stuff before that happens.


Regarding JIRA: I agree that it is not very well maintained right now, and
that the "fix version" flag is used more as a wish than a plan.
I will not move all the 1.2 issues that haven't been closed to 1.3 to avoid
having a bad start for the time-based releases.







On Wed, Jan 18, 2017 at 5:34 PM, Greg Hogan <[hidden email]> wrote:

> I'm +0 on switching to a pre-determined schedule. It may be that the Flink
> codebase has reached a level of maturity allowing for a time-based release
> schedule, and I'm hopeful that a known schedule will improve communication
> about and expectations for new features.
>
> I'd like to hear a retrospective on the duration of the 1.2 release cycle.
>
> As noted recently within the Flink community, the number of outstanding
> pull requests and tickets has steadily increased. I'm concerned that with
> fixed deadlines committer priorities will take precedence and community
> contributions will be deferred indefinitely.
>
> I'm concerned that only blockers are fixed for a .0 release, and that
> exactly two weeks are allotted. Will any desirable fix simply become a
> blocker or will we potentially release with a list of known bugs?
>
> I think it would be worthwhile to identity upgradeable dependencies at the
> beginning of each release cycle which would allow the most time for testing
> during development.
>
> There are 130 open tickets scheduled for 1.2.0 [1]. Targeting "inbox zero"
> (without simply bulk-migrating tickets to another release) would be
> preferable to tracking tickets through email chains on the mailing list.
> The number of open GitHub pull requests isn't so much as issue since PRs
> are simply listed by date, but it would be helpful to keep Jira tickets
> up-to-date. It seems that "Fix Version" is often a wish rather than a plan.
>
> Greg
>
> [1]
> https://issues.apache.org/jira/browse/FLINK?selectedTab=
> com.atlassian.jira.jira-projects-plugin:issues-panel
>
> On Wed, Jan 18, 2017 at 5:13 AM, Robert Metzger <[hidden email]>
> wrote:
>
> > Thanks a lot for the positive feedback so far.
> >
> > Thank you Fabian for spotting the off by one error in my email.
> > "There are two hard things in computer science: cache invalidation,
> naming
> > things, and off-by-one errors." (https://twitter.com/
> codinghorror/status/
> > 506010907021828096?lang=en)
> >
> > I agree with Fabian that this model could potentially lead to more
> feature
> > branches in our repository. However, I think we should only do that for
> > major features where many contributors are collaborating on. Using
> private
> > development branches works equally well for smaller groups.
> > I found that the frequent "flip6" branch rebases caused a lot of noise on
> > the commits@flink list.
> >
> > Regarding the "bugfix guarantees":
> > I agree that my proposal doesn't make so much sense. I actually got the
> > same feedback from a draft of my email but forgot to change it before
> > sending it out. I think supporting the current (1.1) and previous (1.0)
> > major release is a doable guarantee.
> >
> >
> >
> >
> > On Wed, Jan 18, 2017 at 10:25 AM, Vasiliki Kalavri <
> > [hidden email]> wrote:
> >
> > > Hi Robert,
> > >
> > > thanks a lot for starting this discussion and for putting together the
> > wiki
> > > pages.
> > > This proposal makes a lot of sense to me.
> > >
> > > Big +1 for merging only features which are tested and *documented*.
> > >
> > > I believe that having a clear timeline will not only make users happier
> > but
> > > also contributors more engaged. With the current unpredictability, it
> is
> > > hard to book time aside to help with testing a release candidate. I
> hope
> > > that knowing exactly when that needs to happen will help us plan our
> own
> > > time better and help out more.
> > >
> > > Cheers,
> > > -Vasia.
> > >
> > > On 18 January 2017 at 09:57, Tzu-Li (Gordon) Tai <[hidden email]>
> > > wrote:
> > >
> > > > Hi Robert,
> > > >
> > > > Thanks for bringing up the discussion. I like the proposal.
> > > >
> > > > Regarding some of the downsides mentioned in the wiki:
> > > >
> > > > 1. Features that don’t make it in time with the feature freeze:
> > > > I think that’s ok, as long as we’re consistent with the schedules for
> > the
> > > > next release. This way users waiting for that particular features
> will
> > > > still be able to rely on the fact that the feature will be included
> in
> > 4
> > > > months.
> > > >
> > > > 2. Frequent releases mean bug fix releases for older branches:
> > > > You mentioned in the email that “old releases are supported for 6
> > months
> > > > by the community”, but not in the wiki. If this is strictly followed,
> > > that
> > > > means we’ll at most be supporting 2 previous major release versions
> > (ex.
> > > as
> > > > soon as 1.4.0 comes out, we’ll still be supporting bugfixes for
> 1.3.0,
> > as
> > > > well as 1.2.0 for another 2 months).
> > > > This might seem a bit odd, so perhaps we can stick to something like
> > > > “support bugfixes for the previous 2 major releases”? Ex. Once 1.4.0
> > > comes
> > > > out, we’ll continue to support only 1.4.0 and 1.3.0.
> > > > Supporting bugfixes for 2 major versions seems workable, and this way
> > > > users can also have a “buffer” that they should not fall behind
> > releases
> > > > for more than 2 major versions (8 months) and preplan upgrades.
> > > >
> > > > - Gordon
> > > >
> > > > On January 18, 2017 at 9:19:41 AM, Robert Metzger (
> [hidden email]
> > )
> > > > wrote:
> > > >
> > > > Hi all!
> > > >
> > > > Since the 1.2.0 release is about to come out, I would like to
> propose a
> > > > change in the way we do releases in the Flink community.
> > > >
> > > > In my opinion, the current model leads to dissatisfaction among users
> > and
> > > > contributors, because releases are really not predictable. A recent
> > > example
> > > > for the issues with our current model are the FLIP-6 changes we
> wanted
> > to
> > > > merge to master, a few weeks before the first RC for 1.2.0. Also,
> there
> > > > were some emails on the mailing lists asking for a release date.
> > > >
> > > > In order to change that, I’m proposing to follow a strictly
> time-based
> > > > release model. Other open source projects like Ubuntu, Cassandra,
> Spark
> > > or
> > > > Kafka are following that model as well, and I think we should try it
> > out
> > > as
> > > > an experiment for the 1.3.0 release.
> > > >
> > > > I’m proposing to:
> > > >
> > > > -
> > > >
> > > > Do a Flink release every 4 months
> > > > -
> > > >
> > > > Cycle:
> > > > -
> > > >
> > > > 3 months development
> > > > -
> > > >
> > > > 1 month before the release: Feature freeze. Create release branch
> > > > with RC0, start testing. Only fixes, tests and minor improvements are
> > > > allowed in.
> > > > -
> > > >
> > > > 2 weeks before the release: Code freeze. Start voting. Only fixes for
> > > > blockers are allowed in.
> > > > -
> > > >
> > > > Forbid blocking a release because a feature is not done yet.
> > > > -
> > > >
> > > > Features are merged to master, when they are tested and documented,
> to
> > > > have an always stable master
> > > > -
> > > >
> > > > Bugfix releases are done as needed.
> > > > -
> > > >
> > > > Old releases are supported for 6 months by the Flink community with
> > > > critical bug fixes
> > > >
> > > >
> > > > This means, that we would have the following release dates:
> > > >
> > > > (Flink 1.3.0 by end of January 2017)
> > > >
> > > > Flink 1.4.0 by end of May 2017
> > > >
> > > > Flink 1.5.0 by end of September 2017
> > > >
> > > > Flink 1.6.0 by end of January 2018
> > > >
> > > > I’ve put some more details including some pro’s and con’s into our
> > wiki.
> > > > The page is based on Kafka’s time-based release wiki page (Kafka also
> > > > recently started following a strictly time-based model)
> > > >
> > > > https://cwiki.apache.org/confluence/display/FLINK/Time-
> based+releases
> > > >
> > > >
> > > > Once we’ve agreed on following that model, I’ll update the release
> plan
> > > > page accordingly:
> > > > https://cwiki.apache.org/confluence/display/FLINK/
> > > > Flink+Release+and+Feature+Plan
> > > >
> > > >
> > > > Please let me know what you think about this idea!
> > > >
> > > > Regards,
> > > >
> > > > Robert
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Time-based releases in Flink

Robert Metzger
Thanks again for all your feedback on my proposal!

The discussion was open for the last 12 days and the majority was very
positive about it.
I will keep an eye on the valid concerns Greg raised (neglected PRs,
unstable releases) and see how we can solve them.

I'll update the wiki pages and include a schedule for upcoming releases.
I'll also try to send reminders to the mailing list about upcoming release
related deadlines.

On Thu, Jan 19, 2017 at 7:15 PM, Robert Metzger <[hidden email]> wrote:

> Thanks a lot for your response Greg!
>
> I'd like to hear a retrospective on the duration of the 1.2 release cycle.
>
>
> 164 days, or 5 months and 11 days have passed since the 1.1 release. The
> other release cycles are listed here: https://cwiki.apache.
> org/confluence/display/FLINK/Flink+Release+and+Feature+Plan
> I would like to increase the release frequency a bit to 4 months, because
> I'm often seeing a lot of interest from our users for the latest features.
> The stream processing space is still quickly evolving, so I would like to
> bring the latest new features out as fast as possible (without compromising
> quality of course).
>
> As noted recently within the Flink community, the number of outstanding
>> pull requests and tickets has steadily increased. I'm concerned that with
>> fixed deadlines committer priorities will take precedence and community
>> contributions will be deferred indefinitely.
>
>
> You are raising a very valid point: Community work hasn't been as good as
> it was a few months ago, and we should fix that as soon as possible.
>
> However, I don't think that time-based releases will change much on that
> situation. Both models can potentially draw all the attention to the
> release deadline vs working on community contributions.
> If you look back at the emails regarding the 1.2.0 release, it was first
> brought up by Fabian in mid October. Early December, I was starting to
> track the progress on the release on the ML. From that time (almost two
> months ago) the committers were focusing a lot on getting their stuff into
> the release. I think that's part of the reason why the community work
> hasn't been that great recently.
>
> Maybe it would make sense to start a separate thread to discuss how we can
> fix the situation with the number of open pull requests?
>
>
> I'm concerned that only blockers are fixed for a .0 release, and that
>> exactly two weeks are allotted. Will any desirable fix simply become a
>> blocker or will we potentially release with a list of known bugs?
>
>
> I hope neither will happen too much, if we enforce that big features don't
> get merged in the last minute and thus get enough testing exposure before
> the merge-window closes.
> I have to admit that I don't have a lot of experience with a strictly
> time-based release model, but we should definitively review the process
> after the 1.3.0 release (and of course ensure that the master is getting
> stable before the release branch is forked off)
>
> The good thing about the time-based release model is, that everybody knows
> well in advance what the dates for feature freeze and code freeze are.
> So the code freeze should not come as a surprise and people should test
> and fix their stuff before that happens.
>
>
> Regarding JIRA: I agree that it is not very well maintained right now, and
> that the "fix version" flag is used more as a wish than a plan.
> I will not move all the 1.2 issues that haven't been closed to 1.3 to
> avoid having a bad start for the time-based releases.
>
>
>
>
>
>
>
> On Wed, Jan 18, 2017 at 5:34 PM, Greg Hogan <[hidden email]> wrote:
>
>> I'm +0 on switching to a pre-determined schedule. It may be that the Flink
>> codebase has reached a level of maturity allowing for a time-based release
>> schedule, and I'm hopeful that a known schedule will improve communication
>> about and expectations for new features.
>>
>> I'd like to hear a retrospective on the duration of the 1.2 release cycle.
>>
>> As noted recently within the Flink community, the number of outstanding
>> pull requests and tickets has steadily increased. I'm concerned that with
>> fixed deadlines committer priorities will take precedence and community
>> contributions will be deferred indefinitely.
>>
>> I'm concerned that only blockers are fixed for a .0 release, and that
>> exactly two weeks are allotted. Will any desirable fix simply become a
>> blocker or will we potentially release with a list of known bugs?
>>
>> I think it would be worthwhile to identity upgradeable dependencies at the
>> beginning of each release cycle which would allow the most time for
>> testing
>> during development.
>>
>> There are 130 open tickets scheduled for 1.2.0 [1]. Targeting "inbox zero"
>> (without simply bulk-migrating tickets to another release) would be
>> preferable to tracking tickets through email chains on the mailing list.
>> The number of open GitHub pull requests isn't so much as issue since PRs
>> are simply listed by date, but it would be helpful to keep Jira tickets
>> up-to-date. It seems that "Fix Version" is often a wish rather than a
>> plan.
>>
>> Greg
>>
>> [1]
>> https://issues.apache.org/jira/browse/FLINK?selectedTab=com.
>> atlassian.jira.jira-projects-plugin:issues-panel
>>
>> On Wed, Jan 18, 2017 at 5:13 AM, Robert Metzger <[hidden email]>
>> wrote:
>>
>> > Thanks a lot for the positive feedback so far.
>> >
>> > Thank you Fabian for spotting the off by one error in my email.
>> > "There are two hard things in computer science: cache invalidation,
>> naming
>> > things, and off-by-one errors." (https://twitter.com/codinghor
>> ror/status/
>> > 506010907021828096?lang=en)
>> >
>> > I agree with Fabian that this model could potentially lead to more
>> feature
>> > branches in our repository. However, I think we should only do that for
>> > major features where many contributors are collaborating on. Using
>> private
>> > development branches works equally well for smaller groups.
>> > I found that the frequent "flip6" branch rebases caused a lot of noise
>> on
>> > the commits@flink list.
>> >
>> > Regarding the "bugfix guarantees":
>> > I agree that my proposal doesn't make so much sense. I actually got the
>> > same feedback from a draft of my email but forgot to change it before
>> > sending it out. I think supporting the current (1.1) and previous (1.0)
>> > major release is a doable guarantee.
>> >
>> >
>> >
>> >
>> > On Wed, Jan 18, 2017 at 10:25 AM, Vasiliki Kalavri <
>> > [hidden email]> wrote:
>> >
>> > > Hi Robert,
>> > >
>> > > thanks a lot for starting this discussion and for putting together the
>> > wiki
>> > > pages.
>> > > This proposal makes a lot of sense to me.
>> > >
>> > > Big +1 for merging only features which are tested and *documented*.
>> > >
>> > > I believe that having a clear timeline will not only make users
>> happier
>> > but
>> > > also contributors more engaged. With the current unpredictability, it
>> is
>> > > hard to book time aside to help with testing a release candidate. I
>> hope
>> > > that knowing exactly when that needs to happen will help us plan our
>> own
>> > > time better and help out more.
>> > >
>> > > Cheers,
>> > > -Vasia.
>> > >
>> > > On 18 January 2017 at 09:57, Tzu-Li (Gordon) Tai <[hidden email]
>> >
>> > > wrote:
>> > >
>> > > > Hi Robert,
>> > > >
>> > > > Thanks for bringing up the discussion. I like the proposal.
>> > > >
>> > > > Regarding some of the downsides mentioned in the wiki:
>> > > >
>> > > > 1. Features that don’t make it in time with the feature freeze:
>> > > > I think that’s ok, as long as we’re consistent with the schedules
>> for
>> > the
>> > > > next release. This way users waiting for that particular features
>> will
>> > > > still be able to rely on the fact that the feature will be included
>> in
>> > 4
>> > > > months.
>> > > >
>> > > > 2. Frequent releases mean bug fix releases for older branches:
>> > > > You mentioned in the email that “old releases are supported for 6
>> > months
>> > > > by the community”, but not in the wiki. If this is strictly
>> followed,
>> > > that
>> > > > means we’ll at most be supporting 2 previous major release versions
>> > (ex.
>> > > as
>> > > > soon as 1.4.0 comes out, we’ll still be supporting bugfixes for
>> 1.3.0,
>> > as
>> > > > well as 1.2.0 for another 2 months).
>> > > > This might seem a bit odd, so perhaps we can stick to something like
>> > > > “support bugfixes for the previous 2 major releases”? Ex. Once 1.4.0
>> > > comes
>> > > > out, we’ll continue to support only 1.4.0 and 1.3.0.
>> > > > Supporting bugfixes for 2 major versions seems workable, and this
>> way
>> > > > users can also have a “buffer” that they should not fall behind
>> > releases
>> > > > for more than 2 major versions (8 months) and preplan upgrades.
>> > > >
>> > > > - Gordon
>> > > >
>> > > > On January 18, 2017 at 9:19:41 AM, Robert Metzger (
>> [hidden email]
>> > )
>> > > > wrote:
>> > > >
>> > > > Hi all!
>> > > >
>> > > > Since the 1.2.0 release is about to come out, I would like to
>> propose a
>> > > > change in the way we do releases in the Flink community.
>> > > >
>> > > > In my opinion, the current model leads to dissatisfaction among
>> users
>> > and
>> > > > contributors, because releases are really not predictable. A recent
>> > > example
>> > > > for the issues with our current model are the FLIP-6 changes we
>> wanted
>> > to
>> > > > merge to master, a few weeks before the first RC for 1.2.0. Also,
>> there
>> > > > were some emails on the mailing lists asking for a release date.
>> > > >
>> > > > In order to change that, I’m proposing to follow a strictly
>> time-based
>> > > > release model. Other open source projects like Ubuntu, Cassandra,
>> Spark
>> > > or
>> > > > Kafka are following that model as well, and I think we should try it
>> > out
>> > > as
>> > > > an experiment for the 1.3.0 release.
>> > > >
>> > > > I’m proposing to:
>> > > >
>> > > > -
>> > > >
>> > > > Do a Flink release every 4 months
>> > > > -
>> > > >
>> > > > Cycle:
>> > > > -
>> > > >
>> > > > 3 months development
>> > > > -
>> > > >
>> > > > 1 month before the release: Feature freeze. Create release branch
>> > > > with RC0, start testing. Only fixes, tests and minor improvements
>> are
>> > > > allowed in.
>> > > > -
>> > > >
>> > > > 2 weeks before the release: Code freeze. Start voting. Only fixes
>> for
>> > > > blockers are allowed in.
>> > > > -
>> > > >
>> > > > Forbid blocking a release because a feature is not done yet.
>> > > > -
>> > > >
>> > > > Features are merged to master, when they are tested and documented,
>> to
>> > > > have an always stable master
>> > > > -
>> > > >
>> > > > Bugfix releases are done as needed.
>> > > > -
>> > > >
>> > > > Old releases are supported for 6 months by the Flink community with
>> > > > critical bug fixes
>> > > >
>> > > >
>> > > > This means, that we would have the following release dates:
>> > > >
>> > > > (Flink 1.3.0 by end of January 2017)
>> > > >
>> > > > Flink 1.4.0 by end of May 2017
>> > > >
>> > > > Flink 1.5.0 by end of September 2017
>> > > >
>> > > > Flink 1.6.0 by end of January 2018
>> > > >
>> > > > I’ve put some more details including some pro’s and con’s into our
>> > wiki.
>> > > > The page is based on Kafka’s time-based release wiki page (Kafka
>> also
>> > > > recently started following a strictly time-based model)
>> > > >
>> > > > https://cwiki.apache.org/confluence/display/FLINK/Time-based
>> +releases
>> > > >
>> > > >
>> > > > Once we’ve agreed on following that model, I’ll update the release
>> plan
>> > > > page accordingly:
>> > > > https://cwiki.apache.org/confluence/display/FLINK/
>> > > > Flink+Release+and+Feature+Plan
>> > > >
>> > > >
>> > > > Please let me know what you think about this idea!
>> > > >
>> > > > Regards,
>> > > >
>> > > > Robert
>> > > >
>> > >
>> >
>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS] Time-based releases in Flink

Jin Mingjian
+1. (sorry, I am not a committer now but still like to contribute some
ideas.)

Time-based releasing schema is more from reflections on fast paced
ecosystem. More stable revisions and more features are continued to
delivered in the future release. The stability of one release is a "best
effort" in fast iterations. The stability is more trusted to be guaranteed
by the culture of developer team rather than the psyche dependence on the
version number.

Furthermore, we may consider more changes to the versioning schema as well.
What the version number after 1.9.0? 1.10 or 2.0? (If we do not break APIs,
then we can have 1.100?...) The experiences from other large projects like
Chromium, LLVM show that the happy could be achieved with only two version
segments - "major.0.patch" like 1.0.0, 3.0.3.

Jin


On Mon, Jan 30, 2017 at 11:03 PM, Robert Metzger <[hidden email]>
wrote:

> Thanks again for all your feedback on my proposal!
>
> The discussion was open for the last 12 days and the majority was very
> positive about it.
> I will keep an eye on the valid concerns Greg raised (neglected PRs,
> unstable releases) and see how we can solve them.
>
> I'll update the wiki pages and include a schedule for upcoming releases.
> I'll also try to send reminders to the mailing list about upcoming release
> related deadlines.
>
> On Thu, Jan 19, 2017 at 7:15 PM, Robert Metzger <[hidden email]>
> wrote:
>
> > Thanks a lot for your response Greg!
> >
> > I'd like to hear a retrospective on the duration of the 1.2 release
> cycle.
> >
> >
> > 164 days, or 5 months and 11 days have passed since the 1.1 release. The
> > other release cycles are listed here: https://cwiki.apache.
> > org/confluence/display/FLINK/Flink+Release+and+Feature+Plan
> > I would like to increase the release frequency a bit to 4 months, because
> > I'm often seeing a lot of interest from our users for the latest
> features.
> > The stream processing space is still quickly evolving, so I would like to
> > bring the latest new features out as fast as possible (without
> compromising
> > quality of course).
> >
> > As noted recently within the Flink community, the number of outstanding
> >> pull requests and tickets has steadily increased. I'm concerned that
> with
> >> fixed deadlines committer priorities will take precedence and community
> >> contributions will be deferred indefinitely.
> >
> >
> > You are raising a very valid point: Community work hasn't been as good as
> > it was a few months ago, and we should fix that as soon as possible.
> >
> > However, I don't think that time-based releases will change much on that
> > situation. Both models can potentially draw all the attention to the
> > release deadline vs working on community contributions.
> > If you look back at the emails regarding the 1.2.0 release, it was first
> > brought up by Fabian in mid October. Early December, I was starting to
> > track the progress on the release on the ML. From that time (almost two
> > months ago) the committers were focusing a lot on getting their stuff
> into
> > the release. I think that's part of the reason why the community work
> > hasn't been that great recently.
> >
> > Maybe it would make sense to start a separate thread to discuss how we
> can
> > fix the situation with the number of open pull requests?
> >
> >
> > I'm concerned that only blockers are fixed for a .0 release, and that
> >> exactly two weeks are allotted. Will any desirable fix simply become a
> >> blocker or will we potentially release with a list of known bugs?
> >
> >
> > I hope neither will happen too much, if we enforce that big features
> don't
> > get merged in the last minute and thus get enough testing exposure before
> > the merge-window closes.
> > I have to admit that I don't have a lot of experience with a strictly
> > time-based release model, but we should definitively review the process
> > after the 1.3.0 release (and of course ensure that the master is getting
> > stable before the release branch is forked off)
> >
> > The good thing about the time-based release model is, that everybody
> knows
> > well in advance what the dates for feature freeze and code freeze are.
> > So the code freeze should not come as a surprise and people should test
> > and fix their stuff before that happens.
> >
> >
> > Regarding JIRA: I agree that it is not very well maintained right now,
> and
> > that the "fix version" flag is used more as a wish than a plan.
> > I will not move all the 1.2 issues that haven't been closed to 1.3 to
> > avoid having a bad start for the time-based releases.
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Jan 18, 2017 at 5:34 PM, Greg Hogan <[hidden email]> wrote:
> >
> >> I'm +0 on switching to a pre-determined schedule. It may be that the
> Flink
> >> codebase has reached a level of maturity allowing for a time-based
> release
> >> schedule, and I'm hopeful that a known schedule will improve
> communication
> >> about and expectations for new features.
> >>
> >> I'd like to hear a retrospective on the duration of the 1.2 release
> cycle.
> >>
> >> As noted recently within the Flink community, the number of outstanding
> >> pull requests and tickets has steadily increased. I'm concerned that
> with
> >> fixed deadlines committer priorities will take precedence and community
> >> contributions will be deferred indefinitely.
> >>
> >> I'm concerned that only blockers are fixed for a .0 release, and that
> >> exactly two weeks are allotted. Will any desirable fix simply become a
> >> blocker or will we potentially release with a list of known bugs?
> >>
> >> I think it would be worthwhile to identity upgradeable dependencies at
> the
> >> beginning of each release cycle which would allow the most time for
> >> testing
> >> during development.
> >>
> >> There are 130 open tickets scheduled for 1.2.0 [1]. Targeting "inbox
> zero"
> >> (without simply bulk-migrating tickets to another release) would be
> >> preferable to tracking tickets through email chains on the mailing list.
> >> The number of open GitHub pull requests isn't so much as issue since PRs
> >> are simply listed by date, but it would be helpful to keep Jira tickets
> >> up-to-date. It seems that "Fix Version" is often a wish rather than a
> >> plan.
> >>
> >> Greg
> >>
> >> [1]
> >> https://issues.apache.org/jira/browse/FLINK?selectedTab=com.
> >> atlassian.jira.jira-projects-plugin:issues-panel
> >>
> >> On Wed, Jan 18, 2017 at 5:13 AM, Robert Metzger <[hidden email]>
> >> wrote:
> >>
> >> > Thanks a lot for the positive feedback so far.
> >> >
> >> > Thank you Fabian for spotting the off by one error in my email.
> >> > "There are two hard things in computer science: cache invalidation,
> >> naming
> >> > things, and off-by-one errors." (https://twitter.com/codinghor
> >> ror/status/
> >> > 506010907021828096?lang=en)
> >> >
> >> > I agree with Fabian that this model could potentially lead to more
> >> feature
> >> > branches in our repository. However, I think we should only do that
> for
> >> > major features where many contributors are collaborating on. Using
> >> private
> >> > development branches works equally well for smaller groups.
> >> > I found that the frequent "flip6" branch rebases caused a lot of noise
> >> on
> >> > the commits@flink list.
> >> >
> >> > Regarding the "bugfix guarantees":
> >> > I agree that my proposal doesn't make so much sense. I actually got
> the
> >> > same feedback from a draft of my email but forgot to change it before
> >> > sending it out. I think supporting the current (1.1) and previous
> (1.0)
> >> > major release is a doable guarantee.
> >> >
> >> >
> >> >
> >> >
> >> > On Wed, Jan 18, 2017 at 10:25 AM, Vasiliki Kalavri <
> >> > [hidden email]> wrote:
> >> >
> >> > > Hi Robert,
> >> > >
> >> > > thanks a lot for starting this discussion and for putting together
> the
> >> > wiki
> >> > > pages.
> >> > > This proposal makes a lot of sense to me.
> >> > >
> >> > > Big +1 for merging only features which are tested and *documented*.
> >> > >
> >> > > I believe that having a clear timeline will not only make users
> >> happier
> >> > but
> >> > > also contributors more engaged. With the current unpredictability,
> it
> >> is
> >> > > hard to book time aside to help with testing a release candidate. I
> >> hope
> >> > > that knowing exactly when that needs to happen will help us plan our
> >> own
> >> > > time better and help out more.
> >> > >
> >> > > Cheers,
> >> > > -Vasia.
> >> > >
> >> > > On 18 January 2017 at 09:57, Tzu-Li (Gordon) Tai <
> [hidden email]
> >> >
> >> > > wrote:
> >> > >
> >> > > > Hi Robert,
> >> > > >
> >> > > > Thanks for bringing up the discussion. I like the proposal.
> >> > > >
> >> > > > Regarding some of the downsides mentioned in the wiki:
> >> > > >
> >> > > > 1. Features that don’t make it in time with the feature freeze:
> >> > > > I think that’s ok, as long as we’re consistent with the schedules
> >> for
> >> > the
> >> > > > next release. This way users waiting for that particular features
> >> will
> >> > > > still be able to rely on the fact that the feature will be
> included
> >> in
> >> > 4
> >> > > > months.
> >> > > >
> >> > > > 2. Frequent releases mean bug fix releases for older branches:
> >> > > > You mentioned in the email that “old releases are supported for 6
> >> > months
> >> > > > by the community”, but not in the wiki. If this is strictly
> >> followed,
> >> > > that
> >> > > > means we’ll at most be supporting 2 previous major release
> versions
> >> > (ex.
> >> > > as
> >> > > > soon as 1.4.0 comes out, we’ll still be supporting bugfixes for
> >> 1.3.0,
> >> > as
> >> > > > well as 1.2.0 for another 2 months).
> >> > > > This might seem a bit odd, so perhaps we can stick to something
> like
> >> > > > “support bugfixes for the previous 2 major releases”? Ex. Once
> 1.4.0
> >> > > comes
> >> > > > out, we’ll continue to support only 1.4.0 and 1.3.0.
> >> > > > Supporting bugfixes for 2 major versions seems workable, and this
> >> way
> >> > > > users can also have a “buffer” that they should not fall behind
> >> > releases
> >> > > > for more than 2 major versions (8 months) and preplan upgrades.
> >> > > >
> >> > > > - Gordon
> >> > > >
> >> > > > On January 18, 2017 at 9:19:41 AM, Robert Metzger (
> >> [hidden email]
> >> > )
> >> > > > wrote:
> >> > > >
> >> > > > Hi all!
> >> > > >
> >> > > > Since the 1.2.0 release is about to come out, I would like to
> >> propose a
> >> > > > change in the way we do releases in the Flink community.
> >> > > >
> >> > > > In my opinion, the current model leads to dissatisfaction among
> >> users
> >> > and
> >> > > > contributors, because releases are really not predictable. A
> recent
> >> > > example
> >> > > > for the issues with our current model are the FLIP-6 changes we
> >> wanted
> >> > to
> >> > > > merge to master, a few weeks before the first RC for 1.2.0. Also,
> >> there
> >> > > > were some emails on the mailing lists asking for a release date.
> >> > > >
> >> > > > In order to change that, I’m proposing to follow a strictly
> >> time-based
> >> > > > release model. Other open source projects like Ubuntu, Cassandra,
> >> Spark
> >> > > or
> >> > > > Kafka are following that model as well, and I think we should try
> it
> >> > out
> >> > > as
> >> > > > an experiment for the 1.3.0 release.
> >> > > >
> >> > > > I’m proposing to:
> >> > > >
> >> > > > -
> >> > > >
> >> > > > Do a Flink release every 4 months
> >> > > > -
> >> > > >
> >> > > > Cycle:
> >> > > > -
> >> > > >
> >> > > > 3 months development
> >> > > > -
> >> > > >
> >> > > > 1 month before the release: Feature freeze. Create release branch
> >> > > > with RC0, start testing. Only fixes, tests and minor improvements
> >> are
> >> > > > allowed in.
> >> > > > -
> >> > > >
> >> > > > 2 weeks before the release: Code freeze. Start voting. Only fixes
> >> for
> >> > > > blockers are allowed in.
> >> > > > -
> >> > > >
> >> > > > Forbid blocking a release because a feature is not done yet.
> >> > > > -
> >> > > >
> >> > > > Features are merged to master, when they are tested and
> documented,
> >> to
> >> > > > have an always stable master
> >> > > > -
> >> > > >
> >> > > > Bugfix releases are done as needed.
> >> > > > -
> >> > > >
> >> > > > Old releases are supported for 6 months by the Flink community
> with
> >> > > > critical bug fixes
> >> > > >
> >> > > >
> >> > > > This means, that we would have the following release dates:
> >> > > >
> >> > > > (Flink 1.3.0 by end of January 2017)
> >> > > >
> >> > > > Flink 1.4.0 by end of May 2017
> >> > > >
> >> > > > Flink 1.5.0 by end of September 2017
> >> > > >
> >> > > > Flink 1.6.0 by end of January 2018
> >> > > >
> >> > > > I’ve put some more details including some pro’s and con’s into our
> >> > wiki.
> >> > > > The page is based on Kafka’s time-based release wiki page (Kafka
> >> also
> >> > > > recently started following a strictly time-based model)
> >> > > >
> >> > > > https://cwiki.apache.org/confluence/display/FLINK/Time-based
> >> +releases
> >> > > >
> >> > > >
> >> > > > Once we’ve agreed on following that model, I’ll update the release
> >> plan
> >> > > > page accordingly:
> >> > > > https://cwiki.apache.org/confluence/display/FLINK/
> >> > > > Flink+Release+and+Feature+Plan
> >> > > >
> >> > > >
> >> > > > Please let me know what you think about this idea!
> >> > > >
> >> > > > Regards,
> >> > > >
> >> > > > Robert
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Loading...