[dpdk-dev] [PATCH v8] doc: add release milestones definition
Thomas Monjalon
thomas at monjalon.net
Fri Sep 3 13:50:50 CEST 2021
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.
More information about the dev
mailing list