Re: [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility

[Neil Horman <nhorman@tuxdriver.com>]

On Wed, Oct 01, 2014 at 02:59:40PM -0400, Neil Horman wrote:
> On Fri, Sep 26, 2014 at 10:45:49AM -0400, Neil Horman wrote:
> > On Fri, Sep 26, 2014 at 12:41:33PM +0200, Thomas Monjalon wrote:
> > > Hi Neil,
> > > 
> > > 2014-09-24 14:19, Neil Horman:
> > > > Ping Thomas. I know you're busy, but I would like this to not fall off anyones
> > > > radar.  You alluded to concerns regarding what, for lack of a better term,
> > > > ABI/API lockin.  I had asked you to enuumerate/elaborate on specifics, but never
> > > > heard back.  Are there further specifics you wish to discuss, or are you
> > > > satisfied with the above answers?
> > > 
> > > Sorry for not being very reactive on this thread.
> > > All this discussion is very interesting but it's really not the proper
> > > time to apply it. As you said, it requires an extra effort. I'm not saying
> > > it will never be integrated. I'm just saying that we cannot change
> > > everything at the same time.
> > > 
> > > Let me sum up the situation. This community project has been very active
> > > for few months now. First, we learnt how to make some releases together
> > > and we are improving the process to be able to deliver a new major release
> > > every 4 months while having some good quality process.
> > > But these releases are still not complete because documentation is not
> > > integrated yet. Then developers should have a role in documentation updates.
> > > We also need to integrate and learn how to use more tools to be more
> > > efficient and improve quality.
> > > 
> > > So the question is "when should we care about API compatibility"?
> > > And the answer is: ASAP, but not now. I feel next year is a better target.
> > > Because the most important priority is to move together at a pace which
> > > allow most of us to stay in the race.
> > > 
> > 
> > 
> > I'm sorry Thomas, I don't accept this.  I asked you for details as to your
> > concerns regarding this patch series, and you've provided more vague comments.
> > I need details to address
> > 
> > You say it requires extra effort, you're right it does.  Any feature that you
> > integreate requires some additional effort.  How is this patch any different
> > from adding the acl library or any other new API?  Everything requires
> > maintenence, thats how software works.  What specfically about this patch series
> > makes the effort insurmountable to you?
> > 
> > You say you're improving your process.  Great, this patch aids in that process
> > by ensuring backwards compatibility for a period of time.  Given that the API
> > and ABI can still evolve within this framework, as I've described, how is this
> > patch series not a significant step forward toward your goal of quality process.
> > 
> > You say documentation isn't integrated.  So, what does getting documentation
> > integrated have to do with this patch set, or any other?  I don't see you
> > holding any other patches based on documentation.  Again, nothing in this series
> > prevents evolution of the API or ABI.  If you're hope is to wait until
> > everything is perfect, then apply some control to the public facing API, and get
> > it all documented, none of thosse things will ever happen, I promise you.
> > 
> > You say you also need to learn to use more tools to be more efficient and
> > improve quality.  Great!  Thats exactly what this is. If we mandate even a short
> > term commitment to ABI stability (1 single relese worth of time), we will
> > quickly identify what API's change quickly and where we need to be cautious with
> > our API design.  If you just assume that developers will get better of their own
> > volition, it will never happen.
> > 
> > You say this should go in next year, but not now.  When exactly?  What event do
> > you forsee occuring in the next 12-18 months that will change everything such
> > that we can start supporing an ABI for more than just a few weeks at the head of
> > the tree?  
> > 
> > To this end, I just did a quick search through the git history for dpdk to look
> > at the histories of all the header files that are exposed via the makefile
> > SYMLINK command (given that that provides a list of header files that
> > applications can include, and embodies all the function symbols and data types
> > applications have access to.
> > 
> > There are 179 total commits in that list
> > Of those, a bit of spot checking suggests that about 10-15% of them actually
> > change ABI, and many of those came from Bruce's rework of the mbuf structure.
> > That about 17-20 instances over the last 2 years where an ABI update would have
> > been needed.  That seems pretty reasonable to me.  Where exactly is your concern
> > here?
> > 
> > Neil
> > 
> 
> Ping Thomas, I'd like to continue this debate to a conclusion.  Could you please
> provide specific details and/or concerns that you have with this patch series?
> 
> Thanks
> Neil
> 
Ping again Thomas, please lets debate this to a reasonable consensus.  Ignoring
it won't help anything.


Regards
Neil