Synchronize publishing of release artifact files
Nadie ha tomado este issue todavía.
- Lenguaje dominante
- Python
- Estrellas
- 61
- Forks
- 48
- Merge medio
- 1 h 22 min
- PR fusionados (30 d)
- 4
Descripción
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.
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Línea de trabajo
Comienza trazando la automatización de releases y los tres roles del equipo de releases descritos en el issue, incluidos los traspasos al servidor de descargas. Revisa los pasos del RM para producir archivos sigstore, actualizar la base de datos de releases con addfiles y anunciar un release. Se considerará terminado cuando el RM pueda activar un único paso final de publicación después de que todos los artefactos estén listos.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- python
- Área
- release
- Tipo de issue
- Nueva funcionalidad
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Estado de actividad
- Estancado
- Claridad
- Necesita aclaración
- Aptitud para principiantes
- 25/100