Re: Process for getting the first stable release out

[Robert Bradshaw]

On Mon, May 8, 2017 at 1:12 PM, Dan Halperin
 wrote:
> I like putting in master then CPing into release, because we should have a
> high bar for what goes into release. It should absolutely NOT default to
> everything; we should have to justify everything.

Agreed the bar should be high, and "release" should not be the
default. However, for things we know we want to be in the release
(which is much of the work going on right now) it's different. E.g.
instructions like "no backwards compatible changes in master *unless*
you're planning on cherry picking them" would be better stated "no
backwards compatible changes in master" and then the debate about
whether such a change should be in release would happen on the
release-sitting PR.

Right now we're using the master branch as a mix of release-intended
and post-release PRs, which is cumbersome and error-prone.

> E.g., https://github.com/apache/beam/pull/2958 - where I open the CP but
> suggest this may not be worthy for release as it's just cleaning up logs
> and errors.

It's easy to discuss on the PR the best destination, and change it to
be against one or the other before it's merged. There certainly may be
cases where we decide to merge into master to be safe and optionally
CP after the fact, but for many PRs it's clear where they should end
up.

> On Mon, May 8, 2017 at 1:10 PM, Robert Bradshaw > wrote:
>
>> On Mon, May 8, 2017 at 12:57 PM, Davor Bonaci  wrote:
>> > We cannot do (clean) merges; both branches contain unwanted changes in
>> the
>> > other branch. So, we have to cherry-pick regardless where we merge first.
>>
>> Shouldn't the set of changes wanted in release but not in master be
>> quite small (if any)? In that case, one could do an explicit revert
>> following merge from release to master, when needed. The extra work
>> scales in terms of how much we want to diverge (rather than all the
>> changes we want in release that should also be in master, which is the
>> bulk of them, touched by significantly more people.)
>>
>> > With post commits running automatically on master only, that seems like a
>> > logical starting point. But, it doesn't matter really -- either way
>> works.
>> >
>> > On Mon, May 8, 2017 at 12:30 PM, Robert Bradshaw <
>> > rober...@google.com.invalid> wrote:
>> >
>> >> An alternative strategy, given the number of outstanding changes,
>> >> would be to create release-intended PRs against the release branch
>> >> itself, then periodically merge back to master. This would reduce the
>> >> need for manual (and error-prone) cherry-picking.
>> >>
>> >> On Fri, May 5, 2017 at 5:21 PM, Davor Bonaci  wrote:
>> >> > The release branch is now created [1]. Anything for the first stable
>> >> > release should go into master as usual, and then get cherry-picked
>> into
>> >> the
>> >> > release branch.
>> >> >
>> >> > I'll create the first RC shortly and then start a doc around the
>> >> acceptance
>> >> > criteria.
>> >> >
>> >> > From this point onward, backward-incompatible changes should *not* be
>> >> > merged to master, unless they are also getting cherry-picked into the
>> >> > release branch.
>> >> >
>> >> > Davor
>> >> >
>> >> > [1] https://github.com/apache/beam/tree/release-2.0.0
>> >> >
>> >> > On Fri, May 5, 2017 at 1:57 PM, Thomas Groh > >
>> >> > wrote:
>> >> >
>> >> >> I'm also +1 on the branch. It'll help us make sure that what we're
>> >> getting
>> >> >> in is what we need for the FSR.
>> >> >>
>> >> >> On Fri, May 5, 2017 at 12:41 PM, Dan Halperin 
>> >> wrote:
>> >> >>
>> >> >> > I am +1 on cutting the branch, and the sentiment that we expect the
>> >> first
>> >> >> > pancake
>> >> >> > > first-pancake
>> >> >
>> >> >> > will
>> >> >> > be not ready to serve customers.
>> >> >> >
>> >> >> > On Fri, May 5, 2017 at 11:40 AM, Kenneth Knowles
>> >> > >> >> >
>> >> >> > wrote:
>> >> >> >
>> >> >> > > On Thu, May 4, 2017 at 12:07 PM, Davor Bonaci 
>> >> >> wrote:
>> >> >> > >
>> >> >> > > > I'd like to propose the following (tweaked) process for this
>> >> special
>> >> >> > > > release:
>> >> >> > > >
>> >> >> > > > * Create a release branch, and start building release
>> candidates
>> >> >> *now*
>> >> >> > > > This would accelerate branch creation compared to the normal
>> >> process,
>> >> >> > but
>> >> >> > > > would separate the first stable release from other development
>> on
>> >> the
>> >> >> > > > master branch. This yields to stability and avoids unnecessary
>> >> churn.
>> >> >> > > >
>> >> >> > >
>> >> >> > > +1 to cutting a release branch now.
>> >> >> > >
>> >> >> > > This sounds compatible with the release process [1] to me,
>> actually.
>> >> >> This
>> >> >> > > thread seems like the dev@ thread where we "decide to release"
>> and
>> >> I
>> >> >> > agree
>> 

Re: Process for getting the first stable release out

[Dan Halperin]

I like putting in master then CPing into release, because we should have a
high bar for what goes into release. It should absolutely NOT default to
everything; we should have to justify everything.

E.g., https://github.com/apache/beam/pull/2958 - where I open the CP but
suggest this may not be worthy for release as it's just cleaning up logs
and errors.

On Mon, May 8, 2017 at 1:10 PM, Robert Bradshaw  wrote:

> On Mon, May 8, 2017 at 12:57 PM, Davor Bonaci  wrote:
> > We cannot do (clean) merges; both branches contain unwanted changes in
> the
> > other branch. So, we have to cherry-pick regardless where we merge first.
>
> Shouldn't the set of changes wanted in release but not in master be
> quite small (if any)? In that case, one could do an explicit revert
> following merge from release to master, when needed. The extra work
> scales in terms of how much we want to diverge (rather than all the
> changes we want in release that should also be in master, which is the
> bulk of them, touched by significantly more people.)
>
> > With post commits running automatically on master only, that seems like a
> > logical starting point. But, it doesn't matter really -- either way
> works.
> >
> > On Mon, May 8, 2017 at 12:30 PM, Robert Bradshaw <
> > rober...@google.com.invalid> wrote:
> >
> >> An alternative strategy, given the number of outstanding changes,
> >> would be to create release-intended PRs against the release branch
> >> itself, then periodically merge back to master. This would reduce the
> >> need for manual (and error-prone) cherry-picking.
> >>
> >> On Fri, May 5, 2017 at 5:21 PM, Davor Bonaci  wrote:
> >> > The release branch is now created [1]. Anything for the first stable
> >> > release should go into master as usual, and then get cherry-picked
> into
> >> the
> >> > release branch.
> >> >
> >> > I'll create the first RC shortly and then start a doc around the
> >> acceptance
> >> > criteria.
> >> >
> >> > From this point onward, backward-incompatible changes should *not* be
> >> > merged to master, unless they are also getting cherry-picked into the
> >> > release branch.
> >> >
> >> > Davor
> >> >
> >> > [1] https://github.com/apache/beam/tree/release-2.0.0
> >> >
> >> > On Fri, May 5, 2017 at 1:57 PM, Thomas Groh  >
> >> > wrote:
> >> >
> >> >> I'm also +1 on the branch. It'll help us make sure that what we're
> >> getting
> >> >> in is what we need for the FSR.
> >> >>
> >> >> On Fri, May 5, 2017 at 12:41 PM, Dan Halperin 
> >> wrote:
> >> >>
> >> >> > I am +1 on cutting the branch, and the sentiment that we expect the
> >> first
> >> >> > pancake
> >> >> >  first-pancake
> >> >
> >> >> > will
> >> >> > be not ready to serve customers.
> >> >> >
> >> >> > On Fri, May 5, 2017 at 11:40 AM, Kenneth Knowles
> >>  >> >> >
> >> >> > wrote:
> >> >> >
> >> >> > > On Thu, May 4, 2017 at 12:07 PM, Davor Bonaci 
> >> >> wrote:
> >> >> > >
> >> >> > > > I'd like to propose the following (tweaked) process for this
> >> special
> >> >> > > > release:
> >> >> > > >
> >> >> > > > * Create a release branch, and start building release
> candidates
> >> >> *now*
> >> >> > > > This would accelerate branch creation compared to the normal
> >> process,
> >> >> > but
> >> >> > > > would separate the first stable release from other development
> on
> >> the
> >> >> > > > master branch. This yields to stability and avoids unnecessary
> >> churn.
> >> >> > > >
> >> >> > >
> >> >> > > +1 to cutting a release branch now.
> >> >> > >
> >> >> > > This sounds compatible with the release process [1] to me,
> actually.
> >> >> This
> >> >> > > thread seems like the dev@ thread where we "decide to release"
> and
> >> I
> >> >> > agree
> >> >> > > that we should decide to release. Certainly `master` is not ready
> >> nor
> >> >> is
> >> >> > > the web site - there are ~29 issues as I write this though many
> are
> >> not
> >> >> > > really significant code changes. But we should never wait until
> >> >> `master`
> >> >> > is
> >> >> > > "ready".
> >> >> > >
> >> >> > > We know what we want to get done, and there are no radical
> changes,
> >> so
> >> >> I
> >> >> > > think that makes this the right time to branch. We can easily
> cherry
> >> >> pick
> >> >> > > fixes for our burndown list to ensure we don't introduce
> additional
> >> >> > > blockers.
> >> >> > >
> >> >> > > Some of the burndown list are of the form "investigate if this
> >> >> suspected
> >> >> > > bug still repros" and a release candidate is the perfect thing to
> >> use
> >> >> for
> >> >> > > that.
> >> >> > >
> >> >> > > [1] https://beam.apache.org/contribute/release-guide/#
> >> >> decide-to-release
> >> >> > >
> >> >> >
> >> >>
> >>
>

Re: Process for getting the first stable release out

[Robert Bradshaw]

On Mon, May 8, 2017 at 12:57 PM, Davor Bonaci  wrote:
> We cannot do (clean) merges; both branches contain unwanted changes in the
> other branch. So, we have to cherry-pick regardless where we merge first.

Shouldn't the set of changes wanted in release but not in master be
quite small (if any)? In that case, one could do an explicit revert
following merge from release to master, when needed. The extra work
scales in terms of how much we want to diverge (rather than all the
changes we want in release that should also be in master, which is the
bulk of them, touched by significantly more people.)

> With post commits running automatically on master only, that seems like a
> logical starting point. But, it doesn't matter really -- either way works.
>
> On Mon, May 8, 2017 at 12:30 PM, Robert Bradshaw <
> rober...@google.com.invalid> wrote:
>
>> An alternative strategy, given the number of outstanding changes,
>> would be to create release-intended PRs against the release branch
>> itself, then periodically merge back to master. This would reduce the
>> need for manual (and error-prone) cherry-picking.
>>
>> On Fri, May 5, 2017 at 5:21 PM, Davor Bonaci  wrote:
>> > The release branch is now created [1]. Anything for the first stable
>> > release should go into master as usual, and then get cherry-picked into
>> the
>> > release branch.
>> >
>> > I'll create the first RC shortly and then start a doc around the
>> acceptance
>> > criteria.
>> >
>> > From this point onward, backward-incompatible changes should *not* be
>> > merged to master, unless they are also getting cherry-picked into the
>> > release branch.
>> >
>> > Davor
>> >
>> > [1] https://github.com/apache/beam/tree/release-2.0.0
>> >
>> > On Fri, May 5, 2017 at 1:57 PM, Thomas Groh 
>> > wrote:
>> >
>> >> I'm also +1 on the branch. It'll help us make sure that what we're
>> getting
>> >> in is what we need for the FSR.
>> >>
>> >> On Fri, May 5, 2017 at 12:41 PM, Dan Halperin 
>> wrote:
>> >>
>> >> > I am +1 on cutting the branch, and the sentiment that we expect the
>> first
>> >> > pancake
>> >> > > >
>> >> > will
>> >> > be not ready to serve customers.
>> >> >
>> >> > On Fri, May 5, 2017 at 11:40 AM, Kenneth Knowles
>> > >> >
>> >> > wrote:
>> >> >
>> >> > > On Thu, May 4, 2017 at 12:07 PM, Davor Bonaci 
>> >> wrote:
>> >> > >
>> >> > > > I'd like to propose the following (tweaked) process for this
>> special
>> >> > > > release:
>> >> > > >
>> >> > > > * Create a release branch, and start building release candidates
>> >> *now*
>> >> > > > This would accelerate branch creation compared to the normal
>> process,
>> >> > but
>> >> > > > would separate the first stable release from other development on
>> the
>> >> > > > master branch. This yields to stability and avoids unnecessary
>> churn.
>> >> > > >
>> >> > >
>> >> > > +1 to cutting a release branch now.
>> >> > >
>> >> > > This sounds compatible with the release process [1] to me, actually.
>> >> This
>> >> > > thread seems like the dev@ thread where we "decide to release" and
>> I
>> >> > agree
>> >> > > that we should decide to release. Certainly `master` is not ready
>> nor
>> >> is
>> >> > > the web site - there are ~29 issues as I write this though many are
>> not
>> >> > > really significant code changes. But we should never wait until
>> >> `master`
>> >> > is
>> >> > > "ready".
>> >> > >
>> >> > > We know what we want to get done, and there are no radical changes,
>> so
>> >> I
>> >> > > think that makes this the right time to branch. We can easily cherry
>> >> pick
>> >> > > fixes for our burndown list to ensure we don't introduce additional
>> >> > > blockers.
>> >> > >
>> >> > > Some of the burndown list are of the form "investigate if this
>> >> suspected
>> >> > > bug still repros" and a release candidate is the perfect thing to
>> use
>> >> for
>> >> > > that.
>> >> > >
>> >> > > [1] https://beam.apache.org/contribute/release-guide/#
>> >> decide-to-release
>> >> > >
>> >> >
>> >>
>>

Re: Process for getting the first stable release out

[Davor Bonaci]

We cannot do (clean) merges; both branches contain unwanted changes in the
other branch. So, we have to cherry-pick regardless where we merge first.
With post commits running automatically on master only, that seems like a
logical starting point. But, it doesn't matter really -- either way works.

On Mon, May 8, 2017 at 12:30 PM, Robert Bradshaw <
rober...@google.com.invalid> wrote:

> An alternative strategy, given the number of outstanding changes,
> would be to create release-intended PRs against the release branch
> itself, then periodically merge back to master. This would reduce the
> need for manual (and error-prone) cherry-picking.
>
> On Fri, May 5, 2017 at 5:21 PM, Davor Bonaci  wrote:
> > The release branch is now created [1]. Anything for the first stable
> > release should go into master as usual, and then get cherry-picked into
> the
> > release branch.
> >
> > I'll create the first RC shortly and then start a doc around the
> acceptance
> > criteria.
> >
> > From this point onward, backward-incompatible changes should *not* be
> > merged to master, unless they are also getting cherry-picked into the
> > release branch.
> >
> > Davor
> >
> > [1] https://github.com/apache/beam/tree/release-2.0.0
> >
> > On Fri, May 5, 2017 at 1:57 PM, Thomas Groh 
> > wrote:
> >
> >> I'm also +1 on the branch. It'll help us make sure that what we're
> getting
> >> in is what we need for the FSR.
> >>
> >> On Fri, May 5, 2017 at 12:41 PM, Dan Halperin 
> wrote:
> >>
> >> > I am +1 on cutting the branch, and the sentiment that we expect the
> first
> >> > pancake
> >> >  >
> >> > will
> >> > be not ready to serve customers.
> >> >
> >> > On Fri, May 5, 2017 at 11:40 AM, Kenneth Knowles
>  >> >
> >> > wrote:
> >> >
> >> > > On Thu, May 4, 2017 at 12:07 PM, Davor Bonaci 
> >> wrote:
> >> > >
> >> > > > I'd like to propose the following (tweaked) process for this
> special
> >> > > > release:
> >> > > >
> >> > > > * Create a release branch, and start building release candidates
> >> *now*
> >> > > > This would accelerate branch creation compared to the normal
> process,
> >> > but
> >> > > > would separate the first stable release from other development on
> the
> >> > > > master branch. This yields to stability and avoids unnecessary
> churn.
> >> > > >
> >> > >
> >> > > +1 to cutting a release branch now.
> >> > >
> >> > > This sounds compatible with the release process [1] to me, actually.
> >> This
> >> > > thread seems like the dev@ thread where we "decide to release" and
> I
> >> > agree
> >> > > that we should decide to release. Certainly `master` is not ready
> nor
> >> is
> >> > > the web site - there are ~29 issues as I write this though many are
> not
> >> > > really significant code changes. But we should never wait until
> >> `master`
> >> > is
> >> > > "ready".
> >> > >
> >> > > We know what we want to get done, and there are no radical changes,
> so
> >> I
> >> > > think that makes this the right time to branch. We can easily cherry
> >> pick
> >> > > fixes for our burndown list to ensure we don't introduce additional
> >> > > blockers.
> >> > >
> >> > > Some of the burndown list are of the form "investigate if this
> >> suspected
> >> > > bug still repros" and a release candidate is the perfect thing to
> use
> >> for
> >> > > that.
> >> > >
> >> > > [1] https://beam.apache.org/contribute/release-guide/#
> >> decide-to-release
> >> > >
> >> >
> >>
>

Re: Process for getting the first stable release out

[Davor Bonaci]

The release branch is now created [1]. Anything for the first stable
release should go into master as usual, and then get cherry-picked into the
release branch.

I'll create the first RC shortly and then start a doc around the acceptance
criteria.

>From this point onward, backward-incompatible changes should *not* be
merged to master, unless they are also getting cherry-picked into the
release branch.

Davor

[1] https://github.com/apache/beam/tree/release-2.0.0

On Fri, May 5, 2017 at 1:57 PM, Thomas Groh 
wrote:

> I'm also +1 on the branch. It'll help us make sure that what we're getting
> in is what we need for the FSR.
>
> On Fri, May 5, 2017 at 12:41 PM, Dan Halperin  wrote:
>
> > I am +1 on cutting the branch, and the sentiment that we expect the first
> > pancake
> > 
> > will
> > be not ready to serve customers.
> >
> > On Fri, May 5, 2017 at 11:40 AM, Kenneth Knowles  >
> > wrote:
> >
> > > On Thu, May 4, 2017 at 12:07 PM, Davor Bonaci 
> wrote:
> > >
> > > > I'd like to propose the following (tweaked) process for this special
> > > > release:
> > > >
> > > > * Create a release branch, and start building release candidates
> *now*
> > > > This would accelerate branch creation compared to the normal process,
> > but
> > > > would separate the first stable release from other development on the
> > > > master branch. This yields to stability and avoids unnecessary churn.
> > > >
> > >
> > > +1 to cutting a release branch now.
> > >
> > > This sounds compatible with the release process [1] to me, actually.
> This
> > > thread seems like the dev@ thread where we "decide to release" and I
> > agree
> > > that we should decide to release. Certainly `master` is not ready nor
> is
> > > the web site - there are ~29 issues as I write this though many are not
> > > really significant code changes. But we should never wait until
> `master`
> > is
> > > "ready".
> > >
> > > We know what we want to get done, and there are no radical changes, so
> I
> > > think that makes this the right time to branch. We can easily cherry
> pick
> > > fixes for our burndown list to ensure we don't introduce additional
> > > blockers.
> > >
> > > Some of the burndown list are of the form "investigate if this
> suspected
> > > bug still repros" and a release candidate is the perfect thing to use
> for
> > > that.
> > >
> > > [1] https://beam.apache.org/contribute/release-guide/#
> decide-to-release
> > >
> >
>

Re: Process for getting the first stable release out

[Thomas Groh]

I'm also +1 on the branch. It'll help us make sure that what we're getting
in is what we need for the FSR.

On Fri, May 5, 2017 at 12:41 PM, Dan Halperin  wrote:

> I am +1 on cutting the branch, and the sentiment that we expect the first
> pancake
> 
> will
> be not ready to serve customers.
>
> On Fri, May 5, 2017 at 11:40 AM, Kenneth Knowles 
> wrote:
>
> > On Thu, May 4, 2017 at 12:07 PM, Davor Bonaci  wrote:
> >
> > > I'd like to propose the following (tweaked) process for this special
> > > release:
> > >
> > > * Create a release branch, and start building release candidates *now*
> > > This would accelerate branch creation compared to the normal process,
> but
> > > would separate the first stable release from other development on the
> > > master branch. This yields to stability and avoids unnecessary churn.
> > >
> >
> > +1 to cutting a release branch now.
> >
> > This sounds compatible with the release process [1] to me, actually. This
> > thread seems like the dev@ thread where we "decide to release" and I
> agree
> > that we should decide to release. Certainly `master` is not ready nor is
> > the web site - there are ~29 issues as I write this though many are not
> > really significant code changes. But we should never wait until `master`
> is
> > "ready".
> >
> > We know what we want to get done, and there are no radical changes, so I
> > think that makes this the right time to branch. We can easily cherry pick
> > fixes for our burndown list to ensure we don't introduce additional
> > blockers.
> >
> > Some of the burndown list are of the form "investigate if this suspected
> > bug still repros" and a release candidate is the perfect thing to use for
> > that.
> >
> > [1] https://beam.apache.org/contribute/release-guide/#decide-to-release
> >
>

Re: Process for getting the first stable release out

[Aviem Zur]

+1.

A document similar to the one we had for the Hackathon could serve us here
again.
A section for acceptance criteria compiled by the community and a matrix of
tests per runner to be filled for each RC version could help us synchronize
and get there.

On Fri, May 5, 2017 at 10:42 PM Dan Halperin  wrote:

> I am +1 on cutting the branch, and the sentiment that we expect the first
> pancake
> 
> will
> be not ready to serve customers.
>
> On Fri, May 5, 2017 at 11:40 AM, Kenneth Knowles 
> wrote:
>
> > On Thu, May 4, 2017 at 12:07 PM, Davor Bonaci  wrote:
> >
> > > I'd like to propose the following (tweaked) process for this special
> > > release:
> > >
> > > * Create a release branch, and start building release candidates *now*
> > > This would accelerate branch creation compared to the normal process,
> but
> > > would separate the first stable release from other development on the
> > > master branch. This yields to stability and avoids unnecessary churn.
> > >
> >
> > +1 to cutting a release branch now.
> >
> > This sounds compatible with the release process [1] to me, actually. This
> > thread seems like the dev@ thread where we "decide to release" and I
> agree
> > that we should decide to release. Certainly `master` is not ready nor is
> > the web site - there are ~29 issues as I write this though many are not
> > really significant code changes. But we should never wait until `master`
> is
> > "ready".
> >
> > We know what we want to get done, and there are no radical changes, so I
> > think that makes this the right time to branch. We can easily cherry pick
> > fixes for our burndown list to ensure we don't introduce additional
> > blockers.
> >
> > Some of the burndown list are of the form "investigate if this suspected
> > bug still repros" and a release candidate is the perfect thing to use for
> > that.
> >
> > [1] https://beam.apache.org/contribute/release-guide/#decide-to-release
> >
>

Re: Process for getting the first stable release out

[Dan Halperin]

I am +1 on cutting the branch, and the sentiment that we expect the first
pancake
 will
be not ready to serve customers.

On Fri, May 5, 2017 at 11:40 AM, Kenneth Knowles 
wrote:

> On Thu, May 4, 2017 at 12:07 PM, Davor Bonaci  wrote:
>
> > I'd like to propose the following (tweaked) process for this special
> > release:
> >
> > * Create a release branch, and start building release candidates *now*
> > This would accelerate branch creation compared to the normal process, but
> > would separate the first stable release from other development on the
> > master branch. This yields to stability and avoids unnecessary churn.
> >
>
> +1 to cutting a release branch now.
>
> This sounds compatible with the release process [1] to me, actually. This
> thread seems like the dev@ thread where we "decide to release" and I agree
> that we should decide to release. Certainly `master` is not ready nor is
> the web site - there are ~29 issues as I write this though many are not
> really significant code changes. But we should never wait until `master` is
> "ready".
>
> We know what we want to get done, and there are no radical changes, so I
> think that makes this the right time to branch. We can easily cherry pick
> fixes for our burndown list to ensure we don't introduce additional
> blockers.
>
> Some of the burndown list are of the form "investigate if this suspected
> bug still repros" and a release candidate is the perfect thing to use for
> that.
>
> [1] https://beam.apache.org/contribute/release-guide/#decide-to-release
>

Re: Process for getting the first stable release out

[Kenneth Knowles]

On Thu, May 4, 2017 at 12:07 PM, Davor Bonaci  wrote:

> I'd like to propose the following (tweaked) process for this special
> release:
>
> * Create a release branch, and start building release candidates *now*
> This would accelerate branch creation compared to the normal process, but
> would separate the first stable release from other development on the
> master branch. This yields to stability and avoids unnecessary churn.
>

+1 to cutting a release branch now.

This sounds compatible with the release process [1] to me, actually. This
thread seems like the dev@ thread where we "decide to release" and I agree
that we should decide to release. Certainly `master` is not ready nor is
the web site - there are ~29 issues as I write this though many are not
really significant code changes. But we should never wait until `master` is
"ready".

We know what we want to get done, and there are no radical changes, so I
think that makes this the right time to branch. We can easily cherry pick
fixes for our burndown list to ensure we don't introduce additional
blockers.

Some of the burndown list are of the form "investigate if this suspected
bug still repros" and a release candidate is the perfect thing to use for
that.

[1] https://beam.apache.org/contribute/release-guide/#decide-to-release