Files
pmaports-rtwo/docs/modules/ROOT/pages/merging-rules.adoc
T

49 lines
1.9 KiB
Plaintext

= pmaports merging rules =
pmaports follows the general
xref:handbook:Technical-Docs:review-merging-guidelines.adoc[merging rules] with
some specific 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, then 2 any approvals are required.
== Move device from category ==
Moving devices from category is a special operation that requires more work. You
can find further details in the
xref:device-categorization#_review_process[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 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.