Synchronize publishing of release artifact files
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by mapping the release automation and the three release team roles described in the issue, including the download server handoffs. Review the RM steps for producing sigstore files, updating the release database with addfiles, and announcing a release. Done should mean the RM can trigger one final publication step after every artifact is ready.
Written by the indexing model from the issue text.
Description
There are some timing holes in the current cPython release process which, while somewhat minor, could be tightened up. Currently, there are three release team member roles in producing downloable artifacts for a release and each is responsible for ensuring that their artifacts have been moved into the final file system location on the download server. Once they have done that, those subsets of the release artifacts become immediately available to download, independent of any release notice. Since the three release team members in general work asynchronously once the RM tags the release engineering branch, it is unpredictable when various release files appear on the download server. The release automation waits at various points for the artificats to show up there, also independent of any manual (email) notification to the RM.
It is up to the RM to finish things off and produce the sigstore files, update the release database (addfiles), and announce the release. But because the URLs of the downloadable files for each release are generally predictable, there are some downstream users and likely bots that can poll for these files becoming available. This can, on infrequent occasions, be an issue if some problem is discovered late in the release process, for example, a problem that is discovered while testing the macOS installer or the Windows binaries, that may require a re-spin of the entire release.
Granted users shouldn't be using things before they are officially announced, but they will. It would be better if we modified the process somewhat so the RM is responsible for triggering the final step of making all of the downloadable artifacts publically available after all the pieces are in place.
- Dominant language
- Python
- Stars
- 61
- Forks
- 48
- Avg merge
- 1h 22m
- Merged PRs (30d)
- 4
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from python/release-tools
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
python/release-tools#401 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
python/release-tools#434 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
python/release-tools#417 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 68/100
python/release-tools#397 ·
-
bug
python/release-tools#286 · 1 assignee ·
All issues in python/release-tools
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
learningequality/ricecooker#747 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
BSData/horus-heresy-3rd-edition#3171 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
run-llama/llama_index#23199 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
KhronosGroup/glTF-Blender-IO#2769 ·