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