As seen with a recent pull request, there have been implicit assumptions about how much custodians can change patches before applying and merging them. This has lead to an unfortunate situation with a contributor being understandably upset about the changes.
To avoid this in the future, document a few things: - Non-trivial changes to make something apply need to have at least [name: what] in the commit message. - Only trivial and obviously correct changes can be made by the custodian, and ideally this is done in a merge commit and not the patch itself. - It is the responsibility of the custodian to gather relevant tags that have been provided by the community. Link: https://lore.kernel.org/u-boot/[email protected]/ Signed-off-by: Tom Rini <[email protected]> --- With this, Heinrich, per E Shattow's comment on IRC, can you please revert the commit in question, then apply his patch as-is, and then your changes as a new patch in order to show correct history? And I realize at this point the subsection of this document is a bit wordy. Maybe a follow-up of restructuring this part of the document would be helpful? I'm not sure what would flow better however. Cc: E Shattow <[email protected]> Cc: Heinrich Schuchardt <[email protected]> Cc: Quentin Schulz <[email protected]> --- doc/develop/process.rst | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/doc/develop/process.rst b/doc/develop/process.rst index 4bfbf0eb9c63..84ab09132a0b 100644 --- a/doc/develop/process.rst +++ b/doc/develop/process.rst @@ -244,7 +244,12 @@ like this: 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. + something does not apply cleanly. If non-trivial changes need to be made + for it to apply the custodian is expected to annotate the commit message + with ``[name: note about changes made]``. Furthermore, only trivial and + obviously correct changes can be made, no other changes should be made to + the patch itself. Ideally all of these changes will be in a merge commit, + and not the commit itself, but that is not always possible. #. Passes :doc:`ci_testing` as this checks for new warnings and other issues. @@ -255,6 +260,8 @@ like this: #. Commits must show original author in the ``author`` field and include all of the ``Signed-off-by``, ``Reviewed-by``, etc, tags that have been submitted. + It is the responsibility of the custodian to gather these additional tags as + most tooling makes this easy. #. The final decision to accept or reject a patch comes down to the custodian in question. -- 2.43.0
