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

[Thomas Monjalon <thomas@monjalon.net>]

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?

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

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

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

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