Guía para la presentación de cambios

En general, los cambios sirven para coordinar el esfuerzo de desarrollo y para la comunicación (tanto interna como externa). No obligan a que alguien más implemente una idea (por muy buena que sea). Si tiene en mente una mejora, trabaje para que los implementadores se comprometan con el esfuerzo antes de presentar una propuesta de cambio, en lugar de esperar que se presenten a trabajar una vez aceptado el cambio.

Mira el video sobre la directiva de cambios de Fedora para obtener una introducción rápida al proceso.

¿Cómo propongo un nuevo cambio?

Para que se considere una propuesta de cambio oficial aceptada para la próxima versión de Fedora Linux, la propuesta de cambio debe estar documentada formalmente en una página wiki separada.

Lea directivas para conocer los cambios autónomos y los cambios a nivel de todo el sistema.
Toma la categoría correcta. ¡Recuerda que la categoría puede cambiarse según la opinión de la comunidad o la revisión de FESCo!

  1. Crea una página wiki nueva

    1. Cuando inicie la sesión, pulse en el botón Ver fuente en el formulario de propuesta de cambio vacío.

    2. Copia el contenido

    3. Cambie la URL a https://fedoraproject.org/wiki/Changes/<TuTítulo> (cambiando "<TuTítulo>" a un ficha para su página, p.e., "ExampleChangeProposal")

    4. Pulse “Crear”

    5. Pegue el contenido

  2. Complete los detalles requeridos para la categoría seleccionada (consulte los comentarios en línea y la orientación a continuación).

  3. Una vez que esté satisfecho con la página de propuesta de cambio, configure la categoría de la página wiki en ChangeReadyForWrangler y ponga la categoría de cambio adecuada (SelfContainedChange o SystemWideChange). Ambas categorías deben estar configuradas.

  4. Pulse el botón Guardar Cambios

Puedes quitar los comentarios HTML en la plantilla si lo elige.
¡Asegúrese de completar su propuesta de cambio antes de la fecha límite de presentación! Si no cumple con esta fecha, deberá solicitar una excepción a FESCo.

El Gestor del Programa es responsable del anuncio real de la propuesta de cambio, la creación del ticket de FESCo y el seguimiento de defectos en Bugzilla.

¿Cómo muestro el estado de un cambio que me pertenece?

El progreso del desarrollo se muestra en Bugzilla con los estados de error definidos, como se explica en la plantilla de propuesta de cambio. Utilice este seguimiento de fallos para mostrar los bloqueadores mediante los campos Bloqueos/Dependencias (por ejemplo, revisiones de paquetes), actualizar la descripción del defecto con el estado actual y modificarlo para reflejarlo. El administrador del programa o los miembros de FESCo podrían solicitarle que proporcione un estado más detallado (especialmente para cambios a nivel de sistema).

Un cambio se considera código completo cuando el estado del error pasa a ON_QA y cuando no hay defectos bloqueadores abiertos.

Consulte la sección Rastreadores de Bugzilla de la Directiva de cambios para obtener más información sobre los estados de Bugzilla.
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.

¿Cuáles son las fechas límite del proceso de cambio (puntos de control)?

Consulte la sección Hitos del proceso de cambio de la directiva de Cambios para obtener información sobre los hitos del proceso.

¿Qué pasa si no completo un cambio?

Los cambios que no se puedan completar para la versión se posponen automáticamente a la siguiente. No es necesario volver a proponer el cambio a menos que se realicen revisiones sustanciales. Si necesita posponer un cambio, informe al administrador del programa y este actualizará la página wiki y el rastreador de Bugzilla según corresponda.

¿Qué pasa si tengo que modificar mi Cambio?

Se pueden realizar modificaciones menores en cualquier momento. Si necesita realizar modificaciones significativas después de la aprobación de un cambio, solicite la aprobación de FESCo.

Guía sección por sección

Cambiar el Nombre de la Propuesta

Debe ser descriptivo, pero único. Por ejemplo, es preferible "glibc 2.29" a "glibc upgrade".

Asegúrese de que su página esté en el espacio de nombres Cambios (p.e., llámela Cambios/glibc_2.29)

Resumen

Una o dos frases que resuman este cambio y sus efectos. Esta información se utiliza para la página de resumen general del conjunto de cambios de cada versión. Tenga en cuenta que la motivación del cambio debe figurar en la sección "Motivación" a continuación, y que esta parte debe responder a la pregunta "¿Qué?" en lugar de "¿Por qué?".

Suponga que no todos los que vean esto sabrán de qué está hablando. Describa brevemente los paquetes o servicios cuando sea pertinente.

Propietario

Para que las propuestas de cambio se consideren independientes, deben incluirse aquí los propietarios de todos los paquetes afectados. Como alternativa, un SIG puede figurar como propietario si posee todos los paquetes afectados.

Utilice su correo electrónico de Bugzilla en el campo correo electrónico para hacer feliz a su Administrador de programa.

Estado actual

No edite esta sección excepto para establecer la versión de lanzamiento de destino y actualizar las etiquetas [[Category:*]].

Descripción Detallada

Amplíe el resumen, si corresponde. Un par de frases bastan para explicar el objetivo, pero cuantos más detalles proporcione, mejor. Si existen varios enfoques razonables, debe indicar por qué descartó utilizar los demás.

Realimentación

Resuma los comentarios de la comunidad y explique por qué decidió no aceptar las alternativas propuestas. Esta sección es opcional para todas las propuestas de cambio, pero se recomienda encarecidamente. Incorporar los comentarios aquí a medida que se generan le da a FESCo una visión más clara de su propuesta y deja un buen registro para el futuro. Si no recibe comentarios, es útil anotarlo también en esta sección. Esta sección está inspirada en parte en la sección "Ideas Rechazadas" descrita en PEP-0001.

Para ideas innovadoras o posiblemente controvertidas, considere recopilar comentarios antes de presentar la propuesta de cambio. Esto puede hacerse publicando en la lista de correo de desarrollo para obtener la opinión completa de la comunidad, o compartiéndola con otras personas de confianza para que le den su opinión sincera. En el futuro, habrá instrucciones más específicas sobre cómo publicar comentarios previos a la propuesta. En cualquier caso, cuando reciba comentarios, debería resumirlos en esta sección.

Debe completar esta sección a medida que reciba sus comentarios. Dado que es opcional, el gestor del programa no necesita esperar a que la complete antes de enviarla a FESCo. Si la discusión se acalora, considere pedirle a una persona neutral que resuma las discusiones. Esto ayuda a evitar sesgos y reacciones emocionales.

Beneficio para Fedora

¿Qué beneficio aporta a la distribución? ¿Se mejorará el software que generamos? ¿Cómo se optimizará el proceso de creación de versiones de Fedora Linux?

Asegúrese de incluir las siguientes áreas si es relevante:

  • Si se trata de una actualización importante de capacidades, ¿qué ha cambiado? Por ejemplo: Este cambio introduce Python 5, que se ejecuta sin el bloqueo global del intérprete y es totalmente multiproceso.

  • Si se trata de una nueva funcionalidad, ¿qué capacidades ofrece? Por ejemplo: Este cambio permite que las mejoras de paquetes se realicen automáticamente y se reviertan a voluntad.

  • ¿Esto mejora algún paquete o conjunto de paquetes? Por ejemplo: este cambio modifica un paquete para que use una pila de lenguaje diferente que reduce el tamaño de la instalación al eliminar dependencias.

  • ¿Esto mejora versiones o ediciones específicas? Por ejemplo: este cambio modifica la instalación predeterminada de Fedora Workstation para que sea más coherente con la instalación base de Fedora Server.

  • ¿Esto hace que la distribución sea más eficiente? Por ejemplo: este cambio reemplaza miles de scriptlets %post individuales en paquetes con un script que se ejecuta al final.

  • ¿Es esto una mejora para los procesos de mantenimiento? Por ejemplo: la inclusión de paquetes de Fedora en las pruebas de control de calidad automáticas hará que Rawhide sea más estable y permitirá que los cambios se implementen con mayor fluidez.

  • ¿Se trata de una mejora dirigida a colaboradores específicos? Por ejemplo: garantizar que se instale por defecto un conjunto mínimo de herramientas necesarias para contribuir a Fedora facilita la incorporación de nuevos colaboradores.

Cuando un cambio tiene múltiples beneficios, es mejor enumerarlos todos.

Ámbito

  • Propietarios de la propuesta: ¿Qué trabajo deben realizar los propietarios de las funciones para completarlas a tiempo para su lanzamiento? ¿Se trata de un cambio importante que afecta a muchas partes de la distribución o de un cambio muy aislado? ¿Cuáles son esos cambios?

  • Otros desarrolladores: REQUERIDO PARA CAMBIOS EN TODO EL SISTEMA ¿Qué trabajo deben realizar los demás desarrolladores para completar la función a tiempo para el lanzamiento? ¿Se trata de un cambio importante que afecta a muchas partes de la distribución o es un cambio muy aislado? ¿Cuáles son esos cambios?

  • Ingeniería de lanzamiento: OBLIGATORIO PARA CAMBIOS EN TODO EL SISTEMA ¿Esta función requiere coordinación con la ingeniería de lanzamiento (p. ej., cambios en la generación de imágenes del instalador o la entrega de paquetes de actualización)? ¿Se requiere una reconstrucción masiva? Incluya un enlace al problema de redistribución. El problema debe registrarse antes del envío de la función para garantizar que haya alguien disponible para realizar el desarrollo y las pruebas del proceso, y que todos los cambios se integren en el proceso de desarrollo; una viñeta en un cambio no es suficiente comunicación.

  • Directivas y directrices: ¿Es necesario actualizar las directrices de empaquetado u otros documentos para esta función? De ser así, ¿es necesario hacerlo antes o después de la implementación? Si existe un ticket de FPC, agregue un enlace aquí. Siempre que sea posible, presente una solicitud de incorporación de cambios (pull request) con los documentos de política correspondientes antes de enviar la propuesta de cambio. De esta manera, la comunidad y FESCo pueden evaluar los cambios específicos necesarios.

  • Aprobación de marca registrada: si su cambio puede requerir la aprobación de marca registrada (por ejemplo, si es un nuevo giro), presente un ticket de Fedora Council solicitando la aprobación de marca registrada.

  • Alineación con los objetivos: ¿Su propuesta se alinea con los objetivos actuales de Fedora? Esto no se aplicará a muchos cambios, pero es importante tenerlo en cuenta al proponer un cambio. No estar alineado no implica un rechazo automático, sino un aspecto más a considerar.

Impacto de actualización/compatibilidad

REQUERIDO PARA CAMBIOS EN TODO EL SISTEMA ¿Qué sucede con los sistemas que tenían instalada una versión anterior de Fedora Linux y se actualizan a la versión que contiene este cambio? ¿Se requerirá configuración manual o migración de datos? ¿Se dejará de ofrecer soporte a alguna funcionalidad existente?

Cómo realizar la prueba

OBLIGATORIO PARA CAMBIOS EN TODO EL SISTEMA No es necesario que este documento sea completo. Describa las dimensiones de las pruebas que se espera que supere esta implementación de cambio una vez finalizada. Si es necesario probarla con diferentes configuraciones de hardware o software, indíquelas. Cuanto más específico sea, mejores serán las pruebas comunitarias.

Recuerda que está escribiendo este instructivo para que los evaluadores interesados lo utilicen para verificar la implementación de su cambio. Documentar lo que usted hace para probar está bien, pero es mucho mejor documentar lo que yo puedo hacer para probar su cambio.

Un buen “cómo realizar pruebas” debería responder a estas cuatro preguntas:

  1. ¿Qué hardware/datos/etc. especiales se necesitan (si corresponde)?

  2. ¿Cómo preparo mi sistema para probar este cambio? ¿Qué paquetes debo instalar, editar los archivos de configuración, etc.?

  3. ¿Qué acciones específicas debo realizar para comprobar que el cambio funciona como debería?

  4. ¿Cuáles son los resultados esperados de esas acciones?

Experiencia del Usuario

Si esta propuesta de cambio es perceptible para los usuarios, ¿cómo cambiarán sus experiencias como resultado?

Esta sección se superpone parcialmente con la sección “Beneficios para Fedora” mencionada anteriormente. Esta sección debe centrarse principalmente en la experiencia del usuario, redactada de forma que no presuponga conocimientos técnicos profundos. Una descripción técnica más detallada debe reservarse para la sección “Beneficios para Fedora”.

Describe lo que los usuarios verán o notarán, por ejemplo:

  • Los paquetes se comprimen de manera más eficiente, lo que hace que las descargas y actualizaciones sean un 10% más rápidas.

  • Los tickets Kerberos se pueden renovar automáticamente. Los usuarios ahora tendrán que autenticarse menos y serán más productivos. Las mejoras en la gestión de credenciales permiten que un usuario comience su jornada laboral con un inicio de sesión único y no tenga que detenerse para volver a autenticarse durante toda la jornada.

  • LibreOffice es una de las aplicaciones más comúnmente instaladas en Fedora Linux y ahora está disponible de manera predeterminada para ayudar a los usuarios a "comenzar a trabajar de inmediato".

  • Se ha demostrado científicamente que el verde es el color más relajante. El cambio a un color de fondo verde predeterminado con texto verde hará que los usuarios de Fedora Linux sean los más relajados de cualquier sistema operativo.

Dependencias

REQUERIDO PARA CAMBIOS EN TODO EL SISTEMA ¿Qué otros paquetes (RPM) dependen de este paquete? ¿Existen cambios fuera del control de los desarrolladores de los que dependa la finalización de este cambio? En otras palabras, ¿la finalización de otro cambio que pertenece a otra persona podría impedir que usted lo termine a tiempo o que usted tendría que coordinar? ¿Otros proyectos upstream como el kernel (si no se trata de un cambio del kernel)?

Plan de Contingencia

REQUERIDO PARA CAMBIOS EN TODO EL SISTEMA Si no puede completar su función antes de la congelación final del desarrollo, ¿cuál es el plan B? Podría ser tan simple como "Revertir la configuración original". O podría no serlo (por ejemplo, reconstruir varios paquetes dependientes). Si su función no se completa a tiempo, queremos asegurarles que otras partes de Fedora no estarán en peligro.

Un plan de contingencia incluiría:

  • Mecanismo de contingencia: (¿Qué hacer? ¿Quién lo hará?)

  • Fecha límite de contingencia: ¿Cuándo es la última vez que se puede implementar el mecanismo de contingencia?

La fecha límite de contingencia probablemente sea la congelación de la beta. En algunos casos, puede ser más apropiado establecerla al inicio de la reconstrucción masiva o del día de la rama. En raras ocasiones, se puede usar la congelación final, pero esto solo debe usarse para cambios que sean fácilmente revertibles.

Documentación

REQUERIDO PARA CAMBIOS EN TODO EL SISTEMA ¿Existe documentación original sobre este cambio o notas que hayas escrito tú mismo? Enlaza ese material aquí para que otros desarrolladores interesados puedan participar.

Notas de Liberación

Las Notas de la Versión de Fedora Linux informan a los usuarios finales sobre las novedades de la versión. Encontrará ejemplos de notas de versiones anteriores en la Documentación de Fedora. Las notas de la versión también ayudan a los usuarios a comprender como gestionar los cambios en la plataforma, como las ABI/API, la configuración o los formatos de los archivos de datos, o las actualizaciones. Si este cambio implica algún cambio de este tipo, indíquelo aquí. Un enlace a la documentación original suele satisfacer esta necesidad. Esta información constituye la base de las notas de la versión editadas por el equipo de documentación y enviadas con la versión.

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