Distributed responsibility for picking

HIP	Title	Author(s)	Created	Type	Status
0010	Distributed responsibility for picking	Marc Khouzam marc.khouzam@montreal.ca	2021-01-28	process	draft

Abstract

The picking of PRs into a release branch is currently the responsibility of the maintainer cutting the release. It is usually the largest part of cutting a release. Improving the picking process would make cutting releases easier with a reduced risk of error.

Motivation

In the current picking process the maintainer that merges a PR is only required to tag that PR with a needs-pick label. The day of the patch release the maintainer cutting the release will go through each PR with a needs-pick label and manually cherry-pick it into the release branch. Once the cherry-pick is done, the picked label is added to the PR.

There are multiple issues with this process:

1. Manual work for the maintainer doing the release to pick each relevant PR.
2. Possible merge conflicts during the cherry-picks as the code on master may have substantially diverged from the code in the release branch. This is particularly concerning as the maintainer cutting the release may not be the one who reviewed the PR in question and may not be familiar with its details, thus making resolving the conflicts difficult and error prone.
3. There is basically no soak time for the cherry-picks or merge conflict resolution code: some quick manual testing and the unit tests are the only tests these changes go through.

Rationale

By cherry-picking PRs as soon as they are merged into the master branch will allow to address the issues mentioned above. It will reduce the manual work required at release time, will reduce the risk of errors during merge conflicts, and will provide more time to soak the release branch content.

Specification

The pick process would be modified to the following:

1. Once a PR is merged into the master branch the needs-pick label will still be applied. This is to reduce the risk of forgetting to cherry-pick a PR.
2. Once the PR is merged into the master branch, it becomes the responsibility of the merging maintainer to cherry-pick it into the release branch; this should be done as soon as possible. The cherry-pick could also be done by another maintainer if desired.
3. Once the cherry-pick into the release branch is done, the cherry-picking maintainer should add the picked label in the original PR.
4. On a regular basis, or at least one week before a patch release date, the list of needs-pick PRs without a picked label should be verified in case any was forgotten.

With this process, the release branch should always be in a state that is ready for release; the maintainer cutting the release does not need to perform any cherry-picking.

For increased quality of patch releases, the release branch can be used by the community at any time, so as to verify no issues are present by the time the release day comes around.

The maintainer doing the cherry-pick could optionally choose to create a PR targeting the release branch instead of directly pushing the cherry-pick. This option could be chosen to obtain a review, for example if merge conflicts were substantial. Such PRs would not need to follow the full PR process but could be merged at the discretion of the maintainers.

Security releases

Security releases are currently cut from the release branch and must only contain the security fix itself. However, with the proposed change to the pick-process, the release branch may contain new commits that should not be part of the security release. To address this, the security release process will require to create a new branch off the last release tag, apply the security fix to that new branch and then build the release from that branch. The security fix must also be applied to the release branch in preparation for a future patch release.

Backwards compatibility

N/A

Security implications

N/A

How to teach this

Each Helm core maintainer should be told about this new process and asked to read the HIP.

Reference implementation

A PR will be posted to update the release checklist to match the new process.