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"?
+ 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!
Quentin
