All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Neil Horman <nhorman@tuxdriver.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: RFC: DPDK Long Term Support
Date: Mon, 06 Jun 2016 11:27:29 +0200	[thread overview]
Message-ID: <37570042.soqC7jPioi@xps13> (raw)
In-Reply-To: <20160605181513.GA11762@neilslaptop.think-freely.org>

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.

  reply	other threads:[~2016-06-06  9:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-03 15:07 RFC: DPDK Long Term Support Mcnamara, John
2016-06-03 16:05 ` Thomas Monjalon
2016-06-06 11:49   ` Yuanhan Liu
2016-06-06 13:31     ` Thomas Monjalon
2016-06-06 14:14       ` Yuanhan Liu
2016-06-06 14:23         ` Thomas Monjalon
2016-06-07 13:17   ` Mcnamara, John
2016-06-03 18:17 ` Matthew Hall
2016-06-07 12:53   ` Mcnamara, John
2016-06-05 18:15 ` Neil Horman
2016-06-06  9:27   ` Thomas Monjalon [this message]
2016-06-06 13:47     ` Neil Horman
2016-06-06 14:21       ` Thomas Monjalon
2016-06-06 15:07         ` Neil Horman
2016-06-07 16:21       ` Mcnamara, John
2016-06-07 15:55   ` Mcnamara, John
2016-06-06 13:44 ` Nirmoy Das
2016-06-06 14:16   ` Yuanhan Liu
2016-06-07 12:36 ` Christian Ehrhardt
2016-06-07 19:39   ` Martinx - ジェームズ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37570042.soqC7jPioi@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=christian.ehrhardt@canonical.com \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.com \
    --cc=mchandras@suse.de \
    --cc=nhorman@tuxdriver.com \
    --cc=pmatilai@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.