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 768115A9A for ; Thu, 22 Jan 2015 20:22:01 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YENKF-00084D-An; Thu, 22 Jan 2015 14:21:58 -0500 Date: Thu, 22 Jan 2015 14:21:54 -0500 From: Neil Horman To: Thomas Monjalon Message-ID: <20150122192154.GF20564@hmsreliant.think-freely.org> References: <1419109299-9603-1-git-send-email-nhorman@tuxdriver.com> <118516630.HbYOjXYvMh@xps13> <20150121194304.GA32617@hmsreliant.think-freely.org> <1979052.xAyoMbVLoL@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1979052.xAyoMbVLoL@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v6 4/4] docs: Add ABI documentation 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: Thu, 22 Jan 2015 19:22:01 -0000 On Wed, Jan 21, 2015 at 11:24:12PM +0100, Thomas Monjalon wrote: > 2015-01-21 14:43, Neil Horman: > > On Wed, Jan 21, 2015 at 05:05:51PM +0100, Thomas Monjalon wrote: > > > 2015-01-21 09:59, Neil Horman: > > > > Considered and answered already. I'm in favor of listing macros and structure > > > > changes in the abi document, but I think an exhaustive list isn't needed. If it > > > > is, we could spend pages diving into minute. Better to point out the need for > > > > abi noticies as patches get posted. > > > > > > I'm afraid you don't understand what I'm saying. Copy/paste: > > > "No, I was suggesting to explain in this doc that macro removal must be > > > announced with a deprecation notice, > > > and that in case structure must be reworked, the name must change if we > > > want to preserve ABI compatibility with old structure." > > > Rewording: if you agree with this policy, please add it in this document. > > > > > Yes, we're on the same page regarding what your asking, I just don't agree that > > it needs to be explicitly called out. I thought I was clear on that. > > Appaerntly not however, so if it will settle the point, I'll just add it. > > OK maybe I didn't explain enough my proposal. > You can disagree but I want to be sure we think about the same thing. > > 1) Macros are not part of the ABI but can be part of the API. > Such macro removal must be announced in the previous release. > 2) Structures are part of the ABI but cannot be versionned as the functions. > So an ABI breaking change should be done by cloning the structure in a new one. > And the API functions where this structure appears should be cloned and versionned > to support new structure while keeping old version. > > Maybe that these precisions are confuse and useless. > Now I think I understand what you were saying by "an exhaustive list isn't needed". > You mean listing all types of ABI/API breakage like I did with these 2 cases, right? > I thought it was related to list of real/effective deprecations. > > > > > > Neil, we expect that you consider comments done previously and that you test your patch. > > > > > Otherwise, we are losing time in useless reviews. > > > > > > > > > Thomas, I have considered your comments, I simply don't agree with all of them, > > > > and I made that clear. > > > > > > > > As for losing time, you let the first attempt at this > > > > patch rot on the list in 1.7 and have done the same thing for the 1.8 cycle > > > > until I yelled for reviews. > > > > > > Now, I'm really upset of your wrong assumptions. > > > You sent your first proposal on september, during 1.8 cycle, not 1.7 ! > > > And during this cycle, the decision was to postpone it for 2.0 release. > > > > > you're missing the point. I apologize for not getting the release numbers right, > > it should be 1.8 to 2.0 not 1.7 to 1.8 as you note, but that doesn't really > > matter. The point was 6 months. 6 months this has been sitting around. > > No, 5 months. Yes, it's long. > > > In that time up to this point I've gotten one review from another devloper on the > > set, and you indicating that its not ready yet. Then, the day 1.8 released, I > > reposed the patch series as we agreed, and its taken almost 5 weeks before I've > > gotten any feedback on it, and then its feedback that could have been given 6 > > months ago (you'll note this patch was initially identical to the version I > > posted back in september). I think you can understand how I find that > > frustrating. > > You must understand that I'd prefer more people feel involved by this change. > It would be saner to have this policy reviewed and acked by many developpers. > As it was announced on the roadmap for 2.0, this first month of the cycle was > ideal to have more discussions on how this policy can be precisely applied. > You only received my comments (which may be useless) and it's now time to > apply this important patchset. > > > > I don't understand what's wrong with you. > > The above is whats wrong with me. The fact that I can try and try and try to > > add value to this project so that I can expand its user base, and the best I've > > thus far been able to receive is indifference. At worst, the indifference is > > followed by being told that the indifference is tantamount to rejection. > > > > > > > You don't make any effort to understand what we are saying and > > > you make no effort to understand what is this doc directory. > > > You prefer crying that your patch is not applied. > > No effort? How many emails have I written contesting your opinions, presenting > > supporting evidence, only to be met with assertions? I don't think I'm the one > > not making an effort here. > > At the end, I accept your point of view and will apply the patchset. > > > > And I still don't understand if you are willing to work on a test tool for ABI? > > > > > From this email > > http://dpdk.org/ml/archives/dev/2015-January/011306.html > > > > ======================================================= > > > Yes, it should be another patchset. > > > Do you plan to work on it? It would be very convenient for developpers and > > > maintainers to test ABI compatibility. > > > > > Gladly, if we can get this in. I think its an important tool. > > ========================================================= > > > > I'm not sure how thats unclear, but in the event that it wasn't, yes, I will > > gladly work on such a tool. > > OK thanks, it would be helpful to have it in release 2.0. > Its not going to make 2.0, its a big undertaking. If you wanted it in 2.0 that would have been something to bring up 5 months ago.