[dpdk-dev] [PATCH] doc: add release milestones definition

[dpdk-dev] [PATCH] doc: add release milestones definition

[Asaf Penso]

Signed-off-by: Asaf Penso <asafp@nvidia.com>
---
 doc/guides/contributing/patches.rst | 52 +++++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 4e9140b..849fe6d 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -657,3 +657,55 @@ 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 a couple of milestones that help everyone to converge to the release date.
+The following is a list of these milestones together with concrete definitions and expectations.
+
+Roadmap
+* Content - new features in libs, drivers, apps, and examples
+* Timeframe - to be published until the first day of the release
+
+RFC
+* Content - public design review for the features, explaining the need, and the design
+* It should include the API changes, in libs and apps
+* RFCs are not mandatory but are strongly advised to start early discussions
+* Nice to have - driver implementation (full or draft), example code, and documentation
+
+Proposal Deadline
+* Content - either an RFC as stated above or a v1 patch
+* Nice to have - code complete for libs
+
+rc1
+* Content - new or updated API
+* New API should be defined and implemented in shared libraries
+* The API should include DoxyGen documentation and be part of the relevant .rst files (lib, release_notes)
+* Code and related documentation must be updated atomically in the same patch
+* It should be used in a test application (/apps) and also documented in the relevant .rst files
+* At least one pmd should implement this API. It can be in a draft mode but must be sent as a separate series
+* At least 2 weeks before -rc1 the above should be sent to the ML for review
+* Nice to have: example code (/examples)
+
+rc2
+* Content - drivers
+* All features should be implemented in drivers
+* The drivers should include documentation and be part of the relevant .rst files (driver, release_notes)
+* Code and related documentation must be updated atomically in the same patch
+* At least 2 weeks before -rc2 the above should be sent to the ML for review
+
+rc3
+* Content - test apps
+* New functionality that doesn’t depend on libs update can be integrated as part of -rc3
+* The app should include documentation and be part of the relevant .rst files (app, release_notes if significant)
+* Code and related documentation must be updated atomically in the same patch
+* Last opportunity for Misc changes
+* Small driver rework
+* libs and driver cleanup
+* Big bug fixes
+
+rc4
+* Content - documentation updates
+* Critical bug fixes
-- 
1.8.3.1

[dpdk-dev] [PATCH v2] doc: add release milestones definition

[Michael Baum]

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>
---
v2: fix styling format and add content in the commit message
---
 doc/guides/contributing/patches.rst | 66 +++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 4e9140b..159d220 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -657,3 +657,69 @@ 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 a couple of milestones that help everyone to converge to the release date.
+The following is a list of these milestones together with concrete definitions and expectations.
+
+Roadmap
+~~~~~~~
+
+* Content - new features in libs, drivers, apps, and examples
+* Timeframe - to be published until the first day of the release
+
+RFC
+~~~
+
+* Content - public design review for the features, explaining the need, and the design
+* It should include the API changes, in libs and apps
+* RFCs are not mandatory but are strongly advised to start early discussions
+* Nice to have - driver implementation (full or draft), example code, and documentation
+
+Proposal Deadline
+~~~~~~~~~~~~~~~~~
+
+* Content - either an RFC as stated above or a v1 patch
+* Nice to have - code complete for libs
+
+rc1
+~~~
+
+* Content - new or updated API
+* New API should be defined and implemented in shared libraries
+* The API should include DoxyGen documentation and be part of the relevant .rst files (lib, release_notes)
+* Code and related documentation must be updated atomically in the same patch
+* It should be used in a test application (/apps) and also documented in the relevant .rst files
+* At least one pmd should implement this API. It can be in a draft mode but must be sent as a separate series
+* At least 2 weeks before -rc1 the above should be sent to the ML for review
+* Nice to have: example code (/examples)
+
+rc2
+~~~
+
+* Content - drivers
+* All features should be implemented in drivers
+* The drivers should include documentation and be part of the relevant .rst files (driver, release_notes)
+* Code and related documentation must be updated atomically in the same patch
+* At least 2 weeks before -rc2 the above should be sent to the ML for review
+
+rc3
+~~~
+
+* Content - test apps
+* New functionality that doesn’t depend on libs update can be integrated as part of -rc3
+* The app should include documentation and be part of the relevant .rst files (app, release_notes if significant)
+* Code and related documentation must be updated atomically in the same patch
+* Last opportunity for Misc changes
+* Small driver rework
+* libs and driver cleanup
+* Big bug fixes
+
+rc4
+~~~
+
+* Content - documentation updates
+* Critical bug fixes
-- 
1.8.3.1

[dpdk-dev] [PATCH v3 1/1] doc: add release milestones definition

[Thomas Monjalon]

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>
---
v2: fix styling format and add content in the commit message
v3: change punctuation and avoid plural form when unneeded
---
 doc/guides/contributing/patches.rst | 72 +++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 4e9140bca4..87c1c6f8f6 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -657,3 +657,75 @@ 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.
+
+Roadmap
+~~~~~~~
+
+* Content: new features in libs, drivers, apps, and examples.
+* Timeframe: to be published until the first day of the release cycle.
+
+RFC
+~~~
+
+* Content: public design review for the feature, explaining the need, and the design.
+* Should include the API changes, in libs and apps.
+* RFC is not mandatory but strongly advised to start early discussion.
+* Nice to have: driver implementation (full or draft), example code, and documentation.
+
+Proposal Deadline
+~~~~~~~~~~~~~~~~~
+
+* Content: either an RFC as stated above or a v1 patch.
+* Nice to have: code complete for libs.
+
+rc1
+~~~
+
+* Content: 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 (lib, release notes).
+* Code and related documentation must be updated atomically in the same patch.
+* API should be used in a test application (/apps).
+* At least one PMD should implement the API.
+  It can be a draft but must be sent as a separate series.
+* At least 2 weeks before -rc1 the above should be sent to the ML for review.
+* Nice to have: example code (/examples)
+
+rc2
+~~~
+
+* Content: drivers.
+* New features should be implemented in drivers.
+* A driver change should include documentation
+  in the relevant .rst files (driver, release notes).
+* Code and related documentation must be updated atomically in the same patch.
+* At least 2 weeks before -rc2 the above should be sent to the ML for review.
+
+rc3
+~~~
+
+* Content: test apps.
+* New functionality that does not depend on libs update
+  can be integrated as part of -rc3.
+* The app should include documentation in the relevant .rst files
+  (app, release notes if significant).
+* Code and related documentation must be updated atomically in the same patch.
+* Last opportunity for miscellaneous changes.
+* Libs and drivers cleanup.
+* Small driver reworks.
+* Big bug fixes.
+
+rc4
+~~~
+
+* Documentation updates.
+* Critical bug fixes.
-- 
2.29.2

Re: [dpdk-dev] [PATCH v3 1/1] doc: add release milestones definition

[Mcnamara, John]

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> Sent: Wednesday, January 13, 2021 9:12 AM
> To: dev@dpdk.org
> Cc: david.marchand@redhat.com; Yigit, Ferruh <ferruh.yigit@intel.com>; Asaf
> Penso <asafp@nvidia.com>
> Subject: [dpdk-dev] [PATCH v3 1/1] doc: add release milestones definition
> 
> From: Asaf Penso <asafp@nvidia.com>
> 
> Adding more information about the release milestones.
> This includes the scope of change, expectations, etc.


First off, thanks for putting this together, it is a good initiative to document the processes we follow.

Some minor corrections/suggestions below.


> +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.
> +
> +Roadmap
> +~~~~~~~
> +
> +* Content: new features in libs, drivers, apps, and examples.
> +* Timeframe: to be published until the first day of the release cycle.

s/until/before


> +rc2
> +~~~
> +
> +* Content: drivers.
> +* New features should be implemented in drivers.
> +* A driver change should include documentation
> +  in the relevant .rst files (driver, release notes).
> +* Code and related documentation must be updated atomically in the same
> patch.
> +* At least 2 weeks before -rc2 the above should be sent to the ML for
> review.

Maybe slightly better as:

 * The above should be sent to the mailing list at least 2 weeks before -rc2.

> +rc3
> +~~~
> +
> +* Content: test apps.
> +* New functionality that does not depend on libs update
> +  can be integrated as part of -rc3.
> +* The app should include documentation in the relevant .rst files
> +  (app, release notes if significant).
> +* Code and related documentation must be updated atomically in the same
> patch.
> +* Last opportunity for miscellaneous changes.
> +* Libs and drivers cleanup.
> +* Small driver reworks.
> +* Big bug fixes.

Maybe instead of "Big bug fixes" we could use "Critical and minor bug fixes only"


> +rc4
> +~~~
> +
> +* Documentation updates.
> +* Critical bug fixes.


Acked-by: John McNamara <john.mcnamara@intel.com>

[dpdk-dev] [PATCH v4 1/1] doc: add release milestones definition

[Thomas Monjalon]

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
---
 doc/guides/contributing/patches.rst | 72 +++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 6dbbd5f8d1..15739a43dc 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -660,3 +660,75 @@ 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.
+
+Roadmap
+~~~~~~~
+
+* Content: new features in libraries, drivers, applications, and examples.
+* Timeframe: to be published before the first day of the release cycle.
+
+RFC
+~~~
+
+* Content: public design review for the feature, explaining the need and the design.
+* Should include the API changes, in libraries and applications.
+* RFC is not mandatory but strongly advised to start early discussion.
+* Nice to have: driver implementation (full or draft), example code, and documentation.
+
+Proposal Deadline
+~~~~~~~~~~~~~~~~~
+
+* Content: either an RFC as stated above or a v1 patch.
+* Nice to have: code complete for libraries.
+
+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, release notes).
+* Code and related documentation must be updated atomically in the same patch.
+* 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, release notes).
+* Code and related documentation must be updated atomically in the same patch.
+* 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 libs update
+  can be integrated as part of -rc3.
+* The app should include documentation in the relevant .rst files
+  (app, release notes if significant).
+* Code and related documentation must be updated atomically in the same patch.
+* Last opportunity for miscellaneous changes.
+* Libs and drivers cleanup.
+* Small driver reworks.
+* Critical and minor bug fixes.
+
+rc4
+~~~
+
+* Documentation updates.
+* Critical bug fixes.
-- 
2.30.0

Re: [dpdk-dev] [PATCH v4 1/1] doc: add release milestones definition

[Ajit Khaparde]

[-- Attachment #1: Type: text/plain, Size: 3864 bytes --]

On Mon, Feb 1, 2021 at 2:13 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>
Looks good to me. Can we add a mention somewhere that under some
circumstances an rc5 may be required or the rc enumeration could
change in some rare case, like when we had to spin a new rc during
20.11?


> ---
> 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
> ---
>  doc/guides/contributing/patches.rst | 72 +++++++++++++++++++++++++++++
>  1 file changed, 72 insertions(+)
>
> diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
> index 6dbbd5f8d1..15739a43dc 100644
> --- a/doc/guides/contributing/patches.rst
> +++ b/doc/guides/contributing/patches.rst
> @@ -660,3 +660,75 @@ 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.
> +
> +Roadmap
> +~~~~~~~
> +
> +* Content: new features in libraries, drivers, applications, and examples.
> +* Timeframe: to be published before the first day of the release cycle.
> +
> +RFC
> +~~~
> +
> +* Content: public design review for the feature, explaining the need and the design.
> +* Should include the API changes, in libraries and applications.
> +* RFC is not mandatory but strongly advised to start early discussion.
> +* Nice to have: driver implementation (full or draft), example code, and documentation.
> +
> +Proposal Deadline
> +~~~~~~~~~~~~~~~~~
> +
> +* Content: either an RFC as stated above or a v1 patch.
> +* Nice to have: code complete for libraries.
> +
> +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, release notes).
> +* Code and related documentation must be updated atomically in the same patch.
> +* 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, release notes).
> +* Code and related documentation must be updated atomically in the same patch.
> +* 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 libs update
> +  can be integrated as part of -rc3.
> +* The app should include documentation in the relevant .rst files
> +  (app, release notes if significant).
> +* Code and related documentation must be updated atomically in the same patch.
> +* Last opportunity for miscellaneous changes.
> +* Libs and drivers cleanup.
> +* Small driver reworks.
> +* Critical and minor bug fixes.
> +
> +rc4
> +~~~
> +
> +* Documentation updates.
> +* Critical bug fixes.
> --
> 2.30.0
>

Re: [dpdk-dev] [PATCH v4 1/1] doc: add release milestones definition

[Thomas Monjalon]

01/02/2021 23:31, Ajit Khaparde:
> On Mon, Feb 1, 2021 at 2:13 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>
> 
> Looks good to me. Can we add a mention somewhere that under some
> circumstances an rc5 may be required or the rc enumeration could
> change in some rare case, like when we had to spin a new rc during
> 20.11?

Yes good idea.

[dpdk-dev] [PATCH v5 1/1] doc: add release milestones definition

[Thomas Monjalon]

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
---
 doc/guides/contributing/patches.rst | 74 +++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)

diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 6dbbd5f8d1..650ae7ef9b 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -660,3 +660,77 @@ 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.
+The number and expectations of release candidates might vary slightly.
+
+Roadmap
+~~~~~~~
+
+* Content: new features in libraries, drivers, applications, and examples.
+* Timeframe: to be published before the first day of the release cycle.
+
+RFC
+~~~
+
+* Content: public design review for the feature, explaining the need and the design.
+* Should include the API changes, in libraries and applications.
+* RFC is not mandatory but strongly advised to start early discussion.
+* Nice to have: driver implementation (full or draft), example code, and documentation.
+
+Proposal Deadline
+~~~~~~~~~~~~~~~~~
+
+* Content: either an RFC as stated above or a v1 patch.
+* Nice to have: code complete for libraries.
+
+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, release notes).
+* Code and related documentation must be updated atomically in the same patch.
+* 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, release notes).
+* Code and related documentation must be updated atomically in the same patch.
+* 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 libs update
+  can be integrated as part of -rc3.
+* The app should include documentation in the relevant .rst files
+  (app, release notes if significant).
+* Code and related documentation must be updated atomically in the same patch.
+* Last opportunity for miscellaneous changes.
+* Libs and drivers cleanup.
+* Small driver reworks.
+* Critical and minor bug fixes.
+
+rc4
+~~~
+
+* Documentation updates.
+* Critical bug fixes.
-- 
2.30.0

Re: [dpdk-dev] [PATCH v5 1/1] doc: add release milestones definition

[David Marchand]

On Wed, Feb 3, 2021 at 8:58 AM 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>
> ---
> 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
> ---
>  doc/guides/contributing/patches.rst | 74 +++++++++++++++++++++++++++++
>  1 file changed, 74 insertions(+)
>
> diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
> index 6dbbd5f8d1..650ae7ef9b 100644
> --- a/doc/guides/contributing/patches.rst
> +++ b/doc/guides/contributing/patches.rst
> @@ -660,3 +660,77 @@ 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.
> +The number and expectations of release candidates might vary slightly.

You can still mention that a typical release has 4 rc, since they are
described below.
Maybe add a link to https://core.dpdk.org/roadmap/#dates.


> +
> +Roadmap
> +~~~~~~~
> +
> +* Content: new features in libraries, drivers, applications, and examples.
> +* Timeframe: to be published before the first day of the release cycle.

On the form, roadmap announcements can be either a simple mail or a
patch against dpdk-web.


> +
> +RFC
> +~~~
> +
> +* Content: public design review for the feature, explaining the need and the design.
> +* Should include the API changes, in libraries and applications.
> +* RFC is not mandatory but strongly advised to start early discussion.
> +* Nice to have: driver implementation (full or draft), example code, and documentation.

RFC mails/patches can be sent at any time.
I would not list this as a release milestone.

This part details what should be in a RFC patch for a feature to be
considered for the Proposal deadline.
How about merging this with the milestone below?
On the other hand, those details apply to any RFC, so another option
is to put those details earlier in the doc where RFC patches are
described.


> +
> +Proposal Deadline
> +~~~~~~~~~~~~~~~~~
> +
> +* Content: either an RFC as stated above or a v1 patch.
> +* Nice to have: code complete for libraries.
> +
> +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, release notes).
> +* Code and related documentation must be updated atomically in the same patch.
> +* 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``)

This list has items not really specific to rc1, like documentation is
mandatory, doc and code updates must be atomic...
Can this be moved in a common section?


> +
> +rc2
> +~~~
> +
> +* Priority: drivers.
> +* New features should be implemented in drivers.
> +* A driver change should include documentation
> +  in the relevant .rst files (driver, release notes).
> +* Code and related documentation must be updated atomically in the same patch.
> +* 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 libs update
> +  can be integrated as part of -rc3.
> +* The app should include documentation in the relevant .rst files
> +  (app, release notes if significant).
> +* Code and related documentation must be updated atomically in the same patch.
> +* Last opportunity for miscellaneous changes.
> +* Libs and drivers cleanup.
> +* Small driver reworks.
> +* Critical and minor bug fixes.
> +
> +rc4
> +~~~
> +
> +* Documentation updates.
> +* Critical bug fixes.
> --
> 2.30.0
>


-- 
David Marchand

Re: [dpdk-dev] [PATCH v5 1/1] doc: add release milestones definition

[Thomas Monjalon]

03/02/2021 11:14, David Marchand:
> On Wed, Feb 3, 2021 at 8:58 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> > +Roadmap
> > +~~~~~~~
> > +
> > +* Content: new features in libraries, drivers, applications, and examples.
> > +* Timeframe: to be published before the first day of the release cycle.
> 
> On the form, roadmap announcements can be either a simple mail or a
> patch against dpdk-web.

I prefer having a mail on dpdk-dev first, because:
	- it is inviting for discussions
	- it can explain briefly the changes

Opinions?

[dpdk-dev] [PATCH v6] doc: add release milestones definition

[Thomas Monjalon]

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

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

Re: [dpdk-dev] [PATCH v6] doc: add release milestones definition

[Ajit Khaparde]

[-- Attachment #1: Type: text/plain, Size: 4345 bytes --]

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
>

Re: [dpdk-dev] [PATCH v6] doc: add release milestones definition

[Ferruh Yigit]

On 3/28/2021 8:00 PM, Thomas Monjalon 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>
> ---
> 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.

Can we just say API or libraries?

Overall what is the intention for the 'priority' information? Should we really
split release candidates for libraries, driver and applications?
We merge all as much as possible before -rc1.

Can we say this other-way around, API/library features can't be merged after -rc1.

And similarly driver features shouldn't be merged after -rc2, application
changes shouldn't merge after -rc3.
Fixes can be merged anytime before -rc4. After -rc4 only critical fixes and
documentation changes.

Just I want to highlight that for example we merge documentation updates
anytime, it doesn't have to wait -rc4, but below listing looks like different
part only allocated for different -rc, which is wrong as far as I know.

> +* New API should be defined and implemented in libraries.> +* The API should include Doxygen documentation

s/should/must

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

I am not sure if "must be sent as a separate series" needs to be highlighted,
having all in the same series has a benefit to see bigger picture. If the driver
patches acked/reviewed by its maintainers, I think it can be merged in single
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.

I already mentioned above, but this can cause misunderstanding. We want all
driver implementation to be ready for proposal deadline, same as other patches.
But because of its reduced scope (they don't affect all project but only
specific vendor), we are flexible to get driver features for -rc2 and -rc3 too.

Please check number of driver patches merged for a release, it is impossible to
manage them within period between -rc1 & -rc2.
Also some driver features are complex and big, they should be sent before
proposal deadline so that they can be reviewed for the release.

> +* A driver change should include documentation

s/should/must

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

Again for same issue, let me share my understanding,
the -rc1 has been tested widely, after that each -rc gets less and less tests.
So the -rc1 should have API/library changes, so that they will be tested more
and will have more time to fix any issues, since library changes has biggest
impact for the project.

Next biggest impact is drivers.

Applications and unit tests are internal to DPDK, they have no user impact, that
is why we can get more risk with them and they can be merged even as late as rc3.

And documentation doesn't have anything related to testing, or they don't
introduce any risk for specific release, so they are merged until last stage of
the release.

> +* The application should include documentation in the relevant .rst files
> +  (application-specific and release notes if significant).

s/should/must

> +* It may be the last opportunity for miscellaneous changes.

This is very vague, what does misch changes mean?

> +* Libraries and drivers cleanup are allowed.
> +* Small driver reworks.
> +* Critical and minor bug fixes.
> +
> +rc4
> +~~~
> +
> +* Documentation updates.
> +* Critical bug fixes.
> 

Re: [dpdk-dev] [PATCH v6] doc: add release milestones definition

[Thomas Monjalon]

18/05/2021 13:57, Ferruh Yigit:
> On 3/28/2021 8:00 PM, Thomas Monjalon wrote:
> > From: Asaf Penso <asafp@nvidia.com>
> > 
> > Adding more information about the release milestones.
> > This includes the scope of change, expectations, etc.
[...]
> > +rc1
> > +~~~
> > +
> > +* Priority: new or updated API.
> 
> Can we just say API or libraries?

Yes

> Overall what is the intention for the 'priority' information? Should we really
> split release candidates for libraries, driver and applications?
> We merge all as much as possible before -rc1.

The idea is to simply reflect the priority
in case time is limited. But yes we always merge as much as possible.

> Can we say this other-way around, API/library features can't be merged after -rc1.

Correct

> And similarly driver features shouldn't be merged after -rc2, application
> changes shouldn't merge after -rc3.
> Fixes can be merged anytime before -rc4. After -rc4 only critical fixes and
> documentation changes.
> 
> Just I want to highlight that for example we merge documentation updates
> anytime, it doesn't have to wait -rc4, but below listing looks like different
> part only allocated for different -rc, which is wrong as far as I know.

I understand the confusion and will try to make it clearer in next revision.

> > +* New API should be defined and implemented in libraries.
> > +* The API should include Doxygen documentation
> 
> s/should/must

OK

> > +  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.
> 
> I am not sure if "must be sent as a separate series" needs to be highlighted,
> having all in the same series has a benefit to see bigger picture. If the driver
> patches acked/reviewed by its maintainers, I think it can be merged in single
> series.

That's not the same kind of review for driver and API,
not the same time constraint, and not the same iterations.
I think it is more practical to suggest separate,
but it should not be "must".

> > +* 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.
> 
> I already mentioned above, but this can cause misunderstanding. We want all
> driver implementation to be ready for proposal deadline, same as other patches.
> But because of its reduced scope (they don't affect all project but only
> specific vendor), we are flexible to get driver features for -rc2 and -rc3 too.

-rc3 really? It should be exceptional so not mentioned here.

> Please check number of driver patches merged for a release, it is impossible to
> manage them within period between -rc1 & -rc2.
> Also some driver features are complex and big, they should be sent before
> proposal deadline so that they can be reviewed for the release.

Yes sooner is better. The doc is about deadline + priorities,
showing the no-go limits, without warranty of merge if all good.
Is there a contradiction?

> > +* A driver change should include documentation
> 
> s/should/must

Sometimes there is no doc to change. Is "must" confusing?

> > +  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.
> 
> Again for same issue, let me share my understanding,
> the -rc1 has been tested widely, after that each -rc gets less and less tests.
> So the -rc1 should have API/library changes, so that they will be tested more
> and will have more time to fix any issues, since library changes has biggest
> impact for the project.
> 
> Next biggest impact is drivers.
> 
> Applications and unit tests are internal to DPDK, they have no user impact, that
> is why we can get more risk with them and they can be merged even as late as rc3.
> 
> And documentation doesn't have anything related to testing, or they don't
> introduce any risk for specific release, so they are merged until last stage of
> the release.

Yes

> > +* The application should include documentation in the relevant .rst files
> > +  (application-specific and release notes if significant).
> 
> s/should/must
> 
> > +* It may be the last opportunity for miscellaneous changes.
> 
> This is very vague, what does misch changes mean?

Scripts, code cleanup, yes it is vague, we can remove.

> > +* Libraries and drivers cleanup are allowed.
> > +* Small driver reworks.
> > +* Critical and minor bug fixes.
> > +
> > +rc4
> > +~~~
> > +
> > +* Documentation updates.
> > +* Critical bug fixes.

Re: [dpdk-dev] [PATCH v6] doc: add release milestones definition

[Ferruh Yigit]

On 5/18/2021 1:25 PM, Thomas Monjalon wrote:
> 18/05/2021 13:57, Ferruh Yigit:
>> On 3/28/2021 8:00 PM, Thomas Monjalon wrote:
>>> From: Asaf Penso <asafp@nvidia.com>
>>>
>>> Adding more information about the release milestones.
>>> This includes the scope of change, expectations, etc.
> [...]
>>> +rc1
>>> +~~~
>>> +
>>> +* Priority: new or updated API.
>>
>> Can we just say API or libraries?
> 
> Yes
> 
>> Overall what is the intention for the 'priority' information? Should we really
>> split release candidates for libraries, driver and applications?
>> We merge all as much as possible before -rc1.
> 
> The idea is to simply reflect the priority
> in case time is limited. But yes we always merge as much as possible.
> 
>> Can we say this other-way around, API/library features can't be merged after -rc1.
> 
> Correct
> 
>> And similarly driver features shouldn't be merged after -rc2, application
>> changes shouldn't merge after -rc3.
>> Fixes can be merged anytime before -rc4. After -rc4 only critical fixes and
>> documentation changes.
>>
>> Just I want to highlight that for example we merge documentation updates
>> anytime, it doesn't have to wait -rc4, but below listing looks like different
>> part only allocated for different -rc, which is wrong as far as I know.
> 
> I understand the confusion and will try to make it clearer in next revision.
> 
>>> +* New API should be defined and implemented in libraries.
>>> +* The API should include Doxygen documentation
>>
>> s/should/must
> 
> OK
> 
>>> +  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.
>>
>> I am not sure if "must be sent as a separate series" needs to be highlighted,
>> having all in the same series has a benefit to see bigger picture. If the driver
>> patches acked/reviewed by its maintainers, I think it can be merged in single
>> series.
> 
> That's not the same kind of review for driver and API,
> not the same time constraint, and not the same iterations.
> I think it is more practical to suggest separate,
> but it should not be "must".
> 
>>> +* 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.
>>
>> I already mentioned above, but this can cause misunderstanding. We want all
>> driver implementation to be ready for proposal deadline, same as other patches.
>> But because of its reduced scope (they don't affect all project but only
>> specific vendor), we are flexible to get driver features for -rc2 and -rc3 too.
> 
> -rc3 really? It should be exceptional so not mentioned here.
> 

In practice we are having it, but agree to have it exceptional and not mention
in the guide.

>> Please check number of driver patches merged for a release, it is impossible to
>> manage them within period between -rc1 & -rc2.
>> Also some driver features are complex and big, they should be sent before
>> proposal deadline so that they can be reviewed for the release.
> 
> Yes sooner is better. The doc is about deadline + priorities,
> showing the no-go limits, without warranty of merge if all good.
> Is there a contradiction?
> 

My concern is document can be read as, it is normal/expected to send driver
patches after -rc1, because this documents as -rc2 task is driver patches.

I am OK with it if it is clear that deadline is -rc2, but normal/expected is to
have driver patches also before proposal deadline.

>>> +* A driver change should include documentation
>>
>> s/should/must
> 
> Sometimes there is no doc to change. Is "must" confusing?
> 

I believe we can improve our documentation, there are some new features driver
or library, not documented at all.

But you are right, there may be driver features that may not require any
documentation, but if there is a feature big enough for documentation, I am for
having documentation as a 'must', not sure how to clearly document this.

>>> +  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.
>>
>> Again for same issue, let me share my understanding,
>> the -rc1 has been tested widely, after that each -rc gets less and less tests.
>> So the -rc1 should have API/library changes, so that they will be tested more
>> and will have more time to fix any issues, since library changes has biggest
>> impact for the project.
>>
>> Next biggest impact is drivers.
>>
>> Applications and unit tests are internal to DPDK, they have no user impact, that
>> is why we can get more risk with them and they can be merged even as late as rc3.
>>
>> And documentation doesn't have anything related to testing, or they don't
>> introduce any risk for specific release, so they are merged until last stage of
>> the release.
> 
> Yes
> 
>>> +* The application should include documentation in the relevant .rst files
>>> +  (application-specific and release notes if significant).
>>
>> s/should/must
>>
>>> +* It may be the last opportunity for miscellaneous changes.
>>
>> This is very vague, what does misch changes mean?
> 
> Scripts, code cleanup, yes it is vague, we can remove.
> 
>>> +* Libraries and drivers cleanup are allowed.
>>> +* Small driver reworks.
>>> +* Critical and minor bug fixes.
>>> +
>>> +rc4
>>> +~~~
>>> +
>>> +* Documentation updates.
>>> +* Critical bug fixes.
> 
> 
> 

Re: [dpdk-dev] [PATCH v6] doc: add release milestones definition

[Ajit Khaparde]

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

>
>
> >> I already mentioned above, but this can cause misunderstanding. We want
> all
> >> driver implementation to be ready for proposal deadline, same as other
> patches.
> >> But because of its reduced scope (they don't affect all project but only
> >> specific vendor), we are flexible to get driver features for -rc2 and
> -rc3 too.
> >
> > -rc3 really? It should be exceptional so not mentioned here.
>
Agree. Let's keep it to -rc2.


> >
>
> In practice we are having it, but agree to have it exceptional and not
> mention
> in the guide.
>
> >> Please check number of driver patches merged for a release, it is
> impossible to
> >> manage them within period between -rc1 & -rc2.
> >> Also some driver features are complex and big, they should be sent
> before
> >> proposal deadline so that they can be reviewed for the release.
> >
> > Yes sooner is better. The doc is about deadline + priorities,
> > showing the no-go limits, without warranty of merge if all good.
> > Is there a contradiction?
> >
>
> My concern is document can be read as, it is normal/expected to send driver
> patches after -rc1, because this documents as -rc2 task is driver patches.
>
> I am OK with it if it is clear that deadline is -rc2, but normal/expected
> is to
> have driver patches also before proposal deadline.
>
+1


>
>
>
>

[dpdk-dev] [PATCH v7] doc: add release milestones definition

[Thomas Monjalon]

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
v7: make expectations clearer and stricter
---
 doc/guides/contributing/patches.rst | 72 +++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 6dbbd5f8d1..4d70e326c5 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,73 @@ 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>`_.
+
+.. note::
+   Sooner is always better. Deadlines are not ideal dates.
+
+   Integration is never guaranteed but everyone can help.
+
+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: libraries. No library feature should be accepted after -rc1.
+* New API must be defined and implemented in libraries.
+* The API must 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 may be a draft sent in 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. No driver feature should be accepted after -rc2.
+* A driver change must 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. No application feature should be accepted after -rc3.
+* New functionality that does not depend on libraries update
+  can be integrated as part of -rc3.
+* The application change must include documentation in the relevant .rst files
+  (application-specific and release notes if significant).
+* Libraries and drivers cleanup are allowed.
+* Small driver reworks.
+* Critical and minor bug fixes.
+
+rc4
+~~~
+
+* Documentation updates.
+* Critical bug fixes.
-- 
2.31.1

Re: [dpdk-dev] [PATCH v7] doc: add release milestones definition

[Bruce Richardson]

On Tue, May 18, 2021 at 06:43:03PM +0200, Thomas Monjalon 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
> v7: make expectations clearer and stricter
> ---
This LGTM

Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Re: [dpdk-dev] [PATCH v7] doc: add release milestones definition

[Ferruh Yigit]

On 5/18/2021 5:43 PM, Thomas Monjalon 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
> v7: make expectations clearer and stricter
> ---
>  doc/guides/contributing/patches.rst | 72 +++++++++++++++++++++++++++++
>  1 file changed, 72 insertions(+)
> 
> diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
> index 6dbbd5f8d1..4d70e326c5 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,73 @@ 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,

Is the ',' correct here. John may help better.

> +for a typical release cycle (3 months ending after 4 release candidates).

Can it be better to put explicitly that a regular release cycle takes around 3
months and it mostly has 4 release candidates, instead of giving this shortly
within parenthesis?

> +The number and expectations of release candidates might vary slightly.
> +The schedule is updated in the `roadmap <https://core.dpdk.org/roadmap/#dates>`_.
> +
> +.. note::
> +   Sooner is always better. Deadlines are not ideal dates.
> +

+1

> +   Integration is never guaranteed but everyone can help.
> +
> +Roadmap
> +~~~~~~~
> +
> +* Announce new features in libraries, drivers, applications, and examples.

Do we need to call out the components, what about "Announce new features for
next release."

Is it fair to say features announced with a roadmap will get more priority
against the features that are not announced?

> +* To be published before the first day of the release cycle.
> +
> +Proposal Deadline

Does it have any value to document something like this:

release start - proposal deadline: Initial development phase
proposal deadline - rc1: review / update / review phase
rc1 - release: test / update / test phase

> +~~~~~~~~~~~~~~~~~
> +
> +* Must send an RFC or a complete v1 patch.

The subject is missing, it is developers, but would it be better to say
something like:

An RFC (Request For Comment) or first version of the implementation must be
ready before deadline for the feature to be taken into account for the release.

> +* Early RFC gives time for design review before complete implementation.
> +* Should include at least the API changes in libraries and applications.

Again subject is missing,

Implementation should include ...

> +* Library code should be quite complete at the deadline.
> +* Nice to have: driver implementation (full or draft), example code, and documentation.

This is talking about driver/example/documentation update related to a library
implementation, right?
Otherwise for the standalone driver/example implementation, isn't the target to
send them before proposal deadline?

> +
> +rc1
> +~~~
> +
> +* Priority: libraries. No library feature should be accepted after -rc1.
> +* New API must be defined and implemented in libraries.

Not sure about the value of "defined", why not just "new API must be implemented
in libraries". Also I guess it doesn't need to 'new'.

Also another big step here is it needs to approved by its maintainers.

What about something like:

API changes or additions must be implemented and approved by their maintainers.

And as we know reviews can be bottleneck perhaps we can add a note on that too,
like: Developer should send a reminder for the patches that has not reviewed for
more than two weeks. ??

> +* The API must 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 may be a draft sent in a separate series.

Above 2/3 bullets are the conditions for a feature to be merged, it is not
directly related to the milestone, should we have separate section to document
the expectation to upstream a new API?

> +* The above should be sent to the mailing list at least 2 weeks before -rc1.
> +* Nice to have: example code (``/examples``)
> +

I think we should mention that we expect test result from community after -rc1,
if this is to document the process.

> +rc2
> +~~~
> +
> +* Priority: drivers. No driver feature should be accepted after -rc2.
> +* A driver change must 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.
> +

I think testing and fixing issues found in the -rc1 is the big focus of the
-rc2. But we don't mention of the testing at all. Again I guess this is based on
the confusion if these descriptions define process or todo list for the developers.

> +rc3
> +~~~
> +
> +* Priority: applications. No application feature should be accepted after -rc3.
> +* New functionality that does not depend on libraries update
> +  can be integrated as part of -rc3.
> +* The application change must include documentation in the relevant .rst files
> +  (application-specific and release notes if significant).
> +* Libraries and drivers cleanup are allowed.
> +* Small driver reworks.
> +* Critical and minor bug fixes.

Can this cause misunderstanding that fixes are merged for -rc3 (after -rc2)?
Can we highlight that fixes can be sent and merged anytime until -rc4, only
after -rc4 there is a restriction and only critical fixes are accepted?

> +
> +rc4
> +~~~
> +
> +* Documentation updates.
> +* Critical bug fixes.
> 

Re: [dpdk-dev] [PATCH v7] doc: add release milestones definition

[Thomas Monjalon]

19/05/2021 13:58, Ferruh Yigit:
> On 5/18/2021 5:43 PM, Thomas Monjalon 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
> > v7: make expectations clearer and stricter
> > ---
> >  doc/guides/contributing/patches.rst | 72 +++++++++++++++++++++++++++++
> >  1 file changed, 72 insertions(+)
> > 
> > diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
> > index 6dbbd5f8d1..4d70e326c5 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,73 @@ 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,
> 
> Is the ',' correct here. John may help better.
> 
> > +for a typical release cycle (3 months ending after 4 release candidates).
> 
> Can it be better to put explicitly that a regular release cycle takes around 3
> months and it mostly has 4 release candidates, instead of giving this shortly
> within parenthesis?
> 
> > +The number and expectations of release candidates might vary slightly.
> > +The schedule is updated in the `roadmap <https://core.dpdk.org/roadmap/#dates>`_.
> > +
> > +.. note::
> > +   Sooner is always better. Deadlines are not ideal dates.
> > +
> 
> +1
> 
> > +   Integration is never guaranteed but everyone can help.
> > +
> > +Roadmap
> > +~~~~~~~
> > +
> > +* Announce new features in libraries, drivers, applications, and examples.
> 
> Do we need to call out the components, what about "Announce new features for
> next release."

The idea was to insist that all can be announced, including apps.

> Is it fair to say features announced with a roadmap will get more priority
> against the features that are not announced?

It should be discussed in a separate patch I think.

> > +* To be published before the first day of the release cycle.
> > +
> > +Proposal Deadline
> 
> Does it have any value to document something like this:
> 
> release start - proposal deadline: Initial development phase
> proposal deadline - rc1: review / update / review phase
> rc1 - release: test / update / test phase

I don't know.

> > +~~~~~~~~~~~~~~~~~
> > +
> > +* Must send an RFC or a complete v1 patch.
> 
> The subject is missing, it is developers, but would it be better to say
> something like:
> 
> An RFC (Request For Comment) or first version of the implementation must be
> ready before deadline for the feature to be taken into account for the release.

I was trying to keep it short.

> > +* Early RFC gives time for design review before complete implementation.
> > +* Should include at least the API changes in libraries and applications.
> 
> Again subject is missing,
> 
> Implementation should include ...

I'm afraid it will become boring.

> > +* Library code should be quite complete at the deadline.
> > +* Nice to have: driver implementation (full or draft), example code, and documentation.
> 
> This is talking about driver/example/documentation update related to a library
> implementation, right?

Right

> Otherwise for the standalone driver/example implementation, isn't the target to
> send them before proposal deadline?

Yes

> > +
> > +rc1
> > +~~~
> > +
> > +* Priority: libraries. No library feature should be accepted after -rc1.
> > +* New API must be defined and implemented in libraries.
> 
> Not sure about the value of "defined", why not just "new API must be implemented
> in libraries". Also I guess it doesn't need to 'new'.

OK

> Also another big step here is it needs to approved by its maintainers.
> 
> What about something like:
> 
> API changes or additions must be implemented and approved by their maintainers.

Yes good idea.

> And as we know reviews can be bottleneck perhaps we can add a note on that too,
> like: Developer should send a reminder for the patches that has not reviewed for
> more than two weeks. ??

Yes, 10 days?

> > +* The API must 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 may be a draft sent in a separate series.
> 
> Above 2/3 bullets are the conditions for a feature to be merged, it is not
> directly related to the milestone, should we have separate section to document
> the expectation to upstream a new API?

Yes, you're right but I feel it has a better value here as a complete checklist.

> > +* The above should be sent to the mailing list at least 2 weeks before -rc1.
> > +* Nice to have: example code (``/examples``)
> > +
> 
> I think we should mention that we expect test result from community after -rc1,
> if this is to document the process.

We expect tests after each -rc, so it would better fit as a general comment
in the schedule introduction.

> > +rc2
> > +~~~
> > +
> > +* Priority: drivers. No driver feature should be accepted after -rc2.
> > +* A driver change must 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.
> > +
> 
> I think testing and fixing issues found in the -rc1 is the big focus of the
> -rc2. But we don't mention of the testing at all. Again I guess this is based on
> the confusion if these descriptions define process or todo list for the developers.

I would like to have both at the same place,
so I agree we should mention fixing any issue found in previous stages.

> > +rc3
> > +~~~
> > +
> > +* Priority: applications. No application feature should be accepted after -rc3.
> > +* New functionality that does not depend on libraries update
> > +  can be integrated as part of -rc3.
> > +* The application change must include documentation in the relevant .rst files
> > +  (application-specific and release notes if significant).
> > +* Libraries and drivers cleanup are allowed.
> > +* Small driver reworks.
> > +* Critical and minor bug fixes.
> 
> Can this cause misunderstanding that fixes are merged for -rc3 (after -rc2)?
> Can we highlight that fixes can be sent and merged anytime until -rc4, only
> after -rc4 there is a restriction and only critical fixes are accepted?

I think we should mention "any fix" for -rc2,
and "all accepted" for -rc1 to remove confusion.

> > +
> > +rc4
> > +~~~
> > +
> > +* Documentation updates.
> > +* Critical bug fixes.

[dpdk-dev] [PATCH v8] doc: add release milestones definition

[Thomas Monjalon]

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>
Acked-by: Bruce Richardson <bruce.richardson@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
v7: make expectations clearer and stricter
v8: add tests, more fixes, maintainers approval and new API rules
---
 doc/guides/contributing/patches.rst | 85 +++++++++++++++++++++++++++--
 1 file changed, 80 insertions(+), 5 deletions(-)

diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index b9cc6e67ae..ef784d0f99 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -164,6 +164,10 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
   the :doc:`ABI policy <abi_policy>` and :ref:`ABI versioning <abi_versioning>`
   guides. New external functions should also be added in alphabetical order.
 
+* Any new API function should be used in ``/app`` test directory.
+
+* When introducing a new device API, at least one driver should implement it.
+
 * Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``.
   See the :ref:`Release Notes section of the Documentation Guidelines <doc_guidelines>` for details.
 
@@ -177,6 +181,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
@@ -185,11 +191,6 @@ Larger changes that require different explanations should be separated into logi
 A good way of thinking about whether a patch should be split is to consider whether the change could be
 applied without dependencies as a backport.
 
-It is better to keep the related documentation changes in the same patch
-file as the code, rather than one big documentation patch at the end of a
-patchset. This makes it easier for future maintenance and development of the
-code.
-
 As a guide to how patches should be structured run ``git log`` on similar files.
 
 
@@ -663,3 +664,77 @@ 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.
+An average cycle lasts 3 months and have 4 release candidates in the last month.
+Test reports are expected to be received after each release candidate.
+The number and expectations of release candidates might vary slightly.
+The schedule is updated in the `roadmap <https://core.dpdk.org/roadmap/#dates>`_.
+
+.. note::
+   Sooner is always better. Deadlines are not ideal dates.
+
+   Integration is never guaranteed but everyone can help.
+
+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 (Request For Comments) or a complete patch of new features.
+* 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, example code, and documentation.
+
+rc1
+~~~
+
+* Priority: libraries. No library feature should be accepted after -rc1.
+* API changes or additions must be implemented in libraries.
+* The API must 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 may be a draft sent in a separate series.
+* The above should be sent to the mailing list at least 2 weeks before -rc1
+  to give time for review and maintainers approval.
+* If no review after 10 days, a reminder should be sent.
+* Nice to have: example code (``/examples``)
+
+rc2
+~~~
+
+* Priority: drivers. No driver feature should be accepted after -rc2.
+* A driver change must 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.
+* Any issue found in -rc1 should be fixed.
+
+rc3
+~~~
+
+* Priority: applications. No application feature should be accepted after -rc3.
+* New functionality that does not depend on libraries update
+  can be integrated as part of -rc3.
+* The application change must include documentation in the relevant .rst files
+  (application-specific and release notes if significant).
+* Libraries and drivers cleanup are allowed.
+* Small driver reworks.
+* Critical and minor bug fixes.
+
+rc4
+~~~
+
+* Documentation updates.
+* Critical bug fixes.
-- 
2.31.1

Re: [dpdk-dev] [PATCH v8] doc: add release milestones definition

[Ferruh Yigit]

On 8/26/2021 11:11 AM, Thomas Monjalon 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>
> Acked-by: Bruce Richardson <bruce.richardson@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
> v7: make expectations clearer and stricter
> v8: add tests, more fixes, maintainers approval and new API rules
> ---
>  doc/guides/contributing/patches.rst | 85 +++++++++++++++++++++++++++--
>  1 file changed, 80 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
> index b9cc6e67ae..ef784d0f99 100644
> --- a/doc/guides/contributing/patches.rst
> +++ b/doc/guides/contributing/patches.rst
> @@ -164,6 +164,10 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
>    the :doc:`ABI policy <abi_policy>` and :ref:`ABI versioning <abi_versioning>`
>    guides. New external functions should also be added in alphabetical order.
>  
> +* Any new API function should be used in ``/app`` test directory.
> +
> +* When introducing a new device API, at least one driver should implement it.
> +

ack

>  * Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``.
>    See the :ref:`Release Notes section of the Documentation Guidelines <doc_guidelines>` for details.
>  
> @@ -177,6 +181,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.
> +

ack

>  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
> @@ -185,11 +191,6 @@ Larger changes that require different explanations should be separated into logi
>  A good way of thinking about whether a patch should be split is to consider whether the change could be
>  applied without dependencies as a backport.
>  
> -It is better to keep the related documentation changes in the same patch
> -file as the code, rather than one big documentation patch at the end of a
> -patchset. This makes it easier for future maintenance and development of the
> -code.
> -
>  As a guide to how patches should be structured run ``git log`` on similar files.
>  
>  
> @@ -663,3 +664,77 @@ 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.
> +An average cycle lasts 3 months and have 4 release candidates in the last month.
> +Test reports are expected to be received after each release candidate.
> +The number and expectations of release candidates might vary slightly.
> +The schedule is updated in the `roadmap <https://core.dpdk.org/roadmap/#dates>`_.
> +
> +.. note::
> +   Sooner is always better. Deadlines are not ideal dates.
> +
> +   Integration is never guaranteed but everyone can help.
> +
> +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 (Request For Comments) or a complete patch of new features.
> +* 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, example code, and documentation.
> +
> +rc1
> +~~~
> +
> +* Priority: libraries. No library feature should be accepted after -rc1.
> +* API changes or additions must be implemented in libraries.
> +* The API must 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 may be a draft sent in a separate series.
> +* The above should be sent to the mailing list at least 2 weeks before -rc1
> +  to give time for review and maintainers approval.
> +* If no review after 10 days, a reminder should be sent.
> +* Nice to have: example code (``/examples``)
> +
> +rc2
> +~~~
> +
> +* Priority: drivers. No driver feature should be accepted after -rc2.
> +* A driver change must 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.

Is 'the above' driver changes? It is good the have all driver changes two weeks
before -rc2 but taking into account that overall time between -rc1 & -rc2 is 3/4
weeks, two weeks before -rc2 may be hard to do practically.
We may go with this and try and evaluate later or reduce the requirement to one
week before -rc2, what do you think?

> +* Any issue found in -rc1 should be fixed.
> +
> +rc3
> +~~~
> +
> +* Priority: applications. No application feature should be accepted after -rc3.
> +* New functionality that does not depend on libraries update
> +  can be integrated as part of -rc3.
> +* The application change must include documentation in the relevant .rst files
> +  (application-specific and release notes if significant).
> +* Libraries and drivers cleanup are allowed.
> +* Small driver reworks.
> +* Critical and minor bug fixes.

As mentioned before, my concern is this may create false impression that bugs
are fixed only in this phase. What about remove this line completely and update
below -rc4 one as 'Critical bug fixes only.'? I think that makes intention more
clear.

> +
> +rc4
> +~~~
> +
> +* Documentation updates.
> +* Critical bug fixes.
> 

Re: [dpdk-dev] [PATCH v8] doc: add release milestones definition

[Thomas Monjalon]

02/09/2021 18:33, Ferruh Yigit:
> On 8/26/2021 11:11 AM, Thomas Monjalon wrote:
> > +rc1
> > +~~~
> > +
> > +* Priority: libraries. No library feature should be accepted after -rc1.
> > +* API changes or additions must be implemented in libraries.
> > +* The API must 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 may be a draft sent in a separate series.
> > +* The above should be sent to the mailing list at least 2 weeks before -rc1
> > +  to give time for review and maintainers approval.
> > +* If no review after 10 days, a reminder should be sent.
> > +* Nice to have: example code (``/examples``)
> > +
> > +rc2
> > +~~~
> > +
> > +* Priority: drivers. No driver feature should be accepted after -rc2.
> > +* A driver change must 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.
> 
> Is 'the above' driver changes?

Yes. Do you think to a more explicit wording?

> It is good the have all driver changes two weeks
> before -rc2 but taking into account that overall time between -rc1 & -rc2 is 3/4
> weeks,

No, time between rc1 and rc2 is usually 2 weeks,
so it means having drivers features at the time of -rc1.

> two weeks before -rc2 may be hard to do practically.
> We may go with this and try and evaluate later or reduce the requirement to one
> week before -rc2, what do you think?

This is for the first version of the PMD features.
Then there are reviews and new iterations.
I think one week is too short.
What do you think of 10 days?

> > +* Any issue found in -rc1 should be fixed.
> > +
> > +rc3
> > +~~~
> > +
> > +* Priority: applications. No application feature should be accepted after -rc3.
> > +* New functionality that does not depend on libraries update
> > +  can be integrated as part of -rc3.
> > +* The application change must include documentation in the relevant .rst files
> > +  (application-specific and release notes if significant).
> > +* Libraries and drivers cleanup are allowed.
> > +* Small driver reworks.
> > +* Critical and minor bug fixes.
> 
> As mentioned before, my concern is this may create false impression that bugs
> are fixed only in this phase. What about remove this line completely and update
> below -rc4 one as 'Critical bug fixes only.'? I think that makes intention more
> clear.

I had added in -rc2: "Any issue found in -rc1 should be fixed."
Do you want to remove it as well?

> > +
> > +rc4
> > +~~~
> > +
> > +* Documentation updates.
> > +* Critical bug fixes.

Re: [dpdk-dev] [PATCH v8] doc: add release milestones definition

[Ferruh Yigit]

On 9/3/2021 12:50 PM, Thomas Monjalon wrote:
> 02/09/2021 18:33, Ferruh Yigit:
>> On 8/26/2021 11:11 AM, Thomas Monjalon wrote:
>>> +rc1
>>> +~~~
>>> +
>>> +* Priority: libraries. No library feature should be accepted after -rc1.
>>> +* API changes or additions must be implemented in libraries.
>>> +* The API must 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 may be a draft sent in a separate series.
>>> +* The above should be sent to the mailing list at least 2 weeks before -rc1
>>> +  to give time for review and maintainers approval.
>>> +* If no review after 10 days, a reminder should be sent.
>>> +* Nice to have: example code (``/examples``)
>>> +
>>> +rc2
>>> +~~~
>>> +
>>> +* Priority: drivers. No driver feature should be accepted after -rc2.
>>> +* A driver change must 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.
>>
>> Is 'the above' driver changes?
> 
> Yes. Do you think to a more explicit wording?
> 

Can say 'Driver change' again, it is not too long from 'The above', but no
strong opinion.

>> It is good the have all driver changes two weeks
>> before -rc2 but taking into account that overall time between -rc1 & -rc2 is 3/4
>> weeks,
> 
> No, time between rc1 and rc2 is usually 2 weeks,
> so it means having drivers features at the time of -rc1.
> 

Got the intention now, perhaps we can word like that, '... should be sent before
-rc1 released ...'

>> two weeks before -rc2 may be hard to do practically.
>> We may go with this and try and evaluate later or reduce the requirement to one
>> week before -rc2, what do you think?
> 
> This is for the first version of the PMD features.
> Then there are reviews and new iterations.
> I think one week is too short.
> What do you think of 10 days?
> 

Agree that a week is short, I just thought that it is happening in practice, but
if you don't mind lets keep your original proposal (-rc1 deadline for first
version of driver patches) with the option to update it later if we have
difficulties to keep it.

>>> +* Any issue found in -rc1 should be fixed.
>>> +
>>> +rc3
>>> +~~~
>>> +
>>> +* Priority: applications. No application feature should be accepted after -rc3.
>>> +* New functionality that does not depend on libraries update
>>> +  can be integrated as part of -rc3.
>>> +* The application change must include documentation in the relevant .rst files
>>> +  (application-specific and release notes if significant).
>>> +* Libraries and drivers cleanup are allowed.
>>> +* Small driver reworks.
>>> +* Critical and minor bug fixes.
>>
>> As mentioned before, my concern is this may create false impression that bugs
>> are fixed only in this phase. What about remove this line completely and update
>> below -rc4 one as 'Critical bug fixes only.'? I think that makes intention more
>> clear.
> 
> I had added in -rc2: "Any issue found in -rc1 should be fixed."
> Do you want to remove it as well?
> 

I think we can keep it, good to highlight one of the major tasks for -rc2 is to
fix defects found in -rc1, and it doesn't limit fixes to ones found in -rc1.

>>> +
>>> +rc4
>>> +~~~
>>> +
>>> +* Documentation updates.
>>> +* Critical bug fixes.
> 
> 
> 

Re: [dpdk-dev] [PATCH v8] doc: add release milestones definition

[Thomas Monjalon]

03/09/2021 17:35, Ferruh Yigit:
> On 9/3/2021 12:50 PM, Thomas Monjalon wrote:
> > 02/09/2021 18:33, Ferruh Yigit:
> >> On 8/26/2021 11:11 AM, Thomas Monjalon wrote:
> >>> +* Any issue found in -rc1 should be fixed.
> >>> +
> >>> +rc3
> >>> +~~~
> >>> +
> >>> +* Priority: applications. No application feature should be accepted after -rc3.
> >>> +* New functionality that does not depend on libraries update
> >>> +  can be integrated as part of -rc3.
> >>> +* The application change must include documentation in the relevant .rst files
> >>> +  (application-specific and release notes if significant).
> >>> +* Libraries and drivers cleanup are allowed.
> >>> +* Small driver reworks.
> >>> +* Critical and minor bug fixes.
> >>
> >> As mentioned before, my concern is this may create false impression that bugs
> >> are fixed only in this phase. What about remove this line completely and update
> >> below -rc4 one as 'Critical bug fixes only.'? I think that makes intention more
> >> clear.
> > 
> > I had added in -rc2: "Any issue found in -rc1 should be fixed."
> > Do you want to remove it as well?
> 
> I think we can keep it, good to highlight one of the major tasks for -rc2 is to
> fix defects found in -rc1, and it doesn't limit fixes to ones found in -rc1.

Actually I think it is better to remove.
It looks weird to have it only in -rc2.

Re: [dpdk-dev] [PATCH v8] doc: add release milestones definition

[Ajit Khaparde]

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

On Tue, Sep 14, 2021 at 12:53 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 03/09/2021 17:35, Ferruh Yigit:
> > On 9/3/2021 12:50 PM, Thomas Monjalon wrote:
> > > 02/09/2021 18:33, Ferruh Yigit:
> > >> On 8/26/2021 11:11 AM, Thomas Monjalon wrote:
> > >>> +* Any issue found in -rc1 should be fixed.
> > >>> +
> > >>> +rc3
> > >>> +~~~
> > >>> +
> > >>> +* Priority: applications. No application feature should be accepted after -rc3.
> > >>> +* New functionality that does not depend on libraries update
> > >>> +  can be integrated as part of -rc3.
> > >>> +* The application change must include documentation in the relevant .rst files
> > >>> +  (application-specific and release notes if significant).
> > >>> +* Libraries and drivers cleanup are allowed.
> > >>> +* Small driver reworks.
> > >>> +* Critical and minor bug fixes.
> > >>
> > >> As mentioned before, my concern is this may create false impression that bugs
> > >> are fixed only in this phase. What about remove this line completely and update
> > >> below -rc4 one as 'Critical bug fixes only.'? I think that makes intention more
> > >> clear.
> > >
> > > I had added in -rc2: "Any issue found in -rc1 should be fixed."
> > > Do you want to remove it as well?
> >
> > I think we can keep it, good to highlight one of the major tasks for -rc2 is to
> > fix defects found in -rc1, and it doesn't limit fixes to ones found in -rc1.
>
> Actually I think it is better to remove.
> It looks weird to have it only in -rc2.
I see you have sent the new version and it is looking really good.

We can mention that bug fixes are welcome at any point in the cycle,
but priority will be given to critical fixes close to the release date.

>
>

Re: [dpdk-dev] [PATCH v8] doc: add release milestones definition

[Thomas Monjalon]

14/09/2021 18:11, Ajit Khaparde:
> On Tue, Sep 14, 2021 at 12:53 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> > 03/09/2021 17:35, Ferruh Yigit:
> > > On 9/3/2021 12:50 PM, Thomas Monjalon wrote:
> > > > 02/09/2021 18:33, Ferruh Yigit:
> > > >> On 8/26/2021 11:11 AM, Thomas Monjalon wrote:
> > > >>> +* Any issue found in -rc1 should be fixed.
> > > >>> +
> > > >>> +rc3
> > > >>> +~~~
> > > >>> +
> > > >>> +* Priority: applications. No application feature should be accepted after -rc3.
> > > >>> +* New functionality that does not depend on libraries update
> > > >>> +  can be integrated as part of -rc3.
> > > >>> +* The application change must include documentation in the relevant .rst files
> > > >>> +  (application-specific and release notes if significant).
> > > >>> +* Libraries and drivers cleanup are allowed.
> > > >>> +* Small driver reworks.
> > > >>> +* Critical and minor bug fixes.
> > > >>
> > > >> As mentioned before, my concern is this may create false impression that bugs
> > > >> are fixed only in this phase. What about remove this line completely and update
> > > >> below -rc4 one as 'Critical bug fixes only.'? I think that makes intention more
> > > >> clear.
> > > >
> > > > I had added in -rc2: "Any issue found in -rc1 should be fixed."
> > > > Do you want to remove it as well?
> > >
> > > I think we can keep it, good to highlight one of the major tasks for -rc2 is to
> > > fix defects found in -rc1, and it doesn't limit fixes to ones found in -rc1.
> >
> > Actually I think it is better to remove.
> > It looks weird to have it only in -rc2.
> I see you have sent the new version and it is looking really good.
> 
> We can mention that bug fixes are welcome at any point in the cycle,

I hope it is obvious.

> but priority will be given to critical fixes close to the release date.

Yes it says critical bug fixes only.

Re: [dpdk-dev] [PATCH v8] doc: add release milestones definition

[Andrew Rybchenko]

On 8/26/21 1:11 PM, Thomas Monjalon 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>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>

LGTM, just one nits below

Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

> +Roadmap
> +~~~~~~~
> +
> +* Announce new features in libraries, drivers, applications, and examples.
> +* To be published before the first day of the release cycle.

What is the first day of the release cycle? Proposal deadline?
Or the first day just after the previous release?

Re: [dpdk-dev] [PATCH v8] doc: add release milestones definition

[Thomas Monjalon]

03/09/2021 14:26, Andrew Rybchenko:
> On 8/26/21 1:11 PM, Thomas Monjalon wrote:
> > +* Announce new features in libraries, drivers, applications, and examples.
> > +* To be published before the first day of the release cycle.
> 
> What is the first day of the release cycle? Proposal deadline?
> Or the first day just after the previous release?

Just after the previous release. I will be more explicit in v9, thanks.

[dpdk-dev] [PATCH v9] doc: add release milestones definition

[Thomas Monjalon]

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>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
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
v7: make expectations clearer and stricter
v8: add tests, more fixes, maintainers approval and new API rules
v9: make deadlines more explicit, remove confusing lines about fixes
---
 doc/guides/contributing/patches.rst | 83 +++++++++++++++++++++++++++--
 1 file changed, 78 insertions(+), 5 deletions(-)

diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index b9cc6e67ae..5a83209474 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -164,6 +164,10 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
   the :doc:`ABI policy <abi_policy>` and :ref:`ABI versioning <abi_versioning>`
   guides. New external functions should also be added in alphabetical order.
 
+* Any new API function should be used in ``/app`` test directory.
+
+* When introducing a new device API, at least one driver should implement it.
+
 * Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``.
   See the :ref:`Release Notes section of the Documentation Guidelines <doc_guidelines>` for details.
 
@@ -177,6 +181,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
@@ -185,11 +191,6 @@ Larger changes that require different explanations should be separated into logi
 A good way of thinking about whether a patch should be split is to consider whether the change could be
 applied without dependencies as a backport.
 
-It is better to keep the related documentation changes in the same patch
-file as the code, rather than one big documentation patch at the end of a
-patchset. This makes it easier for future maintenance and development of the
-code.
-
 As a guide to how patches should be structured run ``git log`` on similar files.
 
 
@@ -663,3 +664,75 @@ 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.
+An average cycle lasts 3 months and have 4 release candidates in the last month.
+Test reports are expected to be received after each release candidate.
+The number and expectations of release candidates might vary slightly.
+The schedule is updated in the `roadmap <https://core.dpdk.org/roadmap/#dates>`_.
+
+.. note::
+   Sooner is always better. Deadlines are not ideal dates.
+
+   Integration is never guaranteed but everyone can help.
+
+Roadmap
+~~~~~~~
+
+* Announce new features in libraries, drivers, applications, and examples.
+* To be published before the previous release.
+
+Proposal Deadline
+~~~~~~~~~~~~~~~~~
+
+* Must send an RFC (Request For Comments) or a complete patch of new features.
+* 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, example code, and documentation.
+
+rc1
+~~~
+
+* Priority: libraries. No library feature should be accepted after -rc1.
+* API changes or additions must be implemented in libraries.
+* The API must 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 may be a draft sent in a separate series.
+* The above should be sent to the mailing list at least 2 weeks before -rc1
+  to give time for review and maintainers approval.
+* If no review after 10 days, a reminder should be sent.
+* Nice to have: example code (``/examples``)
+
+rc2
+~~~
+
+* Priority: drivers. No driver feature should be accepted after -rc2.
+* A driver change must include documentation
+  in the relevant .rst files (driver-specific and release notes).
+* Driver changes should be sent to the mailing list before -rc1 is released.
+
+rc3
+~~~
+
+* Priority: applications. No application feature should be accepted after -rc3.
+* New functionality that does not depend on libraries update
+  can be integrated as part of -rc3.
+* The application change must include documentation in the relevant .rst files
+  (application-specific and release notes if significant).
+* Libraries and drivers cleanup are allowed.
+* Small driver reworks.
+
+rc4
+~~~
+
+* Documentation updates.
+* Critical bug fixes only.
-- 
2.33.0

Re: [dpdk-dev] [PATCH v9] doc: add release milestones definition

[Ferruh Yigit]

On 9/14/2021 8:56 AM, Thomas Monjalon 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>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Thanks for the documentation.

Re: [dpdk-dev] [PATCH v9] doc: add release milestones definition

[Thomas Monjalon]

14/09/2021 18:34, Ferruh Yigit:
> On 9/14/2021 8:56 AM, Thomas Monjalon 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>
> > Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> > Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 
> Thanks for the documentation.

Adding this last minute note at the end:
	Bug fixes are integrated as early as possible at any stage.
Is it OK?

Re: [dpdk-dev] [PATCH v9] doc: add release milestones definition

[Ajit Khaparde]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

On Tue, Sep 14, 2021 at 9:50 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 14/09/2021 18:34, Ferruh Yigit:
> > On 9/14/2021 8:56 AM, Thomas Monjalon 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>
> > > Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> > > Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >
> > Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
> >
> > Thanks for the documentation.
>
> Adding this last minute note at the end:
>         Bug fixes are integrated as early as possible at any stage.
> Is it OK?
Looks good to me.

>
>

Re: [dpdk-dev] [PATCH v9] doc: add release milestones definition

[Thomas Monjalon]

14/09/2021 18:51, Ajit Khaparde:
> On Tue, Sep 14, 2021 at 9:50 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 14/09/2021 18:34, Ferruh Yigit:
> > > On 9/14/2021 8:56 AM, Thomas Monjalon 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>
> > > > Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > >
> > > Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > >
> > > Thanks for the documentation.
> >
> > Adding this last minute note at the end:
> >         Bug fixes are integrated as early as possible at any stage.
> > Is it OK?
> Looks good to me.

Applied