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

[Tom Rini]

On Mon, Jan 19, 2026 at 01:17:46PM +0100, Quentin Schulz wrote:
> 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"?

Yes, and it was wrong in the old text but also it's a small enough
change I'll just fold that in with v3.

> > +    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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260119/1081ab11/attachment.sig>