diff options
| author | Alex Bennée | 2022-11-17 18:25:26 +0100 |
|---|---|---|
| committer | Alex Bennée | 2022-11-22 10:52:23 +0100 |
| commit | 73ee4c55f7ff95a835584ae54bf840b9281b11d7 (patch) | |
| tree | 3e9a1c9e6a200945c3d90a44d8623f480b3d2f65 /docs | |
| parent | docs/devel: simplify the minimal checklist (diff) | |
| download | qemu-73ee4c55f7ff95a835584ae54bf840b9281b11d7.tar.gz qemu-73ee4c55f7ff95a835584ae54bf840b9281b11d7.tar.xz qemu-73ee4c55f7ff95a835584ae54bf840b9281b11d7.zip | |
docs/devel: try and improve the language around patch review
It is important that contributors take the review process seriously
and we collaborate in a respectful way while avoiding personal
attacks. Try and make this clear in the language.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20221117172532.538149-8-alex.bennee@linaro.org>
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/devel/submitting-a-patch.rst | 16 |
1 files changed, 11 insertions, 5 deletions
diff --git a/docs/devel/submitting-a-patch.rst b/docs/devel/submitting-a-patch.rst index b2a162ff4c..c641d948f1 100644 --- a/docs/devel/submitting-a-patch.rst +++ b/docs/devel/submitting-a-patch.rst @@ -434,14 +434,20 @@ developers will identify bugs, or suggest a cleaner approach, or even just point out code style issues or commit message typos. You'll need to respond to these, and then send a second version of your patches with the issues fixed. This takes a little time and effort on your part, but -if you don't do it then your changes will never get into QEMU. It's also -just polite -- it is quite disheartening for a developer to spend time -reviewing your code and suggesting improvements, only to find that -you're not going to do anything further and it was all wasted effort. +if you don't do it then your changes will never get into QEMU. + +Remember that a maintainer is under no obligation to take your +patches. If someone has spent the time reviewing your code and +suggesting improvements and you simply re-post without either +addressing the comment directly or providing additional justification +for the change then it becomes wasted effort. You cannot demand others +merge and then fix up your code after the fact. When replying to comments on your patches **reply to all and not just the sender** -- keeping discussion on the mailing list means everybody -can follow it. +can follow it. Remember the spirit of the :ref:`code_of_conduct` and +keep discussions respectful and collaborative and avoid making +personal comments. .. _pay_attention_to_review_comments: |