* docs - adapted abadger's changelog announcement email into dev process
Signed-off-by: Adam Miller <admiller@redhat.com>
* migrate changelog docs to one place, add ref to old location
Signed-off-by: Adam Miller <admiller@redhat.com>
* add changes based on feedback
Signed-off-by: Adam Miller <admiller@redhat.com>
* Refines changelog docs, minor re-org of page
* moves links and anchors for new content
* Further reorg of page
* fixes header per jamescassell
The Ansible development cycle happens on two levels. At a macro level, the team plans releases and tracks progress with roadmaps and projects. At a micro level, each PR has its own lifecycle.
..contents::
:local:
This section discusses how the Ansible development and triage process works.
Road Maps
=========
Macro development: roadmaps, releases, and projects
The Ansible Core team provides a road map for each upcoming release. These road maps can be found :ref:`here <roadmaps>`.
If you want to follow the conversation about what features will be added to Ansible for upcoming releases and what bugs are being fixed, you can watch these resources:
.. Roadmaps are User-oriented. We should also list the Roadmap Projects and the Blocker Bug
Projects here
* the :ref:`roadmaps`
* the :ref:`Ansible Release Schedule <release_and_maintenance>`
* various GitHub `projects <https://github.com/ansible/ansible/projects>`_ - for example:
.. How the actual release schedule, slipping, etc relates to (release_and_maintenance.rst) probably
also belongs here somewhere
* the `2.8 release project <https://github.com/ansible/ansible/projects/30>`_
* the `network bugs project <https://github.com/ansible/ansible/projects/20>`_
* the `core documentation project <https://github.com/ansible/ansible/projects/27>`_
.._community_pull_requests:
Pull Requests
=============
Ansible accepts code via **pull requests** ("PRs" for short). GitHub provides a great overview of `how the pull request process works <https://help.github.com/articles/about-pull-requests/>`_ in general.
Because Ansible receives many pull requests, we use an automated process to help us through the process of reviewing and merging pull requests. That process is managed by **Ansibullbot**.
Backport Pull Request Process
-----------------------------
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.
We do **not** backport features.
..note::
These instructions assume that:
* ``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.
#. Submit the pull request for ``backport/2.7/[PR_NUMBER_FROM_DEVEL]``
against the ``stable-2.7`` branch
Micro development: the lifecycle of a PR
========================================
#. 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.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
multiple stable branches.
..note::
If you prefer, you can use CPython's cherry-picker tool 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.
Ansible accepts code via **pull requests** ("PRs" for short). GitHub provides a great overview of `how the pull request process works <https://help.github.com/articles/about-pull-requests/>`_ in general. The ultimate goal of any pull request is to get merged and become part of Ansible Core.
Here's an overview of the PR lifecycle:
* Contributor opens a PR
* Ansibot reviews the PR
* Ansibot assigns labels
* Ansibot pings maintainers
* Shippable runs the test suite
* Developers, maintainers, community review the PR
* Contributor addresses any feedback from reviewers
* Developers, maintainers, community re-review
* PR merged or closed
Ansibullbot
===========
Automated PR review: ansibullbot
--------------------------------
Overview
--------
Because Ansible receives many pull requests, and because we love automating things, we've automated several steps of the process of reviewing and merging pull requests with a tool called Ansibullbot, or Ansibot for short.
`Ansibullbot`_ serves many functions:
`Ansibullbot <https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md>`_ serves many functions:
- Responds quickly to PR submitters to thank them for submitting their PR
- Identifies the community maintainer responsible for reviewing PRs for any files affected
@ -111,24 +55,8 @@ Overview
- Identifies PRs abandoned by their submitters so that we can close them
- Identifies modules abandoned by their maintainers so that we can find new maintainers
Community Maintainers
---------------------
Each module has at least one assigned maintainer, listed in a `maintainer's file`_:
Some modules have no community maintainers assigned. In this case, the maintainer is listed as ``$team_ansible``. Ultimately, it's our goal to have at least one community maintainer for every module.
The maintainer's job is to review PRs and decide whether that PR should be merged (``shipit``) or revised (``needs_revision``).
The ultimate goal of any pull request is to reach **shipit** status, where the Core team then decides whether the PR is ready to be merged. Not every PR that reaches the **shipit** label is actually ready to be merged, but the better our reviewers are, and the better our guidelines are, the more likely it will be that a PR that reaches **shipit** will be mergeable.
Workflow
--------
Ansibot workflow
^^^^^^^^^^^^^^^^
Ansibullbot runs continuously. You can generally expect to see changes to your issue or pull request within thirty minutes. Ansibullbot examines every open pull request in the repositories, and enforces state roughly according to the following workflow:
@ -151,16 +79,15 @@ Ansibullbot runs continuously. You can generally expect to see changes to your i
- The reviewer is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending_action**, and then may be reassigned to ``$team_ansible`` or labeled **core_review**, or often the submitter of the pull request is asked to step up as a maintainer.
- If Shippable tests fail, or if the code is not able to be merged, the pull request is automatically put into **needs_revision** along with a message to the submitter explaining why.
There are corner cases and frequent refinements, but this is the workflow in general.
PR Labels
---------
PR labels
^^^^^^^^^
There are two types of PR Labels generally: *workflow labels* and *information labels*.
There are two types of PR Labels generally: **workflow** labels and **information** labels.
Workflow Labels
~~~~~~~~~~~~~~~
Workflow labels
"""""""""""""""
- **community_review**: Pull requests for modules that are currently awaiting review by their maintainers in the Ansible community.
- **core_review**: Pull requests for modules that are currently awaiting review by their maintainers on the Ansible Core team.
@ -169,8 +96,8 @@ Workflow Labels
- **needs_revision**: Waiting on the submitter to make changes.
- **shipit**: Waiting for final review by the core team for potential merge.
Informational Labels
~~~~~~~~~~~~~~~~~~~~
Information labels
""""""""""""""""""
- **backport**: this is applied automatically if the PR is requested against any branch that is not devel. The bot immediately assigns the labels backport and ``core_review``.
- **bugfix_pull_request**: applied by the bot based on the templatized description of the PR.
@ -184,8 +111,167 @@ Informational Labels
Special Labels
~~~~~~~~~~~~~~
""""""""""""""
- **new_plugin**: this is for new modules or plugins that are not yet in Ansible.
**Note:**`new_plugin` kicks off a completely separate process, and frankly it doesn't work very well at present. We're working our best to improve this process.
**Note:**`new_plugin` kicks off a completely separate process, and frankly it doesn't work very well at present. We're working our best to improve this process.
Human PR review
---------------
After Ansibot reviews the PR and applies labels, the PR is ready for human review. The most likely reviewers for any PR are the maintainers for the module that PR modifies.
Each module has at least one assigned :ref:`maintainer <maintainers>`, listed in the `BOTMETA.yml <https://github.com/ansible/ansible/blob/devel/.github/BOTMETA.yml>`_ file.
The maintainer's job is to review PRs that affect that module and decide whether they should be merged (``shipit``) or revised (``needs_revision``). We'd like to have at least one community maintainer for every module. If a module has no community maintainers assigned, the maintainer is listed as ``$team_ansible``.
Once a human applies the ``shipit`` label, the :ref:`committers <community_committer_guidelines>` decide whether the PR is ready to be merged. Not every PR that gets the ``shipit`` label is actually ready to be merged, but the better our reviewers are, and the better our guidelines are, the more likely it will be that a PR that reaches **shipit** will be mergeable.
Making your PR merge-worthy
===========================
We don't merge every PR. Here are some tips for making your PR useful, attractive, and merge-worthy.
.._community_changelogs:
Changelogs
----------
Changelogs help users and developers keep up with changes to Ansible.
Ansible builds a changelog for each release from fragments. You **must** add a changelog fragment to any PR that changes functionality or fixes a bug.
You don't have to add a changelog fragment for PRs that add new
modules and plugins, because our tooling does that for you automatically.
We build short summary changelogs for minor releases as well as for major releases. If you backport a bugfix, include a changelog fragment with the backport PR.
.._changelogs_how_to:
Creating a changelog fragment
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A basic changelog fragment is a ``.yaml`` file placed in the
``changelogs/fragments/`` directory. Each file contains a yaml dict with
keys like ``bugfixes`` or ``major_changes`` followed by a list of
changelog entries of bugfixes or features. Each changelog entry is
rst embedded inside of the yaml file which means that certain
constructs would need to be escaped so they can be interpreted by rst
and not by yaml (or escaped for both yaml and rst if that's your
desire). Each PR **must** use a new fragment file rather than adding to
an existing one, so we can trace the change back to the PR that introduced it.
To create a changelog entry, create a new file with a unique name in the ``changelogs/fragments/`` directory. The file name should include the PR number and a description of the change. It must end with the file extension ``.yaml``. For example: ``40696-user-backup-shadow-file.yaml``
A single changelog fragment may contain multiple sections but most will only contain one section.
The toplevel keys (bugfixes, major_changes, etc) are defined in the
`config file <https://github.com/ansible/ansible/blob/devel/changelogs/config.yaml>` for our release note tool. Here are the valid sections and a description of each:
**major_changes**
Major changes to Ansible itself. Generally does not include module or plugin changes.
**minor_changes**
Minor changes to Ansible, modules, or plugins. This includes new features, new parameters added to modules, or behavior changes to existing parameters.
**deprecated_features**
Features that have been deprecated and are scheduled for removal in a future release.
**removed_features**
Features that were previously deprecated and are now removed.
**bugfixes**
Fixes that resolve issues. If there is a specific issue related to this bugfix, add a link in the changelog entry.
**known_issues**
Known issues that are currently not fixed or will not be fixed.
Most changelog entries will be ``bugfixes`` or ``minor_changes``. When writing a changelog entry that pertains to a particular module, start the entry with ``- [module name] -`` and include a link to the related issue if one exists.
Here are some examples:
..code-block:: yaml
bugfixes:
- win_updates - fixed issue where running win_updates on async fails without any error
..code-block:: yaml
minor_changes:
- lineinfile - add warning when using an empty regexp (https://github.com/ansible/ansible/issues/29443)
..code-block:: yaml
bugfixes:
- copy module - The copy module was attempting to change the mode of files for
remote_src=True even if mode was not set as a parameter. This failed on
filesystems which do not have permission bits.
You can find more example changelog fragments in the `changelog directory <https://github.com/ansible/ansible/tree/stable-2.6/changelogs/fragments>`_ for the 2.6 release. You can also find documentation of the format, including hints on embedding rst in the yaml, in the `reno documentation <https://docs.openstack.org/reno/latest/user/usage.html#editing-a-release-note>`_.
Once you've written the changelog fragment for your PR, commit the file and include it with the pull request.
Backporting merged PRs
======================
All Ansible PRs must be merged to the ``devel`` branch first.
After a pull 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 previous stable branch.
We do **not** backport features.
..note::
These instructions assume that:
* ``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.
@ -96,54 +96,16 @@ releases of Ansible, there can sometimes be exceptions for critical issues.
.._GitHub: https://github.com/ansible/ansible
.._changelogs_how_to:
.._release_changelogs:
Changelogs
~~~~~~~~~~~~~~~~~~
~~~~~~~~~~
Older versions logged changes in ``stable-<version>`` branches at ``stable-<version>/CHANGELOG.md``. For example, here is the changelog for 2.4_ on GitHub.
We now generate changelogs based on fragments. Here is the generated changelog for 2.6_ as an example. When creating new features or fixing bugs, create a changelog fragment describing the change. A changelog entry is not needed for new modules or plugins. Details for those items will be generated from the module documentation.
Creating New Fragments
----------------------
Create a new file with a unique and descriptive name in ``changelogs/fragments/`` that ends in ``.yaml`` such as ``user-40696-backup-shadow-file.yaml``
A single changelog fragment may contain multiple sections but most will only contain one section. Here are the valid sections and a description of each:
**major_changes**
Major changes to Ansible itself. Generally does not include module or plugin changes.
**minor_changes**
Minor changes to Ansible, modules, or plugins. This includes new features, new parameters added to modules, or behavior changes to existing parameters.
**deprecated_features**
Features that have been deprecated and are scheduled for removal in a future release.
**removed_features**
Features that were previously deprecated and are now removed.
**bugfixes**
Fixes that resolve issues. If there is a specific issue related to this bugfix, add a link in the changelog entry.
**known_issues**
Known issues that are currently not fixed or will not be fixed.
Most changelog entries will be ``bugfixes`` or ``minor_changes``. When writing a changelog entry that pertains to a particular module, start the entry with ``- [module name] -`` and include a link to the related issue if one exists. Here are some examples:
..code-block:: yaml
bugfixes:
- win_updates - fixed issue where running win_updates on async fails without any error
..code-block:: yaml
minor_changes:
- lineinfile - add warning when using an empty regexp (https://github.com/ansible/ansible/issues/29443)
Commit the changelog fragment and include it with the pull request.
We've got :ref:`examples and instructions on creating changelog fragments <changelogs_how_to>` in the Community Guide.
Adam Miller
6 years ago
committed by