Backportapalooza 08 11

docs/docsite/rst/community/development_process.rst

@@ -45,7 +45,7 @@ Here's an overview of the PR lifecycle:
 * Contributor addresses any feedback from reviewers
 * Developers, maintainers, community re-review
 * PR merged or closed
-* PR `backported <backport_process>`_ to one or more ``stable-X.Y`` branches (optional, bugfixes only)
+* PR :ref:`backported <backport_process>` to one or more ``stable-X.Y`` branches (optional, bugfixes only)
 
 Automated PR review: ansibullbot
 --------------------------------
@@ -369,7 +369,7 @@ We do **not** backport features.
 .. code-block:: shell
 
        git fetch upstream
-       git checkout -b backport/2.12/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.13
+       git checkout -b backport/2.13/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.13
 
 #. Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary:
 

docs/docsite/rst/dev_guide/developing_collections_creating.rst

@@ -22,16 +22,18 @@ A user can then install your collection on their systems.
 Creating a collection skeleton
 ==============================
 
-To start a new collection:
+To start a new collection, run the following command in your collections directory:
 
 .. code-block:: bash
 
-    collection_dir#> ansible-galaxy collection init my_namespace.my_collection
+    ansible_collections#> ansible-galaxy collection init my_namespace.my_collection
 
 .. note::
 
 	Both the namespace and collection names use the same strict set of requirements. See `Galaxy namespaces <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_ on the Galaxy docsite for those requirements.
 
+It will create the structure ``[my_namespace]/[my_collection]/[collection skeleton]``.
+.. hint:: If Git is used for version control, the corresponding repository should be initialized in the collection directory.
 Once the skeleton exists, you can populate the directories with the content you want inside the collection. See `ansible-collections <https://github.com/ansible-collections/>`_ GitHub Org to get a better idea of what you can place inside a collection.
 
 Reference: the ``ansible-galaxy collection`` command

docs/docsite/rst/porting_guides/porting_guide_5.rst

@@ -46,7 +46,7 @@ Playbook
 Python Interpreter Discovery
 ============================
 
-The default value of ``INTERPRETER_PYTHON_FALLBACK`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``.
+The default value of ``INTERPRETER_PYTHON`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``.
 
 ``INTERPRETER_PYTHON_FALLBACK`` can be changed from the default list of interpreters by setting the ``ansible_interpreter_python_fallback`` variable.
 

docs/docsite/rst/porting_guides/porting_guide_core_2.12.rst

@@ -44,7 +44,7 @@ Playbook
 Python Interpreter Discovery
 ============================
 
-The default value of ``INTERPRETER_PYTHON_FALLBACK`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``.
+The default value of ``INTERPRETER_PYTHON`` changed to ``auto``. The list of Python interpreters in ``INTERPRETER_PYTHON_FALLBACK`` changed to prefer Python 3 over Python 2. The combination of these two changes means the new default behavior is to quietly prefer Python 3 over Python 2 on remote hosts. Previously a deprecation warning was issued in situations where interpreter discovery would have used Python 3 but the interpreter was set to ``/usr/bin/python``.
 
 ``INTERPRETER_PYTHON_FALLBACK`` can be changed from the default list of interpreters by setting the ``ansible_interpreter_python_fallback`` variable.