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>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>
Subject: Re: [dpdk-dev] [PATCH v7] doc: add release milestones definition
Date: Wed, 19 May 2021 12:58:47 +0100
Message-ID: <4f2c6803-5c20-6583-9439-1db66cbfe5d9@intel.com> (raw)
In-Reply-To: <20210518164303.4108310-1-thomas@monjalon.net>

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


  parent reply	other threads:[~2021-05-19 11:58 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
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 [this message]
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=4f2c6803-5c20-6583-9439-1db66cbfe5d9@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=ajit.khaparde@broadcom.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 https://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/ https://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