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

docs: structure: move merge-requests related pages

Browse source 
Add a new "merge requests" page and move all related pages under that
page to give the docs more structure.

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 13:35:30 +02:00 • committed by The Friendly Meow (merge) Bot
parent ae07d28bfb
commit ac931d4507
No known key found for this signature in database
8 changed files with 17 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

63
docs/merge-requests/approval-rules.md Normal file
View file

@ -0,0 +1,63 @@
# pmaports Approval Rules
pmaports follows the general
[code review and merge](https://docs.postmarketos.org/policies-and-processes/development/code-review-and-merge.html)
rules, but with the following changes.
## Regular MR approvals
Most MRs, those not considered critical or trivial require approval by the
package maintainer, and by another team member with approval and merge
rights. If the author of the merge request is the sole maintainer of a package
it is sufficient to solely have the approval a team member.
If there is no package maintainer or the package maintainer does not
reply within 2 weeks from the time the MR was opened, then any 2 approvals are
required. When you merge a MR with no maintainer response, open a issue with the
issue template: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/issues/new?description_template=Maintainership_status_of_package>.
If there are multiple maintainers, an approval from any maintainer is sufficient
to satisfy the "approval by the package maintainer" criteria (i.e., not every
maintainer needs to approve it—only one). However, when a maintainer submits a
merge request for a package with multiple maintainers, co-maintainers must be
given a 48-hour review window (starting when they're notified, typically via the
automated GitLab ping). After this window expires, the merge request can proceed
with any 2 approvals from team members. The submitting maintainer may choose to
block the merge request to wait for co-maintainer review beyond the 48-hour
window if desired.
The following flowchart describes the process:
![Approval rules](./approval-rules.svg)
## Move device from category
Moving devices from category is a special operation, see
[device categorization](../device-categorization).
## Changing kconfigcheck requirements
Changes to `kconfigcheck.toml` are a special operation, see
[kconfigcheck](../kconfigcheck).
## Testing requirements
Some MRs require testing due to changes affecting multiple devices. In such
cases, before merging, in addition to the regular approvals, it is required to:
* **edge**: any person in a MR thread confirms that a MR works.
* **stable**: one person from the team confirms that a MR works. On
device-specific MRs that the team can't test, instead require confirmation of
device maintainer that it works.
## Backporting
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.