Mailing-List: contact dev-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
MIME-Version: 1.0
In-Reply-To: <CAGr9p8B4b_sujncPrxaRuy5fca_+E3AZ8tGcH1iyB2n-Eqwdxw@mail.gmail.com>
References: <CAGr9p8DtGXq0KPkx_z6mmoMVdyLQjCeVOmptNFifxZgNUZjUKg@mail.gmail.com>
 <etPan.587f2df1.76750ed7.1cc8@apache.org> <CAJZ2dcV_Td2xMv4aPF+7NQY0keNr+bxsFucK8vuhQBruHrm9-w@mail.gmail.com>
 <CAGr9p8AD5L6FL1N207jsJmLrR_2HPbDsXNNChB4iirowz9L=sA@mail.gmail.com>
 <CA+3U0Z=+oC_KzWuBBu=SF=8jvcie=KKnuV6hk0y=qnCKFY48oQ@mail.gmail.com> <CAGr9p8B4b_sujncPrxaRuy5fca_+E3AZ8tGcH1iyB2n-Eqwdxw@mail.gmail.com>
From: Robert Metzger <rmetzger@apache.org>
Date: Mon, 30 Jan 2017 16:03:54 +0100
Message-ID: <CAGr9p8DgsPTBQ9ri0agKOn-e68cUmgbfd=-ck3SUr_vZYMSHAg@mail.gmail.com>
Subject: Re: [DISCUSS] Time-based releases in Flink
To: "dev@flink.apache.org" <dev@flink.apache.org>
Content-Type: multipart/alternative; boundary=001a113a6296fcfe3905475120c8
archived-at: Mon, 30 Jan 2017 15:04:22 -0000

--001a113a6296fcfe3905475120c8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <rmetzger@apache.org> 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 compromisi=
ng
> 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 wit=
h
>> 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 int=
o
> 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 ca=
n
> 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 know=
s
> 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, an=
d
> 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 <code@greghogan.com> wrote:
>
>> I'm +0 on switching to a pre-determined schedule. It may be that the Fli=
nk
>> codebase has reached a level of maturity allowing for a time-based relea=
se
>> schedule, and I'm hopeful that a known schedule will improve communicati=
on
>> about and expectations for new features.
>>
>> I'd like to hear a retrospective on the duration of the 1.2 release cycl=
e.
>>
>> As noted recently within the Flink community, the number of outstanding
>> pull requests and tickets has steadily increased. I'm concerned that wit=
h
>> 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 t=
he
>> 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 zer=
o"
>> (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=3Dcom.
>> atlassian.jira.jira-projects-plugin:issues-panel
>>
>> On Wed, Jan 18, 2017 at 5:13 AM, Robert Metzger <rmetzger@apache.org>
>> 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=3Den)
>> >
>> > 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 fo=
r
>> > 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 th=
e
>> > 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 <
>> > vasilikikalavri@gmail.com> wrote:
>> >
>> > > Hi Robert,
>> > >
>> > > thanks a lot for starting this discussion and for putting together t=
he
>> > 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, i=
t
>> 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 <tzulitai@apache.or=
g
>> >
>> > > 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=E2=80=99t make it in time with the feature fr=
eeze:
>> > > > I think that=E2=80=99s ok, as long as we=E2=80=99re consistent wit=
h 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 include=
d
>> in
>> > 4
>> > > > months.
>> > > >
>> > > > 2. Frequent releases mean bug fix releases for older branches:
>> > > > You mentioned in the email that =E2=80=9Cold releases are supporte=
d for 6
>> > months
>> > > > by the community=E2=80=9D, but not in the wiki. If this is strictl=
y
>> followed,
>> > > that
>> > > > means we=E2=80=99ll at most be supporting 2 previous major release=
 versions
>> > (ex.
>> > > as
>> > > > soon as 1.4.0 comes out, we=E2=80=99ll still be supporting bugfixe=
s 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 li=
ke
>> > > > =E2=80=9Csupport bugfixes for the previous 2 major releases=E2=80=
=9D? Ex. Once 1.4.0
>> > > comes
>> > > > out, we=E2=80=99ll 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 =E2=80=9Cbuffer=E2=80=9D that they should no=
t 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 (
>> rmetzger@apache.org
>> > )
>> > > > 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 recen=
t
>> > > 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=E2=80=99m proposing to follow a strictl=
y
>> 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=E2=80=99m 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 wit=
h
>> > > > 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=E2=80=99ve put some more details including some pro=E2=80=99s an=
d con=E2=80=99s into our
>> > wiki.
>> > > > The page is based on Kafka=E2=80=99s 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=E2=80=99ve agreed on following that model, I=E2=80=99ll up=
date 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
>> > > >
>> > >
>> >
>>
>
>

--001a113a6296fcfe3905475120c8--