DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility
Date: Fri, 26 Sep 2014 15:02:55 -0700
Message-ID: <20140926150255.75ff6f45@urahara> (raw)
In-Reply-To: <20140926144549.GA5619@hmsreliant.think-freely.org>

On Fri, 26 Sep 2014 10:45:49 -0400
Neil Horman <nhorman@tuxdriver.com> 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

Isn't ABI stablity a distro responsibility not a project responsibility?
I have lots more API/ABI changes, just been too busy trying to release a real
product using DPDK to upstream all the changes.

  reply	other threads:[~2014-09-26 21:56 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15 19:23 Neil Horman
2014-09-15 19:23 ` [dpdk-dev] [PATCH 1/4] compat: Add infrastructure to support symbol versioning Neil Horman
2014-09-23 10:39   ` Sergio Gonzalez Monroy
2014-09-23 14:58     ` Neil Horman
2014-09-23 16:29       ` Sergio Gonzalez Monroy
2014-09-23 17:31         ` Neil Horman
2014-09-25 18:52   ` [dpdk-dev] [PATCH 1/4 v2] " Neil Horman
2014-09-26 14:16     ` Sergio Gonzalez Monroy
2014-09-26 15:16       ` Neil Horman
2014-09-26 15:33         ` Sergio Gonzalez Monroy
2014-09-26 16:22           ` Neil Horman
2014-09-26 19:19             ` Neil Horman
2014-09-29 15:44   ` [dpdk-dev] [PATCH 1/4 v3] " Neil Horman
2014-09-30  8:13     ` Sergio Gonzalez Monroy
2014-09-30 15:18   ` [dpdk-dev] [PATCH 1/4 v4] " Neil Horman
2014-10-01 10:15     ` Sergio Gonzalez Monroy
2014-10-01 10:38       ` Neil Horman
2014-10-01 11:28     ` Sergio Gonzalez Monroy
2014-09-15 19:23 ` [dpdk-dev] [PATCH 2/4] Provide initial versioning for all DPDK libraries Neil Horman
2014-09-19  9:45   ` Bruce Richardson
2014-09-19 10:22     ` Neil Horman
2014-10-01 11:25   ` Sergio Gonzalez Monroy
2014-10-01 14:43     ` Neil Horman
2014-09-15 19:23 ` [dpdk-dev] [PATCH 3/4] Add library version extenstion Neil Horman
2014-10-01 11:27   ` Sergio Gonzalez Monroy
2014-09-15 19:23 ` [dpdk-dev] [PATCH 4/4] docs: Add ABI documentation Neil Horman
2014-10-01 16:06   ` Sergio Gonzalez Monroy
2014-09-18 18:23 ` [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility Thomas Monjalon
2014-09-18 19:14   ` Neil Horman
2014-09-19  8:57     ` Richardson, Bruce
2014-09-19 14:18     ` Venkatesan, Venky
2014-09-19 17:45       ` Neil Horman
2014-09-24 18:19     ` Neil Horman
2014-09-26 10:41       ` Thomas Monjalon
2014-09-26 14:45         ` Neil Horman
2014-09-26 22:02           ` Stephen Hemminger [this message]
2014-09-27  2:22             ` Neil Horman
2014-10-01 18:59           ` Neil Horman
2014-10-07 21:01             ` Neil Horman
2014-10-08 15:57               ` Thomas Monjalon
2014-10-08 18:46                 ` Butler, Siobhan A
2014-10-08 19:09                 ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140926150255.75ff6f45@urahara \
    --to=stephen@networkplumber.org \
    --cc=dev@dpdk.org \
    --cc=nhorman@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git