Merge "Move release team ladder & infra into proper page"
This commit is contained in:
commit
26f9e1990d
131
CONTRIBUTING.rst
131
CONTRIBUTING.rst
|
@ -1,126 +1,17 @@
|
||||||
======================================
|
If you would like to contribute to the development of OpenStack, you must
|
||||||
Release management contribution ladder
|
follow the steps in this page:
|
||||||
======================================
|
|
||||||
|
|
||||||
Getting involved with release management can feel a bit overwhelming.
|
https://docs.openstack.org/infra/manual/developers.html
|
||||||
To set expectations reasonably, we define 4 levels of engagement.
|
|
||||||
|
|
||||||
Stage 0 - Review release requests
|
If you already have a good understanding of how the system works and your
|
||||||
=================================
|
OpenStack accounts are set up, you can skip to the development workflow
|
||||||
|
section of this documentation to learn how changes to OpenStack should be
|
||||||
|
submitted for review via the Gerrit tool:
|
||||||
|
|
||||||
This stage does not require any special rights. You should just review
|
https://docs.openstack.org/infra/manual/developers.html#development-workflow
|
||||||
release requests (modifications of files in deliverables/ directory in
|
|
||||||
the releases repository), apply the release review rules and vote.
|
|
||||||
|
|
||||||
Release review guidelines
|
Pull requests submitted through GitHub will be ignored.
|
||||||
-------------------------
|
|
||||||
|
|
||||||
Three test jobs run for every release request:
|
See the release team documentation at:
|
||||||
|
|
||||||
* openstack-tox-validate checks for proper yaml format and schema validation
|
|
||||||
and checks for things like proper job types and valid release note links
|
|
||||||
|
|
||||||
* releases-tox-list-changes finds included commits, lists PTL and release
|
|
||||||
liaison, requirements changes, and open reviews for docs and release notes
|
|
||||||
|
|
||||||
* build-openstack-sphinx-docs performs a build of the releases website and
|
|
||||||
checks for errors.
|
|
||||||
|
|
||||||
You should:
|
|
||||||
|
|
||||||
* check that the version bump matches semver rules. In particular, a .Z bump
|
|
||||||
means only bugfixes should be listed in list-changes.
|
|
||||||
|
|
||||||
* check the output of the test jobs.
|
|
||||||
|
|
||||||
* Place your vote based on whether you think the request should be accepted
|
|
||||||
as-is or not.
|
|
||||||
|
|
||||||
|
|
||||||
Stage 1 - Approving release requests
|
|
||||||
====================================
|
|
||||||
|
|
||||||
At this stage you will be trusted with CodeReview+2 and Workflow+1 votes
|
|
||||||
on the releases repository, giving you the ability to trigger releases.
|
|
||||||
You will need a base understanding of the release machinery, and know
|
|
||||||
to refrain from approving when unsure.
|
|
||||||
|
|
||||||
Release infrastructure primer
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
What happens when a release is approved? Release infrastructure is divided
|
|
||||||
into two steps, triggered by different, but related events.
|
|
||||||
|
|
||||||
The first step is triggered by the release request being merged into the
|
|
||||||
releases repository, starting a series of jobs in the "post" pipeline
|
|
||||||
of the releases repository:
|
|
||||||
|
|
||||||
Release request merged
|
|
||||||
|
|
|
||||||
+-------v-----------------------+
|
|
||||||
Post pipeline (releases repo)
|
|
||||||
+---+-----------------------+---+
|
|
||||||
| |
|
|
||||||
v v
|
|
||||||
+-------+-------+ +-------+-------+
|
|
||||||
| tag | | publish-docs |
|
|
||||||
| | | |
|
|
||||||
| (pushes tags | | (to releases |
|
|
||||||
| to each repo) | | website) |
|
|
||||||
| | | |
|
|
||||||
+-------+-------+ +---------------+
|
|
||||||
|
|
||||||
The second step is triggered by the creation of the tag, creating a series
|
|
||||||
of jobs in the "tag" pipeline and the "release" pipeline (or "pre-release"
|
|
||||||
pipeline, in case of beta versions) of the repository the tag landed in:
|
|
||||||
|
|
||||||
Tag is created -----------------------------------------------
|
|
||||||
| |
|
|
||||||
+----v------------------------------------+ +----------v-----------+
|
|
||||||
Release pipeline (each repo) Tag pipeline (each repo)
|
|
||||||
+----+---------------+---------------+----+ +----------------------+
|
|
||||||
| | | |
|
|
||||||
v v v v
|
|
||||||
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
|
|
||||||
| release | | announce | | propose | | publish |
|
|
||||||
| | | | |constraints| | release |
|
|
||||||
|(builds | | (sends | | update | | notes |
|
|
||||||
| tarball | | email) | | | | |
|
|
||||||
| & uploads | | | +-----------+ +-----------+
|
|
||||||
| it) | +-----------+
|
|
||||||
+-----------+
|
|
||||||
|
|
||||||
Note that a single release request can create multiple tags in different
|
|
||||||
repositories, triggering that second stage in multiple repositories.
|
|
||||||
|
|
||||||
Jobs in the release pipeline need information from the release request
|
|
||||||
(like series name, or whether to upload to pypi). We use metadata in the
|
|
||||||
git tag itself to pass that information: the "tag" job in step 1 records
|
|
||||||
the information in the tag, and the jobs in step 2 retrieve that information
|
|
||||||
directly from the tag.
|
|
||||||
|
|
||||||
|
|
||||||
Checklist before approving a release
|
|
||||||
-------------------------------------
|
|
||||||
|
|
||||||
* You should only approve release requests.
|
|
||||||
* You should check that release is approved by PTL or release liaison
|
|
||||||
* You should check that infrastructure is not currently experiencing issues
|
|
||||||
* You should check that we are not in any freeze period
|
|
||||||
* If unsure, it is better to wait for a second opinion that to press
|
|
||||||
Workflow+1 directly.
|
|
||||||
|
|
||||||
|
|
||||||
Stage 2 - Knowing the release cycle process
|
|
||||||
===========================================
|
|
||||||
|
|
||||||
At this stage you will be able to help drive the release cycle process,
|
|
||||||
send reminder emails and answer questions from release liaisons.
|
|
||||||
|
|
||||||
|
|
||||||
Stage 3 - Understanding the Release Automation Infrastructure
|
|
||||||
=============================================================
|
|
||||||
|
|
||||||
At this stage you will be able to debug complex release infrastructure
|
|
||||||
failures, and review/approve release tooling changes.
|
|
||||||
|
|
||||||
|
https://releases.openstack.org/#documentation
|
||||||
|
|
|
@ -174,7 +174,9 @@ documentation:
|
||||||
reference/using
|
reference/using
|
||||||
reference/release_models
|
reference/release_models
|
||||||
reference/deliverable_types
|
reference/deliverable_types
|
||||||
|
reference/join_release_team
|
||||||
reference/reviewer_guide
|
reference/reviewer_guide
|
||||||
|
reference/release_infra
|
||||||
reference/process
|
reference/process
|
||||||
|
|
||||||
.. _`openstack/releases`: https://opendev.org/openstack/releases
|
.. _`openstack/releases`: https://opendev.org/openstack/releases
|
||||||
|
|
|
@ -0,0 +1,61 @@
|
||||||
|
======================
|
||||||
|
Join the release team!
|
||||||
|
======================
|
||||||
|
|
||||||
|
Communication channels
|
||||||
|
======================
|
||||||
|
|
||||||
|
The release team communicates and meets on the `#openstack-release`_ channel
|
||||||
|
on OFTC IRC, on the `openstack-discuss mailing-list`_ using the [release]
|
||||||
|
subject prefix.
|
||||||
|
|
||||||
|
.. _`#openstack-release`: https://webchat.oftc.net/?channels=openstack-release
|
||||||
|
|
||||||
|
.. _`openstack-discuss mailing-list`: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
|
||||||
|
|
||||||
|
The engagement ladder
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Getting involved with release management can feel a bit overwhelming.
|
||||||
|
To set expectations reasonably, we define 4 levels of engagement.
|
||||||
|
|
||||||
|
Stage 0 - Review release requests
|
||||||
|
---------------------------------
|
||||||
|
|
||||||
|
This stage does not require any special rights. You should just review
|
||||||
|
release requests (modifications of files in deliverables/ directory in
|
||||||
|
the releases repository), apply the release review rules and vote.
|
||||||
|
|
||||||
|
See the :doc:`reviewer_guide` for more review guidelines.
|
||||||
|
|
||||||
|
Stage 1 - Approving release requests
|
||||||
|
------------------------------------
|
||||||
|
|
||||||
|
At this stage you will be trusted with CodeReview+2 and Workflow+1 votes
|
||||||
|
on the releases repository, giving you the ability to trigger releases.
|
||||||
|
You will need a base understanding of the :doc:`release_infra`, and know
|
||||||
|
to refrain from approving when unsure.
|
||||||
|
|
||||||
|
Checklist before approving a release:
|
||||||
|
|
||||||
|
* You should only approve release requests.
|
||||||
|
* You should check that release is approved by PTL or release liaison
|
||||||
|
* You should check that infrastructure is not currently experiencing issues
|
||||||
|
* You should check that we are not in any freeze period
|
||||||
|
* If unsure, it is better to wait for a second opinion that to press
|
||||||
|
Workflow+1 directly.
|
||||||
|
|
||||||
|
|
||||||
|
Stage 2 - Knowing the release cycle process
|
||||||
|
-------------------------------------------
|
||||||
|
|
||||||
|
At this stage you will be able to help drive the release cycle process,
|
||||||
|
send reminder emails and answer questions from release liaisons.
|
||||||
|
|
||||||
|
|
||||||
|
Stage 3 - Understanding the Release Automation Infrastructure
|
||||||
|
-------------------------------------------------------------
|
||||||
|
|
||||||
|
At this stage you will be able to debug complex :doc:`release_infra`
|
||||||
|
failures, and review/approve release tooling changes.
|
||||||
|
|
|
@ -0,0 +1,54 @@
|
||||||
|
======================
|
||||||
|
Release infrastructure
|
||||||
|
======================
|
||||||
|
|
||||||
|
What happens when a release is approved? Release infrastructure is divided
|
||||||
|
into two steps, triggered by different, but related events.
|
||||||
|
|
||||||
|
The first step is triggered by the release request being merged into the
|
||||||
|
releases repository, starting a series of jobs in the "post" pipeline
|
||||||
|
of the releases repository::
|
||||||
|
|
||||||
|
Release request merged
|
||||||
|
|
|
||||||
|
+-------v-----------------------+
|
||||||
|
Post pipeline (releases repo)
|
||||||
|
+---+-----------------------+---+
|
||||||
|
| |
|
||||||
|
v v
|
||||||
|
+-------+-------+ +-------+-------+
|
||||||
|
| tag | | publish-docs |
|
||||||
|
| | | |
|
||||||
|
| (pushes tags | | (to releases |
|
||||||
|
| to each repo) | | website) |
|
||||||
|
| | | |
|
||||||
|
+-------+-------+ +---------------+
|
||||||
|
|
||||||
|
The second step is triggered by the creation of the tag, creating a series
|
||||||
|
of jobs in the "tag" pipeline and the "release" pipeline (or "pre-release"
|
||||||
|
pipeline, in case of beta versions) of the repository the tag landed in::
|
||||||
|
|
||||||
|
Tag is created -----------------------------------------------
|
||||||
|
| |
|
||||||
|
+----v------------------------------------+ +----------v-----------+
|
||||||
|
Release pipeline (each repo) Tag pipeline (each repo)
|
||||||
|
+----+---------------+---------------+----+ +----------------------+
|
||||||
|
| | | |
|
||||||
|
v v v v
|
||||||
|
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
|
||||||
|
| release | | announce | | propose | | publish |
|
||||||
|
| | | | |constraints| | release |
|
||||||
|
|(builds | | (sends | | update | | notes |
|
||||||
|
| tarball | | email) | | | | |
|
||||||
|
| & uploads | | | +-----------+ +-----------+
|
||||||
|
| it) | +-----------+
|
||||||
|
+-----------+
|
||||||
|
|
||||||
|
Note that a single release request can create multiple tags in different
|
||||||
|
repositories, triggering that second stage in multiple repositories.
|
||||||
|
|
||||||
|
Jobs in the release pipeline need information from the release request
|
||||||
|
(like series name, or whether to upload to pypi). We use metadata in the
|
||||||
|
git tag itself to pass that information: the "tag" job in step 1 records
|
||||||
|
the information in the tag, and the jobs in step 2 retrieve that information
|
||||||
|
directly from the tag.
|
Loading…
Reference in New Issue