Resumen

  • Las políticas de Mozilla distinguen la aprobación de un responsable o par de módulo, el permiso personal de repositorio, la integración de un cambio y la gestión de hitos y árboles por Release Drivers.
  • Un recibo de revisión a lanzamiento debe mantener separados módulo, cambio, rol revisor, base de acceso cuando corresponda, revisión integrada, rama, decisión de lanzamiento y artefacto público.

Cuatro actos detrás de «aprobado»

La frase «Mozilla lo aprobó» puede resultar exacta y, al mismo tiempo, ser insuficiente. Puede referirse a la evaluación de un parche por el responsable de un módulo, a una credencial de una persona, a una integración en una rama de desarrollo, a una decisión para un hito o a un binario que ya se ofrece en Firefox. Cada una tiene un responsable, un registro y una consecuencia propios.

La política de propiedad de módulos atribuye a un responsable la dirección del trabajo de un módulo. Para código, su OK es necesario para que el cambio entre en el módulo. Puede designar pares que también aprueben código, y debe delegar a un par la evaluación de su propio código. El responsable puede pedir cambios, rechazar o posponer una revisión y debe explicar la razón en el bug pertinente. Ante una controversia que no se resuelva, existe una vía de intervención de la estructura de Module Ownership.

Es una autoridad técnica delimitada, no una licencia general. El OK de un responsable no certifica que el autor tenga permisos de escritura en cualquier repositorio, ni decide el contenido de una versión de Firefox. Mozilla también distingue al responsable de módulo del propietario de un componente de Bugzilla: uno dirige y revisa código; el otro es receptor predeterminado de informes. A veces coinciden en una persona, pero la coincidencia no fusiona los actos.

El acceso de commit trata de la confianza en una persona

La Commit Access Policy aborda otra superficie: qué permisos requiere alguien para hacer commit en distintos repositorios. Establece niveles de acceso y requisitos de aval diferentes. Para el acceso al producto central, la política exige los avales indicados de responsables o pares de módulo pertinentes, o de Tree Sheriffs. Aun así, el documento advierte que los controles sociales pueden impedir a alguien hacer check-in en determinados árboles.

Esto deshace una inferencia habitual. Un nivel de acceso no es una excepción transportable a las demás reglas; es un juicio de confianza y familiaridad sobre un individuo. El procedimiento para ser committer pide el nivel deseado, una clave SSH, el acuerdo con requisitos y los avales necesarios antes de la provisión. Los avalistas conservan responsabilidad durante un periodo inicial y pueden solicitar revocación en las circunstancias previstas. Nada de ello sustituye la pregunta técnica de si un cambio concreto merece entrar en un módulo.

La conexión con los módulos es real pero limitada. Un responsable puede avalar una solicitud de acceso conforme a la política; ese hecho no convierte cada revisión favorable en una credencial automática. Y quien tiene acceso no se vuelve por ello el revisor autorizado de cualquier cambio técnicamente alcanzable. Informar con precisión exige guardar el camino de revisión y el fundamento del acceso como registros distintos.

Integrar no equivale a prometer una entrega

La integración une una modificación a una revisión, un repositorio y una rama. Es una evidencia importante, pero no demuestra que llegue al usuario. La guía de envío de Firefox describe un modelo de tren con firefox-main, firefox-beta y firefox-release, y con los canales Nightly, Beta y Release. El movimiento entre esas superficies tiene calendario y condiciones propios; el código debe aterrizar en main antes de poder ser uplifted a beta.

Los Release Drivers tienen una función diferente. Mozilla les asigna gestión de proyectos para lanzamientos de hitos, orientación sobre correcciones importantes y decisiones de gestión de árboles. Una revisión de módulo puede permitir que un cambio siga adelante; no selecciona por sí sola una versión pública. A la inversa, una prioridad de lanzamiento no reescribe la evaluación técnica del módulo. Las actualizaciones puntuales dependen de la importancia de un driver: no son el resultado automático de que un parche haya recibido OK.

Por eso, una rama de desarrollo no debe describirse como un compromiso de Release. La elegibilidad para uplift no es prueba de que ocurrió. Una conversación sobre un hito tampoco es un artefacto firmado. Cuando se necesita afirmar una entrega, hay que poder mostrar el paso de rama o canal, la decisión de lanzamiento y el identificador del artefacto.

Un recibo que conserve los traspasos

Para una afirmación de impacto, el recibo debería comenzar con la identidad estable del cambio y del módulo. Debe señalar el rol de responsable o par que revisó, el registro público de la revisión y su fecha. Si se invoca acceso, debe documentar el nivel o vía autorizada pertinente sin divulgar datos personales innecesarios. Después debe registrar la revisión integrada, repositorio y rama. Una afirmación de lanzamiento añade canal o rama objetivo, evidencia de selección, artefacto público y fecha.

También debe marcar sus límites: no llamar autorización de acceso a una revisión, ni revisión a un permiso, ni lanzamiento a una mera revisión. No se trata de imponer una política nueva a Mozilla. Se trata de hacer visible la separación que ya sostienen sus políticas, de forma que un lector pueda saber qué se probó y qué decisión faltaría antes de convertir un parche en un producto.

Sources

  1. Mozilla Modules and Module Owners
  2. Mozilla Commit Access Policy
  3. Becoming A Mozilla Committer
  4. Mozilla Roles and Leadership
  5. Pocket Guide: Shipping Firefox
  6. Lu Heng, The Multi-Stakeholder Mirage
  7. Lu Heng, Running-Code Primacy