diff --git a/docs/docsite/rst/community/development_process.rst b/docs/docsite/rst/community/development_process.rst index 1826f1012d..2fed1509c4 100644 --- a/docs/docsite/rst/community/development_process.rst +++ b/docs/docsite/rst/community/development_process.rst @@ -10,6 +10,12 @@ Road Maps The Ansible Core team provides a road map for each upcoming release. These road maps can be found `here `_. +.. Roadmaps are User-oriented. We should also list the Roadmap Projects and the Blocker Bug + Projects here + +.. How the actual release schedule, slipping, etc relates to (release_and_maintenance.rst) probably + also belongs here somewhere + Pull Requests ============= diff --git a/docs/docsite/rst/community/github_admins.rst b/docs/docsite/rst/community/github_admins.rst new file mode 100644 index 0000000000..537a7a7617 --- /dev/null +++ b/docs/docsite/rst/community/github_admins.rst @@ -0,0 +1,29 @@ +GitHub Admins +============= + +.. contents:: Topics + +GitHub Admins have more permissions on GitHub than normal contributors. There are +a few responsibilities that come with that increased power. + + +Add and Remove Committers +------------------------- + +The Ansible Team will periodically review who is actively contributing to Ansible to grant or revoke +contributors' ability to commit on their own. GitHub Admins are the people who have the power to +actually manage the GitHub permissions. + + +Change Branch Permissions for Release +------------------------------------- + +When we make releases we make people go through a :doc:`release_manager` to push commits to that +branch. The GitHub admins are responsible for setting the branch so only the Release Manager can +commit to the branch when the release process reaches that stage and later opening the branch once +the release has been made. The Release manager will let the GitHub Admin know when this needs to be +done. + +.. seealso:: The `GitHub Admin Process Docs + `_ for instructions + on how to change branch permissions. diff --git a/docs/docsite/rst/community/index.rst b/docs/docsite/rst/community/index.rst index 78ee69c201..726e104e3e 100644 --- a/docs/docsite/rst/community/index.rst +++ b/docs/docsite/rst/community/index.rst @@ -19,6 +19,7 @@ To get started, select one of the following topics. reporting_bugs_and_features how_can_I_help maintainers + release_managers communication other_tools_and_programs diff --git a/docs/docsite/rst/community/release_managers.rst b/docs/docsite/rst/community/release_managers.rst new file mode 100644 index 0000000000..6f4b5c7d17 --- /dev/null +++ b/docs/docsite/rst/community/release_managers.rst @@ -0,0 +1,80 @@ +Release Managers +================ + +.. contents:: Topics + +The release manager's purpose is to ensure a smooth release. To achieve that goal, they need to +coordinate between: + +* Developers with Commit privileges on the `Ansible github repository `_ +* Contributors without commit privileges +* The community +* Ansible documentation team +* Ansible Tower team + + +Pre-releases: What and Why +-------------------------- + +Pre-releases exist to draw testers. They give people who don't feel comfortable running from source +control a means to get an early version of the code to test and give us feedback. To ensure we get +good feedback about a release, we need to make sure all major changes in a release are put into +a pre-release. Testers must be given time to test those changes before the final release. Ideally we +want there to be sufficient time between pre-releases for people to install and test one version for +a span of time. Then they can spend more time using the new code than installing the latest +version. + +The right length of time for a tester is probably around two weeks. However, for our three-to-four month +development cycle to work, we compress this down to one week; any less runs the risk +of people spending more time installing the code instead of running it. However, if there's a time +crunch (with a release date that cannot slip), it is better to release with new changes than to hold +back those changes to give people time to test between. People cannot test what is not released, so +we have to get those tarballs out there even if people feel they have to install more frequently. + + +What is Beta? +~~~~~~~~~~~~~ + +In a Beta release, we know there are still bugs. We will continue to accept fixes for these. +Although we review these fixes, sometimes they can be invasive or potentially destabilize other +areas of the code. + +During the beta, we will no longer accept feature submissions. + + +What is a Release Candidate? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In a release candidate, we've fixed all known blockers. Any remaining bugfixes are +ones that we are willing to leave out of the release. At this point we need user testing to +determine if there are any other blocker bugs lurking. + +Blocker bugs generally are those that cause significant problems for users. Regressions are +more likely to be considered blockers because they will break present users' usage of Ansible. + +The Release Manager will cherry-pick fixes for new release blockers. The release manager will also +choose whether to accept bugfixes for isolated areas of the code or defer those to the next minor +release. By themselves, non-blocker bugs will not trigger a new release; they will only make it +into the next major release if blocker bugs require that a new release be made. + +The last RC should be as close to the final as possible. The following things may be changed: + + * Version numbers are changed automatically and will differ as the pre-release tags are removed from + the versions. + * Tests and :file:`docs/docsite/` can differ if really needed as they do not break runtime. + However, the release manager may still reject them as they have the potential to cause + breakage that will be visible during the release process. + +.. note:: We want to specifically emphasize that code (in :file:`bin/`, :file:`lib/ansible/`, and + :file:`setup.py`) must be the same unless there are extraordinary extenuating circumstances. If + there are extenuating circumstances, the Release Manager is responsible for notifying groups + (like the Tower Team) which would want to test the code. + + +Release Process +=============== + +The release process is kept in a `separate document +`_ +so that it can be easily updated during a release. If you need access to edit this, please ask one +of the current release managers to add you.