From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
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:13:38 +0100 [thread overview]
Message-ID: <5fa24714-796e-c312-08df-d516e4f6e68e@intel.com> (raw)
In-Reply-To: <5731405.XtSjWBXQUY@thomas>
On 5/18/2021 1:25 PM, Thomas Monjalon wrote:
> 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.
>
In practice we are having it, but agree to have it exceptional and not mention
in the guide.
>> 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?
>
My concern is document can be read as, it is normal/expected to send driver
patches after -rc1, because this documents as -rc2 task is driver patches.
I am OK with it if it is clear that deadline is -rc2, but normal/expected is to
have driver patches also before proposal deadline.
>>> +* A driver change should include documentation
>>
>> s/should/must
>
> Sometimes there is no doc to change. Is "must" confusing?
>
I believe we can improve our documentation, there are some new features driver
or library, not documented at all.
But you are right, there may be driver features that may not require any
documentation, but if there is a feature big enough for documentation, I am for
having documentation as a 'must', not sure how to clearly document this.
>>> + 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 13:13 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 [this message]
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=5fa24714-796e-c312-08df-d516e4f6e68e@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
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).