DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org, 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 14:16:01 +0200	[thread overview]
Message-ID: <3621541.CEykRqKYJk@thomas> (raw)
In-Reply-To: <4f2c6803-5c20-6583-9439-1db66cbfe5d9@intel.com>

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.




  reply	other threads:[~2021-05-19 12:16 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
2021-05-19 12:16     ` Thomas Monjalon [this message]
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=3621541.CEykRqKYJk@thomas \
    --to=thomas@monjalon.net \
    --cc=ajit.khaparde@broadcom.com \
    --cc=asafp@nvidia.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=john.mcnamara@intel.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).