From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id B782A2C5D for ; Mon, 6 Jun 2016 15:47:53 +0200 (CEST) Received: from [107.15.76.160] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1b9usZ-00042G-KP; Mon, 06 Jun 2016 09:47:50 -0400 Date: Mon, 6 Jun 2016 09:47:42 -0400 From: Neil Horman To: Thomas Monjalon Cc: dev@dpdk.org, "Mcnamara, John" , Christian Ehrhardt , Markos Chandras , Panu Matilainen Message-ID: <20160606134742.GA3867@hmsreliant.think-freely.org> References: <20160605181513.GA11762@neilslaptop.think-freely.org> <37570042.soqC7jPioi@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37570042.soqC7jPioi@xps13> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Score: -1.0 (-) X-Spam-Status: No Subject: Re: [dpdk-dev] RFC: DPDK Long Term Support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 13:47:54 -0000 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 >