Re: [dpdk-dev] RFC: DPDK Long Term Support

[Thomas Monjalon <thomas.monjalon@6wind.com>]

Hi,

2016-06-03 15:07, Mcnamara, John:
> Introduction
> ------------
> 
> This document sets out a proposal for a DPDK Long Term Support release (LTS).

In general, LTS refer to a longer maintenance than than regular one.
Here we are talking to doing some maintenance as stable releases first.
Currently we have no maintenance at all.
So I suggest to differentiate "stable branches" and "LTS" for some stable branches.

> 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.
[...]
> The proposed maintainer for the LTS is Yuanhan Liu
> <yuanhan.liu@linux.intel.com>.

I wonder if Yuanhan is OK to maintain every stable releases which could be
requested/needed? Or should we have other committers for the stable releases
that Yuanhan would not want to maintain himself?
The Linux model is to let people declare themselves when they want to maintain
a stable branch.

> The proposed duration of the LTS support is 2 years.

I think we should discuss the support duration for each release separately.

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

Seems a bit too restrictive.
Currently, there is no maintenance at all because nobody was volunteer.
If Yuanhan is volunteer for a stable branch every 2 years, fine.
If someone else is volunteer for other branches, why not let him do it?

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

Let's do a first run with 16.07 and see later what we want to do next.
How long time a stable branch must be announced before its initial release?

> What changes should be backported
> ---------------------------------
> 
> * Bug fixes that don't break the ABI.

And API?
And behaviour (if not clearly documented in the API)?

[...]
> Developers submitting fixes to the mainline should also CC the maintainer so
> that they can evaluate the patch. A <stable@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.

Why?
We must avoid putting too much restrictions on the contributors.

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

Thanks
It must not be just a tag. There should be an announce and a tarball ready
to download.

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

I'm sure there will be more validation on the field or from contributors.

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

Yes seems very reasonnable.
Thanks