diff --git a/doc/source/devref/alembic_migrations.rst b/doc/source/devref/alembic_migrations.rst index 609a31cffbd..20ec09c1f0f 100644 --- a/doc/source/devref/alembic_migrations.rst +++ b/doc/source/devref/alembic_migrations.rst @@ -355,7 +355,7 @@ and "contract" categories, as well as some data migrations. the ``op.create_tab directive is an "expand"; it may be run safely while the old version of the application still runs, as the old code simply doesn't look for this table. The ``op.drop_constraint`` and ``op.drop_column`` directives are -"contract" directives (the drop column moreso than the drop constraint); running +"contract" directives (the drop column more so than the drop constraint); running at least the ``op.drop_column`` directives means that the old version of the application will fail, as it will attempt to access these columns which no longer exist. diff --git a/doc/source/devref/db_models.rst b/doc/source/devref/db_models.rst index e48d35de534..5063202d990 100644 --- a/doc/source/devref/db_models.rst +++ b/doc/source/devref/db_models.rst @@ -33,8 +33,8 @@ Structure of Model Definitions ------------------------------ We have decided to move all models definitions to neutron/db/models/ -with no futher nesting after that point. The deprecation method to move -models is already been added to avoid breakage of third party plugins using +with no further nesting after that point. The deprecation method to move +models has already been added to avoid breakage of third party plugins using those models. All relocated models need to use deprecate method that will generate a warning and return new class for use of old class. Some examples of relocated models [2] and [3]. In future if you define new models diff --git a/doc/source/devref/rpc_callbacks.rst b/doc/source/devref/rpc_callbacks.rst index 5595b760b83..630e812625d 100644 --- a/doc/source/devref/rpc_callbacks.rst +++ b/doc/source/devref/rpc_callbacks.rst @@ -272,7 +272,7 @@ belong to the same resource type, a single push RPC message is sent; if the list contains objects of different resource types, resources of each type are grouped and sent separately, one push RPC message per type. On the receiver side, resources in a list always belong to the same type. In other words, a server-side -push of a list of heterogenous objects will result into N messages on bus and +push of a list of heterogeneous objects will result into N messages on bus and N client-side callback invocations, where N is the number of unique resource types in the given list, e.g. L(A, A, B, C, C, C) would be fragmented into L1(A, A), L2(B), L3(C, C, C), and each list pushed separately. diff --git a/doc/source/stadium/governance.rst b/doc/source/stadium/governance.rst index d3fa45d708a..0713b8061fb 100644 --- a/doc/source/stadium/governance.rst +++ b/doc/source/stadium/governance.rst @@ -49,7 +49,7 @@ team. In fact, it became harder and harder to ensure consistency in the APIs, architecture, design, implementation and testing of the overarching project; all aspects of software development, like documentation, integration, release -management, maintainance, and upgrades started to being neglected for some +management, maintenance, and upgrades started to being neglected for some projects and that led to some unhappy experiences. The point about uniform APIs is particularly important, because the Neutron