| Message ID | 20210113091213.4118267-1-thomas@monjalon.net (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Thomas Monjalon |
| Headers | show |
| Series | [v3,1/1] doc: add release milestones definition | expand |
| Context | Check | Description |
|---|---|---|
| ci/intel-Testing | success | Testing PASS |
| ci/Intel-compilation | success | Compilation OK |
| ci/checkpatch | success | coding style OK |
> -----Original Message----- > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon > Sent: Wednesday, January 13, 2021 9:12 AM > To: dev@dpdk.org > Cc: david.marchand@redhat.com; Yigit, Ferruh <ferruh.yigit@intel.com>; Asaf > Penso <asafp@nvidia.com> > Subject: [dpdk-dev] [PATCH v3 1/1] doc: add release milestones definition > > From: Asaf Penso <asafp@nvidia.com> > > Adding more information about the release milestones. > This includes the scope of change, expectations, etc. First off, thanks for putting this together, it is a good initiative to document the processes we follow. Some minor corrections/suggestions below. > +Milestones definition > +--------------------- > + > +Each DPDK release has milestones that help everyone to converge to the > release date. > +The following is a list of these milestones together with concrete > +definitions and expectations. > + > +Roadmap > +~~~~~~~ > + > +* Content: new features in libs, drivers, apps, and examples. > +* Timeframe: to be published until the first day of the release cycle. s/until/before > +rc2 > +~~~ > + > +* Content: drivers. > +* New features should be implemented in drivers. > +* A driver change should include documentation > + in the relevant .rst files (driver, release notes). > +* Code and related documentation must be updated atomically in the same > patch. > +* At least 2 weeks before -rc2 the above should be sent to the ML for > review. Maybe slightly better as: * The above should be sent to the mailing list at least 2 weeks before -rc2. > +rc3 > +~~~ > + > +* Content: test apps. > +* New functionality that does not depend on libs update > + can be integrated as part of -rc3. > +* The app should include documentation in the relevant .rst files > + (app, release notes if significant). > +* Code and related documentation must be updated atomically in the same > patch. > +* Last opportunity for miscellaneous changes. > +* Libs and drivers cleanup. > +* Small driver reworks. > +* Big bug fixes. Maybe instead of "Big bug fixes" we could use "Critical and minor bug fixes only" > +rc4 > +~~~ > + > +* Documentation updates. > +* Critical bug fixes. Acked-by: John McNamara <john.mcnamara@intel.com>
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst index 4e9140bca4..87c1c6f8f6 100644 --- a/doc/guides/contributing/patches.rst +++ b/doc/guides/contributing/patches.rst @@ -657,3 +657,75 @@ patch accepted. The general cycle for patch review and acceptance is: than rework of the original. * Trivial patches may be merged sooner than described above at the tree committer's discretion. + + +Milestones definition +--------------------- + +Each DPDK release has milestones that help everyone to converge to the release date. +The following is a list of these milestones +together with concrete definitions and expectations. + +Roadmap +~~~~~~~ + +* Content: new features in libs, drivers, apps, and examples. +* Timeframe: to be published until the first day of the release cycle. + +RFC +~~~ + +* Content: public design review for the feature, explaining the need, and the design. +* Should include the API changes, in libs and apps. +* RFC is not mandatory but strongly advised to start early discussion. +* Nice to have: driver implementation (full or draft), example code, and documentation. + +Proposal Deadline +~~~~~~~~~~~~~~~~~ + +* Content: either an RFC as stated above or a v1 patch. +* Nice to have: code complete for libs. + +rc1 +~~~ + +* Content: new or updated API. +* New API should be defined and implemented in libraries. +* The API should include Doxygen documentation + and be part of the relevant .rst files (lib, release notes). +* Code and related documentation must be updated atomically in the same patch. +* API should be used in a test application (/apps). +* At least one PMD should implement the API. + It can be a draft but must be sent as a separate series. +* At least 2 weeks before -rc1 the above should be sent to the ML for review. +* Nice to have: example code (/examples) + +rc2 +~~~ + +* Content: drivers. +* New features should be implemented in drivers. +* A driver change should include documentation + in the relevant .rst files (driver, release notes). +* Code and related documentation must be updated atomically in the same patch. +* At least 2 weeks before -rc2 the above should be sent to the ML for review. + +rc3 +~~~ + +* Content: test apps. +* New functionality that does not depend on libs update + can be integrated as part of -rc3. +* The app should include documentation in the relevant .rst files + (app, release notes if significant). +* Code and related documentation must be updated atomically in the same patch. +* Last opportunity for miscellaneous changes. +* Libs and drivers cleanup. +* Small driver reworks. +* Big bug fixes. + +rc4 +~~~ + +* Documentation updates. +* Critical bug fixes.