diff mbox series

[v6] doc: add release milestones definition

Message ID 20210328190005.4185594-1-thomas@monjalon.net (mailing list archive)
State New
Delegated to: Thomas Monjalon
Headers show
Series [v6] doc: add release milestones definition | expand

Checks

Context Check Description
ci/intel-Testing success Testing PASS
ci/Intel-compilation success Compilation OK
ci/github-robot success github build: passed
ci/travis-robot success travis build: passed
ci/checkpatch success coding style OK

Commit Message

Thomas Monjalon March 28, 2021, 7 p.m. UTC
From: Asaf Penso <asafp@nvidia.com>

Adding more information about the release milestones.
This includes the scope of change, expectations, etc.

Signed-off-by: Asaf Penso <asafp@nvidia.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: John McNamara <john.mcnamara@intel.com>
---
v2: fix styling format and add content in the commit message
v3: change punctuation and avoid plural form when unneeded
v4: avoid abbreviations, "Priority" in -rc, and reword as John suggests
v5: note that release candidates may vary
v6: merge RFC and proposal deadline, add roadmap link and reduce duplication
---
 doc/guides/contributing/patches.rst | 69 +++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

Comments

Ajit Khaparde March 29, 2021, 2:02 a.m. UTC | #1
On Sun, Mar 28, 2021 at 12:00 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> From: Asaf Penso <asafp@nvidia.com>
>
> Adding more information about the release milestones.
> This includes the scope of change, expectations, etc.
>
> Signed-off-by: Asaf Penso <asafp@nvidia.com>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>

> ---
> v2: fix styling format and add content in the commit message
> v3: change punctuation and avoid plural form when unneeded
> v4: avoid abbreviations, "Priority" in -rc, and reword as John suggests
> v5: note that release candidates may vary
> v6: merge RFC and proposal deadline, add roadmap link and reduce duplication
> ---
>  doc/guides/contributing/patches.rst | 69 +++++++++++++++++++++++++++++
>  1 file changed, 69 insertions(+)
>
> diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
> index 6dbbd5f8d1..1277443620 100644
> --- a/doc/guides/contributing/patches.rst
> +++ b/doc/guides/contributing/patches.rst
> @@ -177,6 +177,8 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
>  * Add documentation, if relevant, in the form of Doxygen comments or a User Guide in RST format.
>    See the :ref:`Documentation Guidelines <doc_guidelines>`.
>
> +* Code and related documentation must be updated atomically in the same patch.
> +
>  Once the changes have been made you should commit them to your local repo.
>
>  For small changes, that do not require specific explanations, it is better to keep things together in the
> @@ -660,3 +662,70 @@ patch accepted. The general cycle for patch review and acceptance is:
>       than rework of the original.
>     * Trivial patches may be merged sooner than described above at the tree committer's
>       discretion.
> +
> +
> +Milestones definition
> +---------------------
> +
> +Each DPDK release has milestones that help everyone to converge to the release date.
> +The following is a list of these milestones
> +together with concrete definitions and expectations,
> +for a typical release cycle (3 months ending after 4 release candidates).
> +The number and expectations of release candidates might vary slightly.
> +The schedule is updated in the `roadmap <https://core.dpdk.org/roadmap/#dates>`_.
> +
> +Roadmap
> +~~~~~~~
> +
> +* Announce new features in libraries, drivers, applications, and examples.
> +* To be published before the first day of the release cycle.
> +
> +Proposal Deadline
> +~~~~~~~~~~~~~~~~~
> +
> +* Must send an RFC or a complete v1 patch.
> +* Early RFC gives time for design review before complete implementation.
> +* Should include at least the API changes in libraries and applications.
> +* Library code should be quite complete at the deadline.
> +* Nice to have: driver implementation (full or draft), example code, and documentation.
> +
> +rc1
> +~~~
> +
> +* Priority: new or updated API.
> +* New API should be defined and implemented in libraries.
> +* The API should include Doxygen documentation
> +  and be part of the relevant .rst files (library-specific and release notes).
> +* API should be used in a test application (``/app``).
> +* At least one PMD should implement the API.
> +  It can be a draft but must be sent as a separate series.
> +* The above should be sent to the mailing list at least 2 weeks before -rc1.
> +* Nice to have: example code (``/examples``)
> +
> +rc2
> +~~~
> +
> +* Priority: drivers.
> +* New features should be implemented in drivers.
> +* A driver change should include documentation
> +  in the relevant .rst files (driver-specific and release notes).
> +* The above should be sent to the mailing list at least 2 weeks before -rc2.
> +
> +rc3
> +~~~
> +
> +* Priority: applications.
> +* New functionality that does not depend on libraries update
> +  can be integrated as part of -rc3.
> +* The application should include documentation in the relevant .rst files
> +  (application-specific and release notes if significant).
> +* It may be the last opportunity for miscellaneous changes.
> +* Libraries and drivers cleanup are allowed.
> +* Small driver reworks.
> +* Critical and minor bug fixes.
> +
> +rc4
> +~~~
> +
> +* Documentation updates.
> +* Critical bug fixes.
> --
> 2.30.1
>
diff mbox series

Patch

diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 6dbbd5f8d1..1277443620 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -177,6 +177,8 @@  Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
 * Add documentation, if relevant, in the form of Doxygen comments or a User Guide in RST format.
   See the :ref:`Documentation Guidelines <doc_guidelines>`.
 
+* Code and related documentation must be updated atomically in the same patch.
+
 Once the changes have been made you should commit them to your local repo.
 
 For small changes, that do not require specific explanations, it is better to keep things together in the
@@ -660,3 +662,70 @@  patch accepted. The general cycle for patch review and acceptance is:
      than rework of the original.
    * Trivial patches may be merged sooner than described above at the tree committer's
      discretion.
+
+
+Milestones definition
+---------------------
+
+Each DPDK release has milestones that help everyone to converge to the release date.
+The following is a list of these milestones
+together with concrete definitions and expectations,
+for a typical release cycle (3 months ending after 4 release candidates).
+The number and expectations of release candidates might vary slightly.
+The schedule is updated in the `roadmap <https://core.dpdk.org/roadmap/#dates>`_.
+
+Roadmap
+~~~~~~~
+
+* Announce new features in libraries, drivers, applications, and examples.
+* To be published before the first day of the release cycle.
+
+Proposal Deadline
+~~~~~~~~~~~~~~~~~
+
+* Must send an RFC or a complete v1 patch.
+* Early RFC gives time for design review before complete implementation.
+* Should include at least the API changes in libraries and applications.
+* Library code should be quite complete at the deadline.
+* Nice to have: driver implementation (full or draft), example code, and documentation.
+
+rc1
+~~~
+
+* Priority: new or updated API.
+* New API should be defined and implemented in libraries.
+* The API should include Doxygen documentation
+  and be part of the relevant .rst files (library-specific and release notes).
+* API should be used in a test application (``/app``).
+* At least one PMD should implement the API.
+  It can be a draft but must be sent as a separate series.
+* The above should be sent to the mailing list at least 2 weeks before -rc1.
+* Nice to have: example code (``/examples``)
+
+rc2
+~~~
+
+* Priority: drivers.
+* New features should be implemented in drivers.
+* A driver change should include documentation
+  in the relevant .rst files (driver-specific and release notes).
+* The above should be sent to the mailing list at least 2 weeks before -rc2.
+
+rc3
+~~~
+
+* Priority: applications.
+* New functionality that does not depend on libraries update
+  can be integrated as part of -rc3.
+* The application should include documentation in the relevant .rst files
+  (application-specific and release notes if significant).
+* It may be the last opportunity for miscellaneous changes.
+* Libraries and drivers cleanup are allowed.
+* Small driver reworks.
+* Critical and minor bug fixes.
+
+rc4
+~~~
+
+* Documentation updates.
+* Critical bug fixes.