24681624eb
See the meeting notes from the 2026-01-19: (https://docs.postmarketos.org/policies-and-processes/governance/team-meetings/meeting-notes.html) > Discussed pmaports!7770, possibly limiting the wait period for maintainer > approval from 2 weeks to 1 week. > > We discussed to keep 2 weeks and make an issue template for “had to merge > without maintainer review”, the new process will then be that the template > gets filled out if a MR has to be merged without maintainer review after > two weeks. The maintainer can then either say that they plan to review > future merge requests, or indicate that they don’t want to maintain the > thing anymore, or just not respond (which implies that they don’t want > to maintain anymore). That way we should be able to get the listed > maintainers to reflect reality better. > > Everyone reading this, please make sure you are not listed as maintainer > for packages that you don’t plan to do reviews for anymore :) Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7770>
2.8 KiB
pmaports Approval Rules
pmaports follows the general code review and merge 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.
Move device from category
Moving devices from category is a special operation, see device categorization.
Changing kconfigcheck requirements
Changes to kconfigcheck.toml are a special operation, see
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.