Rules for merging
Workflow
- Use mrhlpr, so we have the MR ID in the commit message.
- Review other people's MRs, and merge their stuff if they have enough approvals (see table below)
Approval requirements
| Critical fixes | Trivial MRs | Any other MRs | Move device from category | Enable kernel options across multiple kernels | |
|---|---|---|---|---|---|
| pmaports | 1 any approval, notify maintainer |
1 any approval | 1 package maintainer approval + 1 any approval |
1 approval from M + 2 CT + 1 CT/TC/M + minimum 1 week | 2 approvals |
| pmbootstrap | 1 any approval, notify maintainers (only CT can merge) |
1 maintainer approval | 1 maintainer approval | does not apply | does not apply |
| Other projects with a maintainer |
1 any approval, notify maintainers |
1 any approval | 1 maintainer approval | does not apply | does not apply |
| Other projects without a maintainer |
1 any approval | 1 any approval | 1 any approval, a maintainer shall be sought |
does not apply | does not apply |
Any approval references anybody with permission to approve.
Maintainers are listed in projects.
Approvals from merge request authors do not count. If the maintainer creates a merge request, "1 approval from M" becomes "1 approval from other maintainer, if such maintainer exists, or otherwise 1 any approval".
Enable kernel options across multiple kernels: can be done in one merge request, does not need approvals from maintainers because then it would be too much effort to enable kernel options across all kernels. It can be reverted afterwards if there is a good reason.
Examples
Critical fixes:
- some devices don't boot anymore without a specific fix
- edge blog posts
Trivial MRs:
- typo fixes
- fix broken links
- aport-kind package upgrades in pmaports
Testing requirements
- pmaports edge: any person in a MR thread confirms that a MR works
- pmaports stable: one person from the team confirms that a MR works
- device specific MRs that the team can't test: require confirmation of device maintainer that it works on stable
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.
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.