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 <[email protected]> > > --- > > 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 <[email protected]> Thanks. -- Tom
signature.asc
Description: PGP signature
