diff options
| author | glozow <gloriajzhao@gmail.com> | 2024-02-20 16:29:08 +0000 |
|---|---|---|
| committer | glozow <gloriajzhao@gmail.com> | 2024-04-18 17:07:57 +0100 |
| commit | 1ea8674316f2dce0005f6094b6ee111b045dd770 (patch) | |
| tree | 311c2418607452caa735b5f9e3f39a3deaa4b7f7 /CONTRIBUTING.md | |
| parent | ddf1d72cc2a1e17dc9cf0bf5df6a95850afb6085 (diff) | |
[doc] update release-process.md and backports section of CONTRIBUTING
- Mention which directories contain the respective unsigned tarballs
- Clarify that bitcoin.conf might not need to be updated
- Specify where to put historical release notes if there is already
something in release-notes.md
- Clarify what exactly is the problem with running guix-codesign more
than once
- Correct number: 6 codesigned attestations are needed before uploading
binaries
- Remove scp command which is outdated
- Remove server path which is outdated
- Specify that translations update should happen before branch-off, not
before each release candidate
- Mention that you should notify lists when RCs are available
- Put "Archive the release notes" as a separate step, since creating the
github release has a dependency on it.
- Put bitcoincore.org website updates as a separate step, since
updating packaging repos may have a dependency on it.
- Update "bitcoin-dev mailing list" to "bitcoin-dev group"
- Document that maintainers should create PRs to collect backports
- Remove section about not uploading `*-debug` files, reader should
upload all build artifacts.
- Torrent is created automatically, so delete instructions.
- Mention that server also generates ots file automatically.
Diffstat (limited to 'CONTRIBUTING.md')
| -rw-r--r-- | CONTRIBUTING.md | 7 |
1 files changed, 2 insertions, 5 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0ae4ff1a92..3c1d3d9568 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -417,11 +417,8 @@ Backporting Security and bug fixes can be backported from `master` to release branches. -If the backport is non-trivial, it may be appropriate to open an -additional PR to backport the change, but only after the original PR -has been merged. -Otherwise, backports will be done in batches and -the maintainers will use the proper `Needs backport (...)` labels +Maintainers will do backports in batches and +use the proper `Needs backport (...)` labels when needed (the original author does not need to worry about it). A backport should contain the following metadata in the commit body: |