[RFC] doc: Document frequency and volume limits on patches.

[RFC] doc: Document frequency and volume limits on patches.

[Aaron Conole]

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 <aconole@redhat.com>
---
NOTE: This is a discussion item from the techboard and I'm
      submitting as RFC first to gather feedback.  I've CC'd
      each maintainer individually as well to try and make sure
      it gets into the inboxes.

 doc/guides/contributing/patches.rst | 31 +++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d21ee288b2..a13f79c7a8 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -644,6 +644,37 @@ 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.
+
+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.
+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.
+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.
+
+Your changes are expected to pass on an x86/x86-64 linux system.
+
+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.
+
 
 Steps to getting your patch merged
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 
2.47.1

Re: [RFC] doc: Document frequency and volume limits on patches.

[Thomas Monjalon]

Hello,

05/03/2025 02:33, Aaron Conole:
> 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.

Thanks for trying to improve our process.

> 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 <aconole@redhat.com>
> ---
> +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.

Should we recommend to ping after a week of inactivity?

> +
> +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.

Should we remind to reply to all feedbacks?

> +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

Should we be more precise about "testing them locally"?
Or recommend minimal testing like 1 compilation target with unit test or DTS?

> +posting to the mailing list.
> +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.

This self test infra should be explained a bit more.

> +
> +Your changes are expected to pass on an x86/x86-64 linux system.

This can be moved above with "local test" recommendation.

> +
> +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.

To be clear, you recommend to split patches and series appropriately.

Thanks again.
I would love reading more comments and feedbacks about this.