Cambios en la justificación y la historia del proceso

La razón por la que tenemos un proceso de Cambios es para coordinar el trabajo en todo el proyecto. Queremos asegurarnos de que todos estén al tanto de lo que sucede para recibir la opinión de la comunidad y asegurarnos de que trabajamos en la misma dirección. El proceso de Cambios se centra, en última instancia, en la comunicación, no en el control de acceso.

Para una opinión sobre el proceso de Cambios, véase el artículo de Ben Cotton sobre Opensource.com o la plática de DevConf.CZ 2019.

Historia

Antes de Fedora 20, Fedora utilizaba un proceso llamado “Características”. Este consistía en determinar si un cambio era una “característica” o una “mejora”. Se consideraba que las mejoras no merecían seguimiento, pero las características eran muy visibles para el usuario o valiosas para el marketing y recibían especial atención. Esto se hacía mediante la especificación manual del porcentaje de finalización en la wiki y otras tareas lúdicas.

FESCo identificó varios problemas clave con este proceso:

  • La definición de “característica” era ambigua, lo que llevó a que las personas enviaran características innecesariamente, lo que generaba una carga administrativa adicional.

  • La página wiki tenía una entrada de datos duplicada

  • El proceso no tuvo en cuenta diferentes tipos o ámbitos de características

  • Las funciones no fueron visibles para la comunidad hasta después de que se aprobaron las propuestas de funciones

Para Fedora 20, introdujimos un nuevo proceso llamado “Cambios”. En cierto modo, es muy similar al proceso de Características anterior, pero presenta algunas diferencias clave. En primer lugar, los cambios se dividen en “A nivel de sistema” y “Auto‐contenidos”. Los cambios a nivel de sistema involucran valores predeterminados, componentes de ruta crítica u otros cambios con un amplio impacto. Los cambios auto‐contenidos tienen un alcance e impacto limitados en el resto del proyecto. Pueden ser cambios en paquetes hoja o cambios que ocurren bajo la responsabilidad de un solo equipo. Cabe destacar que los cambios no son necesariamente elementos que se incluyen en la distribución; también pueden incluir cambios en la creación de paquetes u otros tipos de metatrabajo.

Tanto los cambios a nivel de sistema como los autónomos siguen el mismo proceso. Las principales diferencias residen en el nivel de escrutinio y la información requerida. Los cambios a nivel de sistema deben incluir el impacto en otros desarrolladores, una lista de los cambios de directiva necesarios, el impacto de las actualizaciones, un plan de pruebas, un plan de contingencia y la documentación.

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