You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tooling.apache.org by ar...@apache.org on 2026/10/02 15:20:56 UTC
(tooling-trusted-releases) branch arm updated: #1706 - update links out to external docs
This is an automated email from the ASF dual-hosted git repository.
alitheg pushed a commit to branch arm
in repository https://gitbox.apache.org/repos/asf/tooling-trusted-releases.git
The following commit(s) were added to refs/heads/arm by this push:
new 4e53f451 #1706 - update links out to external docs
4e53f451 is described below
commit 4e53f45136b0b2f85d78dadfbfd61fd5af448a25
Author: Alastair McFarlane <ar...@apache.org>
AuthorDate: Fri Oct 2 16:20:28 2026 +0100
#1706 - update links out to external docs
---
atr/docs/moving-to-atr.md | 4 ++--
atr/docs/podling-releases.md | 2 +-
atr/docs/projects.md | 4 ++--
atr/docs/release-process-description.md | 2 +-
atr/docs/vote-phase.md | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/atr/docs/moving-to-atr.md b/atr/docs/moving-to-atr.md
index 062299b8..5934fc0f 100644
--- a/atr/docs/moving-to-atr.md
+++ b/atr/docs/moving-to-atr.md
@@ -46,7 +46,7 @@ links to the relevant page.
## What stays the same
* The PMC still votes on each release, the vote thread is still on the project's mailing list,
- and whose votes are binding is still a matter of ASF policy. Podlings still vote twice, as described in
+ and whose votes are binding is still a matter of [ASF policy](https://www.apache.org/legal/release-policy.html#release-approval). Podlings still vote twice, as described in
[Podling releases](podling-releases).
* Each release manager still signs the artifacts with their own OpenPGP key, and the committee
still publishes a single `KEYS` file at `svn:dist:release`. See [The KEYS file](#the-keys-file)
@@ -89,7 +89,7 @@ upload credentials. In addition, as a PMC coming from the traditional process, c
## The KEYS file
-Signing releases is done with individual keys, as described in [Signing artifacts](signing-artifacts). Separately, each committee publishes a single `KEYS` file listing the public keys that its release managers sign with. The file lives at `https://dist.apache.org/repos/dist/release/<committee>/KEYS`, is managed independently of any individual release, and is what downstream users fetch to verify release signatures. When you upload your key to ATR and associate it with a committee, it be [...]
+Signing releases is done with individual keys, as described in [Signing artifacts](signing-artifacts). Separately, each committee publishes a single [`KEYS` file](https://infra.apache.org/release-signing.html#keys-policy) listing the public keys that its release managers sign with. The file lives at `https://dist.apache.org/repos/dist/release/<committee>/KEYS`, is managed independently of any individual release, and is what downstream users fetch to verify release signatures. When you up [...]
Committee members choose how the file is kept in step with ATR, using the KEYS file management setting on the committee's page. There are three modes:
diff --git a/atr/docs/podling-releases.md b/atr/docs/podling-releases.md
index 18e8b0eb..5b184cd1 100644
--- a/atr/docs/podling-releases.md
+++ b/atr/docs/podling-releases.md
@@ -17,7 +17,7 @@
A ***Podling*** is a project in the Apache Incubator, and its committee is a ***PPMC***. A
podling release goes through the same compose, vote, and finish phases as any other release, but
-incubation policy adds some requirements. The main one is that a podling release must be approved
+[incubation policy](https://incubator.apache.org/policy/incubation.html#releases) adds some requirements. The main one is that a podling release must be approved
twice: first by the podling's own PPMC, and then by the Incubator PMC. ATR runs these as two
rounds of voting on the same candidate.
diff --git a/atr/docs/projects.md b/atr/docs/projects.md
index c83f5117..4c4a75b5 100644
--- a/atr/docs/projects.md
+++ b/atr/docs/projects.md
@@ -38,7 +38,7 @@ sections below define the major terminology as it is used in ATR.
A ***Committee*** in ATR is a PMC (Project Management Committee), or a PPMC (Podling Project Management Committee). The concept of a committee is
important in ATR because both its members and all release managers have elevated permissions compared to non-member and non-release-manager
-committers. PMC members have ***binding release votes*** and can be ***Release Managers***; designated committers may be explicitly allowed to be
+committers. PMC members have [***binding release votes***](https://www.apache.org/legal/release-policy.html#release-approval) and can be ***Release Managers***; designated committers may be explicitly allowed to be
Release Managers too. Committee status is determined outside of the ATR system, by either the Board of Directors for PMCs or by the Incubator PMC
for PPMCs.
@@ -67,7 +67,7 @@ important for PMCs to acknowledge their *true number of projects*.
* See [Trusted Publishing](trusted-publishing).
Projects are initially defined based on ***DOAP files*** and observed release activity. Once a PMC uses ATR, projects are defined both within the
-platform and via `.asf.yaml`. See [Project configuration](project-configuration) for the metadata fields and naming requirements. The tooling team
+platform and via [`.asf.yaml`](https://github.com/apache/infrastructure-asfyaml#atrsync). See [Project configuration](project-configuration) for the metadata fields and naming requirements. The tooling team
will work with PMCs to properly update their projects.
## Release
diff --git a/atr/docs/release-process-description.md b/atr/docs/release-process-description.md
index 01342449..7c71ad63 100644
--- a/atr/docs/release-process-description.md
+++ b/atr/docs/release-process-description.md
@@ -20,7 +20,7 @@
## Releases
-The ASF releases open source software. The ATR platform helps PMCs release their project's artifacts through several stages:
+The ASF releases open source software under its [release policy](https://www.apache.org/legal/release-policy.html). The ATR platform helps PMCs release their project's artifacts through several stages:
1. ***Candidate***. Guiding a ***Release Candidate*** through the phases of ASF Governance to make a Release is the primary purpose of the ATR platform.
* ***Compose***. ***Release Artifacts*** are assembled and checked for compliance, and the Release Manager iterates on them until the
diff --git a/atr/docs/vote-phase.md b/atr/docs/vote-phase.md
index 0b7d3295..fd0b5588 100644
--- a/atr/docs/vote-phase.md
+++ b/atr/docs/vote-phase.md
@@ -37,7 +37,7 @@ Both the Release Manager and the wider PMC have a part to play in this phase:
* The ***Release Manager*** starts the vote, links to the artifacts under vote, and, when the
vote is over, tallies the result and resolves it.
* PMC members review the candidate and cast their votes on the vote thread. Whose votes are
- binding is a matter of ASF policy.
+ binding is a matter of [ASF policy](https://www.apache.org/legal/release-policy.html#release-approval).
## Casting and resolving the vote
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@tooling.apache.org
For additional commands, e-mail: commits-help@tooling.apache.org