18/05/2021 13:57, Ferruh Yigit: > On 3/28/2021 8:00 PM, Thomas Monjalon wrote: > > From: Asaf Penso <as...@nvidia.com> > > > > Adding more information about the release milestones. > > This includes the scope of change, expectations, etc. [...] > > +rc1 > > +~~~ > > + > > +* Priority: new or updated API. > > Can we just say API or libraries?
Yes > Overall what is the intention for the 'priority' information? Should we really > split release candidates for libraries, driver and applications? > We merge all as much as possible before -rc1. The idea is to simply reflect the priority in case time is limited. But yes we always merge as much as possible. > Can we say this other-way around, API/library features can't be merged after > -rc1. Correct > And similarly driver features shouldn't be merged after -rc2, application > changes shouldn't merge after -rc3. > Fixes can be merged anytime before -rc4. After -rc4 only critical fixes and > documentation changes. > > Just I want to highlight that for example we merge documentation updates > anytime, it doesn't have to wait -rc4, but below listing looks like different > part only allocated for different -rc, which is wrong as far as I know. I understand the confusion and will try to make it clearer in next revision. > > +* New API should be defined and implemented in libraries. > > +* The API should include Doxygen documentation > > s/should/must OK > > + 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 can be a draft but must be sent as a separate series. > > I am not sure if "must be sent as a separate series" needs to be highlighted, > having all in the same series has a benefit to see bigger picture. If the > driver > patches acked/reviewed by its maintainers, I think it can be merged in single > series. That's not the same kind of review for driver and API, not the same time constraint, and not the same iterations. I think it is more practical to suggest separate, but it should not be "must". > > +* The above should be sent to the mailing list at least 2 weeks before > > -rc1. > > +* Nice to have: example code (``/examples``) > > + > > +rc2 > > +~~~ > > + > > +* Priority: drivers. > > +* New features should be implemented in drivers. > > I already mentioned above, but this can cause misunderstanding. We want all > driver implementation to be ready for proposal deadline, same as other > patches. > But because of its reduced scope (they don't affect all project but only > specific vendor), we are flexible to get driver features for -rc2 and -rc3 > too. -rc3 really? It should be exceptional so not mentioned here. > Please check number of driver patches merged for a release, it is impossible > to > manage them within period between -rc1 & -rc2. > Also some driver features are complex and big, they should be sent before > proposal deadline so that they can be reviewed for the release. Yes sooner is better. The doc is about deadline + priorities, showing the no-go limits, without warranty of merge if all good. Is there a contradiction? > > +* A driver change should include documentation > > s/should/must Sometimes there is no doc to change. Is "must" confusing? > > + 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. > > + > > +rc3 > > +~~~ > > + > > +* Priority: applications. > > +* New functionality that does not depend on libraries update > > + can be integrated as part of -rc3. > > Again for same issue, let me share my understanding, > the -rc1 has been tested widely, after that each -rc gets less and less tests. > So the -rc1 should have API/library changes, so that they will be tested more > and will have more time to fix any issues, since library changes has biggest > impact for the project. > > Next biggest impact is drivers. > > Applications and unit tests are internal to DPDK, they have no user impact, > that > is why we can get more risk with them and they can be merged even as late as > rc3. > > And documentation doesn't have anything related to testing, or they don't > introduce any risk for specific release, so they are merged until last stage > of > the release. Yes > > +* The application should include documentation in the relevant .rst files > > + (application-specific and release notes if significant). > > s/should/must > > > +* It may be the last opportunity for miscellaneous changes. > > This is very vague, what does misch changes mean? Scripts, code cleanup, yes it is vague, we can remove. > > +* Libraries and drivers cleanup are allowed. > > +* Small driver reworks. > > +* Critical and minor bug fixes. > > + > > +rc4 > > +~~~ > > + > > +* Documentation updates. > > +* Critical bug fixes.
