[v3-3-test] Support delegating providers release process to non-PMC committers (#69417) - #69634
Merged
Conversation
1 task
…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>
vatsrahul1001
force-pushed
the
backport-4d56e6c-v3-3-test
branch
from
July 9, 2026 07:53
84a6e92 to
dc47ef2
Compare
potiuk
marked this pull request as ready for review
July 12, 2026 23:44
potiuk
requested review from
bugraoz93,
jedcunningham,
jscheffl,
potiuk,
shahar1 and
vincbeck
as code owners
July 12, 2026 23:44
vatsrahul1001
added
the
changelog:skip
vatsrahul1001
pushed a commit
that referenced
this pull request
Aug 5, 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
3 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.
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.
(cherry picked from commit 4d56e6c)
Co-authored-by: Shahar Epstein 60007259+shahar1@users.noreply.github.com