diff options
Diffstat (limited to 'doc/guides/contributing')
| -rw-r--r-- | doc/guides/contributing/documentation.rst | 1 | ||||
| -rw-r--r-- | doc/guides/contributing/patches.rst | 5 | ||||
| -rw-r--r-- | doc/guides/contributing/versioning.rst | 9 |
3 files changed, 13 insertions, 2 deletions
diff --git a/doc/guides/contributing/documentation.rst b/doc/guides/contributing/documentation.rst index cddbd7bb..170dacdb 100644 --- a/doc/guides/contributing/documentation.rst +++ b/doc/guides/contributing/documentation.rst @@ -34,7 +34,6 @@ The main directories that contain files related to documentation are shown below |-- testpmd_app_ug |-- rel_notes |-- nics - |-- xen |-- ... diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst index 27e218b2..40983c15 100644 --- a/doc/guides/contributing/patches.rst +++ b/doc/guides/contributing/patches.rst @@ -367,7 +367,6 @@ The builds can be modified via the following environmental variables: * ``DPDK_BUILD_TEST_CONFIGS`` (target1+option1+option2 target2) * ``DPDK_DEP_CFLAGS`` * ``DPDK_DEP_LDFLAGS`` -* ``DPDK_DEP_MOFED`` (y/[n]) * ``DPDK_DEP_PCAP`` (y/[n]) * ``DPDK_NOTIFY`` (notify-send) @@ -404,6 +403,10 @@ The appropriate maintainer can be found in the ``MAINTAINERS`` file:: git send-email --to maintainer@some.org --cc dev@dpdk.org 000*.patch +Script ``get-maintainer.sh`` can be used to select maintainers automatically:: + + git send-email --to-cmd ./devtools/get-maintainer.sh --cc dev@dpdk.org 000*.patch + New additions can be sent without a maintainer:: git send-email --to dev@dpdk.org 000*.patch diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst index 8aaf370d..8d0fdb77 100644 --- a/doc/guides/contributing/versioning.rst +++ b/doc/guides/contributing/versioning.rst @@ -18,6 +18,8 @@ General Guidelines #. The modification of symbols can generally be managed with versioning #. The removal of symbols generally is an ABI break and requires bumping of the LIBABIVER macro +#. Updates to the minimum hardware requirements, which drop support for hardware which + was previously supported, should be treated as an ABI change. What is an ABI -------------- @@ -77,6 +79,13 @@ for significant reasons, such as performance enhancements. ABI breakage due to changes such as reorganizing public structure fields for aesthetic or readability purposes should be avoided. +.. note:: + + Updates to the minimum hardware requirements, which drop support for hardware + which was previously supported, should be treated as an ABI change, and + follow the relevant deprecation policy procedures as above: 3 acks and + announcement at least one release in advance. + Examples of Deprecation Notices ------------------------------- |