mraible commented on code in PR #240: URL: https://github.com/apache/roller/pull/240#discussion_r4504997759
########## skills/roller-release/references/atr.md: ########## @@ -15,22 +15,113 @@ See the License for the specific language governing permissions and limitations under the License. --> -# Evaluating Apache Trusted Releases +# Apache Trusted Releases for Roller 7 -[Apache Trusted Releases](https://releases.apache.org) is an alternative release -workflow to evaluate with the PMC. Check its current documentation, availability, -project enrollment and supported packaging before adoption; this skill does not -pin a platform status or participating-project list. +Use [ATR](https://releases.apache.org/docs/) for the Roller 7 pilot with local +builds and personal OpenPGP signing. This replaces manual `dist/dev` staging and +SVN promotion. The PMC still approves the release; ATR checks supplement human +verification. [Trusted Publishing](https://releases.apache.org/docs/trusted-publishing) +is a separate CI signing workflow requiring reproducibility and ASF approvals; +it is outside this process. Recheck current ATR documentation at release time. -Try a non-publishing rehearsal and establish how the chosen tool handles: +## Before the first candidate -- Source and convenience binary archives, signatures and checksums. -- Existing project distribution layout and KEYS handling. -- Candidate identity, vote evidence, cancellation and replacement. -- Promotion of the exact approved bytes and website coordination. -- Access control and the separation of private security coordination from - public release artifacts and messages. +Follow [Getting started](https://releases.apache.org/docs/getting-started) and +[Moving to ATR](https://releases.apache.org/docs/moving-to-atr): -Agree the workflow and ownership before a release deadline. Keep the evaluation -and any per-release decision in project planning records. Do not switch an active -release between tools without reconciling candidate identity and approval evidence. +- Sign in with ASF MFA. Confirm PMC membership or PMC designation as a release + manager. Verify the actual Roller project key, committee, repositories and + catalog; do not assume seeded data is correct. +- Confirm the signing public key is associated with Roller and is present in the + published committee KEYS file. Retain SVN-managed KEYS (ATR's default import + mode); update keys in SVN rather than changing ownership for this pilot. +- Review [project configuration](https://releases.apache.org/docs/project-configuration): + metadata, release version policy, source checks, vote recipients and templates, + download page, announcement recipients and destination suffix. Check the actual Review Comment: It'd help to spell out the actual mismatch here. For a committee's top-level project, ATR publishes straight into `dist/release/roller/`, while `dist-svn.md` documents Roller's layout as `roller-<major.minor>/v<version>/`. The suffix tokens are only `{{PROJECT_KEY}}`, `{{VERSION}}` and `{{MAJOR_VERSION}}`, so a saved default can't produce `roller-7.0/`. The RM will need to set the suffix by hand on the finish page when publishing. (The ATR client's `--auto-publish` ignores the configured path and publishes to the top, which is one more reason to keep auto-publish off.) --- _Generated by [Claude Code](https://claude.ai/code)_ ########## skills/roller-release/references/atr.md: ########## @@ -15,22 +15,113 @@ See the License for the specific language governing permissions and limitations under the License. --> -# Evaluating Apache Trusted Releases +# Apache Trusted Releases for Roller 7 -[Apache Trusted Releases](https://releases.apache.org) is an alternative release -workflow to evaluate with the PMC. Check its current documentation, availability, -project enrollment and supported packaging before adoption; this skill does not -pin a platform status or participating-project list. +Use [ATR](https://releases.apache.org/docs/) for the Roller 7 pilot with local +builds and personal OpenPGP signing. This replaces manual `dist/dev` staging and +SVN promotion. The PMC still approves the release; ATR checks supplement human +verification. [Trusted Publishing](https://releases.apache.org/docs/trusted-publishing) +is a separate CI signing workflow requiring reproducibility and ASF approvals; +it is outside this process. Recheck current ATR documentation at release time. -Try a non-publishing rehearsal and establish how the chosen tool handles: +## Before the first candidate -- Source and convenience binary archives, signatures and checksums. -- Existing project distribution layout and KEYS handling. -- Candidate identity, vote evidence, cancellation and replacement. -- Promotion of the exact approved bytes and website coordination. -- Access control and the separation of private security coordination from - public release artifacts and messages. +Follow [Getting started](https://releases.apache.org/docs/getting-started) and +[Moving to ATR](https://releases.apache.org/docs/moving-to-atr): -Agree the workflow and ownership before a release deadline. Keep the evaluation -and any per-release decision in project planning records. Do not switch an active -release between tools without reconciling candidate identity and approval evidence. +- Sign in with ASF MFA. Confirm PMC membership or PMC designation as a release + manager. Verify the actual Roller project key, committee, repositories and + catalog; do not assume seeded data is correct. +- Confirm the signing public key is associated with Roller and is present in the + published committee KEYS file. Retain SVN-managed KEYS (ATR's default import + mode); update keys in SVN rather than changing ownership for this pilot. +- Review [project configuration](https://releases.apache.org/docs/project-configuration): + metadata, release version policy, source checks, vote recipients and templates, + download page, announcement recipients and destination suffix. Check the actual + SVN layout and website before choosing the suffix; do not accept ATR's default + destination without reviewing it. Record the resolved path in the release work + record, not as an assumed path in this skill. +- Use Email vote mode and the normal minimum of 72 hours. Keep automatic + publication and auto-archive off. Review settings that affect both 7 and 6.1.x; + do not retire a supported line or archive its latest release during the pilot. +- Inspect any `.asf.yaml` project configuration before editing settings in ATR: + synchronization from the default branch can overwrite manual changes. Record + required configuration work separately; reading this skill does not configure + the service or establish readiness. + +## Compose and verify + +1. Build and test the exact recorded RC commit using the main skill. Use final + archive filenames, without an RC suffix, so publication needs no renaming or + checksum edits. Run `assembly-release/sign-release.sh "$VERSION"` with the + selected `ROLLER_SIGNING_KEY` exported. Do not re-sign after the vote. +2. Start a candidate in the confirmed Roller project for the final release + version. Use the compose page's **Upload files** browser form to upload only + the intended source and convenience binary archives, `.asc` signatures and + SHA-256/SHA-512 sidecars. Supply the full 40-character source commit. + See [Uploading files](https://releases.apache.org/docs/uploading-files). +3. Wait for archive validation and checks to finish. If validation rejects the + upload, fix the issue and upload the whole rejected set again. For oversized + browser requests, upload smaller batches; if necessary follow ATR's documented + rsync route and explicitly record the same source commit. +4. Resolve blockers and investigate other concerns, including source comparison Review Comment: One concern we can predict: ATR's archive-structure check expects the archive's root folder to match its filename (with or without a trailing `-source`/`-src`). `apache-roller-7.0.0-source.tar.gz` unpacks to `roller-weblogger-7.0.0-source/` (`assembly-release/src/main/assembly/source.xml`), so this will flag on every candidate. Worth naming here, either as a known, justified acknowledgment or as a reason to rename the root folder before 7.0. --- _Generated by [Claude Code](https://claude.ai/code)_ ########## skills/roller-release/references/atr.md: ########## @@ -15,22 +15,113 @@ See the License for the specific language governing permissions and limitations under the License. --> -# Evaluating Apache Trusted Releases +# Apache Trusted Releases for Roller 7 -[Apache Trusted Releases](https://releases.apache.org) is an alternative release -workflow to evaluate with the PMC. Check its current documentation, availability, -project enrollment and supported packaging before adoption; this skill does not -pin a platform status or participating-project list. +Use [ATR](https://releases.apache.org/docs/) for the Roller 7 pilot with local +builds and personal OpenPGP signing. This replaces manual `dist/dev` staging and +SVN promotion. The PMC still approves the release; ATR checks supplement human +verification. [Trusted Publishing](https://releases.apache.org/docs/trusted-publishing) +is a separate CI signing workflow requiring reproducibility and ASF approvals; +it is outside this process. Recheck current ATR documentation at release time. -Try a non-publishing rehearsal and establish how the chosen tool handles: +## Before the first candidate -- Source and convenience binary archives, signatures and checksums. -- Existing project distribution layout and KEYS handling. -- Candidate identity, vote evidence, cancellation and replacement. -- Promotion of the exact approved bytes and website coordination. -- Access control and the separation of private security coordination from - public release artifacts and messages. +Follow [Getting started](https://releases.apache.org/docs/getting-started) and +[Moving to ATR](https://releases.apache.org/docs/moving-to-atr): -Agree the workflow and ownership before a release deadline. Keep the evaluation -and any per-release decision in project planning records. Do not switch an active -release between tools without reconciling candidate identity and approval evidence. +- Sign in with ASF MFA. Confirm PMC membership or PMC designation as a release + manager. Verify the actual Roller project key, committee, repositories and + catalog; do not assume seeded data is correct. +- Confirm the signing public key is associated with Roller and is present in the + published committee KEYS file. Retain SVN-managed KEYS (ATR's default import + mode); update keys in SVN rather than changing ownership for this pilot. +- Review [project configuration](https://releases.apache.org/docs/project-configuration): + metadata, release version policy, source checks, vote recipients and templates, + download page, announcement recipients and destination suffix. Check the actual + SVN layout and website before choosing the suffix; do not accept ATR's default + destination without reviewing it. Record the resolved path in the release work + record, not as an assumed path in this skill. +- Use Email vote mode and the normal minimum of 72 hours. Keep automatic Review Comment: ATR doesn't have a project-level setting for automatic publication. It's a checkbox on the start-vote form ("Automatically publish to SVN distribution area when this vote resolves", see `promoting-to-release.md` in the ATR docs). I'd move this to the vote section (line 84 or so) as an explicit "leave it unchecked" step. Leave auto-archive here, since that one *is* a Finish-tab setting. Also, a new project gets **Trusted** vote mode by default unless it inherits Email from its parent or committee, so maybe say "switch Vote mode to Email" so nobody assumes it's already set. --- _Generated by [Claude Code](https://claude.ai/code)_ ########## skills/roller-release/SKILL.md: ########## @@ -53,24 +63,32 @@ Use [signing-key guidance](references/signing-key.md) before building a candidat (normally `mvn -V -ntp clean install`). Build `assembly-release` separately with `mvn -f assembly-release/pom.xml package`; it is outside the root reactor. 5. Inspect the source and binary tar/zip archives. Sign and generate checksums - using [signing instructions](references/signing-key.md). + using [signing instructions](references/signing-key.md). For ATR, use final + archive filenames from the start; identify RCs with Git tags and ATR revisions. 6. Run `scripts/check-release.sh <artifact-dir>` from this skill. Its optional `--build` compiles the source archive with tests skipped; it does not replace the test suite, a full license review, or independent voter verification. -7. Stage and download the candidate using [distribution guidance](references/dist-svn.md). - Verify signatures, checksums, contents and source build from the downloaded files. +7. Stage and download through the selected workflow: [ATR compose](references/atr.md) + for Roller 7 or [SVN staging](references/dist-svn.md) for 6.1.x. Verify signatures, + checksums, contents and a source build with tests from the downloaded files. ## Vote and publish -Use [vote and announcement templates](references/vote-and-announce.md). Normally -allow at least 72 hours and require at least three positive binding votes and +Follow the selected workflow and review +[vote and announcement templates](references/vote-and-announce.md). Normally allow at least 72 hours and require at least three positive binding votes and Review Comment: Nit: this line got merged during the edit and is about 155 characters now. Could you re-wrap it like the rest of the file? --- _Generated by [Claude Code](https://claude.ai/code)_ ########## skills/roller-release/references/atr.md: ########## @@ -15,22 +15,113 @@ See the License for the specific language governing permissions and limitations under the License. --> -# Evaluating Apache Trusted Releases +# Apache Trusted Releases for Roller 7 -[Apache Trusted Releases](https://releases.apache.org) is an alternative release -workflow to evaluate with the PMC. Check its current documentation, availability, -project enrollment and supported packaging before adoption; this skill does not -pin a platform status or participating-project list. +Use [ATR](https://releases.apache.org/docs/) for the Roller 7 pilot with local +builds and personal OpenPGP signing. This replaces manual `dist/dev` staging and +SVN promotion. The PMC still approves the release; ATR checks supplement human +verification. [Trusted Publishing](https://releases.apache.org/docs/trusted-publishing) +is a separate CI signing workflow requiring reproducibility and ASF approvals; +it is outside this process. Recheck current ATR documentation at release time. -Try a non-publishing rehearsal and establish how the chosen tool handles: +## Before the first candidate -- Source and convenience binary archives, signatures and checksums. -- Existing project distribution layout and KEYS handling. -- Candidate identity, vote evidence, cancellation and replacement. -- Promotion of the exact approved bytes and website coordination. -- Access control and the separation of private security coordination from - public release artifacts and messages. +Follow [Getting started](https://releases.apache.org/docs/getting-started) and +[Moving to ATR](https://releases.apache.org/docs/moving-to-atr): -Agree the workflow and ownership before a release deadline. Keep the evaluation -and any per-release decision in project planning records. Do not switch an active -release between tools without reconciling candidate identity and approval evidence. +- Sign in with ASF MFA. Confirm PMC membership or PMC designation as a release + manager. Verify the actual Roller project key, committee, repositories and + catalog; do not assume seeded data is correct. +- Confirm the signing public key is associated with Roller and is present in the + published committee KEYS file. Retain SVN-managed KEYS (ATR's default import + mode); update keys in SVN rather than changing ownership for this pilot. +- Review [project configuration](https://releases.apache.org/docs/project-configuration): + metadata, release version policy, source checks, vote recipients and templates, + download page, announcement recipients and destination suffix. Check the actual + SVN layout and website before choosing the suffix; do not accept ATR's default + destination without reviewing it. Record the resolved path in the release work + record, not as an assumed path in this skill. +- Use Email vote mode and the normal minimum of 72 hours. Keep automatic + publication and auto-archive off. Review settings that affect both 7 and 6.1.x; + do not retire a supported line or archive its latest release during the pilot. +- Inspect any `.asf.yaml` project configuration before editing settings in ATR: + synchronization from the default branch can overwrite manual changes. Record + required configuration work separately; reading this skill does not configure + the service or establish readiness. + +## Compose and verify + +1. Build and test the exact recorded RC commit using the main skill. Use final + archive filenames, without an RC suffix, so publication needs no renaming or + checksum edits. Run `assembly-release/sign-release.sh "$VERSION"` with the + selected `ROLLER_SIGNING_KEY` exported. Do not re-sign after the vote. +2. Start a candidate in the confirmed Roller project for the final release + version. Use the compose page's **Upload files** browser form to upload only + the intended source and convenience binary archives, `.asc` signatures and + SHA-256/SHA-512 sidecars. Supply the full 40-character source commit. + See [Uploading files](https://releases.apache.org/docs/uploading-files). +3. Wait for archive validation and checks to finish. If validation rejects the + upload, fix the issue and upload the whole rejected set again. For oversized + browser requests, upload smaller batches; if necessary follow ATR's documented + rsync route and explicitly record the same source commit. +4. Resolve blockers and investigate other concerns, including source comparison + and licensing. Document any justified acknowledgments; do not suppress checks + just to start voting. Record the final ATR revision, candidate URL, manifest, + archive filenames and digests, signer fingerprint, RC tag and source commit. + Optionally give the revision an immutable RC tag in ATR. +5. Download that revision to a fresh directory using its candidate page's download + instructions. Verify the inventory against the + [file manifest](https://releases.apache.org/docs/file-manifest), signatures, + checksums and contents; run `scripts/check-release.sh <dir>` and build/test + the downloaded source. ATR's manifest digests do not replace detached + signatures or the project's checksum sidecars. + +## Vote and replacement candidates + +Review the vote email form against [the message guidance](vote-and-announce.md). Review Comment: Since filenames now stay the same across RCs, RC1 and RC2 files will look identical to voters. Could we make sure the vote email (ATR's form or the stored template) includes the SHA-512 digests so people can tell which bytes they tested? Relatedly, ATR template fields accept a template URL on `raw.githubusercontent.com`, so the Roller vote/announce text could live in this repo instead of being re-entered in project settings. --- _Generated by [Claude Code](https://claude.ai/code)_ ########## skills/roller-release/SKILL.md: ########## @@ -53,24 +63,32 @@ Use [signing-key guidance](references/signing-key.md) before building a candidat (normally `mvn -V -ntp clean install`). Build `assembly-release` separately with `mvn -f assembly-release/pom.xml package`; it is outside the root reactor. 5. Inspect the source and binary tar/zip archives. Sign and generate checksums - using [signing instructions](references/signing-key.md). + using [signing instructions](references/signing-key.md). For ATR, use final + archive filenames from the start; identify RCs with Git tags and ATR revisions. 6. Run `scripts/check-release.sh <artifact-dir>` from this skill. Its optional `--build` compiles the source archive with tests skipped; it does not replace the test suite, a full license review, or independent voter verification. -7. Stage and download the candidate using [distribution guidance](references/dist-svn.md). - Verify signatures, checksums, contents and source build from the downloaded files. +7. Stage and download through the selected workflow: [ATR compose](references/atr.md) + for Roller 7 or [SVN staging](references/dist-svn.md) for 6.1.x. Verify signatures, + checksums, contents and a source build with tests from the downloaded files. Review Comment: Step 6 says `check-release.sh --build` skips tests, and this step now requires a source build *with* tests. It'd help to give the command for that, e.g. `mvn -V -ntp clean install` in the unpacked downloaded source. --- _Generated by [Claude Code](https://claude.ai/code)_ -- 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]
