Política de Cambios

Si usted ya conoce el proceso puede saltar inmediatamente a formato vacío de Propuesta de Cambio. Para encontrar ayuda con la comprensión de los campos, vea la página guía de envíos de cambios]. Para una introducción rápida al proceso vea el vídeo Política de Cambios de Fedora.

Para informar de un problema con la plantilla de propuesta, presente una cuestión en el repositorio pgm_docs.

Motivación

La motivación para el proceso Changes es dar visibilidad a los cambios planeados y hacer el esfuerzo de coordinación y planificación más fácil. Es casi imposible seguir todos los cambios que suceden en un gran proyecto como Fedora. Al proporcionar un mecanismo para compartir los cambios, es más fácil para los colaboradores saber que es lo que viene y asegurar que podemos abordar los impactos de los cambios bien antes de la fecha del lanzamiento. Las propuestas de cambios deberían ser compartidas los más pronto posible, antes de implementar el cambio e incluso en un estado muy temprano de la idea, para obtener de la comunidad comentarios y revisiones.

La lista de cambios aceptados, o conjunto de cambios, se usa por diferentes equipos en todo el proyecto. Por ejemplo, el conjunto de cambios se puede usar para preparar materiales externos como notas de versión y anuncios de lanzamiento.

Se confía en los propietarios de los cambios y depende de ellos resaltar todos los cambios relevantes. No tener en cuenta los cambios importantes (ya sea por descuido, por diferente opinión sobre la importancia o intencionadamente) rompe el proceso Change.

El proceso Change es una herramienta interna de planificación y seguimiento y la versión final no requiere que se reflejen todos los cambios propuestos.

Categorías de Cambio

Fedora Engineering and Steering Committee (FESCo) ha definido dos categorías de Change:

  1. Cambios autónomos

  2. Cambios en todo el sistema

Cambios Autónomos

Un cambio autónomo es un cambio en paquete(s) aislado(s) o un cambio general con alcance e impacto limitado al resto de la distribución/proyecto. Ejemplos pueden ser añadir un grupo de paquetes hoja o un esfuerzo coordinado dentro de un Special Interest Group (SIG) con impacto limitado fuera del área funcional del SIG. Los cambios autónomos podrían ser usados como propuestas tempranas de ideas para cambios más amplios y complejos. Crear una nueva Solución (por ejemplo un Spin/Lab) es un Cambio Autónomo.

El anuncio público de un nuevo cambio autónomo promueve la cooperación en el cambio y extiende su visibilidad. Los propietarios del cambio pueden encontrar ayuda de la comunidad o comentarios útiles. En base a la revisión de la comunidad, el cambio autónomo se puede actualizar a la categoría de cambio en todo el sistema y se le puede pedir al propietario más detalles y que amplíe el cambio.

Cambios en Todo el Sistema

Los cambios en todo el sistema involucran a lo predeterminado, a componentes de ruta crítica u otros cambios que no se pueden definir como cambios autónomos. El promover un entregable al estado Edition es un Cambio en Todo el Sistema según la política del Consejo.

Secciones de la Propuesta de Cambio

Table 1. Secciones de la Propuesta de Cambio
Elemento Autónomo Todo el Sistema

Resumen

requerido

requerido

Propietario

requerido

requerido

Estado actual

requerido

requerido

Descripción detallada

requerido

requerido

Comentarios

opcional

opcional

Beneficio a Fedora

requerido

requerido

Alcance/Propuesta de propietarios

requerido

requerido

Alcance/Otros desarrolladores

según corresponda

requerido

Alcance/Ingeniería de Versión

según corresponda

requerido

Alcance/Políticas y directrices

según corresponda

según corresponda

Alcance/Aprobación de marca

según corresponda

según corresponda

Alcance/Alienación de objetivos

según corresponda

según corresponda

Impacto de Actualización y Compatibilidad

opcional

requerido

Como probar

opcional

requerido

Experiencia del usuario

opcional

opcional

Dependencias

opcional

requerido

Plan de contingencia

opcional

requerido

Documentación

opcional

requerido

Notas al lanzamiento

opcional

requerido

Comunicación Esencial

Comité Fedora Packaging

Para cambios que requieran modificaciones a las Directrices de Empaquetamiento de Fedora:

  • La persona o grupo que propone el Cambio es responsable de proporcionar un primer borrador de los cambios en las directrices de empaquetamiento al FPC.

  • Idealmente, este borrador estará disponible como una solicitud de extracción antes de enviar la propuesta de Cambio de modo que la comunidad y FESCo puedan evaluar los cambios específicos.

Ingeniería de Lanzamiento

Para cambios en todo el sistema debe presentar un problema en releng pagure para comprobar si su cambio requiere la participación de Release Engineering.

Los tickets a Release Engineering no se requieren de forma predeterminada para los cambios autónomos, pero pueden ser necesarios si el cambio implica, por ejemplo, añadir un nuevo artefacto de salida.

Aprobación de Marca

Si su Cambio puede requerir aprobación de marca (por ejemplo, si es un nuevo Spin), presente un ticket pidiendo aprobación de marca del Fedora Council.

Proceso de cambio

Este es el flujo general para las propuestas de cambio:

  • El propietario envía la propuesta de cambio estableciendo la página wiki a la categoria ChangeReadyForWrangler.

  • El Program Manager verifica la corrección formal de la página de cambio propuesto. Esto incluye tickets para Release Engineering, Fedora Packaging Committee y aprobación de marca donde sea necesario.

  • Una vez que la propuesta de cambios sea correcta, el Program Manager lo anuncia en las listas de correo devel-announce y devel.

  • El Program Manager presenta un ticket FESCo no antes de una semana después del anuncio en las listas de correo.

    • FESCo votará aprobar o denegar el cambio propuesto de acuerdo con la política de ticket de FESCo. No implemente su propuesta hasta que haya finalizado la votación de FESCO. Cuando el Program Manager cree un rastreo de error para su cuestión será la indicación de que proceda.

    • Cualquier equipo puede compartir sus visiones en la lista de correo y escalar un cambio propuesto a FESCo. Es posible que al propietario del cambio se le pidan más detalles o aborde las inquietudes propuestas. Se anima a los miembros de FESCo a hacer preguntas en la lista de correo en lugar de esperar a la reunión.

    • Opcionalmente, FESCo asigna el cambio a uno de los miembros de FESCo o un miembro de confianza de la comunidad dentro del área funcional (un pastor del cambio), que siga el estado detallado del cambio con FESCo y ayude con los procesos dentro de Fedora. Por ejemplo, el pastor del cambio puede comunicar aspectos de alto impacto del cambio o señalar que será necesaria una buildroot. El pastor sigue el estado del cambio hasta el lanzamiento final.

  • Se anima a los propietarios del cambio a suscribir el ticket FESCo una vez que haya sido creado por el Program Manager.

  • El Program Manager creará rastreadores Bugzilla en el componente Changes Tracking y problemas en el repositorio Release Notes para los cambios aprobados.

  • FESCo revisará el estado de los cambios una semana antes de la congelación beta. En ese momento, normalmente, FESCo decide si activar el plan de contingencia. Cualquier cambio por el que FESCo no pueda tomar esta decisión una semana antes de beta debe incluir una nota en su página wiki Cambio y rastrear el error. Los cambios que no se puedan completar serán diferidos automáticamente al siguiente lanzamiento y no requieren reenvío a menos que se le hagan revisiones sustanciales.

En la mayoría de los casos, no debería enviar cambios en el código a Rawhide hasta después de que FESCo haya votado la aprobación de la propuesta.

Hitos del proceso de cambio

Plazo de presentación de propuestas

Las nuevas propuestas de cambio se pueden enviar siguiendo las directrices descritas en otra parte y hasta el plazo apropiado de envío de propuestas de cambio. Para un lanzamiento dado, esta fecha está disponible en el calendario de lanzamiento y será anunciada por anticipado.

Los cambios no tienen que ser aceptados en este plazo, pero deben haber sido enviados al Program Manager entonces.

Plazo del código completo (para probar)

  • Para esta fecha, un nuevo cambio debe tener todas las funciones o estar lo suficientemente cerca de completarse como para que la mayoría de su funcionalidad se pueda probar antes del lanzamiento Beta.

  • Si una página de propuesta de cambio especifica que un cambio será habilitado de forma predeterminada, debe ser así para ese hito.

  • Los cambios que se pueden probar deben tener su estado en el rastreador de errores establecido a MODIFIED.

En este punto, Rawhide y las versión inmediata que llega "N+1" están ya separadas en ramas. ¡Si se trata de desarrollo, pruebas, integración y pruebas de integración! — en realidad no todos están alineados en este punto y no es ninguna vergüenza plantearlos para la siguiente versión (N+2). Ahora es el momento de que lleve esto a FESCo. O, si este cambio es sensible al momento, pero necesita más recursos o atención de la comunidad llévelo a FESCo, al Fedora Council y a toda la comunidad de Fedora.

Código completo (100%) fecha límite

  • Los cambios deben ser con el código completo, lo que significa que todo el código requerido para habilitar el nuevo cambio está terminado.

  • El nivel de integridad del código se refleja como estado del rastreador ON_QA. El cambio no tiene que estar totalmente probado para esta fecha límite.

La fecha límite de código completo (100%) coincide con la fecha de Beta Freeze porque esta es la última fecha en la que se puede asegurar que una compilación aparecerá en una versión importante. La idea es realmente que estos requisitos se cumplan en la versión Beta, pero debido a la naturaleza de los hitos de congelación, para garantizar que esto sea así, los requisitos deben cumplirse antes de la fecha de congelación.

Rastreadores Bugzilla

Las propuestas de cambio aprobadas tendrán cuestiones en Bugzilla creadas por el Administrador del Programa. Los siguientes campos de estado deben ser usados para reflejar el estado del cambio:

Table 2. Estados del rastreador Bugzilla
Estado BZSignificado

ASSIGNED

Cambio aprobado por FESCo

MODIFIED

El cambio tiene el código lo suficientemente completo para poder ser probado

ON_QA

El cambio tiene el 100% del código completo
No cierre el rastreador de errores cuando se complete el cambio. El Administrador del Programa lo hará como parte de la gestión interna de la liberación.

Want to help? Learn how to contribute to Fedora Docs ›