-
Notifications
You must be signed in to change notification settings - Fork 49
Labels
size-sEstimated task size: small (~2d)Estimated task size: small (~2d)
Description
Each time we make a release, we spend a lot of time crafting a release archive, and we tend to make mistakes (e.g. Mbed-TLS/mbedtls#9524, Mbed-TLS/mbedtls#10332). It's hard to stabilize this process because it involves manual fiddling and the results are not reproducible.
Minimum requirements for this task:
- The script must not require manual intervention: you just point it to a commit and it does its thing.
- Produce a
.tar.bz2file that is suitable as the release archive, if the starting point is suitable as a release (branches merged, changelog prepared, versions bumped, etc.). - Document a validation process. This can be “run the script locally and compare the results” if the script is fully reproducible, or something more complicated if the script isn't reproducible.
Nice to have, without going overboard on the development and review time (this is a size-s task):
- Make the script fully reproducible (with the same tool versions).
- Also produce a checksum file.
- Do some of the work to prepare the release commit: assemble changelog, bump versions, etc.
- Avoid dependencies on third-party tooling.
- Support 3.6 LTS.
Definitely out of scope:
- Running the new script on the CI (Make a mock release in the release/nightly CI job mbedtls#3255). Manual testing will do for now. We can compare this script with the old process the next time we do a release.
- Enforcing reproducibility (Generated files should not vary based on build path mbedtls#9521).
- Git activity such as making a tag.
- Cryptographically signing the release.
- Any validation that involves looking at more than the commit to release, such as checking that everything that should be backported has been backported.
Metadata
Metadata
Assignees
Labels
size-sEstimated task size: small (~2d)Estimated task size: small (~2d)
Type
Projects
Status
Shared backlog