cmueller/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Docs: No need to follow up on backport PRs (#47616)

Browse source 
Also tidy up `notes` section into a single box
This commit is contained in:
John R Barker 2018-10-28 21:40:39 +00:00 committed by Alicia Cozine
parent 6229f89369
commit 166e84b9c4
1 changed files with 20 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

38
docs/docsite/rst/community/development_process.rst
View file

@ -4,7 +4,8 @@
The Ansible Development Process The Ansible Development Process
******************************* *******************************
.. contents:: Topics .. contents::
:local:
This section discusses how the Ansible development and triage process works. 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 accepted and merged, the following instructions will help you create a
pull request to backport the change to a previous stable branch. pull request to backport the change to a previous stable branch.
.. note:: We do **not** backport features.
These instructions assume that ``stable-2.5`` is the targeted release
branch for the backport.
.. note:: .. note::
These instructions assume that ``https://github.com/ansible/ansible.git`` These instructions assume that:
is configured as a ``git remote`` named ``upstream``. If you do not use
a ``git remote`` named ``upstream``, adjust the instructions accordingly.
.. note:: * ``stable-2.7`` is the targeted release branch for the backport
* ``https://github.com/ansible/ansible.git`` is configured as a
These instructions assume that ``https://github.com/<yourgithubaccount>/ansible.git`` ``git remote`` named ``upstream``. If you do not use
is configured as a ``git remote`` named ``origin``. If you do not use a ``git remote`` named ``upstream``, adjust the instructions accordingly.
a ``git remote`` named ``origin``, 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: #. Prepare your devel, stable, and feature branches:
:: ::
git fetch upstream 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 #. Cherry pick the relevant commit SHA from the devel branch into your feature
branch, handling merge conflicts as necessary: 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]`` #. Submit the pull request for ``backport/2.7/[PR_NUMBER_FROM_DEVEL]``
against the ``stable-2.5`` branch 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:: .. 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 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, 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 but it can be helpful, especially when making multiple backport PRs for