Esta página conserva un documento del pasado de Fedora. Puede que no refleje (y probablemente no lo haga) la política actual ni las prácticas del Proyecto Fedora.

La «Visión de Actualizaciones Estables» fue adoptada por la Junta Directiva de Fedora en marzo de 2010 y se menciona en el Comité Directivo de Ingeniería de Fedora (actualmente: normativa de actualizaciones). Si bien algunos factores de fondo han cambiado desde entonces, los fundamentos que fundamentaron la normativa de FESCo siguen siendo relevantes.

Segundo plano

Las discusiones de marzo de 2010 en diversas listas de correo de Fedora han demostrado que actualmente tenemos diversas posturas sobre la estrategia de actualización de Fedora. Estas abarcan desde una versión gradual hasta una solución de actualización limitada y de seguridad. La falta de claridad sobre este tema genera confusión tanto entre los encargados del mantenimiento de paquetes como entre los usuarios finales.

La mayoría de la gente está de acuerdo en que las actualizaciones rotas son perjudiciales para la distribución Fedora y deben evitarse.

Menos personas están de acuerdo en:

  • Cuántas actualizaciones son aceptables para una versión estable y cómo medirlas.

  • Que constituye una actualización aceptable de una versión estable.

  • A qué costo se deben evitar las actualizaciones rotas y sacrificar actualizaciones rotas ocasionales por velocidad en la entrega de software nuevo y simplicidad en el flujo de trabajo del mantenedor.

Por estas razones, la Junta Directiva de Fedora publica una declaración de visión sobre actualizaciones de versiones estables para guiar la creación e implementación de una normativa de actualizaciones de Fedora. Esta normativa no pretende regular la introducción de nuevos paquetes.

Creando esta declaración, está la creencia de la Junta que:

  • Satisfacción del usuario final con nuestra distribución incrementará

  • Desarrolladores y usuarios finales tendrán una experiencia de liberación estable más sólida

  • Los usuarios finales y desarrolladores tendrán más tiempo para enfocar en otras áreas en Fedora

Factores

Al crear un resumen de actualizaciones, hay algunos factores que deben tenerse en cuenta. El primero y más importante es tener en cuenta los criterios generales que la Junta estableció para el público objetivo de toda la distribución de Fedora, que describe a alguien quien:

  1. es voluntario cambiar a Linux

  2. es familiar con equipos pero no es necesario para hacker o desarrollador

  3. es como colaborar en alguna forma cuando algo está equivocado con Fedora, y

  4. desea utilizar Fedora para productividad general, o bien utilizando aplicaciones del escritorio o un explorador Web.

Una plataforma cambiante y cambios visibles de comportamiento afectarán la productividad del usuario, ya que este debe tomarse tiempo para desconectarse de las tareas deseadas para descubrir qué ha cambiado, ajustar la forma en que realiza las tareas de apoyo y volver a centrarse en sus objetivos originales. Dado que la productividad se considera importante para este usuario, este resultado es indeseable. De igual manera, lidiar con un gran número de actualizaciones regularmente lo distrae de las tareas de productividad deseadas.

Las actualizaciones que ofrecen nuestras herramientas integradas, bajo el auspicio del Proyecto Fedora, son consideradas fiables por los usuarios. Si bien es probable que un usuario que cumpla estos criterios reporte un defecto cuando algo falla, no espera automáticamente que surjan nuevos problemas en una versión estable como resultado de usar dichas actualizaciones. Cuando surgen estos problemas, la confianza del usuario en la plataforma se ve socavada.

Otro factor a tener en cuenta es el rápido ciclo de desarrollo de Fedora. Un ciclo de desarrollo de seis meses para cada lanzamiento permite a Fedora integrar las versiones más recientes y destacadas de los proyectos originales en la distribución "rawhide" y poner ese trabajo a disposición de los usuarios en un plazo relativamente corto. Idealmente, este rápido ciclo de lanzamiento permite tanto a desarrolladores como a usuarios centrarse en un conjunto de contenido de software coherente, consistente y funcional para cada lanzamiento.

Declaración de visión

Tomando el fondo y varios factores sobre la cuenta, La Junta considera que los flujos de actualización deben gestionarse teniendo en cuenta los siguientes propósitos:

  • Los repositorios actualizados para liberaciones estables de la distribución Fedora proporcionaría nuestros usuarios con un flujo consistente y de alta calidad de actualizaciones.

  • Las publicaciones estables proporcionarían una experiencia de usuario consistente a través del ciclo de vida, y solo reparar notificaciones de defectos y seguridad.

  • Publicaciones estables no serían utilizadas para seguimiento de versión de clase superior cuando esta sea similar a cambiar el empleo del uso más allá que corregir defectos y problemas de seguridad.

  • Se debe realizar un seguimiento cercano en el mando de desarrollo del repositorio de Rawhide siempre que sea posible, y debemos esforzarnos por mover nuestros parches del mando de desarrollo.

  • Más capaz y/o usuarios intrépidos son recomendados para utilizar Cuero Crudo junto con participar en pruebas de ramas estables durante el desarrollo y el periodo de re-lanzamiento.

  • Liberaciones estables, ramas pre-liberadas, y Cuero Crudo tiene una aproximación gradual que para que tipos de actualizaciones sean esperadas. Por ejemplo, una pre-liberación aceptarían algunas actualizaciones las cuales una liberación estable no lo haría, y la parte cruda aceptaría actualizaciones que no sean apropiadas para cualquier publicaciones estable o una pre-publicación.

  • Los miembros del proyecto serían capaces de medir transparentemente o monitorizar un proceso de actualizaciones para medir objetivamente su efectividad, y determinar si el proceso de actualizaciones se logra en las declaraciones de visión realizada.

Implementación

Siguiendo la visión de Fedora Board, la normativa siguiente fue aprobada y en efecto desde octubre de 2010:

Normativa de Actualizaciones

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