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>
Subject: Re: [dpdk-dev] [PATCH v6] doc: add release milestones definition
Date: Tue, 18 May 2021 14:25:56 +0200	[thread overview]
Message-ID: <5731405.XtSjWBXQUY@thomas> (raw)
In-Reply-To: <45ecbd36-089c-a8a6-740f-3660310dee9d@intel.com>

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.




  reply	other threads:[~2021-05-18 12:26 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 [this message]
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=5731405.XtSjWBXQUY@thomas \
    --to=thomas@monjalon.net \
    --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).