The DPDK project has two constrained resources - reviewers and
public CI infrastructure. These are shared among the entire
project, and there are true costs associated with using these
resources. Thus, there are two motivations behind this change:
- Encourage developers to spend more time ensuring their
changes are in a state that things have gone through some
basic testing
- Encourage people to give reviews by guaranteeing that the
time between series is long enough that comments will be
valid.
We want to document the guidelines for submitting to the list
to encourage more time for reviews, and also encourage
developers to spend a bit more time to put their submissions
in a 'default accept' condition.
Signed-off-by: Aaron Conole <acon...@redhat.com>
---
RFC->v1: Incorporate feedback from Thomas.
doc/guides/contributing/patches.rst | 43 +++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/doc/guides/contributing/patches.rst
b/doc/guides/contributing/patches.rst
index 8ad6b6e715..e4c593b053 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -644,6 +644,49 @@ environment) by the person named.
person.
+Frequency and volume of patches
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Please allow at least 24 hours to pass between posting patch revisions.
+This ensures reviewers from different geographical regions have time to
+provide feedback.
+Additionally, please do not wait too long (read: weeks) between revisions
+as this makes it harder for reviewers and maintainers to recall the context
+of the previous posting.
+If you have not received any feedback within a week, it is appropriate to
+send a ping to the mailing list.
+
+Please do not post new revisions without addressing all feedback.
+Make sure that all outstanding items have been addressed before posting a new
+revision for review (this should involve replying to all the feedback).
+Do not post a new version of a patch while there is ongoing discussion unless
+a reviewer has specifically requested it.
+
+Do not post your patches to the list in lieu of running tests.
+**YOU MUST ENSURE** that your patches are ready by testing them locally before
+posting to the mailing list.
+Testing locally should involve, at a minimum, running compilation with debug
+and release flags, and invoking the unit tests.
+Your changes are expected to pass on an x86/x86-64 linux system.
+The infrastructure running the tests is a shared resource among all developers
+on the project, and many frequent reposts will result in delays for all
+developers.
+We do our best to include CI and self-test infrastructure that can be used on
+an individual developer basis.
+
+For details on running the unit tests, see :ref:`Running a test <unit_test>`
+section of the ``unit_test`` documentation.
+It is also recommended to run the **DTS** comprehensive tests. See
+the ``dts`` guide.
+Finally, you can also push to a branch on the GitHub service to trigger
+a comprehensive set of compile and unit test runs.
+
+Please keep all patch sets to a reasonable length.
+Too many or too large patches and series can quickly become very difficult
+for a reasonable review.
+It is recommended to appropriately split patches and series to groups of
+digestible logical changes.
+
Steps to getting your patch merged
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.47.1
