[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PULL v2 07/11] docs/devel: try and improve the language around patch re
From: |
Alex Bennée |
Subject: |
[PULL v2 07/11] docs/devel: try and improve the language around patch review |
Date: |
Tue, 22 Nov 2022 09:56:06 +0000 |
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>
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:
--
2.34.1
- [PULL v2 for 7.2-rc2 00/11] testing and doc updates, Alex Bennée, 2022/11/22
- [PULL v2 02/11] tests/avocado/machine_aspeed.py: Reduce noise on the console for SDK tests, Alex Bennée, 2022/11/22
- [PULL v2 05/11] docs/devel: make language a little less code centric, Alex Bennée, 2022/11/22
- [PULL v2 06/11] docs/devel: simplify the minimal checklist, Alex Bennée, 2022/11/22
- [PULL v2 04/11] docs/devel: add a maintainers section to development process, Alex Bennée, 2022/11/22
- [PULL v2 03/11] tests/docker: allow user to override check target, Alex Bennée, 2022/11/22
- [PULL v2 01/11] Run docker probe only if docker or podman are available, Alex Bennée, 2022/11/22
- [PULL v2 08/11] tests/avocado: Raise timeout for boot_linux.py:BootLinuxPPC64.test_pseries_tcg, Alex Bennée, 2022/11/22
- [PULL v2 11/11] gitlab: integrate coverage report, Alex Bennée, 2022/11/22
- [PULL v2 09/11] tests/avocado: introduce alpine virt test for CI, Alex Bennée, 2022/11/22
- [PULL v2 07/11] docs/devel: try and improve the language around patch review,
Alex Bennée <=
- [PULL v2 10/11] tests/avocado: skip aarch64 cloud TCG tests in CI, Alex Bennée, 2022/11/22
- Re: [PULL v2 for 7.2-rc2 00/11] testing and doc updates, Stefan Hajnoczi, 2022/11/22