From b49e6707726b84f0c3bae19be43b447e3392a596 Mon Sep 17 00:00:00 2001 From: "Tobin C. Harding" Date: Tue, 16 Apr 2024 05:40:23 +1000 Subject: [PATCH] Add backport section to contributing docs 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`. --- CONTRIBUTING.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index bb571d60..1b426e04 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -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