[dpdk-dev] [PATCH v6 4/4] docs: Add ABI documentation

[Neil Horman]

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.