[dpdk-dev] RFC: DPDK Long Term Support

[dpdk-dev] RFC: DPDK Long Term Support

[Mcnamara, John]

Introduction
------------

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


Testing
-------

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.

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

[Thomas Monjalon]

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

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

[Yuanhan Liu]

On Fri, Jun 03, 2016 at 06:05:15PM +0200, Thomas Monjalon wrote:
> 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?

I'm Okay, since I assume the maintain effort would be small: mainly
for picking acked and tested *bug fix* patches.

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

I have no object though, if somebody volunteer him as a stable branch
maintainer.

> 
> > 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)?

Agreed, we should not include those changes, either.

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

This is actually requested by me, in a behaviour similar to Linux
kernel community takes. Here is the thing, the developer normally
knows better than a generic maintainer (assume it's me) that a patch
applies to stable branch or not. This is especially true for DPDK,
since we ask the developer to note down the bug commit by adding a
fix line.

It wouldn't be a burden for an active contributor, as CCing to related
people (including right mailing list) is a good habit they already
have.  For some one-time contributors, it's okay that they don't know
and follow it.

In such case, I guess we need the help from the related subsystem
maintainer: if it's a good bug fix that applies to stable branch,
and the contributor forgot to make a explicit cc to stable mailing
list, the subsystem maintainer should forward or ask him to forward
to stable mailing list.

The reason I'm asking is that as a generic maintainer, there is
simply no such energy to keep an eye on all patches: you have to
be aware of that we have thoughts of email per month from dpdk dev
mailing list: the number of last month is 1808.

Doing so would allow one person maintain several stable tree
be possible.

For more info, you could check linux/Documentation/stable_kernel_rules.txt.

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

Agreed.

	--yliu

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

[Thomas Monjalon]

2016-06-06 19:49, Yuanhan Liu:
> On Fri, Jun 03, 2016 at 06:05:15PM +0200, Thomas Monjalon wrote:
> > 2016-06-03 15:07, Mcnamara, John:
> > > 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.
> 
> This is actually requested by me, in a behaviour similar to Linux
> kernel community takes. Here is the thing, the developer normally
> knows better than a generic maintainer (assume it's me) that a patch
> applies to stable branch or not. This is especially true for DPDK,
> since we ask the developer to note down the bug commit by adding a
> fix line.
> 
> It wouldn't be a burden for an active contributor, as CCing to related
> people (including right mailing list) is a good habit they already
> have.  For some one-time contributors, it's okay that they don't know
> and follow it.
> 
> In such case, I guess we need the help from the related subsystem
> maintainer: if it's a good bug fix that applies to stable branch,
> and the contributor forgot to make a explicit cc to stable mailing
> list, the subsystem maintainer should forward or ask him to forward
> to stable mailing list.
> 
> The reason I'm asking is that as a generic maintainer, there is
> simply no such energy to keep an eye on all patches: you have to
> be aware of that we have thoughts of email per month from dpdk dev
> mailing list: the number of last month is 1808.
> 
> Doing so would allow one person maintain several stable tree
> be possible.
> 
> For more info, you could check linux/Documentation/stable_kernel_rules.txt.

Makes sense to CC stable@dpdk.org list (must be created).

Why put a CC tag in the commit? For automatic processing?
Maybe it is too early to run before walking ;)

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

[Yuanhan Liu]

On Mon, Jun 06, 2016 at 03:31:09PM +0200, Thomas Monjalon wrote:
> 2016-06-06 19:49, Yuanhan Liu:
> > On Fri, Jun 03, 2016 at 06:05:15PM +0200, Thomas Monjalon wrote:
> > > 2016-06-03 15:07, Mcnamara, John:
> > > > 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.
> > 
> > This is actually requested by me, in a behaviour similar to Linux
> > kernel community takes. Here is the thing, the developer normally
> > knows better than a generic maintainer (assume it's me) that a patch
> > applies to stable branch or not. This is especially true for DPDK,
> > since we ask the developer to note down the bug commit by adding a
> > fix line.
> > 
> > It wouldn't be a burden for an active contributor, as CCing to related
> > people (including right mailing list) is a good habit they already
> > have.  For some one-time contributors, it's okay that they don't know
> > and follow it.
> > 
> > In such case, I guess we need the help from the related subsystem
> > maintainer: if it's a good bug fix that applies to stable branch,
> > and the contributor forgot to make a explicit cc to stable mailing
> > list, the subsystem maintainer should forward or ask him to forward
> > to stable mailing list.
> > 
> > The reason I'm asking is that as a generic maintainer, there is
> > simply no such energy to keep an eye on all patches: you have to
> > be aware of that we have thoughts of email per month from dpdk dev
> > mailing list: the number of last month is 1808.
> > 
> > Doing so would allow one person maintain several stable tree
> > be possible.
> > 
> > For more info, you could check linux/Documentation/stable_kernel_rules.txt.
> 
> Makes sense to CC stable@dpdk.org list (must be created).
> 
> Why put a CC tag in the commit? For automatic processing?
> Maybe it is too early to run before walking ;)

It's a tip/trick used a lot in kernel community. Assume you have made
a patchset, that just one of them fixes a bug that you hope this patch
could also be cc'ed to the original author that introduces the bug.
You could achieve that by adding him to the cc list from cli. However,
in such way, all patches are cc'ed to him. The alternative is to add
a line "Cc: some.one <some@one.com>" in the commit log so that he will
get that patch only.

If you look at a small micro optimization patchset I sent out last
month [0], you will find that I used this trick for the 1st patch,
as it touches the core part of virtio-net vring operation, that I
hope I can get some comments from the virtio guru/maintainer, Michael.
Therefore, he is cc'ed. However, for the 2 other patches in the same
set, it's basically DPDK vhost-user stuff, so that I didn't cc him
to not bother him.

This rule, of course, also applies to the stable branch (for bug
fixing patches in a set). It doesn't matter which way you take if
it's just a patch set of one bug fixing patch though.

[0]: http://dpdk.org/ml/archives/dev/2016-May/038246.html

	--yliu

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

[Thomas Monjalon]

2016-06-06 22:14, Yuanhan Liu:
> On Mon, Jun 06, 2016 at 03:31:09PM +0200, Thomas Monjalon wrote:
> > 2016-06-06 19:49, Yuanhan Liu:
> > > On Fri, Jun 03, 2016 at 06:05:15PM +0200, Thomas Monjalon wrote:
> > > > 2016-06-03 15:07, Mcnamara, John:
> > > > > 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 put a CC tag in the commit? For automatic processing?
> > Maybe it is too early to run before walking ;)
> 
> It's a tip/trick used a lot in kernel community. Assume you have made
> a patchset, that just one of them fixes a bug that you hope this patch
> could also be cc'ed to the original author that introduces the bug.
> You could achieve that by adding him to the cc list from cli. However,
> in such way, all patches are cc'ed to him. The alternative is to add
> a line "Cc: some.one <some@one.com>" in the commit log so that he will
> get that patch only.
> 
> If you look at a small micro optimization patchset I sent out last
> month [0], you will find that I used this trick for the 1st patch,
> as it touches the core part of virtio-net vring operation, that I
> hope I can get some comments from the virtio guru/maintainer, Michael.
> Therefore, he is cc'ed. However, for the 2 other patches in the same
> set, it's basically DPDK vhost-user stuff, so that I didn't cc him
> to not bother him.
> 
> This rule, of course, also applies to the stable branch (for bug
> fixing patches in a set). It doesn't matter which way you take if
> it's just a patch set of one bug fixing patch though.
> 
> [0]: http://dpdk.org/ml/archives/dev/2016-May/038246.html

OK

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

[Mcnamara, John]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, June 3, 2016 5:05 PM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev@dpdk.org; Christian Ehrhardt <christian.ehrhardt@canonical.com>;
> Markos Chandras <mchandras@suse.de>; Panu Matilainen <pmatilai@redhat.com>
> Subject: Re: [dpdk-dev] RFC: DPDK Long Term Support
> 
> 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.

Hi Thomas,

I have no argument against this. It would be great to have a series of stable
branches of which some are LTS.

But at a minimum we are committing to have a least one maintained stable branch 
that will also be a LTS.

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


I think it is fine to have other committers.


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

I see no problem with that. This proposal just reflects that fact that we
have only had one volunteer to date and is based on what could be reasonably
done by one person (plus the validation support). If more maintainers come 
forward we can have more/more frequent stable branches.

We will, however, be constrained by the validation effort that can be offered, 
unless there are other validation volunteers.


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

Ok. The statement at the end about reviewing at the end of the first year
is meant to cover adjustments like this. I think that we will have to see
how things work out in practice and adjust as we go.



> > What changes should be backported
> > ---------------------------------
> >
> > * Bug fixes that don't break the ABI.
> 
> And API?
> And behaviour (if not clearly documented in the API)?


Yes. It should say ABI and API. Undocumented but implied or existing
bahaviour should also be maintained.


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

Hopefully. :-)

John.
-- 

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

[Matthew Hall]

On Fri, Jun 03, 2016 at 03:07:49PM +0000, Mcnamara, John wrote:
> What changes should be backported
> ---------------------------------
> 
> * Bug fixes that don't break the ABI.
> 
> 
> What changes should not be backported
> -------------------------------------
> 
> * API or ABI breaking changes.

I think this part needs some adjusting.

It seems like there should be allowance for bug fixes where the original does 
break ABI but it is possible to make a version that doesn't.

A lot of DPDK bug fixes I see would fall into this category and it isn't 
discussed.

Matthew.

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

[Mcnamara, John]

> -----Original Message-----
> From: Matthew Hall [mailto:mhall@mhcomputing.net]
> Sent: Friday, June 3, 2016 7:17 PM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev <dev@dpdk.org>; Christian Ehrhardt
> <christian.ehrhardt@canonical.com>; Markos Chandras <mchandras@suse.de>;
> Panu Matilainen <pmatilai@redhat.com>
> Subject: Re: [dpdk-dev] RFC: DPDK Long Term Support
> 
> >
> > What changes should not be backported
> > -------------------------------------
> >
> > * API or ABI breaking changes.
> 
> I think this part needs some adjusting.
> 
> It seems like there should be allowance for bug fixes where the original
> does break ABI but it is possible to make a version that doesn't.
> 
> A lot of DPDK bug fixes I see would fall into this category and it isn't
> discussed.

Hi Matthew,

Agreed, we should allow fix to be backported even if the patch itself cannot be, for ABI reasons.

John

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

[Neil Horman]

On Fri, Jun 03, 2016 at 03:07:49PM +0000, Mcnamara, John wrote:
> Introduction
> ------------
> 
> 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@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@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.
> 
> 
> Testing
> -------
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
I'm not opposed to an LTS release, but it seems to be re-solving the issue of
ABI breakage.  That is to say, there is alreay a process in place for managing
ABI changes to the DPDK, which is designed to help ensure that:

1) ABI changes are signaled at least 2 releases early
2) ABI changes whenever possible are designed such that backward compatibility
versions can be encoded at the same time with versioning tags

Those two mechanism are expressly intended to allow application upgrades of DPDK
libraries without worrying about ABI breakage.  While LTS releases are a fine
approach for  some things, they sacrifice upstream efficiency (by creating work
for backporting teams), while allowing upstream developers more leverage to just
create ABI breaking changes on a whim, ignoring the existing ABI compatibility
mechanism

LTS is a fine process for projects in which API/ABI breakage is either uncommon
or fairly isolated, but that in my mind doesn't really describe DPDK.

Neil

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

[Thomas Monjalon]

2016-06-05 14:15, Neil Horman:
> On Fri, Jun 03, 2016 at 03:07:49PM +0000, Mcnamara, John wrote:
> > Introduction
> > ------------
> > 
> > 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.
[...]
> I'm not opposed to an LTS release, but it seems to be re-solving the issue of
> ABI breakage.  That is to say, there is alreay a process in place for managing
> ABI changes to the DPDK, which is designed to help ensure that:
> 
> 1) ABI changes are signaled at least 2 releases early
> 2) ABI changes whenever possible are designed such that backward compatibility
> versions can be encoded at the same time with versioning tags

Sorry I don't understand your point.
We are talking about two different things:
1/ ABI care for each new major release
2/ Minor release for bug fixes

I think both may exist.

> Those two mechanism are expressly intended to allow application upgrades of DPDK
> libraries without worrying about ABI breakage.  While LTS releases are a fine
> approach for  some things, they sacrifice upstream efficiency (by creating work
> for backporting teams), while allowing upstream developers more leverage to just
> create ABI breaking changes on a whim, ignoring the existing ABI compatibility
> mechanism

No it was not stated that upstream developers should ignore ABI compatibility.
Do you mean having a stable branch means ABI preservation for the next major
release is less important?

> LTS is a fine process for projects in which API/ABI breakage is either uncommon
> or fairly isolated, but that in my mind doesn't really describe DPDK.

Yes API/ABI breakages are still common in DPDK.
So it's even more important to have some stable branches.

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

[Neil Horman]

On Mon, Jun 06, 2016 at 11:27:29AM +0200, Thomas Monjalon wrote:
> 2016-06-05 14:15, Neil Horman:
> > On Fri, Jun 03, 2016 at 03:07:49PM +0000, Mcnamara, John wrote:
> > > Introduction
> > > ------------
> > > 
> > > 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.
> [...]
> > I'm not opposed to an LTS release, but it seems to be re-solving the issue of
> > ABI breakage.  That is to say, there is alreay a process in place for managing
> > ABI changes to the DPDK, which is designed to help ensure that:
> > 
> > 1) ABI changes are signaled at least 2 releases early
> > 2) ABI changes whenever possible are designed such that backward compatibility
> > versions can be encoded at the same time with versioning tags
> 
> Sorry I don't understand your point.
> We are talking about two different things:
> 1/ ABI care for each new major release
> 2/ Minor release for bug fixes
> 
> I think both may exist.
> 
Sure, they can exist together (they being both an ABI backwards compatible HEAD
and a set of LTS releases).  The point I'm trying to make is that if you do your
ABI compatible HEAD well enough, you don't really need an LTS release.

Thats not to say that you can't do both, but an LTS release is a significant
workload item, especially given the rapid pace of change in HEAD.  The longer
you maintain an LTS release, the more difficult "minor" bugfixes are to
integrate, especially if you wind up skipping any ABI breaking patches.  I think
its worth calling attention to that as this approach gets considered.

> > Those two mechanism are expressly intended to allow application upgrades of DPDK
> > libraries without worrying about ABI breakage.  While LTS releases are a fine
> > approach for  some things, they sacrifice upstream efficiency (by creating work
> > for backporting teams), while allowing upstream developers more leverage to just
> > create ABI breaking changes on a whim, ignoring the existing ABI compatibility
> > mechanism
> 
> No it was not stated that upstream developers should ignore ABI compatibility.
> Do you mean having a stable branch means ABI preservation for the next major
> release is less important?
> 
I never stated that developers should ignore ABI compatibility, I stated that
creating an LTS release will make it that much easier for developers to do so.

And I think, pragmatically speaking, that is a concern.  Given that the
existance of an LTS release will make it tempting for developers to simply
follow the deprecation process rather than try to create ABI backward compatible
paths.

Looking at the git history, it seems clear to me that this is already happening.
I'm able to find a multitude of instances in which the deprecation process has
been followed reasonably well, but I can find no instances in which any efforts
have been made for backward compatibility.

> > LTS is a fine process for projects in which API/ABI breakage is either uncommon
> > or fairly isolated, but that in my mind doesn't really describe DPDK.
> 
> Yes API/ABI breakages are still common in DPDK.
> So it's even more important to have some stable branches.

We seem to be comming to different conclusions based on the same evidence. We
agree that API/ABI changes continue to be frequent ocurances, but my position is
that we already have a process in place to mitigate that, which is simply not
being used (i.e. versioning symbols to provide backward compatible paths),
whereas you seem to be asserting that an LTS model will allow for ABI stabiilty
and bug fixes.

While I don't disagree with that statement (LTS does provide both of those
things if the maintainer does it properly), I'm forced to ask the question,
before we solve this problem in a new way, lets ask why the existing way isn't
being used.  Do developers just not care about backwards compatibility?  Is the
process to hard?  Something else?  I really don't like the idea of abandoning
what currently exists to replace it with something else, without first
addressing why what we have isn't working.

Neil

> 

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

[Thomas Monjalon]

2016-06-06 09:47, Neil Horman:
> On Mon, Jun 06, 2016 at 11:27:29AM +0200, Thomas Monjalon wrote:
> > 2016-06-05 14:15, Neil Horman:
> > > On Fri, Jun 03, 2016 at 03:07:49PM +0000, Mcnamara, John wrote:
> > > > Introduction
> > > > ------------
> > > > 
> > > > 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.
> > [...]
> > > I'm not opposed to an LTS release, but it seems to be re-solving the issue of
> > > ABI breakage.  That is to say, there is alreay a process in place for managing
> > > ABI changes to the DPDK, which is designed to help ensure that:
> > > 
> > > 1) ABI changes are signaled at least 2 releases early
> > > 2) ABI changes whenever possible are designed such that backward compatibility
> > > versions can be encoded at the same time with versioning tags
> > 
> > Sorry I don't understand your point.
> > We are talking about two different things:
> > 1/ ABI care for each new major release
> > 2/ Minor release for bug fixes
> > 
> > I think both may exist.
> > 
> Sure, they can exist together (they being both an ABI backwards compatible HEAD
> and a set of LTS releases).  The point I'm trying to make is that if you do your
> ABI compatible HEAD well enough, you don't really need an LTS release.
> 
> Thats not to say that you can't do both, but an LTS release is a significant
> workload item, especially given the rapid pace of change in HEAD.  The longer
> you maintain an LTS release, the more difficult "minor" bugfixes are to
> integrate, especially if you wind up skipping any ABI breaking patches.  I think
> its worth calling attention to that as this approach gets considered.
> 
> > > Those two mechanism are expressly intended to allow application upgrades of DPDK
> > > libraries without worrying about ABI breakage.  While LTS releases are a fine
> > > approach for  some things, they sacrifice upstream efficiency (by creating work
> > > for backporting teams), while allowing upstream developers more leverage to just
> > > create ABI breaking changes on a whim, ignoring the existing ABI compatibility
> > > mechanism
> > 
> > No it was not stated that upstream developers should ignore ABI compatibility.
> > Do you mean having a stable branch means ABI preservation for the next major
> > release is less important?
> > 
> I never stated that developers should ignore ABI compatibility, I stated that
> creating an LTS release will make it that much easier for developers to do so.
> 
> And I think, pragmatically speaking, that is a concern.  Given that the
> existance of an LTS release will make it tempting for developers to simply
> follow the deprecation process rather than try to create ABI backward compatible
> paths.
> 
> Looking at the git history, it seems clear to me that this is already happening.
> I'm able to find a multitude of instances in which the deprecation process has
> been followed reasonably well, but I can find no instances in which any efforts
> have been made for backward compatibility.

There were some examples of backward compatibility in hash and lpm libraries.

> > > LTS is a fine process for projects in which API/ABI breakage is either uncommon
> > > or fairly isolated, but that in my mind doesn't really describe DPDK.
> > 
> > Yes API/ABI breakages are still common in DPDK.
> > So it's even more important to have some stable branches.
> 
> We seem to be comming to different conclusions based on the same evidence. We
> agree that API/ABI changes continue to be frequent ocurances, but my position is
> that we already have a process in place to mitigate that, which is simply not
> being used (i.e. versioning symbols to provide backward compatible paths),
> whereas you seem to be asserting that an LTS model will allow for ABI stabiilty
> and bug fixes.
> 
> While I don't disagree with that statement (LTS does provide both of those
> things if the maintainer does it properly), I'm forced to ask the question,
> before we solve this problem in a new way, 

The following questions are interesting but please don't assume the stable
branch address the same issue as ABI compat.
In each major release, we add some new bugs because of new features, even
if the ABI is kept.
In a minor stable release there are only some bug fixes. So the only way
to have a "bug free" version in a stable environment, is to do some
maintenance in a stable branch.

> lets ask why the existing way isn't
> being used.  Do developers just not care about backwards compatibility?  Is the
> process to hard?  Something else?  I really don't like the idea of abandoning
> what currently exists to replace it with something else, without first
> addressing why what we have isn't working.

We can address both. But I strongly think the ABI compat is another topic.

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

[Neil Horman]

On Mon, Jun 06, 2016 at 04:21:11PM +0200, Thomas Monjalon wrote:
> 2016-06-06 09:47, Neil Horman:
> > On Mon, Jun 06, 2016 at 11:27:29AM +0200, Thomas Monjalon wrote:
> > > 2016-06-05 14:15, Neil Horman:
> > > > On Fri, Jun 03, 2016 at 03:07:49PM +0000, Mcnamara, John wrote:
> > > > > Introduction
> > > > > ------------
> > > > > 
> > > > > 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.
> > > [...]
> > > > I'm not opposed to an LTS release, but it seems to be re-solving the issue of
> > > > ABI breakage.  That is to say, there is alreay a process in place for managing
> > > > ABI changes to the DPDK, which is designed to help ensure that:
> > > > 
> > > > 1) ABI changes are signaled at least 2 releases early
> > > > 2) ABI changes whenever possible are designed such that backward compatibility
> > > > versions can be encoded at the same time with versioning tags
> > > 
> > > Sorry I don't understand your point.
> > > We are talking about two different things:
> > > 1/ ABI care for each new major release
> > > 2/ Minor release for bug fixes
> > > 
> > > I think both may exist.
> > > 
> > Sure, they can exist together (they being both an ABI backwards compatible HEAD
> > and a set of LTS releases).  The point I'm trying to make is that if you do your
> > ABI compatible HEAD well enough, you don't really need an LTS release.
> > 
> > Thats not to say that you can't do both, but an LTS release is a significant
> > workload item, especially given the rapid pace of change in HEAD.  The longer
> > you maintain an LTS release, the more difficult "minor" bugfixes are to
> > integrate, especially if you wind up skipping any ABI breaking patches.  I think
> > its worth calling attention to that as this approach gets considered.
> > 
> > > > Those two mechanism are expressly intended to allow application upgrades of DPDK
> > > > libraries without worrying about ABI breakage.  While LTS releases are a fine
> > > > approach for  some things, they sacrifice upstream efficiency (by creating work
> > > > for backporting teams), while allowing upstream developers more leverage to just
> > > > create ABI breaking changes on a whim, ignoring the existing ABI compatibility
> > > > mechanism
> > > 
> > > No it was not stated that upstream developers should ignore ABI compatibility.
> > > Do you mean having a stable branch means ABI preservation for the next major
> > > release is less important?
> > > 
> > I never stated that developers should ignore ABI compatibility, I stated that
> > creating an LTS release will make it that much easier for developers to do so.
> > 
> > And I think, pragmatically speaking, that is a concern.  Given that the
> > existance of an LTS release will make it tempting for developers to simply
> > follow the deprecation process rather than try to create ABI backward compatible
> > paths.
> > 
> > Looking at the git history, it seems clear to me that this is already happening.
> > I'm able to find a multitude of instances in which the deprecation process has
> > been followed reasonably well, but I can find no instances in which any efforts
> > have been made for backward compatibility.
> 
> There were some examples of backward compatibility in hash and lpm libraries.
> 
Ok, apologies, but you still see my point.  A relatively minor number of
instances of creating backward compatibility among a much larger set of easier
deprecate and replace instances.  Its not really having the effect it was
intended to.

> > > > LTS is a fine process for projects in which API/ABI breakage is either uncommon
> > > > or fairly isolated, but that in my mind doesn't really describe DPDK.
> > > 
> > > Yes API/ABI breakages are still common in DPDK.
> > > So it's even more important to have some stable branches.
> > 
> > We seem to be comming to different conclusions based on the same evidence. We
> > agree that API/ABI changes continue to be frequent ocurances, but my position is
> > that we already have a process in place to mitigate that, which is simply not
> > being used (i.e. versioning symbols to provide backward compatible paths),
> > whereas you seem to be asserting that an LTS model will allow for ABI stabiilty
> > and bug fixes.
> > 
> > While I don't disagree with that statement (LTS does provide both of those
> > things if the maintainer does it properly), I'm forced to ask the question,
> > before we solve this problem in a new way, 
> 
> The following questions are interesting but please don't assume the stable
> branch address the same issue as ABI compat.
Given your perspecive on what LTS/stable branches should be, I absolutely agree,
but thats not what John M. Was proposing.  from his initial proposal, he
specifically called out which changes were acceptable:

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.

The above list in my mind amounts to "Any change that there is sufficient
consumer demand for and doesn't present too much validation difficulty, except
ABI or API breaking changes".

While theres nothing really wrong with that, if we want to go down that path,
that really says to me that this is a way around ABI compatibilty problems,
because the inclusion of any other fix, given sufficient demand, can be
potentially justified.  So, in Johns proposal, a stable branch / LTS release is
going to effectively be a way to allow consumers to stay on one API/ABI level
for  longer period of time before having to make a major change catch up to the
HEAD release.

> In each major release, we add some new bugs because of new features, even
> if the ABI is kept.
> In a minor stable release there are only some bug fixes. So the only way
> to have a "bug free" version in a stable environment, is to do some
> maintenance in a stable branch.
> 
Again, I agree with your perspecitive on what a stable branch should be, but
thats not what John was proposing, and thats what I'm raising a concern about.

> > lets ask why the existing way isn't
> > being used.  Do developers just not care about backwards compatibility?  Is the
> > process to hard?  Something else?  I really don't like the idea of abandoning
> > what currently exists to replace it with something else, without first
> > addressing why what we have isn't working.
> 
> We can address both. But I strongly think the ABI compat is another topic.

I agree it can be a separate topic, but given the proposal here, it seems like
an awfully tempting way to avoid having to address it.  Not saying its a bad
plan, mind you, just that ABI compatibility is something that does need to be
kept at the forefront, because it still changes often (more often than it has
to).
Neil
 
> 

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

[Mcnamara, John]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman
> Sent: Monday, June 6, 2016 2:48 PM
> To: Thomas Monjalon <thomas.monjalon@6wind.com>
> Cc: dev@dpdk.org; Mcnamara, John <john.mcnamara@intel.com>; Christian
> Ehrhardt <christian.ehrhardt@canonical.com>; Markos Chandras
> <mchandras@suse.de>; Panu Matilainen <pmatilai@redhat.com>
> Subject: Re: [dpdk-dev] RFC: DPDK Long Term Support
> 
> While I don't disagree with that statement (LTS does provide both of those
> things if the maintainer does it properly), I'm forced to ask the
> question, before we solve this problem in a new way, lets ask why the
> existing way isn't being used.  Do developers just not care about
> backwards compatibility?  Is the process to hard?  Something else?  I
> really don't like the idea of abandoning what currently exists to replace
> it with something else, without first addressing why what we have isn't
> working.

Hi Neil,

I think these questions around why the current ABI policy isn't working 
(or at least not working well) and how it can be fixed are worth raising
as a new discussion.

John.
-- 

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

[Mcnamara, John]

> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Sunday, June 5, 2016 7:15 PM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev <dev@dpdk.org>; Christian Ehrhardt
> <christian.ehrhardt@canonical.com>; Markos Chandras <mchandras@suse.de>;
> Panu Matilainen <pmatilai@redhat.com>
> Subject: Re: [dpdk-dev] RFC: DPDK Long Term Support
> 
> >
> I'm not opposed to an LTS release, but it seems to be re-solving the issue
> of ABI breakage.  That is to say, there is alreay a process in place for
> managing ABI changes to the DPDK, which is designed to help ensure that:
> 
> 1) ABI changes are signaled at least 2 releases early
> 2) ABI changes whenever possible are designed such that backward
> compatibility versions can be encoded at the same time with versioning
> tags
> 
> Those two mechanism are expressly intended to allow application upgrades
> of DPDK libraries without worrying about ABI breakage.  

Hi,

The purpose of the LTS proposal isn't to replace or circumvent the ABI policy.
In fact backporting of patches would be very difficult without an upstream
ABI policy.

Even if the ABI policy was working perfectly there would still be a use case
for an LTS among consumers who want a fixed version with bug fixes or minor
changes. There are already several companies maintaining their own branches
like this. This purpose of this proposal is to get them to converge on a 
single version (or, if there is support, versions) and combine their efforts.


> While LTS releases
> are a fine approach for  some things, they sacrifice upstream efficiency
> (by creating work for backporting teams), while allowing upstream
> developers more leverage to just create ABI breaking changes on a whim,
> ignoring the existing ABI compatibility mechanism


An LTS release doesn't prevent us from maintaining upstream ABI compatibility
and it only gives developers leverage if we allow it to.

John.
-- 

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

[Nirmoy Das]

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

Hi,

I can see 16.07's release due date is 18th July. Is it possible to know
the timeline for RC versions of dpdk-16.07 ? This might be helpful for
SUSE to decide the supported product(SLE12 SP*/Leap) for dpdk-lts.

regards,
Nirmoy
-- 
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB
21284 (AG Nürnberg) Maxfeldstr. 5
D-90409 Nürnberg / Phone: +49-911-740 18-4

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

[Yuanhan Liu]

On Mon, Jun 06, 2016 at 03:44:47PM +0200, Nirmoy Das wrote:
> 
> > 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.
> 
> Hi,
> 
> I can see 16.07's release due date is 18th July. Is it possible to know
> the timeline for RC versions of dpdk-16.07 ? This might be helpful for
> SUSE to decide the supported product(SLE12 SP*/Leap) for dpdk-lts.

You can get it from http://dpdk.org/dev/roadmap:

    16.07
    Proposal deadline: May 8
    Integration deadline: June 16
    Release: July 18

In another word, we're gona have 1st RC release in less then 2 weeks.

	--yliu

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

[Christian Ehrhardt]

On Fri, Jun 3, 2016 at 5:07 PM, Mcnamara, John <john.mcnamara@intel.com>
wrote:
[...]
>
> 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.
>

I can see on the discussions that much more things around this have to be
discussed and agreed, but to some extend we will also just "have to wait
and see" how things work out.
I fully agree to the API change argument to start with 16.07 and the 2 year
cycle (more would be nice, but this means effort and after a while almost
nothing is "easily" backportable).

Never the less I have to ask - as I'd be personally much more happy if it
would be the odd years autumn release that would make the LTS as it would
match our LTS releases much much better.
Otherwise we (Ubuntu) will always "just miss" the LTS by a few months.
First I'd have thought on xx.02 releases, but consuming applications might
need time to adapt and while there are the nice API/ABI guarantees
experience tells me to better leave some kind of time-buffer.

Also this would give all of us a first shot with a shorter (not so long as
in L) LTS to see if the process we defined works out before jumping on a
full 2 year cadence.

So while I see that this is kind of "my problem" I would at least try to
personally ask and vote for LTS being: 16.7, 17.11, 19.11, 21.11, ...

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

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

[Martinx - ジェームズ]

On 7 June 2016 at 08:36, Christian Ehrhardt <
christian.ehrhardt@canonical.com> wrote:

> On Fri, Jun 3, 2016 at 5:07 PM, Mcnamara, John <john.mcnamara@intel.com>
> wrote:
> [...]
> >
> > 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.
> >
>
> I can see on the discussions that much more things around this have to be
> discussed and agreed, but to some extend we will also just "have to wait
> and see" how things work out.
> I fully agree to the API change argument to start with 16.07 and the 2 year
> cycle (more would be nice, but this means effort and after a while almost
> nothing is "easily" backportable).
>
> Never the less I have to ask - as I'd be personally much more happy if it
> would be the odd years autumn release that would make the LTS as it would
> match our LTS releases much much better.
> Otherwise we (Ubuntu) will always "just miss" the LTS by a few months.
> First I'd have thought on xx.02 releases, but consuming applications might
> need time to adapt and while there are the nice API/ABI guarantees
> experience tells me to better leave some kind of time-buffer.
>
> Also this would give all of us a first shot with a shorter (not so long as
> in L) LTS to see if the process we defined works out before jumping on a
> full 2 year cadence.
>
> So while I see that this is kind of "my problem" I would at least try to
> personally ask and vote for LTS being: 16.7, 17.11, 19.11, 21.11, ...
>
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>

+1 For DPDK LTS being:

16.7, 17.11, 19.11, 21.11, ...

This way, DPDK LTS 17.11 will be part of Ubuntu LTS 18.04... DPDK LTS 19.11
on Ubuntu LTS 20.04...

Very likely that DPDK LTS 16.07 will be available to Ubuntu 16.04 via
Ubuntu Cloud Archive Newton.

Cheers!
Thiago