Synchronize publishing of release artifact files

[ned-deily]

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.

[hugovk]

One idea: instead of putting all files directly in their final home (such as https://www.python.org/ftp/python/3.14.0/), put them in a staging directory first (perhaps https://www.python.org/ftp/python/3.14.0-staging/ or something with a name to clearly indicate they're not ready yet), and only move them all to https://www.python.org/ftp/python/3.14.0/ when all the files are ready and uploaded.

[ned-deily]

When this issue was brought up before I recall that using a staging location would cause some problems for the Windows steps of the release process. @zooba, is that right?

[zooba]

I'm sure whatever I was concerned about is written down somewhere, but the only ones I can think of now are the install/download tests.

Given how the CDN works, I'd prefer a staging directory to be outside of the HTTP/FTP handlers, so that they're only accessible via SSH.

Possibly I was more concerned about a suggestion to move it all into a combined GitHub build process? I think that came up about the same time (I much prefer Azure Pipelines here as it has better user management and approval controls, so that signed builds of random code can't be done without notifying the release team, and the team that defines the release team isn't the same as the release team).