You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tooling.apache.org by sb...@apache.org on 2026/08/28 17:34:03 UTC
(tooling-trusted-releases) branch sbp updated (854abe49 -> cab39ac7)
This is an automated email from the ASF dual-hosted git repository.
sbp pushed a change to branch sbp
in repository https://gitbox.apache.org/repos/asf/tooling-trusted-releases.git
discard 854abe49 Remove documentation about the superseded ATR SVN test area
add 3863dd51 Fix key publishing in manual mode
add 28e5e289 Bump astral-sh/setup-uv from 9.0.0 to 10.0.1
add 9adac34b Bump docker/setup-buildx-action from 4.2.0 to 4.3.0
new cab39ac7 Remove documentation about the superseded ATR SVN test area
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (854abe49)
\
N -- N -- N refs/heads/sbp (cab39ac7)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
.github/workflows/analyze.yml | 2 +-
.github/workflows/build.yml | 2 +-
.github/workflows/generatesbom.yml | 2 +-
atr/post/keys.py | 3 ++-
atr/storage/writers/keys.py | 26 +++++++++++++++++---------
tests/unit/test_keys_writer.py | 32 ++++++++++++++++++++++++++++++++
6 files changed, 54 insertions(+), 13 deletions(-)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@tooling.apache.org
For additional commands, e-mail: commits-help@tooling.apache.org
(tooling-trusted-releases) 01/01: Remove documentation about the superseded ATR SVN test area
Posted by sb...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
sbp pushed a commit to branch sbp
in repository https://gitbox.apache.org/repos/asf/tooling-trusted-releases.git
commit cab39ac7ddd3aebcd1b9bd32bfa96f9dae1113b7
Author: Sean B. Palmer <se...@miscoranda.com>
AuthorDate: Fri Aug 28 17:55:30 2026 +0100
Remove documentation about the superseded ATR SVN test area
---
atr/docs/promoting-to-release.md | 97 +++++++++-------------------------------
atr/docs/staging-and-voting.md | 2 +-
atr/docs/user-guide.md | 4 +-
3 files changed, 25 insertions(+), 78 deletions(-)
diff --git a/atr/docs/promoting-to-release.md b/atr/docs/promoting-to-release.md
index 551151de..2898f1f1 100644
--- a/atr/docs/promoting-to-release.md
+++ b/atr/docs/promoting-to-release.md
@@ -9,113 +9,60 @@
**Sections**:
* [Overview](#overview)
-* [Prerequisites](#prerequisites)
-* [Moving the files](#moving-the-files)
-* [Verifying the move](#verifying-the-move)
+* [Publishing to SVN](#publishing-to-svn)
+* [Announcing](#announcing)
* [Removing superseded releases](#removing-superseded-releases)
* [The KEYS file](#the-keys-file)
## Overview
-SVN is not an intrinsic part of the ATR release process until publication. The candidate is staged in ATR and voted on there, whatever method was used to upload the files, as described in [Staging and voting](staging-and-voting). Where ATR publishes to at the end of that process differs between Alpha and Beta.
-
-### Alpha
-
-During Alpha, when the ATR workflow completes, i.e. when the vote is resolved and the release announced, ATR commits the approved artifacts to its own area of the Apache distribution SVN repository:
-
-* TLP: `https://dist.apache.org/repos/dist/atr/<committee>/`
-* Podling: `https://dist.apache.org/repos/dist/atr/incubator/<committee>/`
-
-Files in `/dist/atr/` are **not mirrored** by the Apache distribution mirror network and are not considered official releases. To make the release official and available on `downloads.apache.org` and the mirror network, a project committer with write permissions on the destination must move the files into the canonical release area:
+SVN is not an intrinsic part of the ATR release process until publication. The candidate is staged in ATR and voted on there, whatever method was used to upload the files, as described in [Staging and voting](staging-and-voting). When the vote passes, the release moves to the finish phase, in which ATR commits the approved artifacts to the canonical release area of the Apache distribution SVN repository:
* TLP: `https://dist.apache.org/repos/dist/release/<committee>/`
* Podling: `https://dist.apache.org/repos/dist/release/incubator/<committee>/`
-The move is a manual SVN step performed once per release, and the rest of this page describes it. ATR does not do it for you during Alpha because automatic publishing to SVN is being tested: `/dist/atr/` is a testing area, not a release area.
-
-### Beta
-
-From Beta, ATR publishes the approved artifacts directly to `/dist/release/` after a successful vote, and the manual step described on this page is no longer needed. The finish page for your release shows which area your ATR instance publishes to.
-
-## Prerequisites
+Files committed there are served from `downloads.apache.org` and the download CDN, and are picked up by `archive.apache.org` automatically. No manual SVN step is needed to publish a release.
-You need a working `svn` client and your ASF committer credentials. The destination path under `/dist/release/` must be writable by your ASF user. You can check committee membership on [the Whimsy roster](https://whimsy.apache.org/roster/).
+**Podling note**: for a podling, prefix the committee path with `incubator/` in every path below, including the `downloads.apache.org` URL.
-Before you start, confirm what ATR published and where. List the source directory with:
+## Publishing to SVN
-```shell
-svn ls https://dist.apache.org/repos/dist/atr/<committee>/
-```
-
-**Podling note**: For a podling, prefix the committee path with `incubator/`. Podlings replace `release/<committee>/` with `release/incubator/<committee>/` everywhere below. The source paths under `atr/incubator/<committee>/` follow the same shape.
-
-You should also decide the destination layout. Two common conventions exist. The first is a flat layout that matches what ATR produced, where files sit directly under `release/<committee>/`. The second is a per version subdirectory, where files live at `release/<committee>/<version>/`_file_. Most TLPs use the per version layout. Stick to whatever your project has used for previous releases, which you can check with:
+Publication happens in the finish phase, once the vote has resolved successfully. There are two ways to trigger it:
-```shell
-svn ls https://dist.apache.org/repos/dist/release/<committee>/
-```
+* Automatically, by selecting "Automatically publish to SVN when this vote resolves" when starting the vote. This option is offered when a committee member starts a non-expedited vote in email or Trusted Vote mode.
+* Manually, by pressing the publish button on the finish page for the release.
-## Moving the files
+The finish page shows the destination, and the resulting SVN revision and URL once publication completes.
-There are two general ways to perform the move. Choose based on whether the destination layout matches the source.
+By default the files are placed in a per release subdirectory, `release/<committee>/<project>-<version>/`, except for a committee's top level project, whose files go directly into `release/<committee>/`. Projects can configure this layout with the download path suffix in their release policy, using the `{{PROJECT_KEY}}`, `{{VERSION}}`, and `{{MAJOR_VERSION}}` tokens, and the release manager can adjust the suffix when publishing manually.
-Both `svn move` and `svnmucc mv` record copyfrom metadata, linking each file in `dist/release` to the exact path and revision that it was moved from in `dist/atr`. This preserves the provenance of the artifacts across the move, and can be inspected with `svn log -v`. Do not download and re-import the files instead, as that would break the link.
+## Announcing
-### Option A: flat to flat
+A release cannot be announced until it has been published to SVN. When you announce, ATR verifies that the published artifacts are reachable on the download servers, and asks you to try again later if they have not finished propagating. Once verified, ATR sends the announcement email and adds the release to the release catalog.
-If the destination layout matches the source layout, a single `svn move` from URL to URL moves every artifact for one version in one revision. List each source URL explicitly so that unrelated files in `/dist/atr/<committee>/`, e.g. artifacts from other versions, are left alone:
-
-```shell
-svn move -m "Promote <committee> <version> to release" \
- https://dist.apache.org/repos/dist/atr/<committee>/<artifact>.tar.gz \
- https://dist.apache.org/repos/dist/atr/<committee>/<artifact>.tar.gz.asc \
- https://dist.apache.org/repos/dist/atr/<committee>/<artifact>.tar.gz.sha256 \
- https://dist.apache.org/repos/dist/release/<committee>/
-```
-
-Multiple sources moved to a single destination directory commit atomically as one revision.
-
-### Option B: flat to per version subdirectory
-
-If you need to place files under a new _version_ directory, or you need to rename anything in flight, use `svnmucc`. This is the _Multiple URL Command Client_, and it ships with the standard `subversion` package. It can perform many URL operations in a single atomic revision:
-
-```shell
-svnmucc -m "Promote <committee> <version> to release" \
- mkdir https://dist.apache.org/repos/dist/release/<committee>/<version> \
- mv https://dist.apache.org/repos/dist/atr/<committee>/<artifact>.tar.gz \
- https://dist.apache.org/repos/dist/release/<committee>/<version>/<artifact>.tar.gz \
- mv https://dist.apache.org/repos/dist/atr/<committee>/<artifact>.tar.gz.asc \
- https://dist.apache.org/repos/dist/release/<committee>/<version>/<artifact>.tar.gz.asc \
- mv https://dist.apache.org/repos/dist/atr/<committee>/<artifact>.tar.gz.sha256 \
- https://dist.apache.org/repos/dist/release/<committee>/<version>/<artifact>.tar.gz.sha256
-```
-
-Drop the `mkdir` line if the version directory already exists. `svnmucc` will refuse with error `E160020` if it does.
-
-## Verifying the move
-
-After the commit, list both directories and confirm that the artifacts have moved:
+You can also verify the publication yourself:
```shell
svn ls https://dist.apache.org/repos/dist/release/<committee>/
-svn ls https://dist.apache.org/repos/dist/atr/<committee>/
```
-The artifacts should appear under `release/` and be gone from `atr/`. The files should soon become visible at `https://downloads.apache.org/<committee>/...`.
+The files should soon become visible at `https://downloads.apache.org/<committee>/...`.
## Removing superseded releases
-Apache distribution policy is that `/dist/release/` should hold only the current release of each line, with everything older moved to `archive.apache.org`. Releases committed to `/dist/release/` are picked up by the archive automatically, so you do not have to copy them there yourself. You do, however, have to delete the superseded ones:
+Apache distribution policy is that `/dist/release/` should hold only the current release of each line, with everything older moved to `archive.apache.org`. Releases committed to `/dist/release/` are picked up by the archive automatically, so you do not have to copy them there yourself. You do, however, have to delete the superseded ones. What to delete depends on the layout your project publishes to, described above. With the default layout for a project that is not the committee's top l [...]
```shell
svn rm -m "Remove superseded <committee> <previous-version>" \
- https://dist.apache.org/repos/dist/release/<committee>/<previous-version>
+ https://dist.apache.org/repos/dist/release/<committee>/<project>-<previous-version>
```
-Do this as a separate commit, after promotion, once you have verified that the new release is reachable.
+A top level project's files sit directly in the committee directory, so list each superseded file in the `svn rm` command instead.
+
+Do this once you have verified that the new release is reachable. Archiving a release in ATR records the archival in the release catalog, but does not currently remove the files from `/dist/release/`, so this step remains manual.
## The KEYS file
-The `KEYS` file lives at `https://dist.apache.org/repos/dist/release/<committee>/KEYS` and is managed independently of any individual release. ATR publishes its own version into `dist/atr/<committee>/KEYS` during Alpha as long as `dist/atr/<committee>` already exists. This file is the result of attempting to import the `dist/release` version of `KEYS`, augmenting it with any keys which have been uploaded and associated with this committee by users on ATR, and then formatting it cleanly. [...]
+The `KEYS` file lives at `https://dist.apache.org/repos/dist/release/<committee>/KEYS` and is managed independently of any individual release. Depending on a setting chosen by committee members on the committee's page in ATR, either ATR maintains and publishes this file from the keys that users have uploaded and associated with the committee, or ATR follows the copy managed directly in SVN.
-If you want to use ATR's version of the `KEYS` file, you can move it to the `dist/release` area in similar ways to the above. You must ensure that the public keys of any keypairs used to sign a release are present in your `dist/release` `KEYS` file, no matter its origin, before you publish signed artifacts to `dist/release`. When ATR goes to Beta, we will review how `KEYS` files are managed and published, and this process will likely change.
+Whichever way the file is managed, the public keys of any keypairs used to sign a release must be present in the committee's `KEYS` file before you publish signed artifacts.
diff --git a/atr/docs/staging-and-voting.md b/atr/docs/staging-and-voting.md
index df3ab82c..2c5357fd 100644
--- a/atr/docs/staging-and-voting.md
+++ b/atr/docs/staging-and-voting.md
@@ -50,4 +50,4 @@ The SVN import is one option among four, and we expect most release managers to
Before ATR published anything to SVN, we advised release managers to upload their candidate to `dist/dev`, copy the files into ATR, hold the vote, and then move the files from `dist/dev` to `dist/release` to publish. Under that workflow it was the release manager's responsibility to make sure that the files in `dist/dev` matched the ones in ATR for the duration of the vote.
-That workflow still works, but it is no longer necessary, because ATR now publishes the approved artifacts itself once the vote passes: to `dist/atr` during Alpha, and directly to `dist/release` from Beta. Unless you have a specific reason to keep using `dist/dev`, you do not need it when using ATR.
+That workflow still works, but it is no longer necessary, because ATR now publishes the approved artifacts itself, directly to `dist/release`, after the vote passes. Unless you have a specific reason to keep using `dist/dev`, you do not need it when using ATR.
diff --git a/atr/docs/user-guide.md b/atr/docs/user-guide.md
index d8572df2..67b3835f 100644
--- a/atr/docs/user-guide.md
+++ b/atr/docs/user-guide.md
@@ -62,8 +62,8 @@ The ASF releases open source software. The ATR platform helps PMCs release their
* ***Vote***. In this phase the PMC votes on the release and approves (or not). Votes may be canceled. Once the vote passes it is ready to publish.
The artifacts being voted on remain in ATR for the duration of the vote, and vote emails should link to them there. See [Staging and voting](staging-and-voting).
* ***Finish***. In this phase the Release Artifacts are committed to the Apache distribution SVN repository and announcement is deferred until the artifacts have made it
- onto the download servers. The announcement is sent and the artifacts published to the Release Catalog. During Alpha the commit goes to `svn:dist:atr` and a
- manual move is needed to publish, as described in [Promoting to release](promoting-to-release); from Beta the commit goes directly to `svn:dist:release`.
+ onto the download servers. The announcement is sent and the artifacts published to the Release Catalog. The commit goes directly to `svn:dist:release`,
+ as described in [Promoting to release](promoting-to-release).
2. ***Released***. Releases that are released are active and cataloged and available via both a standard catalog api and at the proper urls using the CDN and download servers.
Releases that use the current legacy methods skipping the ATR are also cataloged,
3. ***Archived***. All cataloged releases may be archived using the ATR platform or by direct removal from `svn:dist:release`.
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@tooling.apache.org
For additional commands, e-mail: commits-help@tooling.apache.org