summaryrefslogtreecommitdiffstats
path: root/documentation
diff options
context:
space:
mode:
authorPaul Barker <pbarker@konsulko.com>2020-11-23 18:02:17 +0000
committerRichard Purdie <richard.purdie@linuxfoundation.org>2020-11-24 09:07:28 +0000
commited36bd89d7b60d69fb94b363ce78eb5720b6429f (patch)
tree671366272be65503139d29fec64aacfec12fdb89 /documentation
parent8b607a18b113b92b2222001561d643c2b66c475b (diff)
downloadpoky-ed36bd89d7b60d69fb94b363ce78eb5720b6429f.tar.gz
dev-manual-common-tasks: Describe how to handle patch feedback
The contribution guidelines would benefit from a brief section on how to address feedback from patch reviewers and how to re-submit amended patches. The information here is based on my personal experience and on the existing notes on the "How to submit a patch to OpenEmbedded" page on the OE wiki. (From yocto-docs rev: fcff5c524fdf2f465153319d0fdc6fb557b588dd) Signed-off-by: Paul Barker <pbarker@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r--documentation/dev-manual/dev-manual-common-tasks.rst22
1 files changed, 22 insertions, 0 deletions
diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst
index 1c6d88a93a..4b76217ad3 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/documentation/dev-manual/dev-manual-common-tasks.rst
@@ -10982,6 +10982,28 @@ reduce the burden of patch review on maintainers.
10982 Asking about the status of a patch or change is reasonable if the change 10982 Asking about the status of a patch or change is reasonable if the change
10983 has been idle for a while with no feedback. 10983 has been idle for a while with no feedback.
10984 10984
10985Responding to Patch Review
10986~~~~~~~~~~~~~~~~~~~~~~~~~~
10987
10988You may get feedback on your submitted patches from other community members
10989or from the automated patchtest service. If issues are identified in your
10990patch then it is usually necessary to address these before the patch will be
10991accepted into the project. In this case you should amend the patch according
10992to the feedback and submit an updated version to the relevant mailing list,
10993copying in the reviewers who provided feedback to the previous version of the
10994patch.
10995
10996The patch should be amended using ``git commit --amend`` or perhaps ``git
10997rebase`` for more expert git users. You should also modify the ``[PATCH]``
10998tag in the email subject line when sending the revised patch to mark the new
10999iteration as ``[PATCH v2]``, ``[PATCH v3]``, etc as appropriate. This can be
11000done by passing the ``-v`` argument to ``git format-patch`` with a version
11001number.
11002
11003Lastly please ensure that you also test your revised changes. In particular
11004please don't just edit the patch file written out by ``git format-patch`` and
11005resend it.
11006
10985Working With Licenses 11007Working With Licenses
10986===================== 11008=====================
10987 11009