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 <[email protected] > wrote: > On Mon, May 8, 2017 at 12:57 PM, Davor Bonaci <[email protected]> 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 < > > [email protected]> 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 <[email protected]> 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 <[email protected] > > > >> > 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 <[email protected]> > >> wrote: > >> >> > >> >> > I am +1 on cutting the branch, and the sentiment that we expect the > >> first > >> >> > pancake > >> >> > <https://www.quora.com/Why-do-you-have-to-throw-out-the- > first-pancake > >> > > >> >> > will > >> >> > be not ready to serve customers. > >> >> > > >> >> > On Fri, May 5, 2017 at 11:40 AM, Kenneth Knowles > >> <[email protected] > >> >> > > >> >> > wrote: > >> >> > > >> >> > > On Thu, May 4, 2017 at 12:07 PM, Davor Bonaci <[email protected]> > >> >> 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 > >> >> > > > >> >> > > >> >> > >> >
