Make Gordon in charge or cherry picking for releases.

[calavera]

Cherry picking PRs into the release branch is the most consuming part of releasing Docker. We should let Gordon do the work for us. This might imply to change the release workflow a little bit, but I think it will be worth it.

TODOs:

1 Gordon needs to have push access to the fork where we create the release branch from if we want to do this. We could add the bot as a collaborator to our repos, but in order to eliminate more human interaction, I think it would be better if we started to create the release branches in one single repo, for instance https://github.com/GordonTheTurtle/docker. We can all the docker maintainers as collaborators to that team to create the initial branches and what not, but we could also automate that if we need to.

2 We need to let Gordon know when we want to cherry pick a pull request, we have several options on how to do this, but I think these two are the most obvious:

• When maintainer comments in a merged PR: @GordonTheTurtle cherry pick into bump_v1.9.0
• When the PR is merged and has an impact label, like impact/v1.9.0

The second option can also be useful to keep track of changes for the changelog.

Every pull request in GitHub has a .patch url assigned, so cherry picking is as easy as these three commands in the right place:

$ curl -SsL https://github.com/docker/docker/pull/15862.patch > /tmp/15862.patch
$ git am < /tmp/15862.patch
$ git push GordonTheTurtle bump_v1.9.0

3 If the merge fails, we should notify the original author of the pull request. It should be up to them to resolve the conflicts to be merged into the release. We should ask them to open a pull request against Gordon's fork with the conflicts resolved. The bot could cherry pick from there if the patch applies and tests pass. This also implies that we should run have a jenkins build for Gordon's repo, but it doesn't sound that bad if you think about it.

[icecrime]

Totally agree we should work on automating the release process.

Also I would add:

• I kind of dream of an API / web UI to manage this (click checkbox to cherry-pick, click button to generate and advertise for an RC, ...) :innocent:
• Have the bot manage the "bump PR", comment in a standard way with a link to the binaries and a link to the changelog when a new RC is issued, maybe even advertise on the newsgroups in a standard format? ;-)

Should we keep docker/leeroy reasonably project agnostic and do this in another tool?

[thaJeztah]

Would it be a problem that the release captain is no longer "in charge" to decide if something actually should be cherry-picked. I know I've sometimes suggested cherry-picking PRs that the release captain didn't agree on (rightfully in many cases :smile:)

Or would the "Gordon" release branch be a "suggested" cherry-pick list, that can later be curated by the release captain?

[icecrime]

Agree with @thajeztah, it should remain in control of the release captain.

[thaJeztah]

Having a list for cherry picking would help though, so some way to have Gordon help with that would be good (perhaps just labels, and creating a checkboxed list with links to suggested PRs in a bump-PR?)

[moxiegirl]

This is something I've wanted for docs. We would most likely use it not just at release time and to automate cherry pick into docs branch. I'm not sure if we could use the same mechanism -- I'm sure we could steal some.

Is there a way where we could mark a PR for a particular release and then just have the cherry pick happen automatically. IOW, oh, this goes into vX.X so Gordon just CPs it in?

[tiborvass]

I'm totally in favor of automating, however if we're about to change things, I'd love to revisit our release logic in Docker.

Basically what I don't like is that we're cherry-picking from master to a-branch-from-which-we-release-that-is-based-on-the-release-branch, for 2 reasons:

• if master and release diverge too much, resolving conflicts on release can add too much risk in introducing bugs, without review.
• when we merge the release branch back into master, both branches have the same behavior but from different commits that are based on diverging branches. This can result in some weird conflicts too.

If instead of cherry-picking PRs that were open against master, we merged PRs that were open against some new branch B (the equivalent of master in http://nvie.com/posts/a-successful-git-branching-model/, where their develop branch is our master branch), then we could do the review on what's actually going to be in release without any weird unreviewed conflict resolution, and also once the release is done, we can backport to our master branch, fixing all potential conflicts. The risk of making a mistake when resolving conflicts with master is less than the risk of making a mistake when resolving conflicts with release.

In practice:

• If you're hotfixing, open a PR against branch B (I don't know what to name it, it's supposed to be master, maybe stable? or just branch 1.8 ?)
• Once everything is ready in branch B, open bump PR against release, it should contain only branch B + bump commit, review and merge bump PR.
• Once bump PR is merged in release, open PR against master to backport all the hotfixes. Here is where we fix all the conflicts when master deviated too much.

[moxiegirl]

@tiborvass does having a branch mean no more RCs?

[tiborvass]

@moxiegirl no, we could still have RCs.

[dnephin]

I think some of this can be automated without a bot, or changing anything about the release process.

We have a set of release scripts in compose that do some of this: https://github.com/docker/compose/tree/master/script/release

Using https://gist.github.com/dnephin/d3f92cc2ab03c5b52424 to iterate over the PRs and cherry-pick-pr (from the compose release scripts) to run the git am automation described in the OP

This uses github PR "updated" order, which is a bit naive. An improvement could be to order all the PRs based on the first commit ordering in the master branch. In practice using the github PR update order has worked for us so far in compose.

When the iteration hits a PR that can't be merged, it can either drop into a shell to allow for a manual merge, or it could abort the git am and instead track the failed PRs (maybe by opening new PRs against the release branch).