doc: release: move merge criteria under release process

Merge criteria does not beling under project role, move it under release
process.

Signed-off-by: Anas Nashif <[email protected]>

Author: nashif

doc/project/project_roles.rst

@@ -349,72 +349,4 @@ Generic guidelines for deciding and filling in the Maintainers' list
     implementation
 
 
-Release Activity
-################
-
-    .. figure:: img/img_release_activity.png
-         :width: 663px
-         :align: center
-         :alt: Release Activity
-
-.. _merge_criteria:
-
-Merge Criteria
-++++++++++++++
-
-* All :ref:`pr_requirements` must be met.
-* Minimal of 2 approvals, including an approval by the designated assignee.
-* Pull requests should be reviewed by at least a maintainer or collaborator of
-  each affected area; Unless the changes to a given area are considered trivial
-  enough, in which case approvals by other affected subsystems
-  maintainers/collaborators would suffice.
-* Four eye principle on the organisation level. We already require at least 2
-  approvals (basic four eye principle), however, such reviews and approvals
-  might be unintentionally biased in the case where the submitter is from the
-  same organisation as the approvers. To allow for project wide review and
-  approvals, the merge criteria is extended with the guidelines below:
-
-  * Changes or additions to common and shared code shall have approvals from
-    different organisations (at least one approval from an
-    organisation different than the submitters').
-    Common and shared code is defined as anything that does not fall under
-    :file:`soc`, :file:`boards` and :file:`drivers/*/*`.
-  * Changes or additions to hardware support (driver, SoC, boards) shall at
-    least have the merger be from a different organisation. This applies only
-    to implementation of an API supporting vendor specific hardware and not the
-    APIs.
-  * Release engineers may make exceptions for areas with contributions primarily
-    coming from one organisation and where reviews from other organisations are
-    not possible, however, merges shall be completed by a person from a different
-    organisation. In such cases, the minimum review period of at least 2 days
-    shall be strictly followed to allow for additional reviews.
-  * Release engineers shall not merge code changes originating and reviewed
-    only by their own organisation. To be able to merge such changes, at least
-    one review shall be from a different organisation.
-
-* A minimum review period of 2 business days, 4 hours for trivial changes (see
-  :ref:`review_time`).
-* Hotfixes can be merged at any time after CI has passed and are excluded from
-  most of the conditions listed above.
-* All required checks are passing:
-
-  * Device Tree
-  * Documentation
-  * Code linters (Gitlint, Pylint, Ruff, Sphinx, etc.)
-  * Identity/Emails
-  * Kconfig
-  * License checks
-  * Checkpatch (Coding Style)
-  * Integration Tests (Via twister) on emulation/simulation platforms
-  * Simulated Bluetooth Tests
-
-* Planned
-
-  * Footprint
-  * Code coverage
-  * Coding Guidelines
-  * Static Analysis (Coverity)
-  * Documentation coverage (APIs)
-
-
 .. _Zephyr Contributor Badge form: https://forms.gle/oCw9iAPLhUsHTapc8

doc/project/release_process.rst

@@ -51,6 +51,71 @@ The Zephyr release model was loosely based on the Linux kernel model:
     `Official GitHub Wiki <https://github.com/zephyrproject-rtos/zephyr/wiki/Release-Management>`_.
     Information on previous releases can be found :ref:`here <zephyr_release_notes>`.
 
+
+.. _merge_criteria:
+
+Merge Criteria
+**************
+
+.. figure:: img/img_release_activity.png
+      :width: 663px
+      :align: center
+      :alt: Release Activity
+
+* All :ref:`pr_requirements` must be met.
+* Minimal of 2 approvals, including an approval by the designated assignee.
+* Pull requests should be reviewed by at least a maintainer or collaborator of
+  each affected area; Unless the changes to a given area are considered trivial
+  enough, in which case approvals by other affected subsystems
+  maintainers/collaborators would suffice.
+* Four eye principle on the organisation level. We already require at least 2
+  approvals (basic four eye principle), however, such reviews and approvals
+  might be unintentionally biased in the case where the submitter is from the
+  same organisation as the approvers. To allow for project wide review and
+  approvals, the merge criteria is extended with the guidelines below:
+
+  * Changes or additions to common and shared code shall have approvals from
+    different organisations (at least one approval from an
+    organisation different than the submitters').
+    Common and shared code is defined as anything that does not fall under
+    :file:`soc`, :file:`boards` and :file:`drivers/*/*`.
+  * Changes or additions to hardware support (driver, SoC, boards) shall at
+    least have the merger be from a different organisation. This applies only
+    to implementation of an API supporting vendor specific hardware and not the
+    APIs.
+  * Release engineers may make exceptions for areas with contributions primarily
+    coming from one organisation and where reviews from other organisations are
+    not possible, however, merges shall be completed by a person from a different
+    organisation. In such cases, the minimum review period of at least 2 days
+    shall be strictly followed to allow for additional reviews.
+  * Release engineers shall not merge code changes originating and reviewed
+    only by their own organisation. To be able to merge such changes, at least
+    one review shall be from a different organisation.
+
+* A minimum review period of 2 business days, 4 hours for trivial changes (see
+  :ref:`review_time`).
+* Hotfixes can be merged at any time after CI has passed and are excluded from
+  most of the conditions listed above.
+* All required checks are passing:
+
+  * Device Tree
+  * Documentation
+  * Code linters (Gitlint, Pylint, Ruff, Sphinx, etc.)
+  * Identity/Emails
+  * Kconfig
+  * License checks
+  * Checkpatch (Coding Style)
+  * Integration Tests (Via twister) on emulation/simulation platforms
+  * Simulated Bluetooth Tests
+
+* Planned
+
+  * Footprint
+  * Code coverage
+  * Coding Guidelines
+  * Static Analysis (Coverity)
+  * Documentation coverage (APIs)
+
 Development Phase
 *****************