On 04/04/2019 20:08, Wiles, Keith wrote:
>
>
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktray...@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
> 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.
New APIs will be experimental in any case, as you say they are less of
problem.
I agree, if we can make a change and preserve API compatibility with
versioning then everyone is happy.
Changes only need be referred to the higher power in case on absolutely
breakage - _but_ these need to become as rare as hens teeth.
>>
>>> 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
>
