Políticas de Actualizaciones

El "Primer" fundamento de Fedora

Fedora Linux es una distribución de rápido movimiento por diseño. Esto se expresa en nuestro fundamento First: ofrecemos lo último en software gratuito, estable, robusto, útil y poderoso.

Nuestra comunidad espera que Fedora integre nuevas versiones de software de diversos desarrolladores en nuestros repositorios rápidamente, pero con una interrupción mínima y de una manera que encaje perfectamente con otros paquetes. Este es el balance que está en el corazón de ser un mantenedor de paquetes y este documento describe nuestras políticas para trabajar juntos con el objetivo de crear la mejor experiencia para cada uno.

Damos a los mantenedores de paquetes individuales una gran confianza en como administran y actualizan sus paquetes, dentro de las Directrices de Empaquetamiento de Fedora y las políticas de aquí. Pero recuerde, por favor, que esto es un esfuerzo colectivo. Respetamos, apreciamos y celebramos el trabajo que cada mantenedor pone en sus paquetes y también fomentamos el mantenimiento conjunto y la colaboración para mejorar el empaquetamiento en toda la colección de Fedora.

Sobre esta política

Fedora tiene diferentes políticas para cada una de sus ramas. Este documento describe para los mantenedores que tipo de actualizaciones deben crearse en los paquetes para cada uno de los tipos de ramas existentes en Fedora. En el caso de preguntas o aclaraciones, por favor presente un ticket FESCo o converse en la lista devel. En general, los lanzamientos deberían ir desde los menos conservadores (Rawhide) a más aún (la versión estable soportada más antigua). Este documento intenta describir cuando y que tipo de actualizaciones deben enviar los mantenedores a los usuarios de las diversas ramas de Fedora. La visión de actualización de la versión Estable de la Fedora Board (Junta de Fedora) incluye más debate y filosofía de alto nivel, mientras que este documento es una guía más práctica. Vea en la Guía de Actualización de Paquetes los pasos técnicos para enviar las actualizaciones. El Ciclo de Vida de los Lanzamientos de Fedora proporciona una visión general más detallada del proceso de desarrollo.

Requisitos comunes de actualizaciones para todos los lanzamientos de Fedora

Algunos criterios a aplicar a cualquier actualización de cualquier rama/lanzamiento de fedora:

Actualizar paquetes interdependientes

Cuando un paquete actualizado requiere de otro u otros paquetes, los paquetes se deberían enviar juntos como una única actualización. Por ejemplo, si el paquete A depende de los paquetes B y C, y usted desea actualizar a una nueva versión del paquete A que requiere nuevas versiones de B y C, debe enviar una única actualización que contenga las versiones actualizadas de los tres paquetes. Es una mala idea enviar tres actualizaciones separadas, porque si la actualización para el paquete A es puesta estable antes de las actualizaciones de los paquetes B y C, causará problemas de dependencia. Hay información sobre como enviar actualizaciones de múltiples paquetes en la Guía de Actualización de Paquetes e información sobre el uso de etiquetas laterales para múltiples actualizaciones en Rawhide Gating/multi-builds.

Actualizaciones consumibles

Las actualizaciones en Bodhi solo se deberían crear para construcciones que se esperan que se califiquen como subidas a estables. Los mantenedores no deberían usar los estados de prueba de Bodhi para probar actualizaciones que no se pretende nunca que sean estables. Este tipo de pruebas deberían ser hechas en Copr u otros repositorios públicos separados. Consulte con el equipo de QA (Garantía de Calidad) para obtener más ayuda con las pruebas.

Rawhide

Rawhide es el árbol de desarrollo en constante evolución. Las actualizaciones de paquetes construidas para Rawhide se componen cada día y se envían a todos los consumidores. Las nuevas compilaciones de este árbol también se añaden a la raíz de compilación (es decir, otros paquetes se compilan a partir de ellas). Este árbol está destinado a cumplir con los Criterios Básicos de Lanzamiento para cualquier composición con éxito de modo que los mantenedores puedan integrar sus cambios con todos los demás.

Repositorio disponible: rawhide

Desde que se introdujo el cambio en los Paquetes Gating Rawhide, las actualizaciones de paquetes en Fedora Rawhide necesitan pasar verificación antes de que aterricen en los repositorios Rawhide. Esto se implementa como una verificación de la actualización de Bodhi, que verifica que la actualización satisface la política de Gating. Vea detalles en Rawhide Gating/Compilaciones Únicas y Rawhide Gating/Múltiples Compilaciones.

Actualmente la política de activación predeterminada está vacía, por lo tanto una actualización Rawhide puede pasar la puerta, sin importar los resultados de la prueba. El mantenedor de un paquete puede optar por la activación de un paquete, configurando políticas de activación individuales, vea ¿Cómo Optar por la Activación?.

Tan pronto como se completa la compilación, se crea automáticamente una actualización Bodhi. La actualización se usa para recopilar resultados de pruebas. Si pasa las pruebas de activación, la actualización se marca como estable después de unos minutos, puesta estable y será añadida a la siguiente composición nocturna.

Para las actualizaciones a los paquetes Rawhide, los mantenedores DEBEN:

  • no enviar ninguna compilación rota conocida (rompe el conjunto de paquetes buildroot predeterminado, etc.). Esto causa trabajo adicional para los otros mantenedores que intentan integrar sus cambios.

  • Cuando una actualización propuesta contiene un cambio ABI o API: notificar una semana por adelantado tanto en la devel list como a los mantenedores directamente (usando el alias packagename-maintainers@fedoraproject.org) cuyos paquetes dependan del suyo para que reconstruyan u ofrecerles hacer esa reconstrucción por ellos.

  • Utilice una etiqueta lateral cuando trabaje con compilaciones masivas de muchos paquetes, para que puedan aterrizar al mismo tiempo. Vea Rawhide Gating/Múltiples Compilaciones.

  • Siéntase libre de publicar la versión más reciente de los paquetes siempre que no provoquen rupturas. También tenga en mente cuando se ramificará la próxima versión de Fedora y tengan bastante confianza en que habrá una versión suficientemente estable a tiempo para el próximo lanzamiento de Fedora. De lo contrario es posible que tenga que retroceder a una versión más antigua y estable después de la ramificación, lo que puede implicar retrasos y otros inconvenientes.

  • Una vez que un paquete ha sido añadido a la composición y que la composición ha terminado y se ha sincronizado con los espejos maestros, normalmente no se le quitará la etiqueta. Esto es necesario para permitir que otros dependan de la compilación una vez se haya hecho visible. En casos excepcionales, Releng puede quitar la etiqueta a paquetes.

  • Si FESCo lo aprueba, impulse versiones preliminares de paquetes de bajo nivel. FESCo aprueba ciertos paquetes, incluyendo (pero no limitado a) glibc y gcc, para proporcionar versiones anteriores al lanzamiento aquí. Los beneficios de las pruebas tempranas en el mundo real y la colaboración desde el desarrollador en estos paquetes claves superan con creces los riesgos que puedan introducir.

Flujo de Actualización

Versión Branched

Una versión Branched existe como parte del ciclo de desarrollo. Empieza como una bifurcación de Rawhide y eventualmente llega a ser la siguiente versión estable. Todas las composiciones ramificadas con éxito debería cumplir los Criterios Básicos de Lanzamiento.

Las versiones Branched usan el sistema de comentarios de actualización (Bodhi): al principio igual que Rawhide (las actualizaciones son creadas automáticamente cuando finaliza la compilación, se ejecutan las pruebas y las compilaciones son enviadas automáticamente a la siguiente composición), pero después de la Activación de updates-testing cambian para usarse como lo hacen las versiones estables (los mantenedores deben crear actualizaciones y enviarlas para prueba, etc).

Hay diversas fases por las que pasa una versión ramificada que afectan a las actualizaciones que se pueden y se deben realizar. En general los mantenedores deberían tener en cuenta que este árbol está siendo estabilizado para la siguiente versión, por lo que los cambios deben ser cuidadosos y considerados y encaminados hacia la estabilidad.

Después de la ramificación hay tres congelaciones, Congelación posterior a la ramificación (Congelación posterior a la ramificación), Congelación Beta (Congelación Beta) y Congelación Final (Congelación Final).

Congelación posterior a la ramificación

Una vez que la nueva versión es ramificada de Rawhide, el flujo de actualizaciones a través de Bodhi se para hasta que se ha realizado una composición ramificada con éxito. Este período suele durar solo unos pocos días. Ingeniería de versión puede pasar algunas actualizaciones a estables para completar la composición, pero de otro modo todas las actualizaciones son pausadas hasta que la composición ramificada inicial está completada. Esto es para asegurarnos que tengamos una composición sobre la que construir y no tengamos problemas para obtener nuevas actualizaciones antes de que estemos listos para ellas.

Antes de la Activación de updates-testing

Por un corto tiempo después de la ramificación pero antes de la Congelación Beta, la versión Branched trabaja como Rawhide: las compilaciones enviadas por los empaquetadores son consideradas stable (estable) después de pasar por cualquier prueba de activación mediante una actualización de Bodhi y son enviadas al repositorio fedora directamente en la siguiente composición nocturna. No hay restricciones más allá de las de Rawhide en este punto, pero los mantenedores DEBERÍAN pensar en la estabilización desde este punto en adelante y asegurarse de que sus paquetes estén en buenas condiciones mucho antes del lanzamiento estable.

Repositorio disponible: fedora

Activación de updates-testing

En este punto, el sistema de actualización Bodhi se cambia para la versión ramificada para comportarse como si lo hiciera para las versiones estables (ver abajo) en lugar de Rawhide. Desde este punto en adelante los mantenedores deben crear actualizaciones antes de que los paquetes lleguen a estar disponibles para los usuarios y las actualizaciones pasan a través de updates-testing para permitir los comentarios. Las actualizaciones se mueven desde el repositorio updates-testing al repositorio fedora después de que los requisitos de karma apropiados han sido alcanzados. Bodhi establece valores predeterminados razonables para el karma y exige requisitos mínimos para las actualizaciones. Los Requisitos de Karma (requisitos de Karma) para las actualizaciones se describen abajo.

Repositorios disponibles: fedora, updates-testing

Los mantenedores DEBERÍAN:

  • Evitar los cambios ABI/API donde sea posible. Si es inevitable, utilice una etiqueta lateral para reconstruir paquetes.

  • Evitar cualquier cambio que rompa las composiciones de medios Live, instalar medio o probar.

  • Obtener los paquetes requeridos por Changes planificados para esta versión.

Congelación Beta

Esta congelación está planificada para ejecutarse en las tres semanas previas a la fecha de lanzamiento, pero dura hasta que se aprueba el lanzamiento, incluso si se retrasa. Durante las congelaciones las compilaciones no se marcarán como stable y se trasladarán desde updates-testing a fedora (y por lo tanto incluidas en el hito de composición de la versión) excepto para aquellas aprobadas bajos los procesos de error bloqueante o de excepción de congelación de error del equipo de Garantía de Calidad de Fedora. Una vez se ha hecho la versión beta, se abandona la congelación. La página Hitos congelados proporciona más detalles y es la referencia canónica en caso de cualquier conflicto.

Una vez que empieza la Congelación Beta, intentamos estabilizar las versiones principales del software que se enviarán con la versión final del sistema operativo. Se pueden tolerar actualizaciones importantes, pero, si es posible, se debe evitar romper cosas para los primeros evaluadores.

Durante este período:

  • Todas las actualizaciones incluidas DEBEN corregir un bloqueador aceptado o un error de excepción de congelación.

  • Todas las actualizaciones aún van a updates-testing.

Repositorios disponibles: fedora, updates-testing

De Beta a Congelación Final

Este es el tiempo entre la versión Beta y la Congelación Final. El árbol ramificado debería ahora ser estabilizado y preparado para la versión. Durante este período deben evitarse cambios importantes. Tenga en cuenta que en la mayoría de los casos, el estado que alcanzó su paquete en el repositorio estable de fedora en el momento de la Congelación Final es el estado en el que estará la versión final.

Repositorios disponibles: fedora, updates-testing

Congelación Final

Esta congelación lleva a la creación de la versión final. Es similar a la Congelación Beta descrita anteriormente y sigue las mismas reglas de actualización.

El repositorio updates se habilita en algún momento de este tiempo y los paquetes distintos a excepción de congelación / bloqueadores están en cola para las llamadas actualizaciones de "día cero", lo que significa que estarán disponibles en el repositorio updates en el momento del lanzamiento (día cero).

Repositorios disponibles: fedora, updates, updates-testing

Durante este período:

  • Todas las actualizaciones incluidas DEBEN corregir un bloqueador aceptado o un error de excepción de congelación.

  • Todas las actualizaciones van todavía a updates-testing.

  • Una vez que el repositorio updates está disponible, las compilaciones marcadas como stable van allí en lugar de a fedora.

Versiones Estables

Filosofía

Los lanzamientos de la distribución Fedora son como los lanzamientos de los paquetes individuales que la componen. Un número de versión principal refleja un conjunto más o menos estable de características y funcionalidades. Como resultado, deberíamos evitar actualizaciones mayores de los paquetes dentro de una versión estable. Las actualizaciones deben tener como objetivo corregir errores y no introducir características, particularmente cuando esas características afecten a la experiencia del usuario o el desarrollador. La tasa de actualización para cualquier versión determinada debería disminuir con el tiempo, aproximándose a cero cerca del final de vida de la versión; ya que las actualizaciones son principalmente correcciones de errores, serán cada vez menos necesarias según pasa el tiempo.

Esto significa necesariamente que las versiones estables no seguirán muy de cerca el último código upstream para todos los paquetes. Tenemos Rawhide para eso.

Las actualizaciones se deberían considerar cuidadosamente con respecto a sus dependencias. Una actualización que requiere (o proporciona) una nueva ABI (Interfaz Binaria de Aplicaciones) Python, por ejemplo, es casi seguro que no estaría permitida. Los cambios en las ABI en general están fuertemente desaconsejados, imponen conjuntos más grandes de actualizaciones a los usuarios y dificultan la vida a los empaquetadores de terceros. Además, las actualizaciones que convierten recursos o configuración de una manera (esto es, de más antiguo →más nuevo) debería abordarse con extrema precaución ya que habría muchas menos posibilidades de revertir una actualización que hiciera estas cosas.

Siempre que sea posible los empaquetadores deberían trabajar con los desarrolladores para generar versiones de ramas estables o parches comunes para versiones anteriores, especialmente cuando la actualización pudiera requerir grandes actualizaciones de la cadena de dependencia.

Repositorios disponibles: fedora updates updates-testing

Durante este período:

Excepciones

Algunas clases de software no se ajustan a estas directrices. Si su paquete no se ajusta a una de las clases de abajo, pero cree que se debería permitir que se actualice más rápidamente, proponga una nueva clase de excepción a FESCo y/o solicite una excepción para su caso de actualización específico.

Tenga en cuenta que debería abrir este diálogo ANTES de compilar o enviar actualizaciones. En caso de que surja alguna cuestión en medio de una actualización ya en ejecución, asegúrese de desactivar los impulsos de autokarma — esto se puede hacer mientras la actualización está pendiente en Bodhi.

Se deberían considerar las siguientes cosas en una solicitud de excepción.

Cosas que harían más probable que se conceda una solicitud:

  • El paquete es un nodo "hoja". Nada depende de él o lo requiere.

  • La actualización corrige una cuestión de seguridad que afectaría a un gran número de usuarios.

  • La actualización no cambia ABI/API y nada necesita volver a ser compilado contra la nueva versión.

  • La actualización corrige serios errores que muchos usuarios de Fedora están encontrando.

Cosas que harían menos probable que se conceda una solicitud:

  • La actualización convierte bases de datos o recursos de alguna manera a un nuevo formato.

  • La actualización requiere intervención del administrador para que el servicio se mantenga en funcionamiento (cambios de formato en el archivo de configuración, etc.)

  • La actualización causa cambios de comportamiento (algo que denegaba está permitido, etc.)

  • La actualización cambia en la UI (Interfaz de Usuario) lo que ve el usuario final (mueve menús o botones, cambia nombres de opción en la línea de comandos)

  • La actualización corrige errores que ningún usuario de Fedora ha reportado ni afectaría a muchos usuarios de Fedora (esto es, corrige para otras plataformas o configuraciones).

Lista de excepciones

Los siguientes paquetes han obtenido excepciones por las siguientes razones:

KDE

Vea más detalles en la política de actualización KDE.

paquete kernel

  • Las limitaciones de tiempo y recursos impiden que los mantenedores de kernel realicen copias de seguridad de todas las correcciones de errores, correcciones de seguridad y habilitación de nuevo hardware que necesitaríamos para mantener kernels más antiguos que ya no son compatibles.

  • Adicionalmente, se pueden instalar/arrancar múltiples kernels, permitiendo a los usuarios arrancar kernels más antiguos en el caso de que los más nuevos fallen al trabajar y permitiendo a los mantenedores del kernel corregir cualquier error crítico en los nuevos kernels sobre las versiones estables más antiguas.

Paquetes Rust -devel

Esta excepción cubre todos los paquetes Rust -devel packages, esto es rpms con fuentes Rust. Esos paquetes se utilizan para crer archivos binarios de Rust y los usuarios no pueden utilizarlos directamente.

Otros paquetes

Estos paquetes tienen permitido actualizar en las versiones estables:

  • el visor de documentos zathura y la librería girara (FESCo #1255),

  • la aplicación de control de impresora 3D prusa-slicer y la pila Cura (CuraEngine y otros paquetes) (FESCo #2652),

  • el formateador de código Python python-black (FESCo #2652),

  • código Python linter ruff (FESCo #3197),

  • el ejecutor de pruebas Python python-tox (FESCo #2652),

  • el cliente HTTP de línea de comando httpie (FESCo #2652),

  • el Cliente de Escritorio ownCloud owncloud-client (FESCo #2652).

  • el Conjunto de Software KiCad EDA kicad, kicad-packages3d, and kicad-doc (FESCo #2762).

  • librería de análisis HTTP llhttp (FESCo #3115).

  • herramienta de cifrado automático SSL`certbot` (FESCo #3124).

  • Python package and project manager uv (FESCo #3262).

Correcciones de seguridad

Si el desarrollador no proporciona correcciones de seguridad para una versión en particular y si respaldar la solución no sería práctico, el mantenedor(es) del paquete DEBE abrir un ticket FESCo para que apruebe cambiar la base del paquete a una versión que se soporte por el desarrollador.

Los mantenedores de paquete DEBEN:

  • Evitar actualizaciones de versiones Principales, fallas de IA o cambios de API si es posible

  • Evitar cambiar la experiencia del usuario o desarrollador si es posible

FESCo revisará el ticket de manera oportuna y dará directrices de como el mantenedor(es) del paquete debería proceder. A modo de información, a continuación se enumeran varios elementos comunes que harían menos probable que FESCo conceda una solicitud de rebase. Tenga en cuenta, sin embargo, que esta lista no es exhaustiva.

  • La actualización requiere intervención de usuario o administrador para seguir funcionando

  • La actualización requiera archivos de configuración o bases de datos u otros recursos para convertir a un nuevo formato

  • La actualización causa cambios de política o comportamiento (como cuando algo que previamente se denegaba se permite ahora, etc.)

  • La actualización cambia la manera en la que el usuario final interactúa con la interfaz de usuario (como mover menús o botones a una nueva ubicación, cambio de nombres de los argumentos de línea de comando, etc.)

  • El rebase solo aborda problemas que probablemente afecten a un número subjetivamente pequeño de usuarios de Fedora

Paquetes con Excepciones Concedidas

  • Kernel

Interoperabilidad

Si un paquete sirve principalmente para interoperar con el hardware o protocolos de red, y cambia la interfaz, un paquete puede ser rebasado si es necesario. Esto incluye juegos en red, protocolos de IM (Mensajería Instantánea), reproductores hardware de música, teléfonos celulares, etc. estos paquetes pueden también ser actualizados para añadir soporte para nuevos dispositivos o formatos de maneras compatibles.

Ejemplos de este tipo de paquete:

Paquetes de base de datos

Los paquetes como escáneres de virus y filtros de spam normalmente tienen dos componentes: un motor de reglas y una base de datos. Se espera que la base de datos se actualice frecuentemente (algunas veces no a través de los mecanismos normales de actualización del sistema operativo), pero el motor de reglas suele ser bastante estático. Sin embargo, si la base de datos mantenida cambia para requerir una nueva versión del motor de reglas, entonces el paquete puede ser candidato a un rebase.

Ejemplos de este tipo de paquete:

Ejemplos

  • Mozilla lanza Firefox 4.0.1 con una solución de seguridad. Fedora 12 se envía con 3.0.7 y, aunque el error también está presente allí, la corrección en 4.0.1 no se aplica porque parte del navegador ha sido vuelto a escribir completamente. Rebasar a 4.0.1 estaría permitido porque esta es una corrección de seguridad.

  • automake lanza una nueva versión que cambia algunas condiciones de las advertencias de errores. Esto podría romper el proceso de compilación de los paquetes existentes y no sería permitido.

  • AOL cambia su protocolo de mensajería instantánea de una forma que requiere una actualización de libpurple. La única versión upstream de libpurple que admite el nuevo protocolo es una ruptura ABI relativa a la versión actual de Fedora. Rebasar estaría permitido ya que es un requisito de interoperabilidad.

  • Abiword lanza una nueva versión que añade compatibilidad con documentos WordStar 4.0. También actualiza completamente la interfaz de usuario para usar menús circulares. Esto sería una mejora de funciones con un cambio importante en la experiencia del usuario y no estaría permitida.

  • WebKit requiere una actualización para resolver un problema de seguridad. Esto requiere una actualización de Midori a una versión con algunos cambios menores en el diseño de menú. Esto sería una decisión basada en cuán intrusivos son los cambios (eliminar el menú Archivo podría ser duro, pero mover el elemento de menú de configuración de complemento sería aceptable).

  • Firefox lanza una actualización que solo contiene cambios para otras plataformas. Esta actualización podría enviarse a Rawhide (para mantenerse al día con la última versión), pero no se debería enviar a las versiones estables, ya que no beneficia a nuestros usuarios y desperdicia recursos para compilar, actualizar, poner en el espejo y descargar a nuestros usuarios.

  • Terminal falla al compilar desde el código fuente cuando se prueba en una recompilación masiva. Se debe enviar un paquete actualizado a Rawhide. Las correcciones para versiones estables deben probarse e incluso confirmarse, pero a no ser que haya problemas con las compilaciones previas existentes en la versión estable, no se enviaría actualización. Esta actualización no cambiará ninguna función del paquete para el usuario.

  • KDE upstream lanza una nueva versión mayor y al mismo tiempo deja de soportar la versión más antigua que está en Fedora N y N-1. Este lanzamiento incluye un gran número de correcciones de errores, mezcladas con mejoras y correcciones de seguridad. Una excepción para este tipo de actualización necesitaría considerar: capacidad de respaldar cuestiones importante de correcciones/seguridad, tipo y cantidad de errores corregidos, capacidad para no actualizar otras partes de Fedora para esta actualización (esto es, evitar cambios de ABI en Qt y otras librerías básicas), cantidad de pruebas y cambios visibles para el usuario final. Una excepción como esta sería sobre una base de caso por caso, basado en todo lo anterior.

Requisitos de Karma

Este sección describe los requisitos para una actualización antes de pueda ser enviada de updates-testing a fedora o updates. Los requisitos se basan en (la suma de) puntos de karma Bodhi y el número de días que la actualización ha pasado en el repositorio_updates-testing_.

El envío puede ser bien por el mantenedor o automáticamente por Bodhi:

  • La actualización llega a ser eligible para ser enviada manualmente después de alcanzar el umbral mínimo "Estable por Karma" para actualizaciones de ruta Crítica (si, se aplica el mismo límite para abos tipos de actualizaciones), O el umbral mínimo "Estable por Tiempo".

  • La actualización será enviada automáticamente por Bodhi después de alcanzar el umbral configurado "Estable por Karma" O el umbral configurado "Estable por Tiempo", si está habilitado ("¿Solicitud automática estable basada en karma?" y "¿Solicitud automática estable basada en tiempo?").

  • Si la actualización tiene cualquier karma negativo, el envío automático es deshabilitado.

  • Si la actualización alcanza el umbral "Inestable por Karma", no será empujada, esto es eliminada del repositorio updates-testing.

El mantenedor es libre de establecer los umbrales, pero no pueden ser más bajos que los valores mínimos descritos a continuación, establecidos por Bodhi. Los predeterminados son adecuados para la mayoría de los paquetes, de modo que normalmente no es necesario modificar los umbrales.

Las actualizaciones de seguridad están sujetas a los mismos umbrales que otros paquetes.

Umbrales de actualización de rutas no críticas

Umbrales de actualización de rutas críticas y EPEL

Las actualizaciones de "ruta critica" contienen al menos un paquete de ruta crítica. El cambio de esta definición solo se puede hacer por FESCo o su delegado.

Problemas o cuestiones con Actualizaciones

En un esfuerzo por aprender de los errores cometidos, en el caso de que una actualización cause un problema generalizado o graves para los usuarios de Fedora, presente un FESCo ticket. En FESCo discutiremos e intentaremos evitar que el problema suceda otra vez. Puede encontrar un registro anterior de estos problemas en Updates Lessons (Lecciones de Actualizaciones).

OpenQA prueba las actualizaciones de rutas criticas en versiones estables y compone artefactos para candidatos Rawhide/branched composes/release..

Fedora CI ejecuta pruebas sobre todas las actualizaciones Bodhi. Si los mantenedores del paquete han marcado las pruebas como bloqueantes, la actualización de Bodhi se bloqueará para que no llegue a estable.

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