From 3c19b268c212a6fdec16b23da72296a4b027a83f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pablo=20Correa=20G=C3=B3mez?= Date: Thu, 25 Sep 2025 08:38:27 +0200 Subject: [PATCH] docs/merging-rules: update backporting information We haven't released service packs in years, so there's no point to document them as a process. Part-of: --- docs/modules/ROOT/pages/merging-rules.adoc | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/modules/ROOT/pages/merging-rules.adoc b/docs/modules/ROOT/pages/merging-rules.adoc index 58a76389c..bb04c7d5d 100644 --- a/docs/modules/ROOT/pages/merging-rules.adoc +++ b/docs/modules/ROOT/pages/merging-rules.adoc @@ -36,13 +36,13 @@ cases, before merging, in addition to the regular approvals, it is required to: == Backporting == -Backporting features from pmaports edge to stable is done in service packs. So -the new feature has some additional testing time in edge, before it potentially -breaks something in stable. +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. The only exception are patches for failures that +only happen on stable. -Critical fixes can be backported immediately, after proper testing to make sure -that there is no breakage. - -All patches for stable branches must go through edge first and get backported -from there. The only exception are patches that fix build failures that only -happen on stable. +Only some members of the team are allowed to push to stable branches. To get a +patch backported to stable, label the MR with the corresponding `backport-to-v*` +label, and request a Core Contributor to cherry-pick it. Cherry-picking should +be done using `-x` option, to make sure that the original commit is mentioned.