All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Traynor <ktraynor@redhat.com>
To: "Wiles, Keith" <keith.wiles@intel.com>
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>,
	Ray Kinsella <mdr@ashroe.eu>, dpdk-dev <dev@dpdk.org>,
	"techboard@dpdk.org" <techboard@dpdk.org>
Subject: Re: [dpdk-techboard] DPDK ABI/API Stability
Date: Thu, 4 Apr 2019 21:13:05 +0100	[thread overview]
Message-ID: <bad76b3a-d229-07cd-eb08-864f4a16d25a@redhat.com> (raw)
In-Reply-To: <B42554A2-232A-48E4-9A61-C234A577E415@intel.com>

On 04/04/2019 20:08, Wiles, Keith wrote:
> 
> 
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
>>
>>>
>>> My thoughts on the matter are:
>>> 1. I think we really need to do work to start hiding more of our data
>>> structures - like what Stephen's latest RFC does. This hiding should reduce
>>> the scope for ABI breaks.
>>> 2. Once done, I think we should commit to having an ABI break only in the
>>> rarest of circumstances, and only with very large justification. I want us
>>> to get to the point where DPDK releases can immediately be picked up by all
>>> linux distros and rolled out because they are ABI compatible.
>>>
>>
>> Maybe techboard should explicitly approve ABI breaks and new APIs (or
>> APIs at transition from experimental to core). Just as a way to get more
>> eyeballs and scrutiny on them.
> 
> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>>

We'll only find out if they are bad when they need ABI breaks later :-)

My point is a good way to avoid future ABI breaks is to have more
reviews on the APIs in the first place. Techboard approval might be one
way, or 3 acks or something else.

>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>> me as a plan where we end up with the same number of ABI breaks as before,
>>> just balled into one release.
>>>
>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>> case that each distro will only ship one version of DPDK, or is it possible
>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>
>>
>> It would probably double validation and maintenance, so it would require
>> a lot of extra effort.
>>
>>>
>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>> similar.
>>>
>>> Regards,
>>> /Bruce
>>>
>>
> 
> Regards,
> Keith
> 

  reply	other threads:[~2019-04-04 20:13 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-03 15:42 DPDK ABI/API Stability Ray Kinsella
2019-04-03 19:53 ` Luca Boccassi
2019-04-04  9:29 ` Burakov, Anatoly
2019-04-04 10:54   ` [dpdk-techboard] " Bruce Richardson
2019-04-04 12:02     ` Luca Boccassi
2019-04-04 13:05       ` Ray Kinsella
2019-04-04 13:10         ` Bruce Richardson
2019-04-05 13:25           ` [dpdk-dev] " Ray Kinsella
2019-04-07  9:37             ` Thomas Monjalon
2019-04-04 13:21         ` Luca Boccassi
2019-04-04 12:52     ` Ray Kinsella
2019-04-04 14:07       ` Burakov, Anatoly
2019-04-07  9:48         ` [dpdk-dev] " Thomas Monjalon
2019-04-08  9:04           ` Ray Kinsella
2019-04-08 10:15             ` Burakov, Anatoly
2019-04-08 13:00               ` Ray Kinsella
2019-04-08 13:38                 ` Burakov, Anatoly
2019-04-08 13:58                   ` David Marchand
2019-04-08 14:02                     ` Burakov, Anatoly
2019-04-08 14:38                       ` David Marchand
2019-04-08 15:13                         ` Stephen Hemminger
2019-04-08 15:49                         ` Burakov, Anatoly
2019-04-10  8:35                           ` David Marchand
2019-04-08 15:50                         ` Burakov, Anatoly
2019-04-09  9:42                   ` Ray Kinsella
2019-04-14  0:42             ` Neil Horman
2019-04-15  9:10               ` Bruce Richardson
2019-04-04 15:51     ` Stephen Hemminger
2019-04-04 16:37       ` Burakov, Anatoly
2019-04-04 16:56     ` Kevin Traynor
2019-04-04 19:08       ` Wiles, Keith
2019-04-04 20:13         ` Kevin Traynor [this message]
2019-04-05 13:30           ` [dpdk-dev] " Ray Kinsella
2019-04-05 13:29         ` Ray Kinsella
2019-04-04  9:47 ` Kevin Traynor
2019-04-04 13:16   ` Ray Kinsella
2019-04-10  5:14 ` [dpdk-dev] " Honnappa Nagarahalli
2019-04-10  9:03   ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-10  9:43   ` [dpdk-dev] " Luca Boccassi

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=bad76b3a-d229-07cd-eb08-864f4a16d25a@redhat.com \
    --to=ktraynor@redhat.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=keith.wiles@intel.com \
    --cc=mdr@ashroe.eu \
    --cc=techboard@dpdk.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.