versions of. In those events ABI's may be updated without backward
compatibility provided. The requirements for doing so are:
-#. At least 3 acknoweldgements of the need on the dpdk.org
+#. At least 3 acknowledgments of the need on the dpdk.org
#. A full deprecation cycle must be made to offer downstream consumers sufficient warning of the change. E.g. if dpdk 2.0 is under development when the change is proposed, a deprecation notice must be added to this file, and released with dpdk 2.0. Then the change may be incorporated for dpdk 2.1
#. The LIBABIVER variable in the makefile(s) where the ABI changes are incorporated must be incremented in parallel with the ABI changes themselves
lightly. ABI stability is extremely important for downstream consumers of the
DPDK, especially when distributed in shared object form. Every effort should be
made to preserve ABI whenever possible. For instance, reorganizing public
-structure field for astetic or readability purposes should be avoided as it will
+structure field for aesthetic or readability purposes should be avoided as it will
cause ABI breakage. Only significant (e.g. performance) reasons should be seen
as cause to alter ABI.