Support delegating providers release process to non-PMC committers - #69417
Merged
Conversation
shahar1
requested review from
bugraoz93,
jedcunningham,
jscheffl,
potiuk and
vincbeck
as code owners
July 5, 2026 19:44
potiuk
reviewed
Jul 5, 2026
The provider release cycle currently assumes a PMC member drives every step, yet ASF policy only reserves the binding vote and dist/release publication to the PMC. Documenting a clear split lets a non-PMC committer run the bulk of the process while the PMC signs, publishes to PyPI, and casts the binding votes — both spreading the release-manager load and giving prospective PMC members a supervised on-ramp. Generated-by: Claude Code (Opus 4.8 1M context)
A PMC member who only signs artifacts built by someone else does not actually know what they are signing, per ASF release policy guidance on owned/controlled hardware. Move the build step into the PMC block so the same PMC member builds, signs, commits to dist/dev, and publishes the PyPI RC without handing control back to the Delegate.
shahar1
force-pushed
the
delegate-providers-release
branch
from
July 7, 2026 16:18
8b5c43c to
9b5247f
Compare
potiuk
approved these changes
Jul 8, 2026
Contributor
Backport successfully created: v3-3-testNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
|
github-actions Bot
pushed a commit
to aws-mwaa/upstream-to-airflow
that referenced
this pull request
Jul 8, 2026
…ommitters (apache#69417) * Add framework for delegating providers release to non-PMC committers The provider release cycle currently assumes a PMC member drives every step, yet ASF policy only reserves the binding vote and dist/release publication to the PMC. Documenting a clear split lets a non-PMC committer run the bulk of the process while the PMC signs, publishes to PyPI, and casts the binding votes — both spreading the release-manager load and giving prospective PMC members a supervised on-ramp. Generated-by: Claude Code (Opus 4.8 1M context) * Merge the provider build step into the PMC-owned release block A PMC member who only signs artifacts built by someone else does not actually know what they are signing, per ASF release policy guidance on owned/controlled hardware. Move the build step into the PMC block so the same PMC member builds, signs, commits to dist/dev, and publishes the PyPI RC without handing control back to the Delegate. (cherry picked from commit 4d56e6c) Co-authored-by: Shahar Epstein <60007259+shahar1@users.noreply.github.com>
aws-airflow-bot
pushed a commit
to aws-mwaa/upstream-to-airflow
that referenced
this pull request
Jul 9, 2026
…ommitters (apache#69417) * Add framework for delegating providers release to non-PMC committers The provider release cycle currently assumes a PMC member drives every step, yet ASF policy only reserves the binding vote and dist/release publication to the PMC. Documenting a clear split lets a non-PMC committer run the bulk of the process while the PMC signs, publishes to PyPI, and casts the binding votes — both spreading the release-manager load and giving prospective PMC members a supervised on-ramp. Generated-by: Claude Code (Opus 4.8 1M context) * Merge the provider build step into the PMC-owned release block A PMC member who only signs artifacts built by someone else does not actually know what they are signing, per ASF release policy guidance on owned/controlled hardware. Move the build step into the PMC block so the same PMC member builds, signs, commits to dist/dev, and publishes the PyPI RC without handing control back to the Delegate. (cherry picked from commit 4d56e6c) Co-authored-by: Shahar Epstein <60007259+shahar1@users.noreply.github.com>
Lee-W
added a commit
to astronomer/airflow
that referenced
this pull request
Jul 9, 2026
vatsrahul1001
pushed a commit
that referenced
this pull request
Jul 9, 2026
…ommitters (#69417) * Add framework for delegating providers release to non-PMC committers The provider release cycle currently assumes a PMC member drives every step, yet ASF policy only reserves the binding vote and dist/release publication to the PMC. Documenting a clear split lets a non-PMC committer run the bulk of the process while the PMC signs, publishes to PyPI, and casts the binding votes — both spreading the release-manager load and giving prospective PMC members a supervised on-ramp. Generated-by: Claude Code (Opus 4.8 1M context) * Merge the provider build step into the PMC-owned release block A PMC member who only signs artifacts built by someone else does not actually know what they are signing, per ASF release policy guidance on owned/controlled hardware. Move the build step into the PMC block so the same PMC member builds, signs, commits to dist/dev, and publishes the PyPI RC without handing control back to the Delegate. (cherry picked from commit 4d56e6c) Co-authored-by: Shahar Epstein <60007259+shahar1@users.noreply.github.com>
Lee-W
added a commit
to astronomer/airflow
that referenced
this pull request
Jul 9, 2026
Lee-W
added a commit
to astronomer/airflow
that referenced
this pull request
Jul 9, 2026
Lee-W
added a commit
to astronomer/airflow
that referenced
this pull request
Jul 9, 2026
Lee-W
added a commit
to astronomer/airflow
that referenced
this pull request
Jul 9, 2026
Lee-W
added a commit
to astronomer/airflow
that referenced
this pull request
Jul 9, 2026
Lee-W
added a commit
to astronomer/airflow
that referenced
this pull request
Jul 9, 2026
Lee-W
added a commit
to astronomer/airflow
that referenced
this pull request
Jul 9, 2026
Lee-W
added a commit
to astronomer/airflow
that referenced
this pull request
Jul 9, 2026
…non-PMC committers (apache#69417)
potiuk
pushed a commit
that referenced
this pull request
Jul 12, 2026
…ommitters (#69417) (#69634) * Add framework for delegating providers release to non-PMC committers The provider release cycle currently assumes a PMC member drives every step, yet ASF policy only reserves the binding vote and dist/release publication to the PMC. Documenting a clear split lets a non-PMC committer run the bulk of the process while the PMC signs, publishes to PyPI, and casts the binding votes — both spreading the release-manager load and giving prospective PMC members a supervised on-ramp. Generated-by: Claude Code (Opus 4.8 1M context) * Merge the provider build step into the PMC-owned release block A PMC member who only signs artifacts built by someone else does not actually know what they are signing, per ASF release policy guidance on owned/controlled hardware. Move the build step into the PMC block so the same PMC member builds, signs, commits to dist/dev, and publishes the PyPI RC without handing control back to the Delegate. (cherry picked from commit 4d56e6c) Co-authored-by: Shahar Epstein <60007259+shahar1@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human Summary
This PR sets up a structured framework for delegating the providers release process to non-PMC committers.
It has been practiced in the past (so nothing new here in terms of consensus, I hope), but it's better
when it's laid out as part of the actual instructions.
AI Summary
Click here
Documents an explicit split of the providers release cycle between a non-PMC **Delegate** and an overseeing **PMC member**, grounded in ASF policy (the Release Manager need not be PMC; only binding votes and `dist/release` publication are PMC-reserved). Changes are confined to `dev/README_RELEASE_PROVIDERS.md`:dist/dev→ publish RC to PyPI) are grouped into one contiguous PMC block to avoid bouncing control back and forth, with the PMC handingfiles/packages.txtback to the Delegate for the vote email.dist/devcommit, PyPI RC,[VOTE]email,[RESULT][VOTE],dist/release, final PyPI, announcements) so a reader landing directly on a step knows who owns it in the delegated flow.IS_RM_VOTE_BINDINGflag: a non-PMC Delegate sets it tofalse, which drops the "(binding)" claim and adds a one-line clarification to the email body that a PMC member will cast the binding votes.Anchor links verified; doctoc TOC regenerated (no drift); all prek hooks pass.
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.8 1M context) following the guidelines