vhaudiquet/u-boot-krane
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

doc: develop: process: Rework the custodian feedback section

Browse Source 
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@konsulko.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
This commit is contained in:
Tom Rini
2026-01-28 21:12:04 +01:00
committed by Heinrich Schuchardt
parent 5f6776883c
commit 78e100db5b
1 changed files with 21 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/develop/process.rst
+21 -20
View File
@@ -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.
feedback to the submitter of a patch about what is going on:
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.
* 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.
* 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
------------------------