Conversation
| ## Round 2 and Repairs | ||
|
|
||
| - If the tarball, signature, tag, or any release content changes after voting starts, prefer a new RC tag and a new vote round. | ||
| - If only the `.sha512` sidecar file is malformed and the user explicitly wants an in-place fix, update only that checksum file in `dist/dev`, verify `shasum -c`, and comment in the VOTE thread that the tarball and signature are unchanged. | ||
| - In-place checksum repair is weaker than issuing `rc.N+1`. Call out that tradeoff explicitly. |
There was a problem hiding this comment.
If any release artifact under vote needs to change, prefer cutting a new RC and restarting the vote.
For a malformed checksum sidecar, in-place repair should be treated only as an exceptional project decision, not the default release procedure. 🤔
|
|
||
| https://github.com/apache/opendal-reqsign/releases/tag/vX.Y.Z-rc.N | ||
|
|
||
| Please download, verify, and test. |
There was a problem hiding this comment.
May we also add a verify script in the repo(attach link here)?
There was a problem hiding this comment.
agents know how to verify
There was a problem hiding this comment.
Although agents know how to verify, but with a verify script or some verify guideline is more friendly for human voter, and make verify process more reproducible.
I'm not sure about how you use agents in the verify process, but I'm sure we should not rely on implicit agents behavior.
suyanhanx
left a comment
suyanhanx
left a comment
There was a problem hiding this comment.
I think we should be a bit more careful with this PR, especially since it defines part of our release process.
|
|
||
| https://github.com/apache/opendal-reqsign/releases/tag/vX.Y.Z-rc.N | ||
|
|
||
| Please download, verify, and test. |
There was a problem hiding this comment.
Although agents know how to verify, but with a verify script or some verify guideline is more friendly for human voter, and make verify process more reproducible.
I'm not sure about how you use agents in the verify process, but I'm sure we should not rely on implicit agents behavior.
| ## Round 2 and Repairs | ||
|
|
||
| - If the tarball, signature, tag, or any release content changes after voting starts, prefer a new RC tag and a new vote round. | ||
| - If only the `.sha512` sidecar file is malformed and the user explicitly wants an in-place fix, update only that checksum file in `dist/dev`, verify `shasum -c`, and comment in the VOTE thread that the tarball and signature are unchanged. | ||
| - In-place checksum repair is weaker than issuing `rc.N+1`. Call out that tradeoff explicitly. |
There was a problem hiding this comment.
If any release artifact under vote needs to change, prefer cutting a new RC and restarting the vote.
For a malformed checksum sidecar, in-place repair should be treated only as an exceptional project decision, not the default release procedure. 🤔
2 participants
This adds a repo-local
reqsign-releaseskill so release preparation and execution can be driven from a single self-contained workflow instead of relying on personal notes.It captures the
opendal-reqsignspecific release sequence, GitHub Discussion templates, ASF dist/SVN conventions, and finalcargo publish --workspacebehavior. It also records the recent.sha512path pitfall so future release candidates generate portable checksum files.