diff --git a/.agents/skills/release/SKILL.md b/.agents/skills/release/SKILL.md index 1e6643a..8cad0ca 100644 --- a/.agents/skills/release/SKILL.md +++ b/.agents/skills/release/SKILL.md @@ -37,8 +37,8 @@ Keep these values and supporting links in the conversation so work can resume ac - `VERSION`: the final crate version, such as `0.7.2`; RCs do not change the package version. - `RC`: the positive candidate number; `RC_TAG` is `v${VERSION}-rc.${RC}`. - `RELEASE_COMMIT`: the merged release pull request commit bound to the candidate. -- `RELEASE_DIR`: an absolute working directory outside the repository for artifacts, verification, and SVN checkouts; reuse it while continuing the same candidate. -- Candidate tag and artifact location, checksum/signature results, relevant CI runs, PPMC/IPMC vote threads and results, and completed publication steps. +- `RELEASE_DIR`: an absolute working directory outside the repository for artifacts and verification; reuse it while continuing the same candidate. +- Staging service and candidate URL, ATR revision when applicable, checksum/signature results, relevant CI runs, PPMC/IPMC vote threads and results, and completed publication steps. ATR uses `VERSION` as its release version; its revision serial is separate from the Git RC number. Report completed work with evidence, the next useful step, and any input still needed. Distinguish pending, failed, and unverified steps. Keep handoff notes in the conversation unless the user requests a file. diff --git a/.agents/skills/release/references/candidate.md b/.agents/skills/release/references/candidate.md index 7dbd2b7..40a0911 100644 --- a/.agents/skills/release/references/candidate.md +++ b/.agents/skills/release/references/candidate.md @@ -90,23 +90,15 @@ Verify the existing artifacts with the [candidate-verification guide](verificati For the separate `license-audit` review, provide the original source archive, the extracted source, and the Cargo package produced by verification, together with `RELEASE_COMMIT`. Discuss its evidence and suggestions with the release manager. Keep the verification directory available until both reviews finish; then remove that disposable directory. -## Stage the candidate on ASF infrastructure +## Stage the candidate in Apache Trusted Releases -Check whether this candidate is already staged. For a new staging operation, check out a working copy under `RELEASE_DIR`, add the three candidate files, and commit them: +Use [Apache Trusted Releases (ATR)](https://releases.apache.org/) for new candidates. Resume an existing candidate where it is already staged; moving a vote in progress between services would change its artifact links. -```shell -svn checkout --depth=empty \ - https://dist.apache.org/repos/dist/dev/incubator/asyncband "${RELEASE_DIR}/svn-dev" -mkdir "${RELEASE_DIR}/svn-dev/${VERSION}-rc.${RC}" -cp \ - "${ARTIFACT_DIR}/${SOURCE_DIR}.tar.gz" \ - "${ARTIFACT_DIR}/${SOURCE_DIR}.tar.gz.asc" \ - "${ARTIFACT_DIR}/${SOURCE_DIR}.tar.gz.sha512" \ - "${RELEASE_DIR}/svn-dev/${VERSION}-rc.${RC}/" -svn add "${RELEASE_DIR}/svn-dev/${VERSION}-rc.${RC}" -svn status "${RELEASE_DIR}/svn-dev" -svn commit "${RELEASE_DIR}/svn-dev" \ - -m "Stage Apache Asyncband ${VERSION} release candidate ${RC}" -``` +1. Open the `asyncband` project in ATR and locate the draft for `VERSION`, or create it if absent. Use the final version, such as `0.8.0`, without `v` or `-rc.N`. ATR assigns a new revision serial as files change; record that serial alongside `RC_TAG` and `RELEASE_COMMIT` rather than assuming it equals `RC`. +2. Upload the verified `.tar.gz`, `.tar.gz.asc`, and `.tar.gz.sha512` files through the browser, or use the rsync command provided by ATR. Use the release manager's existing signing identity. Keep verification reports and the crates.io convenience package outside the staged source bundle. +3. Inspect ATR's signature, checksum, archive, and license results for the resulting revision. Investigate concrete concerns with the `license-audit` skill where relevant; a scanner result is evidence to discuss, and a passing scan does not replace source or build verification. If the source archive is misclassified or a signing key is missing, consult [Infrastructure](infrastructure.md). +4. Download the staged files into a separate directory and compare them with the local verified originals. Record the candidate URL and revision, then prepare the vote on that exact set of bytes. + +ATR holds the files through compose and vote, and pins the revision when voting starts. Use that candidate page as the voting artifact source. Its download commands are available to voters without committer access. See the official [staging and voting guide](https://releases.apache.org/docs/staging-and-voting); an additional `dist/dev` copy is unnecessary for this route. -Confirm the candidate at `https://dist.apache.org/repos/dist/dev/incubator/asyncband/${VERSION}-rc.${RC}/` and verify every link prepared for the vote email. +If ATR cannot be used for a new candidate, agree on the existing SVN staging route before starting its vote: upload the same three files to `https://dist.apache.org/repos/dist/dev/incubator/asyncband/${VERSION}-rc.${RC}/` and record that as the voting source. Preserve an existing SVN candidate through publication rather than silently switching it to ATR. diff --git a/.agents/skills/release/references/infrastructure.md b/.agents/skills/release/references/infrastructure.md index 69a078a..6d79c9d 100644 --- a/.agents/skills/release/references/infrastructure.md +++ b/.agents/skills/release/references/infrastructure.md @@ -29,6 +29,24 @@ Trusted Publishing is already configured for `asyncband`: repository `apache/asy ## Signing and ASF distribution -Candidates are staged under `https://dist.apache.org/repos/dist/dev/incubator/asyncband/`; approved releases are promoted to `https://dist.apache.org/repos/dist/release/incubator/asyncband/`. The public verification key list is `https://downloads.apache.org/incubator/asyncband/KEYS`. +New candidates use [Apache Trusted Releases](https://releases.apache.org/) for staging, automated artifact checks, email votes, and publication to `https://dist.apache.org/repos/dist/release/incubator/asyncband/`. The existing `https://dist.apache.org/repos/dist/dev/incubator/asyncband/` area remains available for candidates already using SVN or an agreed fallback. The public verification key list is `https://downloads.apache.org/incubator/asyncband/KEYS`. The release manager uses an ASF-associated signing key published in the existing project `KEYS` file. For a new signing key, follow the [ASF release signing guide](https://infra.apache.org/release-signing.html), verify the fingerprint through an independent channel, and add the public key while preserving existing keys. Reuse established distribution areas and signing configuration; investigate a reported access or verification failure before proposing infrastructure changes. + +## ATR project configuration + +The `project` block in `.asf.yaml` is the maintained ATR configuration. ASF infrastructure synchronizes it from the default branch, so edit the repository for lasting changes; subsequent syncs can overwrite corresponding UI edits. It identifies `asyncband` as both the project and its owning committee, classifies the incubating source archive, chooses email votes on the development list with a 72-hour minimum, and publishes into `{{VERSION}}`. See the official [.asf.yaml project reference](https://github.com/apache/infrastructure-asfyaml#project-metadata). + +After initially merging this configuration, confirm the project and settings in ATR and record the result. Confirm that its committee is marked as a podling and that the existing signing key is available. Podling status comes from ASF committee records, not this repository. The first ATR release still requires this live check; a valid YAML file does not establish that synchronization or key import has completed. + +Keep the existing SVN `KEYS` file as the source of truth and use ATR's automatic import mode unless the project chooses another ownership model. This avoids maintaining two key lists. See [KEYS management](https://releases.apache.org/docs/promoting-to-release#the-keys-file). ATR's [artifact checks](https://releases.apache.org/docs/checks) complement the local verifier and license audit. Add narrowly justified scanner exclusions only in response to inspected findings; the current policy leaves the default license checks enabled. + +ATR's current [podling vote implementation](https://github.com/apache/tooling-trusted-releases/blob/55dbd1b1a69e383941505f87d6b85b840b491288/atr/storage/writers/vote.py#L706) starts the IPMC round when the release manager resolves a passing PPMC round. It does not offer automatic resolution of the first round. Preserve both rounds when changing the workflow. + +## Later: automated signing and upload + +ASF [Trusted Publishing](https://releases.apache.org/docs/trusted-publishing) is separate from crates.io Trusted Publishing. Browser or personal rsync uploads can use the release manager's existing signature now; GitHub Actions uploads through `apache/tooling-actions/upload-to-atr` require ATR workflow trust and an eligible committee signing key. + +For automated signing, demonstrate reproducibility to ASF Security, arrange an automated project key with ASF Infrastructure, and register its public half through the committee's `KEYS` management. Then configure the repository secret and ATR compose workflow allowlist. These are one-time onboarding steps; record their completion rather than repeating them for every candidate. Neither this configuration nor the existing crates.io OIDC setup establishes that onboarding is complete. + +OpenDAL's [source compose workflow](https://github.com/apache/opendal/blob/af11b6ee9ad1e4df1ff7b1e61156b1f3c4a74357/.github/workflows/release-compose.yml) separates source preparation, signing, and OIDC upload, which is a useful reference for that follow-up. Introduce compose automation after validating a release through ATR, and retain vote and finish as separate release-manager actions. Weekly scheduling, version selection, and automatic lifecycle coordination remain in [#303](https://github.com/apache/asyncband/issues/303). diff --git a/.agents/skills/release/references/publication.md b/.agents/skills/release/references/publication.md index d850c6b..f00c6b7 100644 --- a/.agents/skills/release/references/publication.md +++ b/.agents/skills/release/references/publication.md @@ -25,24 +25,30 @@ Resume from the recorded candidate and vote results. Check which publication ste Incubating releases use the [Incubator two-phase vote](https://incubator.apache.org/cookbook/#two-phase-vote-on-podling-releases). Each vote remains open for at least 72 hours. -When the staged candidate and supporting links have been verified, send `[VOTE] Release Apache Asyncband (Incubating) ${VERSION} RC${RC}` to `dev@asyncband.apache.org`. Include: +For an ATR candidate, use its email vote mode with `dev@asyncband.apache.org` as the first-round recipient and `general@incubator.apache.org` as the second-round recipient. Use at least 72 hours and keep automatic SVN publication off for the initial ATR release so the release manager can inspect the destination before publishing. ATR pins the staged revision when voting starts. -- the staged source URL; +When the staged candidate and supporting links have been verified, review the vote message before sending it through ATR. Use `[VOTE] Release Apache Asyncband (Incubating) ${VERSION} RC${RC}` as the subject and include: + +- the ATR candidate page identifying the voted revision, or the staged SVN URL for a legacy candidate; - the `KEYS` URL and signing-key fingerprint; - the signed RC tag and commit hash; - the changelog or comparison with the previous release; - verification commands or a checklist for signatures, checksums, licensing, unexpected binaries, and the build; - a closing time at least 72 hours after the vote starts. -The PPMC vote passes with at least three PPMC `+1` votes and more PPMC `+1` votes than `-1` votes. Publish a result email that identifies the voters and links the archived vote thread. +The PPMC vote passes with at least three PPMC `+1` votes and more PPMC `+1` votes than `-1` votes. Record the voters, result, and archived thread. Resolving a passing first-round podling vote in ATR also starts the IPMC vote; prepare both actions with the release manager before resolving it. Do not send a duplicate IPMC proposal outside ATR. + +The IPMC vote passes with at least three binding IPMC `+1` votes and more binding `+1` votes than `-1` votes. Confirm its result and record the archived vote and result links. ATR's checks and phase labels support the release manager's review; retain the evidence for both vote rounds. -Then send the proposal to `general@incubator.apache.org` with the PPMC result and archive link. The IPMC vote passes with at least three binding IPMC `+1` votes and more binding `+1` votes than `-1` votes. Publish its result email and record the archive link. +For a candidate already staged in SVN, conduct the same two votes by email: send and resolve the PPMC proposal, then send the IPMC proposal with the PPMC result and archive link. Publish each result and retain its archive link. Begin publication after the IPMC result records a passing vote. ## Promote and publish the approved release -Promote the exact voted artifacts from the development distribution area: +For an ATR candidate, open its finish page after both rounds pass. Verify that the destination is `https://dist.apache.org/repos/dist/release/incubator/asyncband/${VERSION}/`, then use ATR's publish action to promote the exact voted artifacts. The `download_path_suffix` in `.asf.yaml` selects the version directory. Record the resulting SVN revision and URL; there is no separate `svn move` for this route. See [Promoting to release](https://releases.apache.org/docs/promoting-to-release). + +For a legacy SVN candidate, promote the exact voted artifacts from its recorded staging area: ```shell svn move \ @@ -69,14 +75,14 @@ After publication: 1. Verify the version and metadata on crates.io and docs.rs. 2. After ASF distribution syncs, verify the source archive, checksum, and signature under `https://downloads.apache.org/incubator/asyncband/${VERSION}/` and the project `KEYS` file at `https://downloads.apache.org/incubator/asyncband/KEYS`. 3. Submit a post-release pull request that adds the actual publication date to the `v${VERSION}` changelog heading. -4. Announce the release on `dev@asyncband.apache.org` and other appropriate channels as Apache Asyncband (Incubating). +4. Announce the release on `dev@asyncband.apache.org` and other appropriate channels as Apache Asyncband (Incubating). For an ATR release, use its announcement action after checking crates.io and docs.rs; ATR also checks download availability and records the release in its catalog. Reuse an announcement already sent through ATR. 5. Remove superseded releases from `dist/release`; ASF retains them in the archive. ## Recover from failures -A transient CI, staging, or registry error can be retried against the same candidate after checking what already succeeded. +A transient CI, staging, or registry error can be retried against the same candidate after checking what already succeeded. For ATR, inspect the current phase, revision, vote tasks, and SVN publication result before repeating an upload or action; a lost response does not mean the operation failed. -If the community rejects a candidate or its content changes, coordinate a new candidate with an incremented `RC`. Remove the rejected candidate from the development distribution area: +If the community rejects a candidate or its content changes, coordinate a new candidate with an incremented `RC`. In ATR, end the affected vote and return the release to compose before uploading the replacement as a new revision; record its new Git tag, commit, and ATR revision. Keep the prior vote identity in the handoff. For a legacy SVN candidate, remove the rejected files from the development distribution area: ```shell svn delete \ diff --git a/.asf.yaml b/.asf.yaml index 6308283..d24b14e 100644 --- a/.asf.yaml +++ b/.asf.yaml @@ -17,6 +17,29 @@ # See https://github.com/apache/infrastructure-asfyaml/ for the configuration reference. +project: + metadata: + key: asyncband + committee: asyncband + name: Apache Asyncband + homepage: https://asyncband.apache.org + repositories: + - https://github.com/apache/asyncband.git + programming_languages: + - Rust + policy: + source_artifact_paths: + - "apache-asyncband-*-incubating-src.tar.gz" + vote_mode: email + min_hours: 72 + vote_recipients: + to: dev@asyncband.apache.org + announce_recipients: + to: dev@asyncband.apache.org + download_path_suffix: "{{VERSION}}" + features: + atr_sync: true + github: description: >- This crate provides concurrency control and async coordination primitives that are runtime agnostic.