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

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 9/3/2021 12:50 PM, Thomas Monjalon wrote:
> 02/09/2021 18:33, Ferruh Yigit:
>> On 8/26/2021 11:11 AM, Thomas Monjalon wrote:
>>> +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.

>> 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 ...'

>> 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.

>>> +* 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.

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