Re: [dpdk-dev] [PATCH v8] doc: add release milestones definition

On 9/3/2021 12:50 PM, Thomas Monjalon wrote:

02/09/2021 18:33, Ferruh Yigit:

quoted

On 8/26/2021 11:11 AM, Thomas Monjalon wrote:

quoted

+rc1
+~~~
+
+* Priority: libraries. No library feature should be accepted after -rc1.
+* API changes or additions must be implemented in libraries.
+* 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.
+* The above should be sent to the mailing list at least 2 weeks before -rc1
+  to give time for review and maintainers approval.
+* If no review after 10 days, a reminder should be sent.
+* Nice to have: example code (``/examples``)
+
+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.

Is 'the above' driver changes?

Yes. Do you think to a more explicit wording?

Can say 'Driver change' again, it is not too long from 'The above', but no
strong opinion.

quoted

It is good the have all driver changes two weeks
before -rc2 but taking into account that overall time between -rc1 & -rc2 is 3/4
weeks,

No, time between rc1 and rc2 is usually 2 weeks,
so it means having drivers features at the time of -rc1.

Got the intention now, perhaps we can word like that, '... should be sent before
-rc1 released ...'

quoted

two weeks before -rc2 may be hard to do practically.
We may go with this and try and evaluate later or reduce the requirement to one
week before -rc2, what do you think?

This is for the first version of the PMD features.
Then there are reviews and new iterations.
I think one week is too short.
What do you think of 10 days?

Agree that a week is short, I just thought that it is happening in practice, but
if you don't mind lets keep your original proposal (-rc1 deadline for first
version of driver patches) with the option to update it later if we have
difficulties to keep it.

quoted

quoted

+* Any issue found in -rc1 should be fixed.
+
+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.

As mentioned before, my concern is this may create false impression that bugs
are fixed only in this phase. What about remove this line completely and update
below -rc4 one as 'Critical bug fixes only.'? I think that makes intention more
clear.

I had added in -rc2: "Any issue found in -rc1 should be fixed."
Do you want to remove it as well?

I think we can keep it, good to highlight one of the major tasks for -rc2 is to
fix defects found in -rc1, and it doesn't limit fixes to ones found in -rc1.

quoted

quoted

+
+rc4
+~~~
+
+* Documentation updates.
+* Critical bug fixes.