From 5897d57975c4cba3e7e1c26ff1355343eaf6da5a Mon Sep 17 00:00:00 2001 From: tison Date: Tue, 1 Sep 2026 09:51:35 +0800 Subject: [PATCH 1/2] docs: mark release communications as human handoffs Release automation can prepare evidence and message templates, but sending votes, results, and announcements represents the release manager in the Apache community. Make those boundaries explicit so the procedure stops before public communication and hands the reviewed text to the release manager's Apache email account. --- RELEASE.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index 05d12f84..ecd2ad03 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -112,6 +112,10 @@ CI does not run on every push to `main` or on release tags. Complete the local r 4. **Release tools**: Install Git, GPG, SVN, `unzip`, and the tools required by `cargo x lint`. 5. **Clean checkout**: Start from a current checkout of `main` with no local changes. +## Human communication handoffs + +Release tooling may prepare message templates, deadlines, vote tallies, and supporting links, but it does not send public communications on behalf of the release manager. The release manager reviews and manually sends the `[VOTE]`, `[RESULT][VOTE]`, and `[ANNOUNCE]` messages from their Apache email account, then records the resulting mailing-list thread URLs in the release tracking issue. + ## Step 1: Prepare the release on `main` Create a release-preparation pull request that: @@ -341,7 +345,7 @@ The commands verify both that `signing_key_fingerprint` is present in `KEYS` and ## Step 6: Send the release vote -Send the vote to `dev@datasketches.apache.org`. +Hand the prepared vote template to the release manager. The release manager reviews it and manually sends the vote to `dev@datasketches.apache.org` from their Apache email account. **Subject:** `[VOTE] Release Apache DataSketches Rust ${release_version} (RC${rc_number})` @@ -431,7 +435,7 @@ A release requires at least three explicit binding `+1` votes from PMC members a ## Step 7: Publish an approved release -Send a `[RESULT][VOTE]` message that lists the binding and non-binding vote totals. +After the voting period closes and the vote requirements are met, hand the prepared result and tally to the release manager. The release manager reviews and manually sends a `[RESULT][VOTE]` message that lists the binding and non-binding vote totals. Move the exact approved artifacts from `dist/dev` to `dist/release` without rebuilding or renaming them: @@ -501,7 +505,7 @@ cargo info "datasketches@$release_version" 4. Review the generated `_includes/downloadsInclude.txt`, submit the website change, and verify the download, signature, checksum, and `KEYS` links after it is published. 5. Wait at least one hour after the release first appears on `downloads.apache.org` before announcing it. -6. Send a plain-text announcement from an `@apache.org` address to `dev@datasketches.apache.org` and `announce@apache.org`. Include a short project description and links to the project download page, changelog, crates.io, and docs.rs. +6. Prepare a plain-text announcement with a short project description and links to the project download page, changelog, crates.io, and docs.rs. Hand it to the release manager, who reviews and manually sends it from their Apache email account to `dev@datasketches.apache.org` and `announce@apache.org`. 7. Submit a post-release pull request that adds the actual release date to the `v${release_version}` changelog heading, then close the release tracking issue. ## Troubleshooting From ad15da1096442c93a98afc168887cd02964ef786 Mon Sep 17 00:00:00 2001 From: tison Date: Tue, 1 Sep 2026 09:58:34 +0800 Subject: [PATCH 2/2] docs: express release communication as checkpoints Agent-oriented handoff language makes the release guide read like tool instructions rather than a shared operational runbook. Define actor-neutral review, send, and evidence requirements that tell both release managers and supporting tools when each public communication step is complete. --- RELEASE.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index ecd2ad03..1cc5a10e 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -112,9 +112,16 @@ CI does not run on every push to `main` or on release tags. Complete the local r 4. **Release tools**: Install Git, GPG, SVN, `unzip`, and the tools required by `cargo x lint`. 5. **Clean checkout**: Start from a current checkout of `main` with no local changes. -## Human communication handoffs +## Public communication checkpoints -Release tooling may prepare message templates, deadlines, vote tallies, and supporting links, but it does not send public communications on behalf of the release manager. The release manager reviews and manually sends the `[VOTE]`, `[RESULT][VOTE]`, and `[ANNOUNCE]` messages from their Apache email account, then records the resulting mailing-list thread URLs in the release tracking issue. +The release manager is responsible for the `[VOTE]`, `[CANCEL][VOTE]`, `[RESULT][VOTE]`, and `[ANNOUNCE]` messages. For each message: + +1. Populate the documented template from verified release state. +2. Review the recipients, subject, version, links, and any deadline or vote tally. +3. Send the message from the release manager's Apache email account. +4. Record the resulting mailing-list thread URL in the release tracking issue. + +A prepared draft does not complete a communication step; the sent message and its mailing-list thread are the evidence of completion. ## Step 1: Prepare the release on `main` @@ -345,7 +352,7 @@ The commands verify both that `signing_key_fingerprint` is present in `KEYS` and ## Step 6: Send the release vote -Hand the prepared vote template to the release manager. The release manager reviews it and manually sends the vote to `dev@datasketches.apache.org` from their Apache email account. +Prepare and review the vote using the verified candidate details and the template below. The release manager sends it to `dev@datasketches.apache.org` and records the mailing-list thread URL in the release tracking issue. **Subject:** `[VOTE] Release Apache DataSketches Rust ${release_version} (RC${rc_number})` @@ -420,7 +427,7 @@ A release requires at least three explicit binding `+1` votes from PMC members a ### If the vote is cancelled -1. Send a `[CANCEL][VOTE]` message with the reason. +1. The release manager sends a `[CANCEL][VOTE]` message with the reason and records its mailing-list thread URL. 2. Confirm and remove the failed candidate from `dist/dev`: ```bash @@ -435,7 +442,7 @@ A release requires at least three explicit binding `+1` votes from PMC members a ## Step 7: Publish an approved release -After the voting period closes and the vote requirements are met, hand the prepared result and tally to the release manager. The release manager reviews and manually sends a `[RESULT][VOTE]` message that lists the binding and non-binding vote totals. +After the voting period closes and the vote requirements are met, prepare a `[RESULT][VOTE]` message that lists the binding and non-binding vote totals. The release manager reviews and sends it, then records the mailing-list thread URL. Move the exact approved artifacts from `dist/dev` to `dist/release` without rebuilding or renaming them: @@ -505,7 +512,7 @@ cargo info "datasketches@$release_version" 4. Review the generated `_includes/downloadsInclude.txt`, submit the website change, and verify the download, signature, checksum, and `KEYS` links after it is published. 5. Wait at least one hour after the release first appears on `downloads.apache.org` before announcing it. -6. Prepare a plain-text announcement with a short project description and links to the project download page, changelog, crates.io, and docs.rs. Hand it to the release manager, who reviews and manually sends it from their Apache email account to `dev@datasketches.apache.org` and `announce@apache.org`. +6. Prepare and review a plain-text announcement with a short project description and links to the project download page, changelog, crates.io, and docs.rs. The release manager sends it to `dev@datasketches.apache.org` and `announce@apache.org`, then records the mailing-list thread URLs. 7. Submit a post-release pull request that adds the actual release date to the `v${release_version}` changelog heading, then close the release tracking issue. ## Troubleshooting