[docs][2.11][backport] Backportapalooza3

changelogs/fragments/cmd_wording.yml

@@ -0,0 +1,2 @@
+minor_changes:
+- command - update the user warning message to point out command name (https://github.com/ansible/ansible/pull/74475).

docs/docsite/rst/community/development_process.rst

@@ -22,8 +22,7 @@ If you want to follow the conversation about what features will be added to ``an
 * the :ref:`Ansible Release Schedule <release_and_maintenance>`
 * various GitHub `projects <https://github.com/ansible/ansible/projects>`_ - for example:
 
-   * the `2.10 release project <https://github.com/ansible/ansible/projects/39>`_
-   * the `network bugs project <https://github.com/ansible/ansible/projects/20>`_
+   * the `2.12 release project <https://github.com/ansible/ansible/projects/43>`_
    * the `core documentation project <https://github.com/ansible/ansible/projects/27>`_
 
 .. _community_pull_requests:
@@ -224,7 +223,7 @@ Here are some examples:
       remote_src=True even if mode was not set as a parameter.  This failed on
       filesystems which do not have permission bits (https://github.com/ansible/ansible/issues/29444).
 
-You can find more example changelog fragments in the `changelog directory <https://github.com/ansible/ansible/tree/stable-2.10/changelogs/fragments>`_ for the 2.10 release.
+You can find more example changelog fragments in the `changelog directory <https://github.com/ansible/ansible/tree/stable-2.11/changelogs/fragments>`_ for the 2.11 release.
 
 After you have written the changelog fragment for your PR, commit the file and include it with the pull request.
 
@@ -241,23 +240,18 @@ We do **not** backport features.
 
    These instructions assume that:
 
-    * ``stable-2.10`` is the targeted release branch for the backport
-    * ``https://github.com/ansible/ansible.git`` is configured as a
-      ``git remote`` named ``upstream``. If you do not use
-      a ``git remote`` named ``upstream``, adjust the instructions accordingly.
-    * ``https://github.com/<yourgithubaccount>/ansible.git``
-      is configured as a ``git remote`` named ``origin``. If you do not use
-      a ``git remote`` named ``origin``, adjust the instructions accordingly.
+    * ``stable-2.11`` is the targeted release branch for the backport
+    * ``https://github.com/ansible/ansible.git`` is configured as a ``git remote`` named ``upstream``. If you do not use a ``git remote`` named ``upstream``, adjust the instructions accordingly.
+    * ``https://github.com/<yourgithubaccount>/ansible.git`` is configured as a ``git remote`` named ``origin``. If you do not use a ``git remote`` named ``origin``, adjust the instructions accordingly.
 
 #. Prepare your devel, stable, and feature branches:
 
    ::
 
        git fetch upstream
-       git checkout -b backport/2.10/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.10
+       git checkout -b backport/2.11/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.11
 
-#. Cherry pick the relevant commit SHA from the devel branch into your feature
-   branch, handling merge conflicts as necessary:
+#. Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary:
 
    ::
 
@@ -269,27 +263,16 @@ We do **not** backport features.
 
    ::
 
-       git push origin backport/2.10/[PR_NUMBER_FROM_DEVEL]
+       git push origin backport/2.11/[PR_NUMBER_FROM_DEVEL]
 
-#. Submit the pull request for ``backport/2.10/[PR_NUMBER_FROM_DEVEL]``
-   against the ``stable-2.10`` branch
+#. Submit the pull request for ``backport/2.11/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.11`` branch
 
-#. The Release Manager will decide whether to merge the backport PR before
-   the next minor release. There isn't any need to follow up. Just ensure that the automated
-   tests (CI) are green.
+#. The Release Manager will decide whether to merge the backport PR before the next minor release. There isn't any need to follow up. Just ensure that the automated tests (CI) are green.
 
 .. note::
 
-    The choice to use ``backport/2.10/[PR_NUMBER_FROM_DEVEL]`` as the
-    name for the feature branch is somewhat arbitrary, but conveys meaning
-    about the purpose of that branch. It is not required to use this format,
-    but it can be helpful, especially when making multiple backport PRs for
-    multiple stable branches.
+    The branch name ``backport/2.11/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary, but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches.
 
 .. note::
 
-    If you prefer, you can use CPython's cherry-picker tool
-    (``pip install --user 'cherry-picker >= 1.3.2'``) to backport commits
-    from devel to stable branches in Ansible. Take a look at the `cherry-picker
-    documentation <https://pypi.org/p/cherry-picker#cherry-picking>`_ for
-    details on installing, configuring, and using it.
+    If you prefer, you can use CPython's cherry-picker tool (``pip install --user 'cherry-picker >= 1.3.2'``) to backport commits from devel to stable branches in Ansible. Take a look at the `cherry-picker documentation <https://pypi.org/p/cherry-picker#cherry-picking>`_ for details on installing, configuring, and using it.

docs/docsite/rst/dev_guide/platforms/aws_guidelines.rst

@@ -386,27 +386,18 @@ The combination of these two approaches is then:
            module.fail_json_aws(e, msg="Could not describe some resource")
 
 
-If the underlying ``describe_some_resources`` API call throws a ``ResourceNotFound``
-exception, ``AWSRetry`` takes this as a cue to retry until it's not thrown (this
-is so that when creating a resource, we can just retry until it exists).
-
-To handle authorization failures or parameter validation errors in
-``describe_some_resource_with_backoff``, where we just want to return ``None`` if
-the resource doesn't exist and not retry, we need:
+Prior to Ansible 2.10 if the underlying ``describe_some_resources`` API call threw
+a ``ResourceNotFound`` exception, ``AWSRetry`` would take this as a cue to retry until
+it is not thrown (this is so that when creating a resource, we can just retry until it
+exists).  This default was changed and it is now necessary to explicitly request
+this behaviour.  This can be done by using the ``catch_extra_error_codes``
+argument on the decorator.
 
 .. code-block:: python
 
-   @AWSRetry.exponential_backoff(retries=5, delay=5)
-   def describe_some_resource_with_backoff(client, **kwargs):
-        try:
-            return client.describe_some_resource(ResourceName=kwargs['name'])['Resources']
-        except botocore.exceptions.ClientError as e:
-            if e.response['Error']['Code'] == 'ResourceNotFound':
-                return None
-            else:
-                raise
-        except BotoCoreError as e:
-            raise
+   @AWSRetry.exponential_backoff(retries=5, delay=5, catch_extra_error_codes=['ResourceNotFound'])
+   def describe_some_resource_retry_missing(client, **kwargs):
+        return client.describe_some_resource(ResourceName=kwargs['name'])['Resources']
 
    def describe_some_resource(client, module):
        name = module.params.get['name']