document how to request a branch
Change-Id: I7360a791c8f7d8cfc61ecf4e9294834a6db239e1 Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This commit is contained in:
parent
bbc1e85f6b
commit
b37ae73448
260
README.rst
260
README.rst
|
@ -42,7 +42,7 @@ repository.
|
||||||
* If you are not the release liaison or PTL, have the PTL of the
|
* If you are not the release liaison or PTL, have the PTL of the
|
||||||
project acknowledge the request with a +1.
|
project acknowledge the request with a +1.
|
||||||
|
|
||||||
* Do not used the "Depends-On" feature of zuul to make a release
|
* Do not use the "Depends-On" feature of zuul to make a release
|
||||||
request depend on merging another patch in your project. The
|
request depend on merging another patch in your project. The
|
||||||
dependency management does not work properly in the release check
|
dependency management does not work properly in the release check
|
||||||
jobs, and the validator requires that the patch listed in your
|
jobs, and the validator requires that the patch listed in your
|
||||||
|
@ -57,16 +57,57 @@ repository.
|
||||||
release request depends on a request that is deprioritized, you may
|
release request depends on a request that is deprioritized, you may
|
||||||
miss the deadline.
|
miss the deadline.
|
||||||
|
|
||||||
Reviewing a Release Request
|
* RC1 tags and stable branches should be submitted together for
|
||||||
---------------------------
|
projects using the cycle-with-milestone release model.
|
||||||
|
|
||||||
Care needs to be taken when reviewing a release request such that the version
|
Requesting a Branch
|
||||||
|
===================
|
||||||
|
|
||||||
|
The PTL or release liaison for a project may request a new branch by
|
||||||
|
submitting a patch to this repository, adding the necessary branch
|
||||||
|
metadata to the file describing the deliverable to be released. The
|
||||||
|
release team will review the request and provide feedback about the
|
||||||
|
branch point and possibly the name.
|
||||||
|
|
||||||
|
Prepare the branch request by submitting a patch to this repository.
|
||||||
|
|
||||||
|
* RC1 tags and stable branches should be submitted together for
|
||||||
|
projects using the cycle-with-milestone release model.
|
||||||
|
|
||||||
|
* Always add the new branch to the end of the list in the file being
|
||||||
|
edited.
|
||||||
|
|
||||||
|
* Branches should use one of the standard prefixes:
|
||||||
|
|
||||||
|
stable/ -- for stable series
|
||||||
|
|
||||||
|
feature/ -- for temporary feature branches
|
||||||
|
|
||||||
|
driverfixes/ -- for long-term driver maintenance, beyond the end of
|
||||||
|
the stable branch
|
||||||
|
|
||||||
|
* stable/ and driverfixes/ branch names must match a valid series
|
||||||
|
name.
|
||||||
|
|
||||||
|
* If you are not the release liaison or PTL, have the PTL of the
|
||||||
|
project acknowledge the request with a +1.
|
||||||
|
|
||||||
|
* Do not use the "Depends-On" feature of zuul to make a branch
|
||||||
|
request depend on merging another patch in your project. The
|
||||||
|
dependency management does not work properly in the release check
|
||||||
|
jobs, and the validator requires that the patch listed in your
|
||||||
|
deliverable file actually be merged into a proper branch.
|
||||||
|
|
||||||
|
Reviewing a Release or Branch Request
|
||||||
|
=====================================
|
||||||
|
|
||||||
|
Care needs to be taken when reviewing a request such that the version
|
||||||
proposed (1) follows semver rules and (2) will not cause issues between
|
proposed (1) follows semver rules and (2) will not cause issues between
|
||||||
branches, particularly stable branches (at least stable branches that are not
|
branches, particularly stable branches (at least stable branches that are not
|
||||||
yet using upper-constraints checking in CI runs, which is anything before
|
yet using upper-constraints checking in CI runs, which is anything before
|
||||||
stable/liberty).
|
stable/liberty).
|
||||||
|
|
||||||
General notes when reviewing a release request:
|
General notes when reviewing a request:
|
||||||
|
|
||||||
* Make sure you follow semantic versioning rules `semver <http://semver.org/>`_
|
* Make sure you follow semantic versioning rules `semver <http://semver.org/>`_
|
||||||
when picking the version number. In particular, if there is a change going
|
when picking the version number. In particular, if there is a change going
|
||||||
|
@ -118,6 +159,9 @@ team should +1 the following types of changes before they are approved.
|
||||||
version range prevents those patch-level versions from breaking each other's
|
version range prevents those patch-level versions from breaking each other's
|
||||||
branch.
|
branch.
|
||||||
|
|
||||||
|
* Ensure that new branches are listed at the end of the branch list in
|
||||||
|
the file.
|
||||||
|
|
||||||
Release Approval
|
Release Approval
|
||||||
================
|
================
|
||||||
|
|
||||||
|
@ -142,145 +186,171 @@ team is responsible for taking the necessary corrective action.
|
||||||
Deliverable Files
|
Deliverable Files
|
||||||
=================
|
=================
|
||||||
|
|
||||||
Deliverable repositories for projects tagged with
|
Deliverable repositories for projects using cycle_with_intermediatry
|
||||||
release:cycle_with_intermediatry or release:cycle_with_milestones
|
or cycle_with_milestones should be placed in their respective releases
|
||||||
should be placed in their respective releases within the
|
within the deliverables directory. Deliverable repositories for
|
||||||
deliverables directory. Deliverable repositories for projects tagged with
|
projects using the indepedent release model should be placed in the
|
||||||
release:indepedent should be placed in the ``deliverables/_independent``
|
``deliverables/_independent`` directory.
|
||||||
directory. Deliverable repositories tagged with release:none have no
|
|
||||||
release and are not tracked in this repository.
|
|
||||||
|
|
||||||
For deliverable set of projects, we use one YAML file per release
|
For deliverable set of projects, we use one YAML file per release
|
||||||
series to hold all of the metadata for all releases of that
|
series to hold all of the metadata for all releases and branches of
|
||||||
deliverable. For each release, we need to track:
|
that deliverable. For each deliverable, we need to track:
|
||||||
|
|
||||||
* the launchpad project name (such as ``oslo.config``)
|
* the launchpad project name (such as ``oslo.config``)
|
||||||
* the series (Kilo, Liberty, etc.)
|
* the series (Kilo, Liberty, etc.)
|
||||||
* the release model being used
|
* the release model being used
|
||||||
* for each repository
|
* for each repository
|
||||||
|
|
||||||
* the name (such as ``openstack/oslo.config``)
|
* the name (such as ``openstack/oslo.config``)
|
||||||
* the hash of the commit to be tagged
|
* the hash of the commit to be tagged
|
||||||
|
|
||||||
* the version number to use
|
* the version number to use
|
||||||
* highlights for the release notes email (optional)
|
* highlights for the release notes email (optional)
|
||||||
|
* the starting points of all branches
|
||||||
|
|
||||||
We track this metadata for the history of all releases of the
|
We track this metadata for the history of all releases of the
|
||||||
deliverable, so we can render a set of release history documentation.
|
deliverable, so we can render a set of release history documentation.
|
||||||
|
|
||||||
The file should be named based on the deliverable to be tagged, so
|
The file should be named based on the deliverable to be tagged, so
|
||||||
releases for ``liberty`` from the ``openstack/oslo.config`` repository
|
releases for ``liberty`` from the ``openstack/oslo.config`` repository
|
||||||
will have a file in ``openstack/releases`` called
|
will have a file in ``openstack/releases`` called
|
||||||
``deliverables/liberty/oslo.config.yaml``. Releases of the same deliverable from
|
``deliverables/liberty/oslo.config.yaml``. Releases of the same deliverable from
|
||||||
the ``stable/kilo`` branch will be described by
|
the ``stable/kilo`` branch will be described by
|
||||||
``deliverables/kilo/oslo.config.yaml``.
|
``deliverables/kilo/oslo.config.yaml``.
|
||||||
|
|
||||||
Deliverables File Schema
|
Deliverables File Schema
|
||||||
========================
|
========================
|
||||||
|
|
||||||
The top level of a deliverable file is a mapping with keys:
|
The top level of a deliverable file is a mapping with keys:
|
||||||
|
|
||||||
``team``
|
``team``
|
||||||
The name of the team that owns the deliverable, as listed in the
|
The name of the team that owns the deliverable, as listed in the
|
||||||
governance repository data files.
|
governance repository data files.
|
||||||
|
|
||||||
``launchpad``
|
``launchpad``
|
||||||
The slug name of the launchpad project, suitable for use in URLs.
|
The slug name of the launchpad project, suitable for use in URLs.
|
||||||
|
|
||||||
``release-notes``
|
``release-notes``
|
||||||
The URL or URLs to the published release notes for the deliverable
|
The URL or URLs to the published release notes for the deliverable
|
||||||
for the series.
|
for the series.
|
||||||
|
|
||||||
Deliverables contained a single repository should simply include the
|
Deliverables contained a single repository should simply include the
|
||||||
URL to the notes for that repository. Deliverables made up of
|
URL to the notes for that repository. Deliverables made up of
|
||||||
multiple repositories should use a hash to map each repository name
|
multiple repositories should use a hash to map each repository name
|
||||||
to its notes URL.
|
to its notes URL.
|
||||||
|
|
||||||
``include-pypi-link``
|
``include-pypi-link``
|
||||||
Either ``yes`` or ``no``, indicating whether the release
|
Either ``yes`` or ``no``, indicating whether the release
|
||||||
announcement should include the link to the package on
|
announcement should include the link to the package on
|
||||||
PyPI. Defaults to ``no``.
|
PyPI. Defaults to ``no``.
|
||||||
|
|
||||||
``release-model``
|
``release-model``
|
||||||
Identify the release model used by the deliverable. See
|
Identify the release model used by the deliverable. See
|
||||||
the reference section of the documentation for descriptions
|
the reference section of the documentation for descriptions
|
||||||
of the valid models.
|
of the valid models.
|
||||||
|
|
||||||
``type``
|
``type``
|
||||||
Categorize the deliverable based on what it does. See the reference
|
Categorize the deliverable based on what it does. See the reference
|
||||||
section of the documentation for descriptions of the valid
|
section of the documentation for descriptions of the valid
|
||||||
deliverable types.
|
deliverable types.
|
||||||
|
|
||||||
``artifact-link-mode``
|
``artifact-link-mode``
|
||||||
Describe how to link to artifacts produced by the project. The
|
Describe how to link to artifacts produced by the project. The
|
||||||
default is ``tarball`. Valid values are:
|
default is ``tarball`. Valid values are:
|
||||||
|
|
||||||
tarball
|
tarball
|
||||||
Automatically generates links to version-specific files on
|
Automatically generates links to version-specific files on
|
||||||
tarballs.openstack.org.
|
tarballs.openstack.org.
|
||||||
|
|
||||||
none
|
none
|
||||||
Do not link to anything, just show the version number.
|
Do not link to anything, just show the version number.
|
||||||
|
|
||||||
``repository-settings``
|
``repository-settings``
|
||||||
Mapping of special settings to control the behavior for each repository, keyed
|
Mapping of special settings to control the behavior for each repository, keyed
|
||||||
by the repository name.
|
by the repository name.
|
||||||
|
|
||||||
``flags``
|
``flags``
|
||||||
A list of flags attached to the repository.
|
A list of flags attached to the repository.
|
||||||
|
|
||||||
``no-artifact-build-job``
|
``no-artifact-build-job``
|
||||||
This repository has no job for building an artifact, but should
|
This repository has no job for building an artifact, but should
|
||||||
be tagged anyway.
|
be tagged anyway.
|
||||||
|
|
||||||
``retired``
|
``retired``
|
||||||
This repository is no longer used, but was present in old
|
This repository is no longer used, but was present in old
|
||||||
versions of a deliverable.
|
versions of a deliverable.
|
||||||
|
|
||||||
``release-type``
|
``release-type``
|
||||||
This (optional) key sets the level of validation for the versions numbers.
|
This (optional) key sets the level of validation for the versions numbers.
|
||||||
|
|
||||||
``std``
|
``std``
|
||||||
Default: Enforces 3 digit semver version numbers in releases and allows
|
Default: Enforces 3 digit semver version numbers in releases and allows
|
||||||
for common alpha, beta and dev releases. This should be appropriate for
|
for common alpha, beta and dev releases. This should be appropriate for
|
||||||
most OpenStack release requirements.
|
most OpenStack release requirements.
|
||||||
|
|
||||||
``xstatic``
|
``xstatic``
|
||||||
Allows a more flexible versioning in line with xstatic package guidelines
|
Allows a more flexible versioning in line with xstatic package guidelines
|
||||||
and requirements.
|
and requirements.
|
||||||
|
|
||||||
``fuel``
|
``fuel``
|
||||||
The Fuel project manages its own packages.
|
The Fuel project manages its own packages.
|
||||||
|
|
||||||
``releases``
|
``releases``
|
||||||
A list of the releases for the deliverable.
|
A list of the releases for the deliverable.
|
||||||
|
|
||||||
|
``branches``
|
||||||
|
A list of the branches for the deliverable.
|
||||||
|
|
||||||
Each `release` entry is a mapping with keys:
|
Each `release` entry is a mapping with keys:
|
||||||
|
|
||||||
``version``
|
``version``
|
||||||
The version tag for that release, to be applied to all of the member
|
The version tag for that release, to be applied to all of the member
|
||||||
projects.
|
projects.
|
||||||
|
|
||||||
``projects``
|
``projects``
|
||||||
A list of all of the projects making up the deliverable for that
|
A list of all of the projects making up the deliverable for that
|
||||||
release.
|
release.
|
||||||
|
|
||||||
``highlights``
|
``highlights``
|
||||||
An optional message to be included in the release note email
|
An optional message to be included in the release note email
|
||||||
announcing the release. (Use ``|`` to indicate a multi-line,
|
announcing the release. (Use ``|`` to indicate a multi-line,
|
||||||
pre-formatted message.)
|
pre-formatted message.)
|
||||||
|
|
||||||
Each `project` entry is a mapping with keys:
|
Each `project` entry is a mapping with keys:
|
||||||
|
|
||||||
``repo``
|
``repo``
|
||||||
The name of the repository on git.openstack.org.
|
The name of the repository on git.openstack.org.
|
||||||
|
|
||||||
``hash``
|
``hash``
|
||||||
The SHA1 hash for the commit to receive the version tag.
|
The SHA1 hash for the commit to receive the version tag.
|
||||||
|
|
||||||
``tarball-base``
|
``tarball-base``
|
||||||
An optional name for the base of the tarball created by the
|
An optional name for the base of the tarball created by the
|
||||||
release. If no value is provided, it defaults to the repo base name.
|
release. If no value is provided, it defaults to the repo base name.
|
||||||
|
|
||||||
|
Each ``branch`` entry is a mapping with keys:
|
||||||
|
|
||||||
|
``name``
|
||||||
|
The name of the branch.
|
||||||
|
|
||||||
|
``location``
|
||||||
|
The location value depends on the name.
|
||||||
|
|
||||||
|
If a branch name starts with stable/ then the location must be
|
||||||
|
either an existing version tag or the most recently added version
|
||||||
|
number under the releases list (allowing a tag and branch to be
|
||||||
|
submitted together). All repositories associated with the version
|
||||||
|
(as identified by the deliverable file) will be branched from that
|
||||||
|
version using the name given.
|
||||||
|
|
||||||
|
If a branch name starts with feature/ then the location must be a
|
||||||
|
mapping between the target repository name and the SHA of a commit
|
||||||
|
already in the target repository.
|
||||||
|
|
||||||
|
If a branch name starts with driverfixes/ then the location must be
|
||||||
|
a SHA of a commit already in the target repository on the associated
|
||||||
|
stable branch.
|
||||||
|
|
||||||
|
|
||||||
Examples
|
Examples
|
||||||
========
|
========
|
||||||
|
@ -290,6 +360,10 @@ For example, one version of
|
||||||
|
|
||||||
---
|
---
|
||||||
launchpad: oslo.config
|
launchpad: oslo.config
|
||||||
|
branches:
|
||||||
|
- name: feature/random-feature-work
|
||||||
|
location:
|
||||||
|
openstack/oslo.config: 02a86d2eefeda5144ea8c39657aed24b8b0c9a39
|
||||||
releases:
|
releases:
|
||||||
- version: 1.12.0
|
- version: 1.12.0
|
||||||
projects:
|
projects:
|
||||||
|
@ -300,6 +374,12 @@ and then for the subsequent release it would be updated to contain::
|
||||||
|
|
||||||
---
|
---
|
||||||
launchpad: oslo.config
|
launchpad: oslo.config
|
||||||
|
branches:
|
||||||
|
- name: feature/random-feature-work
|
||||||
|
location:
|
||||||
|
openstack/oslo.config: 02a86d2eefeda5144ea8c39657aed24b8b0c9a39
|
||||||
|
- name: stable/newton
|
||||||
|
location: 1.12.1
|
||||||
releases:
|
releases:
|
||||||
- version: 1.12.0
|
- version: 1.12.0
|
||||||
projects:
|
projects:
|
||||||
|
|
Loading…
Reference in New Issue