[PATCH v2 2/3] doc: develop: process: Rework the custodian feedback section

[Quentin Schulz]

Hi Tom,

On 1/16/26 7:16 PM, Tom Rini wrote:
> Now that we have two items here, rework this slightly to be using bullet
> points, and so easier to expand on.
> 
> Signed-off-by: Tom Rini <trini at konsulko.com>
> ---
> Changes in v2:
> - New patch.
> ---
>   doc/develop/process.rst | 43 +++++++++++++++++++++--------------------
>   1 file changed, 22 insertions(+), 21 deletions(-)
> 
> diff --git a/doc/develop/process.rst b/doc/develop/process.rst
> index 81e1aa7e34db..6f5bdd3db957 100644
> --- a/doc/develop/process.rst
> +++ b/doc/develop/process.rst
> @@ -132,27 +132,28 @@ 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 (which 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.
> -
> -Another form of feedback is about applying the patch itself to the
> -source 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.
> +feedback to the submitter of a patch about what is going on:
> +
> +  * If the patch was accepted, or if it was rejected (which exact list

For another patch as this isn't added/modified by this patch, but wasn't 
"with" meant here instead of "which"?

> +    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.
> +
> +  * If the patch itself can still be applied to the tree. The custodian

Ah, the wording I complained about in patch 1 is gone, so i guess you 
can ignore it. I don't think it makes sense to nitpick about something 
that exists for one commit.

Reviewed-by: Quentin Schulz <quentin.schulz at cherry.de>

Thanks!
Quentin