This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch v3-3-test
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/v3-3-test by this push:
new 50c5a2c34ec [v3-3-test] Document the access a first-time provider
release manager must request (#72169) (#72178)
50c5a2c34ec is described below
commit 50c5a2c34ec87057ee7a5a25bc839c6da40b8bdb
Author: github-actions[bot]
<41898282+github-actions[bot]@users.noreply.github.com>
AuthorDate: Fri Aug 28 10:47:15 2026 +0200
[v3-3-test] Document the access a first-time provider release manager must
request (#72169) (#72178)
Two steps of the release depend on access someone else has to grant, and
both
fail in ways that are hard to read mid-release. Add a pre-reqs step to
cover them both.
(cherry picked from commit a26f17fcef435c0fbf0693401305d7b7f13d15a3)
Co-authored-by: Niko Oliveira <[email protected]>
---
dev/README_RELEASE_PROVIDERS.md | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/dev/README_RELEASE_PROVIDERS.md b/dev/README_RELEASE_PROVIDERS.md
index 2aceaeed98f..34c2132bf0f 100644
--- a/dev/README_RELEASE_PROVIDERS.md
+++ b/dev/README_RELEASE_PROVIDERS.md
@@ -24,6 +24,7 @@
- [What the provider distributions are](#what-the-provider-distributions-are)
- [Decide when to release](#decide-when-to-release)
- [Delegating release duties to a non-PMC
committer](#delegating-release-duties-to-a-non-pmc-committer)
+- [Prerequisites (first-time release
managers)](#prerequisites-first-time-release-managers)
- [Collect ambiguities during the release (for a follow-up doc
PR)](#collect-ambiguities-during-the-release-for-a-follow-up-doc-pr)
- [Special procedures (done very
infrequently)](#special-procedures-done-very-infrequently)
- [Bump min Airflow version for
providers](#bump-min-airflow-version-for-providers)
@@ -129,6 +130,27 @@ remains the party accountable for the release under ASF
policy.
> Delegate sees exactly how it is done. The aim is simply that these steps are
> familiar rather than
> a surprise if and when the Delegate later becomes a PMC member and runs them
> for real.
+# Prerequisites (first-time release managers)
+
+Two steps of the release depend on access that you must request. Request both
**before** you start your first
+release. They only need to be done once for new release managers, but may take
some time.
+
+* **PyPI: membership of the `apache-airflow` organization.** The
+ [RC upload](#publish-the-regular-distributions-to-pypi-release-candidates)
and the
+ [final upload](#publish-the-packages-to-pypi) steps push to the
`apache-airflow-providers-*` PyPi projects.
+ Ask a PMC member who is an owner of the Apache Airflow PyPI organization to
invite your account. Then
+ accept the invitation. Confirm it worked by opening [your PyPI
projects](https://pypi.org/manage/projects/)
+ and you should see many Airflow related projects (170+ at the time of
writing).
+
+* **GitHub: the docs-publishing allowlist.** The
+ [`publish-docs-to-s3.yml`](../.github/workflows/publish-docs-to-s3.yml)
workflow gates its
+ `build-info` job on `github.event.sender.login`, and every other job depends
on `build-info`. If
+ your GitHub handle is not in that list, dispatching the workflow (as
+ [Prepare documentation in Staging](#prepare-documentation-in-staging) does)
reports **no error at
+ all**. The run is created and every job is silently skipped, which is easy
to mistake for a
+ successful publish. Add your handle with a one-line PR to that file and
merge it to main. Example:
+ [#71848](https://github.com/apache/airflow/pull/71848).
+
# Collect ambiguities during the release (for a follow-up doc PR)
These instructions are imperfect. Every release uncovers at least one command
