"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "docs/docsite/rst/community/development_process.rst" between
ansible-2.14.0.tar.gz and ansible-2.14.1rc1.tar.gz

About: Ansible is an IT Configuration Management, Deployment & Orchestration tool.
Release candidate.

development_process.rst  (ansible-2.14.0):development_process.rst  (ansible-2.14.1rc1)
skipping to change at line 26 skipping to change at line 26
Macro development: ``ansible-core`` roadmaps, releases, and projects Macro development: ``ansible-core`` roadmaps, releases, and projects
===================================================================== =====================================================================
If you want to follow the conversation about what features will be added to ``an sible-core`` for upcoming releases and what bugs are being fixed, you can watch these resources: If you want to follow the conversation about what features will be added to ``an sible-core`` for upcoming releases and what bugs are being fixed, you can watch these resources:
* the :ref:`roadmaps` * the :ref:`roadmaps`
* the :ref:`Ansible Release Schedule <release_and_maintenance>` * the :ref:`Ansible Release Schedule <release_and_maintenance>`
* the :ref:`ansible-core project branches and tags <core_branches_and_tags>` * the :ref:`ansible-core project branches and tags <core_branches_and_tags>`
* various GitHub `projects <https://github.com/ansible/ansible/projects>`_ - for example: * various GitHub `projects <https://github.com/ansible/ansible/projects>`_ - for example:
* the `2.12 release project <https://github.com/ansible/ansible/projects/43>` * the `2.15 release project <https://github.com/ansible/ansible/projects/46>`
_ _
* the `core documentation project <https://github.com/ansible/ansible/project * the `core documentation project <https://github.com/orgs/ansible/projects/9
s/27>`_ 4/views/1>`_
.. _community_pull_requests: .. _community_pull_requests:
Micro development: the lifecycle of a PR Micro development: the lifecycle of a PR
======================================== ========================================
If you want to contribute a feature or fix a bug in ``ansible-core`` or in a col lection, you must open a **pull request** ("PR" for short). GitHub provides a gr eat overview of `how the pull request process works <https://help.github.com/art icles/about-pull-requests/>`_ in general. The ultimate goal of any pull request is to get merged and become part of a collection or ``ansible-core``. If you want to contribute a feature or fix a bug in ``ansible-core`` or in a col lection, you must open a **pull request** ("PR" for short). GitHub provides a gr eat overview of `how the pull request process works <https://help.github.com/art icles/about-pull-requests/>`_ in general. The ultimate goal of any pull request is to get merged and become part of a collection or ``ansible-core``.
Here's an overview of the PR lifecycle: Here's an overview of the PR lifecycle:
* Contributor opens a PR (always against the ``devel`` branch) * Contributor opens a PR (always against the ``devel`` branch)
skipping to change at line 318 skipping to change at line 318
=========================================== ===========================================
All ``ansible-core`` PRs must be merged to the ``devel`` branch first. After a p ull request has been accepted and merged to the ``devel`` branch, the following instructions will help you create a pull request to backport the change to a pre vious stable branch. All ``ansible-core`` PRs must be merged to the ``devel`` branch first. After a p ull request has been accepted and merged to the ``devel`` branch, the following instructions will help you create a pull request to backport the change to a pre vious stable branch.
We do **not** backport features. We do **not** backport features.
.. note:: .. note::
These instructions assume that: These instructions assume that:
* ``stable-2.13`` is the targeted release branch for the backport * ``stable-2.14`` 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``, ad just the instructions accordingly. * ``https://github.com/ansible/ansible.git`` is configured as a ``git remote `` named ``upstream``. If you do not use a ``git remote`` named ``upstream``, ad just 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 ``orig in``, 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 ``orig in``, adjust the instructions accordingly.
#. Prepare your devel, stable, and feature branches: #. Prepare your devel, stable, and feature branches:
.. code-block:: shell .. code-block:: shell
git fetch upstream git fetch upstream
git checkout -b backport/2.13/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.13 git checkout -b backport/2.14/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.14
#. Cherry pick the relevant commit SHA from the devel branch into your feature b ranch, handling merge conflicts as necessary: #. Cherry pick the relevant commit SHA from the devel branch into your feature b ranch, handling merge conflicts as necessary:
.. code-block:: shell .. code-block:: shell
git cherry-pick -x [SHA_FROM_DEVEL] git cherry-pick -x [SHA_FROM_DEVEL]
#. Add a :ref:`changelog fragment <changelogs_how_to>` for the change, and commi t it. #. Add a :ref:`changelog fragment <changelogs_how_to>` for the change, and commi t it.
#. Push your feature branch to your fork on GitHub: #. Push your feature branch to your fork on GitHub:
.. code-block:: shell .. code-block:: shell
git push origin backport/2.13/[PR_NUMBER_FROM_DEVEL] git push origin backport/2.14/[PR_NUMBER_FROM_DEVEL]
#. Submit the pull request for ``backport/2.13/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.13`` branch #. Submit the pull request for ``backport/2.14/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.14`` branch
#. The Release Manager will decide whether to merge the backport PR before the n ext minor release. There isn't any need to follow up. Just ensure that the autom ated tests (CI) are green. #. The Release Manager will decide whether to merge the backport PR before the n ext minor release. There isn't any need to follow up. Just ensure that the autom ated tests (CI) are green.
.. note:: .. note::
The branch name ``backport/2.13/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitra ry 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. The branch name ``backport/2.14/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitra ry 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:: .. note::
If you prefer, you can use CPython's cherry-picker tool (``pip install --use r '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 usin g it. If you prefer, you can use CPython's cherry-picker tool (``pip install --use r '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 usin g it.
 End of changes. 6 change blocks. 
9 lines changed or deleted 9 lines changed or added

Home  |  About  |  Features  |  All  |  Newest  |  Dox  |  Diffs  |  RSS Feeds  |  Screenshots  |  Comments  |  Imprint  |  Privacy  |  HTTP(S)