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> >> >>> >>> 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 >
