pingtimeout commented on code in PR #2824: URL: https://github.com/apache/polaris/pull/2824#discussion_r2610543294
########## site/content/release-verify.md: ########## @@ -0,0 +1,223 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--> + +# Release Verification Guide + +**Audience**: Committers and interested contributors. + +This guide walks you through the process of **verifying** a staged Apache Polaris release candidate. + +Please keep the [ASF Release Policy](https://www.apache.org/legal/release-policy.html#owned-controlled-hardware), +especially the section on "Owned and Controlled Hardware," in mind: +**_Strictly speaking, releases must be verified on hardware owned and controlled by the committer._** + +Verifying a (staged) release of an Apache project has to follow a bunch of tasks, which can be +grouped into tasks that can be automated and those that need human intervention. +Polaris provides a tool to automate the tasks that can be automated. + +Tasks that are automated: +* Checksums and PGP signatures are valid. +* All expected artifacts are present. +* Source code artifacts have correct names matching the current release. +* Built artifacts are [reproducible](#reproducible-builds). +* Build passes. +* `DISCLAIMER`, `LICENSE` and `NOTICE` files are included. +* main and sources jar artifacts contain `META-INF/LICENSE` and `META-INF/NOTICE` files. +* main distribution artifacts contain `DISCLAIMER`, `LICENSE` and `NOTICE` files in the top-level directory. + +Tasks that need human attention: +* Download links are valid. Check all links in the `[VOTE]` email for the release: + * Tag on the GitHub website + * Commit on the GitHub website + * SVN repository with the source tarball and binary release artifacts + * SVN repository with the Helm chart + * Link to the KEYS file (_MUST_ be equal to `https://downloads.apache.org/incubator/polaris/KEYS`) + * Maven staging repository + * A link to this page is included. +* The contents of the `DISCLAIMER`, `LICENSE` and `NOTICE` files are correct for the repository. +* Contents of jar artifacts `META-INF/LICENSE` and `META-INF/NOTICE` files are correct. +* All files have license headers, if necessary. + This is (mostly) verified using the "rat" tool during builds/CI. +* No disallowed binary artifacts are bundled in the source archive. + This is a (soft) requirement to be held true by committers. +* The commits on the Git tag, created on the release branch, do only contain changes that are relevant to the + release process and approved cherry-picks. + +Other tests: +* Running Polaris built from the Git tag and testing it manually is recommended. You can use the build + generated by [release verification script](#running-the-script) for this. +* You can also manually test the Docker images and the helm chars for the release candidate. + +**Imply good intent!** +Although the release manager is responsible for producing a "proper" release, mistakes can and will happen. +The Polaris project is committed to providing reproducible builds as an essential building block of +_Apache trusted releases_. +The project depends on frameworks which also strive to provide reproducible builds, but not all +these frameworks can provide fully reproducible builds yet. +The Polaris project's release verification tool will therefore report some issues that are currently expected. +See [below](#reproducible-builds) for details. + +After you have completed the verification of the release candidate, respond to the release vote email, +detailing the checks and tests you performed, and providing a summary of their outcomes. +Remember to include your +[vote (+1/0/-1)](https://www.apache.org/foundation/glossary.html#MajorityApproval) +and whether it's "binding." +A -1 vote requires a technical justification. +As a (P)PMC member, your vote is "binding," all other votes are "non-binding." + +# Verifying a release candidate + +Instead of performing all mentioned steps manually, you can leverage the script +`tools/verify-release/verify-release.sh`, available in the main repository, to perform the +automatable tasks. The script is intended to be run on Linux or macOS. + +## Verifying the script + +Verifying a release using any kind of automation, like this script, requires "trust" into the automation. +It is therefore recommended to verify the script before running it on a release candidate. +You can inspect it by +[looking at the source code](https://github.com/snazy/polaris/blob/main/tools/verify-release/verify-release.sh) +before running it. +The link to the `Raw` file must be the same as the one used in the command below to run the script. + +## Running the script + +Run the most recent version of the script using the following command: +```bash +bash <(curl \ + -s https://raw.githubusercontent.com/apache/polaris/refs/heads/main/tools/verify-release/verify-release.sh) \ + --help +``` + +The tool is intended for Polaris versions 1.3 and newer. +The tool may report issues, see [below](#reproducible-builds) for details. + +That script requires a couple of tools installed and will check that those are available +and report those that need to be installed. + +To run the script, you need the following pieces of information from the release-vote email: +* The *full* Git SHA of the corresponding source commit. +* The version number of the release, something like `1.3.0` +* The RC number of the release, for example `1` or `2` +* The Maven staging repository ID, for example `1033` (the full number at the end of the Maven repository URL `https://repository.apache.org/content/repositories/orgapachepolaris-1033/`). + +Example (values taken from the 1.2.0-rc2 release) +```bash +bash <(curl \ + --silent https://raw.githubusercontent.com/apache/polaris/refs/heads/main/tools/verify-release/verify-release.sh) \ + --git-sha 354a5ef6b337bf690b7a12fefe2c984e2139b029 \ + --version 1.3.0-incubating-rc0 \ + --maven-repo-id 1033 +``` + +Same example, but using the short option names: +```bash +bash <(curl \ + -s https://raw.githubusercontent.com/apache/polaris/refs/heads/main/tools/verify-release/verify-release.sh) \ + -s 354a5ef6b337bf690b7a12fefe2c984e2139b029 \ + -v 1.3.0-incubating-rc0 \ + -m 1033 +``` + +The verification script creates a temporary directory that will eventually contain a fresh Git clone, +all downloaded and all built artifacts. +This temporary directory is deleted after the script has finished. To keep the temporary directory +around, you can use the `--keep-temp-dir` (`-k`) option. + +A log file, the name matches the pattern `polaris-release-verify-*.log`, +will be created and contain detailed information about the identified issues reported on the console. + +Note: The script is maintained in the Polaris source tree in the `/tools/verify-release` directory. + +## Verifications performed by the tool + +After some startup checks, the tool emits some information about the release candidate. For example: +``` +Verifying staged release +======================== + +Git tag: apache-polaris-1.3.0-incubating-rc0 +Git sha: 354a5ef6b337bf690b7a12fefe2c984e2139b029 +Version: 1.3.0-incubating +RC: 0 +Maven repo URL: https://repository.apache.org/content/repositories/orgapachepolaris-1033/ +Main dist URL: https://dist.apache.org/repos/dist/dev/incubator/polaris/1.3.0-incubating +Helm chart URL: https://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart/1.3.0-incubating +Verify directory: /tmp/polaris-release-verify-2025-10-23-14-22-31-HPmmiybzk + +A verbose log containing the identified issues will be available here: + .../polaris-release-verify-2025-10-23-14-22-31.log +``` + +After that, release candidate verification starts immediately, performing the following operations: + +1. Create `gpg` keyring for signature verification from the project's `KEYS` file. +2. Clone the Git repository directly from GitHub. +3. Git commit SHA and Git tag match Review Comment: ```suggestion 3. Verifies that the Git tag corresponds to the provided Git SHA ``` ########## site/content/release-verify.md: ########## @@ -0,0 +1,223 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--> + +# Release Verification Guide + +**Audience**: Committers and interested contributors. + +This guide walks you through the process of **verifying** a staged Apache Polaris release candidate. + +Please keep the [ASF Release Policy](https://www.apache.org/legal/release-policy.html#owned-controlled-hardware), +especially the section on "Owned and Controlled Hardware," in mind: +**_Strictly speaking, releases must be verified on hardware owned and controlled by the committer._** + +Verifying a (staged) release of an Apache project has to follow a bunch of tasks, which can be +grouped into tasks that can be automated and those that need human intervention. +Polaris provides a tool to automate the tasks that can be automated. + +Tasks that are automated: +* Checksums and PGP signatures are valid. +* All expected artifacts are present. +* Source code artifacts have correct names matching the current release. +* Built artifacts are [reproducible](#reproducible-builds). +* Build passes. +* `DISCLAIMER`, `LICENSE` and `NOTICE` files are included. +* main and sources jar artifacts contain `META-INF/LICENSE` and `META-INF/NOTICE` files. +* main distribution artifacts contain `DISCLAIMER`, `LICENSE` and `NOTICE` files in the top-level directory. + +Tasks that need human attention: +* Download links are valid. Check all links in the `[VOTE]` email for the release: + * Tag on the GitHub website + * Commit on the GitHub website + * SVN repository with the source tarball and binary release artifacts + * SVN repository with the Helm chart + * Link to the KEYS file (_MUST_ be equal to `https://downloads.apache.org/incubator/polaris/KEYS`) + * Maven staging repository + * A link to this page is included. +* The contents of the `DISCLAIMER`, `LICENSE` and `NOTICE` files are correct for the repository. +* Contents of jar artifacts `META-INF/LICENSE` and `META-INF/NOTICE` files are correct. +* All files have license headers, if necessary. + This is (mostly) verified using the "rat" tool during builds/CI. +* No disallowed binary artifacts are bundled in the source archive. + This is a (soft) requirement to be held true by committers. +* The commits on the Git tag, created on the release branch, do only contain changes that are relevant to the + release process and approved cherry-picks. + +Other tests: +* Running Polaris built from the Git tag and testing it manually is recommended. You can use the build + generated by [release verification script](#running-the-script) for this. +* You can also manually test the Docker images and the helm chars for the release candidate. + +**Imply good intent!** +Although the release manager is responsible for producing a "proper" release, mistakes can and will happen. +The Polaris project is committed to providing reproducible builds as an essential building block of +_Apache trusted releases_. +The project depends on frameworks which also strive to provide reproducible builds, but not all +these frameworks can provide fully reproducible builds yet. +The Polaris project's release verification tool will therefore report some issues that are currently expected. +See [below](#reproducible-builds) for details. + +After you have completed the verification of the release candidate, respond to the release vote email, +detailing the checks and tests you performed, and providing a summary of their outcomes. +Remember to include your +[vote (+1/0/-1)](https://www.apache.org/foundation/glossary.html#MajorityApproval) +and whether it's "binding." +A -1 vote requires a technical justification. +As a (P)PMC member, your vote is "binding," all other votes are "non-binding." + +# Verifying a release candidate + +Instead of performing all mentioned steps manually, you can leverage the script +`tools/verify-release/verify-release.sh`, available in the main repository, to perform the +automatable tasks. The script is intended to be run on Linux or macOS. + +## Verifying the script + +Verifying a release using any kind of automation, like this script, requires "trust" into the automation. +It is therefore recommended to verify the script before running it on a release candidate. +You can inspect it by +[looking at the source code](https://github.com/snazy/polaris/blob/main/tools/verify-release/verify-release.sh) +before running it. +The link to the `Raw` file must be the same as the one used in the command below to run the script. + +## Running the script + +Run the most recent version of the script using the following command: +```bash +bash <(curl \ + -s https://raw.githubusercontent.com/apache/polaris/refs/heads/main/tools/verify-release/verify-release.sh) \ + --help +``` + +The tool is intended for Polaris versions 1.3 and newer. +The tool may report issues, see [below](#reproducible-builds) for details. + +That script requires a couple of tools installed and will check that those are available +and report those that need to be installed. + +To run the script, you need the following pieces of information from the release-vote email: +* The *full* Git SHA of the corresponding source commit. +* The version number of the release, something like `1.3.0` +* The RC number of the release, for example `1` or `2` +* The Maven staging repository ID, for example `1033` (the full number at the end of the Maven repository URL `https://repository.apache.org/content/repositories/orgapachepolaris-1033/`). + +Example (values taken from the 1.2.0-rc2 release) +```bash +bash <(curl \ + --silent https://raw.githubusercontent.com/apache/polaris/refs/heads/main/tools/verify-release/verify-release.sh) \ + --git-sha 354a5ef6b337bf690b7a12fefe2c984e2139b029 \ + --version 1.3.0-incubating-rc0 \ + --maven-repo-id 1033 +``` + +Same example, but using the short option names: +```bash +bash <(curl \ + -s https://raw.githubusercontent.com/apache/polaris/refs/heads/main/tools/verify-release/verify-release.sh) \ + -s 354a5ef6b337bf690b7a12fefe2c984e2139b029 \ + -v 1.3.0-incubating-rc0 \ + -m 1033 +``` + +The verification script creates a temporary directory that will eventually contain a fresh Git clone, +all downloaded and all built artifacts. +This temporary directory is deleted after the script has finished. To keep the temporary directory +around, you can use the `--keep-temp-dir` (`-k`) option. + +A log file, the name matches the pattern `polaris-release-verify-*.log`, +will be created and contain detailed information about the identified issues reported on the console. + +Note: The script is maintained in the Polaris source tree in the `/tools/verify-release` directory. + +## Verifications performed by the tool + +After some startup checks, the tool emits some information about the release candidate. For example: +``` +Verifying staged release +======================== + +Git tag: apache-polaris-1.3.0-incubating-rc0 +Git sha: 354a5ef6b337bf690b7a12fefe2c984e2139b029 +Version: 1.3.0-incubating +RC: 0 +Maven repo URL: https://repository.apache.org/content/repositories/orgapachepolaris-1033/ +Main dist URL: https://dist.apache.org/repos/dist/dev/incubator/polaris/1.3.0-incubating +Helm chart URL: https://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart/1.3.0-incubating +Verify directory: /tmp/polaris-release-verify-2025-10-23-14-22-31-HPmmiybzk + +A verbose log containing the identified issues will be available here: + .../polaris-release-verify-2025-10-23-14-22-31.log +``` + +After that, release candidate verification starts immediately, performing the following operations: + +1. Create `gpg` keyring for signature verification from the project's `KEYS` file. +2. Clone the Git repository directly from GitHub. +3. Git commit SHA and Git tag match Review Comment: This one is a nit -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
