snoopdave commented on code in PR #240: URL: https://github.com/apache/roller/pull/240#discussion_r4519266539
########## 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: 🤖Codex: moved the auto-publish instruction to the start-vote step and identified the exact checkbox to leave unchecked. The Finish tab instruction now covers only auto-archive. ########## 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: 🤖Codex: documented the Roller path mismatch, the three supported suffix tokens, the manual Finish-page suffix review, and why the ATR client auto-publish option must remain off. ########## 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: 🤖Codex: documented the current archive/root names and ATR concern, with instructions to investigate and acknowledge the project convention or rename the root before the first Roller 7 release. ########## 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: 🤖Codex: added a requirement to include each archive SHA-512 digest in the vote email and documented ATR template URLs from raw.githubusercontent.com or apache.org, including review of fetched text before sending. The existing repository guidance is content guidance rather than a ready-to-fetch ATR body, so the guide now describes using a reviewed plain-text repository template when one is configured. ########## 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: 🤖Codex: added the exact source verification command, `mvn -V -ntp clean install`, to run from the unpacked downloaded source. ########## 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: 🤖Codex: rewrapped the long workflow lines in the release skill. -- 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]
