napcok/calamares
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Docs: update RELEASE.md with some GPG-info and remove old steps

Browse Source
This commit is contained in:
Adriaan de Groot 2020-07-20 14:06:21 +02:00
parent e1c85340e4
commit e8282f27a3
1 changed files with 51 additions and 61 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

112
ci/RELEASE.md
View File

@ -1,21 +1,13 @@
# Calamares Release Process # Calamares Release Process
> Calamares releases are now rolling when-they-are-ready releases. > Calamares releases are now rolling when-they-are-ready releases.
> Releases are made from *master* and tagged there. When, in future, > Releases are made from *calamares* and tagged there. When, in future,
> LTS releases resume, these steps may be edited again. > LTS releases resume, these steps may be edited again.
> >
> Most things are automated through the release script [RELEASE.sh](RELEASE.sh) > Most things are automated through the release script [RELEASE.sh](RELEASE.sh)
## (0) A week in advance ## (1) Preparation
* Run [Coverity scan][coverity], fix what's relevant. The Coverity scan runs
automatically once a week on master. The badge is displayed on the
project front page and in the wiki.
* Build with clang -Weverything, fix what's relevant.
```
rm -rf build ; mkdir build ; cd build
CC=clang CXX=clang++ cmake .. && make
```
* Make sure all tests pass. * Make sure all tests pass.
``` ```
make make
@ -25,16 +17,6 @@
an additional environment variable to be set for some tests, which will an additional environment variable to be set for some tests, which will
destroy an attached disk. This is not always desirable. There are some destroy an attached disk. This is not always desirable. There are some
sample config-files that are empty and which fail the config-tests. sample config-files that are empty and which fail the config-tests.
* Notify [translators][transifex]. In the dashboard there is an *Announcements*
link that you can use to send a translation announcement. Note that regular
use of `txpush.sh` will notify translators as well of any changes.
[coverity]: https://scan.coverity.com/projects/calamares-calamares?tab=overview
[transifex]: https://www.transifex.com/calamares/calamares/dashboard/
## (1) Preparation
* Pull latest translations from Transifex. We only push / pull translations * Pull latest translations from Transifex. We only push / pull translations
from master, so longer-lived branches (e.g. 3.1.x) don't get translation from master, so longer-lived branches (e.g. 3.1.x) don't get translation
updates. This is to keep the translation workflow simple. The script updates. This is to keep the translation workflow simple. The script
@ -47,13 +29,8 @@
fairly complete translations, or use `ci/txstats.py` for an automated fairly complete translations, or use `ci/txstats.py` for an automated
suggestion. If there are changes, commit them. suggestion. If there are changes, commit them.
* Push the changes. * Push the changes.
* Drop the RC variable to 0 in `CMakeLists.txt`, *CALAMARES_VERSION_RC*.
* Check `README.md` and the
[Coding Guide](https://github.com/calamares/calamares/wiki/Develop-Code),
make sure it's all still
relevant. Run `ci/calamaresstyle` to check the C++ code style.
Run pycodestyle on recently-modified Python modules, fix what makes sense.
* Check defaults in `settings.conf` and other configuration files. * Check defaults in `settings.conf` and other configuration files.
* Drop the RC variable to 0 in `CMakeLists.txt`, *CALAMARES_VERSION_RC*.
* Edit `CHANGES` and set the date of the release. * Edit `CHANGES` and set the date of the release.
* Commit both. This is usually done with commit-message * Commit both. This is usually done with commit-message
*Changes: pre-release housekeeping*. *Changes: pre-release housekeeping*.
@ -73,44 +50,16 @@
On success, it prints out a suitable signature- and SHA256 blurb On success, it prints out a suitable signature- and SHA256 blurb
for use in the release announcement. for use in the release announcement.
### (2.1) Buld and Test ## (3) Release
* Build with gcc. If available, build again with Clang and double-check Follow the instructions printed by the release script.
any warnings Clang produces.
* Run the tests; `make test` in the build directory should have no
failures (or if there are, know why they are there).
### (2.2) Tag * Push the tags.
* Create a new release on GitHub.
* `git tag -s v1.1.0` Make sure the signing key is known in GitHub, so that the * Upload tarball and signature.
tag is shown as a verified tag. Do not sign -rc tags.
You can use `make show-version` in the build directory to get the right
version number -- this will fail if you didn't follow step (1).
### (2.3) Tarball
* Create tarball: `git-archive-all -v calamares-1.1-rc1.tar.gz` or without
the helper script,
```
V=calamares-3.1.5
git archive -o $V.tar.gz --prefix $V/ master
```
Double check that the tarball matches the version number.
* Test tarball (e.g. unpack somewhere else and run the tests from step 0).
## (3) Housekeeping
* Generate MD5 and SHA256 checksums.
* Upload tarball.
* Announce on mailing list, notify packagers.
* Write release article.
* Publish tarball.
* Update download page.
* Publish release article on `calamares.io`. * Publish release article on `calamares.io`.
* Publicize on social networks. * Close associated milestone on GitHub if it's entirely done.
* Close associated milestone on GitHub if this is the actual release. * Update topic on #calamares IRC channel.
* Publish blog post.
## (4) Post-Release ## (4) Post-Release
@ -133,3 +82,44 @@ This release contains contributions from (alphabetically by first name):
## Modules ## ## Modules ##
- No module changes yet - No module changes yet
``` ```
# Related Material
> This section isn't directly related to any specific release,
> but bears on all releases.
## GPG Key Maintainence
Calamares uses GPG Keys for signing the tarballs and some commits
(tags, mostly). Calamares uses the **maintainer's** personal GPG
key for this. This section details some GPG activities that the
maintainer should do with those keys.
- Signing sub-key. It's convenient to use a signing sub-key specifically
for the signing of Calamares. To do so, add a key to the private key.
It's recommended to use key expiry, and to update signing keys periodically.
- Run `gpg -K` to find the key ID of your personal GPG secret key.
- Run `gpg --edit-key <keyid>` to edit that personal GPG key.
- In gpg edit-mode, use `addkey`, then pick a key type that is *sign-only*
(e.g. type 4, *RSA (sign only)*), then pick a keysize (3072 seems ok
as of 2020) and set a key expiry time, (e.g. in 18 months time).
- After generation, the secret key information is printed again, now
including the new signing subkey:
```
ssb rsa3072/0xCFDDC96F12B1915C
created: 2020-07-11 expires: 2022-01-02 usage: S
```
- Update the `RELEASE.sh` script with a new signing sub-key ID when a new
one is generated. Also announce the change of signing sub-key (e.g. on
the Calmares site or as part of a release announcement).
- Send the updated key to keyservers with `gpg --send-keys <keyid>`
- Optional: sanitize the keyring for use in development machines.
Export the current subkeys of the master key and keep **only** those
secret keys around. There is documentation
[here](https://blog.tinned-software.net/create-gnupg-key-with-sub-keys-to-sign-encrypt-authenticate/)
but be careful.
- Export the public key material with `gpg --export --armor <keyid>`,
possibly also setting an output file.
- Upload that public key to the relevant GitHub profile.
- Upload that public key to the Calamares site.