Skip to content

Commit

Permalink
Add backport section to contributing docs
Browse files Browse the repository at this point in the history
Add a section on how we do backports and what the merge policy is.

Recently I backported a patch by pushing directly to the `0.32.x`
release branch but this is not an optimal process because it leaves no
history on github. Instead PR backports in like we do for patching
`master` but allow one-ACK merging if the backport is a straight cherry
pick of a patch from `master`.
  • Loading branch information
tcharding committed Apr 18, 2024
1 parent 4d9449e commit b49e670
Showing 1 changed file with 13 additions and 0 deletions.
13 changes: 13 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -182,6 +182,19 @@ any of the following conditions:
[1] - The aim is to reduce the burden of re-ACK'ing trivial changes and also
alleviate the problem of devs spread around the world in different timezones.

#### Backporting

We maintain release branches (e.g. `0.32.x` for the `v0.32` releases).

In order to backport changes to these branches the process we use is as follows:

- PR change into `master`.
- Mark the PR with the appropriate labels if backporting is needed (e.g. `port-0.32.x`).
- Once PR merges create another PR that targets the appropriate branch.
- If, and only if, the backport PR is identical to the original PR (i.e. created using
`git cherry-pick`) then the PR may be one-ACK merged.

Any other changes to the release branches should follow the normal 2-ACK merge policy.

## Coding conventions

Expand Down

0 comments on commit b49e670

Please sign in to comment.