Jens Reidel
93885e9498
Signed-off-by: Jens Reidel <adrian@postmarketos.org> Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7526>
50 lines
2.1 KiB
Markdown
50 lines
2.1 KiB
Markdown
# 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 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.
|
|
|
|
## Move device from category
|
|
|
|
Moving devices from category is a special operation, see
|
|
[device categorization](./device-categorization).
|
|
|
|
## Enable kernel options across multiple kernels
|
|
|
|
Enable kernel options across multiple kernels can be done in one merge request,
|
|
and requires 2 any approvals from the team, but does not need approvals from
|
|
package maintainers. The reason is that would be too much effort to enable
|
|
kernel options across all kernels. It can be reverted afterwards if there is a
|
|
good reason.
|
|
|
|
## 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. The only exception are patches for 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.
|