From 166e84b9c4fe63dd5ec4cec5f2dad5b24b9bc26e Mon Sep 17 00:00:00 2001 From: John R Barker Date: Sun, 28 Oct 2018 21:40:39 +0000 Subject: [PATCH] Docs: No need to follow up on backport PRs (#47616) Also tidy up `notes` section into a single box --- .../rst/community/development_process.rst | 38 ++++++++++--------- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/docs/docsite/rst/community/development_process.rst b/docs/docsite/rst/community/development_process.rst index 1942f05965..b3c716ee26 100644 --- a/docs/docsite/rst/community/development_process.rst +++ b/docs/docsite/rst/community/development_process.rst @@ -4,7 +4,8 @@ The Ansible Development Process ******************************* -.. contents:: Topics +.. contents:: + :local: This section discusses how the Ansible development and triage process works. @@ -33,29 +34,26 @@ After the pull request submitted to Ansible for the ``devel`` branch is accepted and merged, the following instructions will help you create a pull request to backport the change to a previous stable branch. -.. note:: - - These instructions assume that ``stable-2.5`` is the targeted release - branch for the backport. +We do **not** backport features. .. note:: - These instructions assume that ``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. + These instructions assume that: -.. note:: - - These instructions assume that ``https://github.com//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.7`` 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//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.5/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.5 + git checkout -b backport/2.7/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.7 #. Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary: @@ -70,14 +68,18 @@ pull request to backport the change to a previous stable branch. :: - git push origin backport/2.5/[PR_NUMBER_FROM_DEVEL] + git push origin backport/2.7/[PR_NUMBER_FROM_DEVEL] -#. Submit the pull request for ``backport/2.5/[PR_NUMBER_FROM_DEVEL]`` - against the ``stable-2.5`` branch +#. Submit the pull request for ``backport/2.7/[PR_NUMBER_FROM_DEVEL]`` + against the ``stable-2.7`` 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. .. note:: - The choice to use ``backport/2.5/[PR_NUMBER_FROM_DEVEL]`` as the + The choice to use ``backport/2.7/[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