diff options
author | Paul Barker <pbarker@konsulko.com> | 2020-11-23 18:02:17 +0000 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2020-11-24 09:07:28 +0000 |
commit | ed36bd89d7b60d69fb94b363ce78eb5720b6429f (patch) | |
tree | 671366272be65503139d29fec64aacfec12fdb89 | |
parent | 8b607a18b113b92b2222001561d643c2b66c475b (diff) | |
download | poky-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>
-rw-r--r-- | documentation/dev-manual/dev-manual-common-tasks.rst | 22 |
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 | ||
10985 | Responding to Patch Review | ||
10986 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
10987 | |||
10988 | You may get feedback on your submitted patches from other community members | ||
10989 | or from the automated patchtest service. If issues are identified in your | ||
10990 | patch then it is usually necessary to address these before the patch will be | ||
10991 | accepted into the project. In this case you should amend the patch according | ||
10992 | to the feedback and submit an updated version to the relevant mailing list, | ||
10993 | copying in the reviewers who provided feedback to the previous version of the | ||
10994 | patch. | ||
10995 | |||
10996 | The patch should be amended using ``git commit --amend`` or perhaps ``git | ||
10997 | rebase`` for more expert git users. You should also modify the ``[PATCH]`` | ||
10998 | tag in the email subject line when sending the revised patch to mark the new | ||
10999 | iteration as ``[PATCH v2]``, ``[PATCH v3]``, etc as appropriate. This can be | ||
11000 | done by passing the ``-v`` argument to ``git format-patch`` with a version | ||
11001 | number. | ||
11002 | |||
11003 | Lastly please ensure that you also test your revised changes. In particular | ||
11004 | please don't just edit the patch file written out by ``git format-patch`` and | ||
11005 | resend it. | ||
11006 | |||
10985 | Working With Licenses | 11007 | Working With Licenses |
10986 | ===================== | 11008 | ===================== |
10987 | 11009 | ||