[dpdk-dev] RFC: DPDK Long Term Support

Mcnamara, John john.mcnamara at intel.com
Fri Jun 3 17:07:49 CEST 2016


This document sets out a proposal for a DPDK Long Term Support release (LTS).

The purpose of the DPDK LTS will be to maintain a stable release of DPDK with
backported bug fixes over an extended period of time. This will provide
downstream consumers of DPDK with a stable target on which to base
applications or packages.

As with previous DPDK guidelines this proposal is open for discussion within
the community. The consensus view will be included in the DPDK documentation
as a guideline.

LTS Maintainer

The proposed maintainer for the LTS is Yuanhan Liu
<yuanhan.liu at linux.intel.com>.

LTS Duration

The proposed duration of the LTS support is 2 years.

There will only be one LTS branch being maintained at any time. At the end of
the 2 year cycle the maintenance on the previous LTS will be wound down.

LTS Version

The proposed initial LTS version will be DPDK 16.07. The next versions, based
on a 2 year cycle, will be DPDK 18.08, 20.08, etc.

What changes should be backported

* Bug fixes that don't break the ABI.

What changes should not be backported

* API or ABI breaking changes.

* Features should not be backported. Unless:

   * There is a justifiable use case (for example a new PMD).
   * The change is non-invasive.
   * The work of preparing the backport is done by the proposer.
   * There is support within the community.

Role of the maintainer

* The maintainer will evaluate fixes to the DPDK master submitted by the
  fixing developer and apply them to the LTS branch/tree.

* The maintainer will evaluate backported patches from downstream consumers
  and apply them to the LTS branch/tree.

* The maintainer will not backport non-trivial fixes without assistance from
  the downstream consumers or requester.

Role of the downstream consumers

Developers submitting fixes to the mainline should also CC the maintainer so
that they can evaluate the patch. A <stable at dpdk.org> email address could be
provided for this so that it can be included as a CC in the commit messages
and documented in the Code Contribution Guidelines.

The downstream consumers (OSVs and DPDK dependent application and framework
developers) should identify issues in the field that have been fixed in the
mainline release and report them to the maintainer. They should, ideally,
assist with backporting any required fixes.


Intel will provide validation engineers to test the LTS branch/tree. Tested
releases can be marked using a Git tag with an incremented revision number. For
example: 16.07.00_LTS -> 16.07.01_LTS. The testing cadence should be quarterly
but will be best effort only and dependent on available resources.

Validated OSes

In order to reduce the testing effort the number of OSes which will be
officially validated should be as small as possible. The proposal is that the
following long term OSes are used for validation:

(OSV reps please confirm.)

* Ubuntu 16.04 LTS
* RHEL 7.3
* SuSE 11 SP4 or 12
* FreeBSD 10.3

Fixes for newer OSes, kernels (and associated KNI fixes), and newer GCC/Clang
versions can be backported but the validation effort will be limited to the
above platforms.

Release Notes

The LTS release notes should be updated to include a section with backported
fixes. Patches for backporting should include additions to the release notes
like patches to the mainline branch.

LTS Review

The LTS guidelines shall be reviewed after 1 year to adjust for any experiences
from LTS maintainership.

More information about the dev mailing list