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.
next prev parent 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).