[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

>