From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 239AD2E81 for ; Mon, 6 Jun 2016 16:21:14 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id n184so94948671wmn.1 for ; Mon, 06 Jun 2016 07:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=c0I60sAVnHs3ZCMq9+S12bixwCFv7q/xAQUjRXrw38A=; b=q7vxUeuVXEAjtWwVGMGZQnMwEl4VWCBg6biVFGb1AQlqHmjD5YLzknO/DjZaSgB1ba jdx+Er9qsI8IOJWyISeLM4FT9+ceWJR/ROhxRCK3GTaebMkvUVRp9gKFLzBIBNGTry2c vECRdkwC3R2zkMnkQ8o4Z+QI46OzdRSSTQbivLwGWyIRLJZBQD78Bp0uFbvXROhugHgD DTRB+6dpymun93DOhMF4TwjICVAePAAPEz0ASMqrVIm4YsApKoUW+gxxvqe9GQormMwF pFgIx1tZy5SHwc0FFDKFt/x6vxnHQ6GvI632Jf6Clb4JAmXYsv0rODpGRB23WH0lojFZ 8UQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=c0I60sAVnHs3ZCMq9+S12bixwCFv7q/xAQUjRXrw38A=; b=MNo7z0Vxpjredv3qR4rrkFSIS50wgO8i4avZb1pGAWQCMcLptBQH0IVhUkaKiT8lLP 8ER/naoi7ZJsysuWuIWtT4Ofeg+FAR/g+00KxlgiPmkgrDXRm8Vw95orGLHqYMzCpDzg Xn5aZ1MUpORnrxnpRRvSQAUKk+ow2q3dDDaKYWYLwF3IFrpXQzc9y80u2Tdd20XQFKBC b8kKkCYFJgFrJizigE9SEkr//03IB5oyJUEMH70eeeYTznFv2x1vBAmUbD2QhNrrCBr2 5wgJhNCWZeZunvkAr2nL52cwyDvfoVO+IfP7i+acGEjQrG3qleC/rBUSKjRoVjgBejX5 AIlQ== X-Gm-Message-State: ALyK8tJBvLRHGkQufoNBwQMYkjLFdud4T4x+kdTtqN3Y/hhyneYVGeYAArlB8Q9f1Rvi5L0w X-Received: by 10.194.84.74 with SMTP id w10mr15887453wjy.118.1465222873771; Mon, 06 Jun 2016 07:21:13 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id j6sm20501062wjb.29.2016.06.06.07.21.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 07:21:12 -0700 (PDT) From: Thomas Monjalon To: Neil Horman Cc: dev@dpdk.org, "Mcnamara, John" , Christian Ehrhardt , Markos Chandras , Panu Matilainen Date: Mon, 06 Jun 2016 16:21:11 +0200 Message-ID: <1749152.sKPP3yRPqQ@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160606134742.GA3867@hmsreliant.think-freely.org> References: <37570042.soqC7jPioi@xps13> <20160606134742.GA3867@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 14:21:14 -0000 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.