On Wed, 2019-04-10 at 05:14 +0000, Honnappa Nagarahalli wrote: > > I guess the short story is that DPDK ABI hasn't really settled down > > as the > > project has matured. If you take a look at the “Backward Compat.” > > column which measures ABI compatibility compared to the previous > > releases, you will see significant churn in the ABI over successive > > releases > > since v16.04. > > > > Now compare DPDK to GStreamer as an example of a very mature > > project > > with a similar intent, a framework for building applications, and > > which > > enjoys a very stable API. > > > > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer > > > > > > The DPDK ABI churn has the following affects for users:- > > > > 1. The churn obliges users of DPDK to commit to a constant re- > > integration > > and re-validation effort for new versions of DPDK. This effort from > > their > > perspective may not add value to their consuming project, > > particular if > > they are only updating to "stay current". > > Even if the ABI did not change, any claim of support with newer > version needs re-validation. I think, re-integration is the only > extra effort.
>From first-hand experience: re-integration and re-validation are different in scope and resource requirements. Validation is usually done by the QA group, and usually doesn't cover just one library that makes up a part of a product. In other words, whether the DPDK version changes or not, a new version of a product will typically undergo full regression testing anyway. Integration is done by the development group. Any engineering-days that have to be dedicated to re-integrate a new version of DPDK are resources taken away from development of new features or bug fixing. Maintenance costs of OSS components are a sometimes overlooked but critical part of correctly scoping the opex of a project, and it's something that product/project managers do look at. > Why would anyone like to move to newer version just to stay current > if the newer version does not add any value to them? IMO, this is > doing work for no benefit. For many reasons. For example the argument I always use is that while new version Y might not be needed, new version Z might suddenly become required for the successful delivery of critical feature A, or to fix critical bug B. In my experience, jumping from version X to Y and then Y to Z is always cheaper and quicker and lower effort than jumping from X to Z, and the larger the jump, the more work it is. Another reason is that it's orders of magnitude cheaper to consume dependencies from the base distribution of choice when building a Linux product, rather than vendorizing. Doing that has of course drawbacks, including not being in control of the version of dependencies - so you don't have a choice, you need to keep up as the base distro moves on. -- Kind regards, Luca Boccassi
