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 7A12F5684 for ; Mon, 6 Jun 2016 17:08:07 +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 1b9w8F-0004l1-Kp; Mon, 06 Jun 2016 11:08:04 -0400 Date: Mon, 6 Jun 2016 11:07:58 -0400 From: Neil Horman To: Thomas Monjalon Cc: dev@dpdk.org, "Mcnamara, John" , Christian Ehrhardt , Markos Chandras , Panu Matilainen Message-ID: <20160606150758.GC3867@hmsreliant.think-freely.org> References: <37570042.soqC7jPioi@xps13> <20160606134742.GA3867@hmsreliant.think-freely.org> <1749152.sKPP3yRPqQ@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1749152.sKPP3yRPqQ@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 15:08:07 -0000 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 >