2024-04-01 03:27:50 +00:00
|
|
|
## Pull Requests
|
|
|
|
|
|
|
|
Pull requests for every change should follow the given flow:
|
2024-04-14 22:47:41 +00:00
|
|
|
`pull-request-branch -> staging -> current-release-branch -> staging -> main`.
|
|
|
|
Making a commit short-cut the staging or the release branch removes the ability
|
|
|
|
to track who approves contributions and when those contributions has been
|
|
|
|
approved. If a patch is necessary for a release, it should flow from a PR, to
|
|
|
|
staging, to the release branch. The release branch should not contain any
|
|
|
|
changes (ignoring `digests.txt` and signatures) that do not exist in `staging`.
|
2024-04-01 03:27:50 +00:00
|
|
|
|
|
|
|
Pull requests should be merged using a signed merge commit. To configure your
|
|
|
|
Git porcelain to always use merge commits, run `git config merge.ff false`. To
|
|
|
|
configure your Git porcelain to always sign commits, run `git config
|
|
|
|
commit.gpgsign true`.
|
|
|
|
|
|
|
|
## Release Branches
|
|
|
|
|
|
|
|
Release branches take the format `YYYY.MM.release`. A release should include a
|
2024-04-01 04:32:55 +00:00
|
|
|
PR to staging to introduce a bump to `digests.txt`, creating the release
|
2024-04-14 22:47:41 +00:00
|
|
|
branch. Once the branch is created, other maintainers should begin reproducing.
|
|
|
|
The release engineer should run `make sign` to ensure a signature exists for
|
|
|
|
every package included in the release.
|
2024-04-01 03:27:50 +00:00
|
|
|
|
2024-04-01 04:32:55 +00:00
|
|
|
In the Git forge UI, the release pull request should target the `main` branch,
|
2024-04-14 22:47:41 +00:00
|
|
|
to provide a summary of all changes since the latest release.
|
2024-04-01 04:32:55 +00:00
|
|
|
|
2024-04-01 03:27:50 +00:00
|
|
|
Any commits required once the branch is created, but before the release is
|
2024-04-14 22:47:41 +00:00
|
|
|
published, should flow from a PR (if push access to the release branch is not
|
|
|
|
given) to staging, where the release branch can then rebase on staging.
|
2024-04-01 03:27:50 +00:00
|
|
|
|
2024-04-14 22:47:41 +00:00
|
|
|
Once a release is published, the release branch should perform a signed merge
|
|
|
|
commit into staging, followed by a signed merge commit from staging to main.
|
|
|
|
Any further pull requests to the branch after the series of releases is done
|
|
|
|
(which may be published after release, if strictly necessary) can target the
|
|
|
|
release branch, and the release branch will live on its own.
|