Normativa 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, consulte la página guía de envíos de cambios]. Para una introducción rápida al proceso vea el vídeo Normativa 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 normativa del Consejo.

Secciones de la Propuesta de Cambio

Tabla 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 Empaquetado 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 vales para 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:

  • The owner creates their proposal by making a copy of the changes template https://fedoraproject.org/wiki/Changes/EmptyTemplate.

    • It is a good idea to keep the name of the wiki page as similar as possible to the name in the proposal to avoid confusion.

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

  • The Change Wrangler (FOA) checks the proposed change page for formal correctness. This includes Release Engineering, Fedora Packaging Committee, and trademark approval tickets where necessary.

  • Once the change proposal is correct, the Change Wrangler (FOA) announces it on the devel-announce and creates a post on discussion.fedoraproject.org.

  • The change owner must have a username on discussion.fedoraproject.org so their change may be assigned to them. This is easly done by signing in once to discourse using your FAS login credentials.

  • Any team can share their views on the discussion post (preferred) and devel mailing list and escalate a proposed change to FESCo. The change owner may be asked to provide more details or address proposed concerns.

  • FESCo members are encouraged to ask questions on the discussion post ahead of the change ticket being openend.

  • The Change Wrangler (FOA) files a FESCo ticket no sooner than one week after the announcement on the mailing list and discussion post.

  • Change owners are subscribed to the FESCo ticket once it has been created by the Program Manager.

    • Occasionally, more information is needed on some proposals, and FESCo members may use the ticket filed for clarificiation instead of waiting for the meeting.

  • FESCo will then vote to approve or deny a change proposal in accordance with the FESCo ticket policy. Do not implement your proposal until the FESCo vote has ended. When the Change Wrangler (FOA) creates a tracking bug for your issue, that is your indication to proceed.

    • Occasionally, FESCo assigns the change to one of the FESCo members or a trusted community member within the functional area (a change shepherd), who follows the detailed status of the change with FESCo and helps with processes within Fedora. For example, the change shepherd may communicate high-impact aspects of the change, or point out that a buildroot will be necessary. The shepherd follows the status of the change until final release.

  • The Change Wrangler (FOA) will create Bugzilla trackers in the Changes Tracking component and issues in the Release Notes repository for approved changes.

  • FESCo will re-review the status of changes one week before the beta freeze following an Incomplete Changes report from the Change Wrangler (FOA). At this time, FESCo typically decides whether to activate the contingency plan. Any change for which FESCo can’t make this decision one week before beta must include a note on its Change wiki page and tracking bug. Changes that cannot be completed will automatically be deferred to the next release and do not require re-submission unless substantial revisions are made.

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.

Changes do not have to be accepted by this deadline, but they must have been submitted to the Change Wrangler (FOA) by then.

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 seguimiento 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 seguimiento 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.

Seguimientos Bugzilla

Approved change proposals will have Bugzilla issues created by the Change Wrangler (FOA). The following status fields should be used to reflect the status of the change:

Tabla 2. Estados del seguimiento Bugzilla
Estado BZ Significado

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
Do not close tracking bugs when a change is complete. Instead, please comment on your tracking bug that this change is complete. The Change Wrangler (FOA) will auto-close tracking bugs as part of release housekeeping.

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