[v5,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.

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

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
>
  

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?