DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>, dev@dpdk.org
Cc: david.marchand@redhat.com, Asaf Penso <asafp@nvidia.com>,
	John McNamara <john.mcnamara@intel.com>
Subject: Re: [dpdk-dev] [PATCH v6] doc: add release milestones definition
Date: Tue, 18 May 2021 12:57:15 +0100
Message-ID: <45ecbd36-089c-a8a6-740f-3660310dee9d@intel.com> (raw)
In-Reply-To: <20210328190005.4185594-1-thomas@monjalon.net>

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


  parent reply	other threads:[~2021-05-18 11:57 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-10 18:44 [dpdk-dev] [PATCH] " Asaf Penso
2021-01-12 13:30 ` [dpdk-dev] [PATCH v2] " Michael Baum
2021-01-13  9:12   ` [dpdk-dev] [PATCH v3 1/1] " Thomas Monjalon
2021-01-27 18:33     ` Mcnamara, John
2021-02-01 22:13 ` [dpdk-dev] [PATCH v4 " Thomas Monjalon
2021-02-01 22:31   ` Ajit Khaparde
2021-02-01 22:38     ` Thomas Monjalon
2021-02-03  7:58 ` [dpdk-dev] [PATCH v5 " Thomas Monjalon
2021-02-03 10:14   ` David Marchand
2021-02-03 10:27     ` Thomas Monjalon
2021-03-28 19:00 ` [dpdk-dev] [PATCH v6] " Thomas Monjalon
2021-03-29  2:02   ` Ajit Khaparde
2021-05-18 11:57   ` Ferruh Yigit [this message]
2021-05-18 12:25     ` Thomas Monjalon
2021-05-18 13:13       ` Ferruh Yigit
2021-05-18 17:20         ` Ajit Khaparde
2021-05-18 16:43 ` [dpdk-dev] [PATCH v7] " Thomas Monjalon
2021-05-19  8:56   ` Bruce Richardson
2021-05-19 11:58   ` Ferruh Yigit
2021-05-19 12:16     ` Thomas Monjalon
2021-08-26 10:11 ` [dpdk-dev] [PATCH v8] " Thomas Monjalon
2021-09-02 16:33   ` Ferruh Yigit
2021-09-03 11:50     ` Thomas Monjalon
2021-09-03 15:35       ` Ferruh Yigit
2021-09-14  7:53         ` Thomas Monjalon
2021-09-14 16:11           ` Ajit Khaparde
2021-09-14 16:46             ` Thomas Monjalon
2021-09-03 12:26   ` Andrew Rybchenko
2021-09-03 12:55     ` Thomas Monjalon
2021-09-14  7:56 ` [dpdk-dev] [PATCH v9] " Thomas Monjalon
2021-09-14 16:34   ` Ferruh Yigit
2021-09-14 16:50     ` Thomas Monjalon
2021-09-14 16:51       ` Ajit Khaparde
2021-09-14 17:20         ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45ecbd36-089c-a8a6-740f-3660310dee9d@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=asafp@nvidia.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ http://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git