"Release Managers" es un término general que abarca al conjunto de colaboradores de Kubernetes responsables de mantener las ramas de lanzamiento y de crear los lanzamientos utilizando las herramientas proporcionadas por SIG Release.
Las responsabilidades de cada rol se describen a continuación.
| Mailing List | Slack | Visibility | Usage | Membership |
|---|---|---|---|---|
| release-managers@kubernetes.io | #release-management (canal) / @release-managers (grupo de usuarios) | Público | Discusión pública para Release Managers | Todos los Release Managers (incluyendo Associates y SIG Chairs) |
| release-managers-private@kubernetes.io | N/A | Privado | Discusión privada para Release Managers privilegiados | Release Managers, liderazgo de SIG Release |
| security-release-team@kubernetes.io | #security-release-team (canal) / @security-rel-team (grupo de usuarios) | Privado | Coordinación de lanzamientos de seguridad con el Security Response Committee | security-discuss-private@kubernetes.io, release-managers-private@kubernetes.io |
Cierta información sobre los lanzamientos está sujeta a embargo y hemos definido una política sobre cómo se establecen dichos embargos. Por favor, consulta la Política de Embargo de Seguridad para obtener más información.
NOTA: El manual del Patch Release Team y el de Branch Managers se unificarán en un único documento más adelante.
Nota: La documentación puede hacer referencia al Patch Release Team y al rol de Branch Management. Estos dos roles se consolidaron en el rol de Release Managers.
Los requisitos mínimos para los Release Managers y Release Manager Associates son:
git y las invocaciones asociadas de la línea de comandos de git.Los Release Managers son responsables de:
x.y.z, donde z > 0)x.y.z, donde z = 0)k/releaseEste equipo trabaja en ocasiones en estrecha colaboración con el Security Response Committee y, por lo tanto, debe cumplir con las directrices establecidas en el Proceso de Lanzamiento de Seguridad.
Controles de acceso en GitHub: @kubernetes/release-managers
Menciones en GitHub: @kubernetes/release-engineering
To convertirse en Release Manager, primero se debe haber desempeñado el rol de Release Manager Associate. Los Associates ascienden a Release Manager al trabajar activamente en los lanzamientos durante varios ciclos y al:
Los Release Manager Associates son aprendices de los Release Managers, anteriormente conocidos como "Release Manager shadows". Son responsables de:
k/release: actualizar dependencias y familiarizarse con la base de código fuenteMenciones en GitHub: @kubernetes/release-engineering
Los colaboradores pueden convertirse en Associates demostrando lo siguiente:
k/release que mejoren nuestras interacciones con Testgrid, limpiar bibliotecas, etc.
Los SIG Release Chairs y Technical Leads son responsables de:
Se mencionan explícitamente aquí ya que son los propietarios de los diversos canales de comunicación y grupos de permisos (equipos de GitHub, acceso a GCP) para cada rol. Como tales, son miembros de la comunidad altamente privilegiados y tienen acceso a algunas comunicaciones privadas, que en ocasiones pueden estar relacionadas con divulgaciones de seguridad de Kubernetes.
Equipo de GitHub: @kubernetes/sig-release-leads
Los Branch Managers anteriores se pueden encontrar en el directorio de lanzamientos del repositorio kubernetes/sig-release dentro de release-x.y/release_team.md.
Ejemplo: 1.15 Release Team