Merge pull request #54045 from petr-muller/fixup-typos-in-update-docs

Fix typos in updating documentation

Author: jldohmann

modules/understanding-upgrade-channels.adoc

@@ -62,7 +62,7 @@ You can imagine seeing the following releases in your channel:
 * {product-version}.3
 * {product-version}.4
 
-The service recommends only updates that have been tested and have no known serious regressions. For example, if your cluster is on {product-version}.1 and {product-title} suggests {product-version}.4, then it is recommended to update from {product-version}.1 to {product-version}.4. 
+The service recommends only updates that have been tested and have no known serious regressions. For example, if your cluster is on {product-version}.1 and {product-title} suggests {product-version}.4, then it is recommended to update from {product-version}.1 to {product-version}.4.
 
 [IMPORTANT]
 ====
@@ -91,7 +91,7 @@ First, select the minor version you want for your cluster upgrade. Selecting a c
 Due to the complexity involved in planning upgrades between versions many minors apart, channels that assist in planning upgrades beyond a single EUS-to-EUS update are not offered.
 ====
 
-Second, you should choose your desired rollout strategy. You may choose to update as soon as Red Hat declares a release GA by selecting from fast channels or you may want to wait for Red Hat to promote releases to the stable channel. Update recommendations offered in the `fast-{product-version}` and `stable-{product-version}` are both fully supported and benefit equally from ongoing data analysis. The promotion delay before promoting release to the stable channel represets the only difference between the two channels. Updates to the latest z-streams are generally promoted to the stable channel within a week or two, however the delay when initially rolling out updates to the latest minor is much longer, generally 45-90 days. Please consider the promotion delay when choosing your desired channel as waiting for promotion to the stable channel may affect your scheduling plans.
+Second, you should choose your desired rollout strategy. You may choose to update as soon as Red Hat declares a release GA by selecting from fast channels or you may want to wait for Red Hat to promote releases to the stable channel. Update recommendations offered in the `fast-{product-version}` and `stable-{product-version}` are both fully supported and benefit equally from ongoing data analysis. The promotion delay before promoting release to the stable channel represents the only difference between the two channels. Updates to the latest z-streams are generally promoted to the stable channel within a week or two, however the delay when initially rolling out updates to the latest minor is much longer, generally 45-90 days. Please consider the promotion delay when choosing your desired channel as waiting for promotion to the stable channel may affect your scheduling plans.
 
 Additionally, there are several factors which may lead an organization to move clusters to the fast channel either permanently or temporarily including: