Piecuu/pmaports
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

docs: approval-rules: simplify for stable branches

Browse source 
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 <ollieparanoid@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8812>
This commit is contained in:
Oliver Smith 2026-06-14 14:43:13 +02:00 • committed by The Friendly Meow (merge) Bot
parent 8d534ae3d6
commit 4084d06f7b
No known key found for this signature in database
2 changed files with 8 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

13
docs/merge-requests/approval-rules.md
View file

@ -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.

9
docs/merge-requests/stable-branches.md
View file

@ -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