[dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability

[Bruce Richardson]

On Sat, Apr 13, 2019 at 08:42:02PM -0400, Neil Horman wrote:
> On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote:
> > On 07/04/2019 10:48, Thomas Monjalon wrote:
> > > 04/04/2019 16:07, Burakov, Anatoly:
> > >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> > >>> On 04/04/2019 11:54, Bruce Richardson wrote:
> > >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> > >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> > [SNIP]
> > >> So, if we are to cement our core API - we have to make a concrete effort 
> > >> to specify what goes and what stays, if we want it to be maintainable. 
> > >> The DPDK 1.0 specification, if you will :)
> > > 
> > > "DPDK 1.0 specification", that's a great project name :-)
> > > 
> > 
> > Honestly - I would say that I am nervous of this.
> > 
> > The definition of a DPDK 1.0 specification as a gate to API stability,
> > feels like a "great plan tomorrow" instead of a "good plan" today. I
> > think that getting people to dedicate time to such a specification might
> > prove problematic and I could see this effort being very time consuming.
> > It might never get completed.
> > 
> > My preference would be to instead adopt a well-publicised community
> > timeline for adopting more conservative API maintenance rules.
> > 
> > Perhaps we could give ourselves as a community a time-limited window in
> > which to address concerns around the API before they become hardened -
> > perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> > to 9 months.
> > 
> > We then would know the timeline when niggles like exposure of internal
> > structures and mbuf structure needed to be sorted by and could
> > prioritize accordingly.
> > 
> > Ray K
> 
> I'm hesitant to say this, because I'm not usually a fan of throwing up
> barricades to progress, but might some level of CI integration be useful here?
> 
> Part of the problem, as I've seen it (and I think you've noted previously in
> this thread), is that ABI stability just hasn't been a priority, and not
> something that developers look at when making changes, nor when reviewers review
> patches.  When I wrote the early ABI checking tools for DPDK, while the reaction
> was generally positive (I think), the results were informational, and treated as
> such (something to take note of perhaps, but something that could be ignored if
> there were more pressing issues).  Perhaps a concrete step might be to run the
> ABI checker during a CI run on every commit, and block acceptance of a patch if
> it modifies the ABI.  That would at least put a procedural break in ABI
> modification without clear approval from the board.
> 
No objections to that here. Sounds a reasonable suggestion.