edits: release notes

Author: Bob Grabar

source/release-notes/2.2.txt

@@ -13,8 +13,8 @@ Release Notes for MongoDB 2.2
 Upgrading
 ---------
 
-The MongoDB 2.2 series is the production release series of MongoDB
-series that succeeds the 2.0 series.
+MongoDB 2.2 is a production release series and succeeds the 2.0
+production release series.
 
 MongoDB 2.0 data files are compatible with 2.2-series binaries without any
 special migration process. However, always perform the upgrade process for replica
@@ -27,16 +27,19 @@ Synopsis
   replacement.
 
 - For all deployments using authentication, you *must* upgrade the
-  drivers (i.e. client libraries,) before upgrading the
+  drivers (i.e. client libraries), before upgrading the
   :program:`mongod` instance or instances.
 
-- You can upgrade the members of a replica set, one-by-one
+.. To keep with what people are used to, we really should move the comma
+   outside the parens.
+
+- You can upgrade the members of a replica set one-by-one
   [#secondaries-first]_ **except** when using authentication. In
-  deployments that use authentication, (i.e. where the
-  :program:`mongod` runs with :option:`--keyFile <mongod --keyfile>`,)
+  deployments that use authentication (i.e. where the
+  :program:`mongod` runs with :option:`--keyFile <mongod --keyfile>`),
   you must shut down the entire set and perform the upgrade at once.
 
-  The 2.2.1 release will remove this requirement, see
+  The 2.2.1 release will remove this requirement. See
   :issue:`SERVER-6897` for more information.
 
 - For all upgrades of sharded clusters, turn off the balancer during
@@ -50,11 +53,11 @@ Synopsis
 
   - Second, upgrade all :program:`mongos` instances.
 
-  - Finally, upgrade all :program:`mongod` instances.
+  - Last, upgrade all :program:`mongod` instances.
 
 Other than the above restrictions, 2.2 processes can interoperate with
-2.0 and 1.8 tools and processes. You can safely upgrade a the
-:program:`mongod` and :program:`mongos` components of a deployment,
+2.0 and 1.8 tools and processes. You can safely upgrade the
+:program:`mongod` and :program:`mongos` components of a deployment
 one by one while the deployment is otherwise operational.  Be sure to
 read the detailed upgrade procedures below before upgrading production
 systems.
@@ -82,24 +85,25 @@ Upgrading a Replica Set
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 For replica sets running with authentication, (i.e. :option:`--keyFile
-<mongod --keyFile>`,) upgrade the entire set from a release of 2.0 to
-2.2.0 at once. Shut down all :program:`mongod` instances in the set
+<mongod --keyFile>`), upgrade the entire set to
+2.2 at once. Shut down all :program:`mongod` instances in the set
 cleanly, upgrade the binaries, and then restart all instances.
 
 The 2.2.1 release, will remove this "hard" upgrade requirement, see
 :issue:`SERVER-6897`.
 
-If your set does not run with authentication may perform a "rolling"
+If your set does not run with authentication, then to minimize downtime you may perform a "rolling"
 upgrade of the set by upgrading the members individually while the
-other members are available to minimize downtime. Use the following
+other members are available. Use the following
 procedure:
 
 #. Upgrade the :term:`secondary` members of the set one at a time by
    shutting down the :program:`mongod` and replacing the 2.0 binary
    with the 2.2 binary.  After upgrading a :program:`mongod` instance,
-   wait for the member to recover to ``SECONDARY`` state by checking
-   the output of :method:`rs.status()` in the :program:`mongo` shell
+   wait for the member to recover to ``SECONDARY`` state
    before upgrading the next instance.
+   To check the member's state, issue :method:`rs.status()` in the
+   :program:`mongo` shell.
 
 #. Use the :program:`mongo` shell method :method:`rs.stepDown()` to
    step down the :term:`primary` to allow the normal :ref:`failover
@@ -113,9 +117,9 @@ procedure:
    :program:`mongod` binary with the 2.2 binary and start the new
    process.
 
-   .. note:: Replica set failover is not instantaneous, but will
-      render the set unavailable to read and writes sent to the set
-      util failover process completes.  Typically this takes tens of
+   .. note:: Replica set failover is not instantaneous but will
+      render the set unavailable to read or accept writes
+      until the failover process completes. Typically this takes tens of
       seconds, so you may wish to plan the upgrade during a
       non-critical time of day.
 
@@ -144,7 +148,7 @@ Use the following procedure to upgrade a sharded cluster:
 
    Balancing is not currently supported in *mixed* 2.0.x and 2.2.0
    deployments. Thus you will want to reach a consistent version for all
-   shards within a reasonable period of time, e.g., same-day.
+   shards within a reasonable period of time, e.g. same-day.
    See :issue:`SERVER-6902` for more information.
 
 Changes