doc: develop: process: Move Custodians section

trini · xypron · commit 8449e5c2342a · 2026-01-28T21:13:45.000+01:00
Move the "Custodians" section to be after the "Review Process, Git Tags"
section, in preparation for more re-organization.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
Reviewed-by: Quentin Schulz &lt;quentin.schulz@cherry.de&gt;
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
@@ -120,47 +120,6 @@ these can be "cherry-picked" and are subject to the normal merge rules. For
 example, a bug fix can come in later in the window but a full re-sync only
 happens within the merge window itself.
 
-.. _custodians:
-
-Custodians
-----------
-
-The Custodians take responsibility for some area of the U-Boot code.  The
-in-tree ``MAINTAINERS`` files list who is responsible for which areas.
-
-It is their responsibility to pick up patches from the mailing list
-that fall into their responsibility, and to process these.
-
-A very important responsibility of each custodian is to provide
-feedback to the submitter of a patch about what is going on:
-
-  * If the patch was accepted, or if it was rejected (with exact list
-    of reasons), if it needs to be reworked (with respective review
-    comments). Even a "I have no time now, will look into it later"
-    message is better than nothing. Also, if there are remarks to a
-    patch, these should leave no doubt if they were just comments and
-    the patch will be accepted anyway, or if the patch should be
-    reworked/resubmitted, or if it was rejected. However, if a submitter
-    feels it has been too long since posting their patch and not
-    received any feedback, it is OK to follow-up and ask.
-
-    * A custodian may make changes suggested by :doc:`checkpatch.pl
-      <checkpatch>`. They must also in turn amend the commit message noting
-      their change, for example ``[trini: Fix typos]``, and add their own
-      :ref:`Signed-off-by <dco>` tag. All other changes must be handled by
-      another iteration of the patch, or follow-up patch.
-
-  * If the patch itself can still be applied to the tree. The custodian
-    is expected to put in a "best effort" if a patch does not apply
-    cleanly, but can be made to apply still. It is up to the custodian
-    to decide how recent of a commit the patch must be against. It is
-    acceptable to request patches against the last officially released
-    version of U-Boot or newer. Of course a custodian can also accept
-    patches against older code. It can be difficult to find the correct
-    balance between putting too much work on the custodian or too much
-    work on an individual submitting a patch when something does not
-    apply cleanly.
-
 Review Process, Git Tags
 ------------------------
 
@@ -232,6 +191,47 @@ document.
   For example, when your change affects a specific board or driver, then makes
   a lot of sense to put the respective maintainer of this code on Cc:
 
+.. _custodians:
+
+Custodians
+----------
+
+The Custodians take responsibility for some area of the U-Boot code.  The
+in-tree ``MAINTAINERS`` files list who is responsible for which areas.
+
+It is their responsibility to pick up patches from the mailing list
+that fall into their responsibility, and to process these.
+
+A very important responsibility of each custodian is to provide
+feedback to the submitter of a patch about what is going on:
+
+  * If the patch was accepted, or if it was rejected (with exact list
+    of reasons), if it needs to be reworked (with respective review
+    comments). Even a "I have no time now, will look into it later"
+    message is better than nothing. Also, if there are remarks to a
+    patch, these should leave no doubt if they were just comments and
+    the patch will be accepted anyway, or if the patch should be
+    reworked/resubmitted, or if it was rejected. However, if a submitter
+    feels it has been too long since posting their patch and not
+    received any feedback, it is OK to follow-up and ask.
+
+    * A custodian may make changes suggested by :doc:`checkpatch.pl
+      <checkpatch>`. They must also in turn amend the commit message noting
+      their change, for example ``[trini: Fix typos]``, and add their own
+      :ref:`Signed-off-by <dco>` tag. All other changes must be handled by
+      another iteration of the patch, or follow-up patch.
+
+  * If the patch itself can still be applied to the tree. The custodian
+    is expected to put in a "best effort" if a patch does not apply
+    cleanly, but can be made to apply still. It is up to the custodian
+    to decide how recent of a commit the patch must be against. It is
+    acceptable to request patches against the last officially released
+    version of U-Boot or newer. Of course a custodian can also accept
+    patches against older code. It can be difficult to find the correct
+    balance between putting too much work on the custodian or too much
+    work on an individual submitting a patch when something does not
+    apply cleanly.
+
 Work flow of a Custodian
 ------------------------
 
