Move the "Custodians" section to be after the "Review Process, Git Tags" section, in preparation for more re-organization.
Signed-off-by: Tom Rini <[email protected]> --- doc/develop/process.rst | 82 ++++++++++++++++++++--------------------- 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/doc/develop/process.rst b/doc/develop/process.rst index 0651a1c23a48..3bda5e6b51dd 100644 --- 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 ------------------------ -- 2.43.0
