From 4084d06f7b84c69b9051e05d85e09a726ff1cf3a Mon Sep 17 00:00:00 2001 From: Oliver Smith Date: Sun, 14 Jun 2026 14:43:13 +0200 Subject: [PATCH] docs: approval-rules: simplify for stable branches Don't describe how MRs to stable branches are done here, link to the other page instead. Otherwise the approval rules should be the same as for stable branches from now on. Signed-off-by: Oliver Smith Part-of: --- docs/merge-requests/approval-rules.md | 13 +++---------- docs/merge-requests/stable-branches.md | 9 +++++---- 2 files changed, 8 insertions(+), 14 deletions(-) diff --git a/docs/merge-requests/approval-rules.md b/docs/merge-requests/approval-rules.md index 65fbd52d4..f2837f7bd 100644 --- a/docs/merge-requests/approval-rules.md +++ b/docs/merge-requests/approval-rules.md @@ -50,14 +50,7 @@ cases, before merging, in addition to the regular approvals, it is required to: device-specific MRs that the team can't test, instead require confirmation of device maintainer that it works. -## Backporting +## Stable branches -Backporting features from edge to stable is done at request of the MR author or -package maintainer. All patches for stable branches must go through edge first -and get backported from there to get additional testing before they potentially -breaks something in stable, and should be tested in the MR too. The only -exception are patches for failures that only happen on stable. - -While backporting patches to stable, label the MR with the corresponding -`backport-to-v*` label, and cherry-pick the commits with the `-x` option, to -make sure that the original commit is mentioned. +[MRs to stable branches](./stable-branches) follow the same approval rules as +to the `main` branch. diff --git a/docs/merge-requests/stable-branches.md b/docs/merge-requests/stable-branches.md index 042f24a02..f93dc840e 100644 --- a/docs/merge-requests/stable-branches.md +++ b/docs/merge-requests/stable-branches.md @@ -14,9 +14,9 @@ release](../releases) branch. edge. * For packages that have a higher version in `main`: if upstream releases a - [patch-release](https://semver.org), an upgrade MR can directly be sent to - the stable branch without the usual main-first-then-backport approach - described below. + patch-release for an older version that we are using in our stable branch, an + upgrade MR can directly be sent to the stable branch without the usual + main-first-then-backport approach described below. ## Workflow @@ -41,7 +41,8 @@ release](../releases) branch. which commits were already picked and which were not. * Avoid cherry-picking multiple patches that touch the same pmaports in the - wrong order. + wrong order. If there's a conflict, consider additionally cherry-picking a + dependent patch beforehand if it's non-intrusive. ### Initial Release Branch Bringup