openstack/neutron
Code Issues Proposed changes

Merge "Fix dir doc typo error"

Browse Source
This commit is contained in:
Jenkins 2017-01-07 02:26:13 +00:00 committed by Gerrit Code Review
commit a83356bfcd
4 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/source/devref/db_models.rst
View File

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

2
doc/source/devref/rpc_callbacks.rst
View File

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

2
doc/source/stadium/governance.rst
View File

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