Add a roller-release developer skill documenting the release procedure

skills/README.md

@@ -0,0 +1,67 @@
+<!--
+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
+
+    https://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.
+-->
+
+# Roller developer skills
+
+Optional developer tooling. Nothing here is part of the Roller build, the
+source or binary distributions, or the runtime; the source assembly does not
+include this directory. You can ignore it entirely and work on Roller normally.
+
+Each subdirectory is a "skill": a `SKILL.md` describing a project procedure,
+plus supporting reference notes, templates and helper scripts. They exist so
+that recurring project chores are written down in one reviewable place instead
+of living in one committer's head.
+
+| Skill | Covers |
+|---|---|
+| [`roller-release`](roller-release/SKILL.md) | Preparing, building, signing, verifying, staging, voting on and publishing a release, plus the release website and announcement drafts. |
+| [`roller-security`](roller-security/SKILL.md) | Security report triage, private case tracking, CVE preparation, reporter coordination and disclosure planning. |
+
+## Reading them
+
+`SKILL.md` and the files under `references/` are plain Markdown. Read them
+directly for a written account of how a release is put together. No tooling is
+required for this.
+
+## Using them with an AI coding assistant
+
+The layout follows the convention used by Claude Code and similar agent tools,
+which discover skills under `.claude/skills/`. To make them available without
+duplicating the files:
+
+```sh
+mkdir -p .claude/skills
+ln -s ../../skills/roller-release .claude/skills/roller-release
+```
+
+`.claude/` is not tracked by this repository, so this is a local choice that
+affects only your checkout. Copying the directories instead of symlinking works
+equally well.
+
+## Scope and limits
+
+These skills describe procedure; they do not grant authority. The PMC owns
+release decisions, and ASF policy governs what a release requires. Where a skill
+and current ASF policy disagree, policy wins and the skill needs fixing.
+
+The helper scripts under `scripts/` are deliberately conservative: they preview
+by default, they do not commit, tag, push, sign on your behalf, or send mail,
+and they are not a substitute for reading the diff and verifying a candidate
+yourself. Verify current ASF policy from its authoritative sources rather than
+trusting a summary here.
+
+Corrections are welcome as ordinary pull requests.

skills/roller-release/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: roller-release
+description: Prepare, build, sign, verify, stage, vote on and publish Apache Roller releases, including release website updates and announcement drafts.
+---
+
+<!--
+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
+
+    https://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.
+-->
+
+# Apache Roller releases
+
+Use the current checkout, project release decisions and
+[ASF policy sources](references/asf-policy.md). Keep release execution notes,
+personal signing setup and undisclosed security scope outside this skill.
+Loading the skill does not authorize sending mail, pushing tags or publishing.
+
+## Establish release inputs
+
+Record the source checkout, target branch and exact commit; release version;
+RC number and tag; release-manager ASF ID; signing-key fingerprint; distribution
+working copies; and website checkout. Supply these from the actual release,
+not defaults from an earlier session. Use a clean tree or isolated checkout.
+
+Check build documentation and CI for the branch's supported JDK. Confirm Maven,
+GnuPG, SVN and archive tools are available. Python 3 is used by the version helper.
+Use [signing-key guidance](references/signing-key.md) before building a candidate.
+
+## Prepare and verify
+
+1. Agree scope and version, keeping undisclosed vulnerability details private.
+2. Inspect version-bearing POMs and packaging scripts. Run
+   `scripts/bump-version.sh <old> <new>` from this skill for a preview; use
+   `--write` only to apply the reviewed scope. It does not commit. Update release
+   notes and other appropriate references manually, preserving historical entries.
+3. Commit the release inputs and record an RC tag at the exact source revision.
+   Build from that revision so the embedded revision matches the candidate.
+   Preserve candidate history; changed artifacts normally require a new candidate
+   and vote. Do not silently replace artifacts already being voted on.
+4. Build and test from the root using the branch's documented Maven invocation
+   (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).
+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.
+
+## 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
+more positive than negative binding votes. Check current policy for exceptions.
+Record the result and the exact approved candidate.
+
+Promote the approved artifact bytes; do not rebuild. If filenames lose the RC
+suffix, detached signatures still verify those unchanged bytes, but checksum
+filenames must be updated and verified. Point the final Git tag at the approved
+RC commit. Inspect remote destination paths before distribution changes.
+
+Update and publish the [website](references/website.md), verify public download
+links and propagation, then announce. Prune superseded distributions only after
+the website points to the new release and archive availability is confirmed.
+Keep historical signing keys available for verification of old releases.
+
+For security releases, coordinate advisory timing with the PMC and ASF Security;
+use the companion `roller-security` skill when available. Public vote material
+must not expose undisclosed case details. The operator upgrade must be available
+when the advisory is published.
+
+## References and helpers
+
+- [ASF policy](references/asf-policy.md): authoritative sources and review boundaries.
+- [Signing](references/signing-key.md): explicit signer selection and verification.
+- [Distribution](references/dist-svn.md): staging, promotion and pruning.
+- [Vote and announcement](references/vote-and-announce.md): reusable message drafts.
+- [Website](references/website.md): source edits, rebuild and link verification.
+- [Release tooling](references/atr.md): evaluating Apache Trusted Releases.
+
+Resolve helper paths relative to this skill; when using the repository copy,
+they are under `skills/roller-release/scripts/`. Helpers do not commit or publish.

skills/roller-release/references/asf-policy.md

@@ -0,0 +1,45 @@
+<!--
+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
+
+    https://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.
+-->
+
+# Authoritative release policy
+
+Consult these sources when cutting a release; this skill is not a policy snapshot:
+
+- [Release policy](https://www.apache.org/legal/release-policy.html): source artifacts,
+  binding vote requirements, licensing and publication.
+- [Distribution policy](https://infra.apache.org/release-distribution.html): official
+  distribution channels, signatures, digests, download links and archive handling.
+- [Release signing](https://infra.apache.org/release-signing.html): key and signature guidance.
+- [Release publishing](https://infra.apache.org/release-publishing.html): operational steps.
+- [Roller release process](https://cwiki.apache.org/confluence/spaces/ROLLER/pages/75651/Release+Process):
+  project instructions; verify paths and commands against the current checkout.
+
+A source release is the approved artifact; binary packages are convenience
+artifacts. Release approval requires at least three positive binding votes and
+more positive binding votes than negative ones. The normal review period is at
+least 72 hours; consult the policy for exceptional expedited releases.
+
+Independently validate signed source packages, compile and test them, and review
+licensing. `check-release.sh` checks selected mechanical properties only. Presence
+of LICENSE and NOTICE does not prove that bundled material is correctly licensed.
+Inspect compiled artifacts, third-party content and exclusions in the actual
+source archive. Do not treat a historical release as an exemption from policy.
+
+Publish the artifacts that were approved. Rebuilding changes what voters reviewed
+and requires renewed approval. Use the official channels and verify public links
+before announcing availability. Keep per-release findings and corrective actions
+in release notes or the private coordination workspace as appropriate, not here.

skills/roller-release/references/atr.md

@@ -0,0 +1,36 @@
+<!--
+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
+
+    https://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.
+-->
+
+# Evaluating Apache Trusted Releases
+
+[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.
+
+Try a non-publishing rehearsal and establish how the chosen tool handles:
+
+- 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.
+
+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.

skills/roller-release/references/dist-svn.md

@@ -0,0 +1,59 @@
+<!--
+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
+
+    https://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.
+-->
+
+# Distribution staging and promotion
+
+Confirm the current project layout before preparing paths:
+
+```sh
+svn ls https://dist.apache.org/repos/dist/dev/roller/
+svn ls https://dist.apache.org/repos/dist/release/roller/
+```
+
+The conventional layout is `roller-<major.minor>/v<version>/` below each project
+root. RC suffixes are typically in archive filenames. Verify this convention for
+the target branch; do not infer paths from an older wiki example.
+
+Use separate user-selected working directories for dev and release SVN checkouts.
+Stage only the intended candidate archives and signature/checksum sidecars. Review
+`svn status` and `svn diff` before committing. Download staged files to a fresh
+directory and verify them before starting the vote. Development staging is publicly
+accessible even though it is not an official release; do not upload private notes.
+
+## Approved-candidate promotion
+
+Record the passed vote, source SVN revision, candidate filenames and destination.
+Use an SVN working copy or a single reviewed repository transaction to promote
+only that candidate. Preserve archive bytes and detached signatures. If removing
+an RC suffix from filenames, update the filename references in checksum sidecars
+and verify each digest against the unchanged archive.
+
+Do not blindly promote everything in a version directory: it may contain cancelled
+candidates or unrelated files. Verify the final inventory, signature fingerprints
+and checksum checks after promotion. Never rebuild to remove an RC suffix.
+
+Wait for distribution propagation and check the public download URLs, not merely
+SVN success. Follow the current
+[release publishing guidance](https://infra.apache.org/release-publishing.html)
+for timing. Update the website and verify its links before announcing.
+
+## Cleanup
+
+Remove cancelled candidate files only within the agreed cleanup scope, checking
+exact filenames first. For superseded official releases, confirm archive
+availability and update website links before pruning. Preserve the KEYS history.
+A successful delete does not remove copies already downloaded from public staging.

skills/roller-release/references/signing-key.md

@@ -0,0 +1,54 @@
+<!--
+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
+
+    https://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 signing
+
+Read the current [ASF signing guidance](https://infra.apache.org/release-signing.html)
+and [distribution policy](https://infra.apache.org/release-distribution.html).
+Select the acting release manager's key explicitly. Never copy another person's
+fingerprint or assume the default local key is suitable.
+
+Check ownership, expiry, revocation, algorithm and strength, including the signing
+subkey. For a new RSA signing key, use at least 4096 bits and an appropriate ASF
+identity. Keep private keys, passphrases, keyring inventories and local configuration
+backups outside the checkout. Let GnuPG prompt through the user's normal pinentry;
+do not capture a passphrase in shell commands or agent output.
+
+Publish the public key through the project's KEYS process and the release manager's
+ASF profile as applicable. The project KEYS file is available at
+<https://downloads.apache.org/roller/KEYS>. Add new public keys without removing
+historical signing keys. Verify fingerprints independently before trusting an import.
+
+Set `ROLLER_SIGNING_KEY` to the selected fingerprint and `VERSION` / `RC_SUFFIX`
+to the release inputs. Inspect the checkout's `assembly-release/sign-release.sh`
+usage; in versions supporting positional inputs, run from the repository root:
+
+```sh
+assembly-release/sign-release.sh "$VERSION" "$RC_SUFFIX"
+```
+
+The current script expects `ROLLER_SIGNING_KEY` in its environment. Export it
+explicitly in the release session. Confirm that the script signs with the intended
+key and uses an approved digest. Do not transplant an old signing script from
+release notes. Generate armored detached signatures and SHA-256 and/or SHA-512
+checksum sidecars; avoid legacy digest formats.
+
+Verify every archive's signature against its bytes and every checksum from the
+artifact directory. Check the expected fingerprint, not just GnuPG's exit status.
+A cryptographically valid signature does not itself establish signer identity or
+full release compliance. Keep the signer fingerprint in release execution notes
+and the vote draft, not as a fixed default in this skill.