Normativa 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 normativas para funcionar 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 Empaquetedo de Fedora y las normativas 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 el conjunto fomentar el co-mantenimiento y la colaboración para mejorar el empaquetado en toda la colección de Fedora.

Sobre esta normativa

Fedora has differing policies for each of its branches. This document describes for maintainers what sort of updates should be created in packages for each of the various branches of existing Fedora. In the event of questions or clarifications, please file a FESCo ticket or discuss on the devel list. In general, releases should go from less conservative (Rawhide) to more so (the oldest supported stable release). This document attempts to describe when and what kinds of updates maintainers should push to Fedora users of its various branches. The Stable release updates vision from the Fedora Board includes more high level discussion and philosophy, while this document is more a practical guide. Refer to Package Update Guide for the technical steps on pushing the updates. The Fedora Release Life Cycle provides a more detailed overview of the development process.

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.

Desarrollo

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 Obtención de Paquetes en Crudo, las actualizaciones de paquetes en Fedora en Crudo necesitan pasar verificación antes de que aterricen en los repositorios en crudo. Esto se implementa como una verificación de la actualización de Bodhi, que verifica que la actualización satisface la normativa de obtención. Consulte detalles en Obtención en Crudo/Compilaciones Únicas y Obtención en Crudo/Múltiples Compilaciones.

Actualmente la normativa de activación predeterminada está vacía, por lo tanto una actualización en Crudo puede pasar el portal, sin importar los resultados de la prueba. El mantenedor de un paquete puede optar por la activación de un paquete, configurando normativa de activación individuales, consulte ¿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 [updates-testing-activation] 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 de Beta y Activación de pruebas de Actualizaciones (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 de Beta y Activación de pruebas de Actualizaciones, la versión Ramificada 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

Congelación de Beta y Activación de pruebas de Actualizaciones

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.

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.

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

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.

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 de Beta y Activación de pruebas de Actualizaciones 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 auto-karma — 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

Refiérase a la normativa de actualización KDE para más detalles.

LXQt

El LXQt SIG está concedido una excepción permanente para el paquete LXQt Desktop. (Esta excepción no aplica a paquetes de exteriores del proyecto LXQt.)

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.

paquete golang

FESCo grants a blanket exception to update the golang package (Go toolchain) in stable Fedora releases to the next supported upstream release once the version that was shipped at a Fedora release’s GA has gone end-of-life upstream (FESCO #3570).

Otros paquetes

Estos paquetes tienen permitido actualizar en las versiones estables:

  • the document viewer zathura and the girara library (FESCo #1255),

  • 3D printer control application prusa-slicer and the Cura stack (CuraEngine and other packages) (FESCo #2652),

  • Python code formatter python-black (FESCo #2652),

  • Python code linter ruff (FESCo #3197),

  • Python test executor python-tox (FESCo #2652),

  • command-line HTTP client httpie (FESCo #2652),

  • ownCloud Desktop Client owncloud-client (FESCo #2652),

  • KiCad EDA Software Suite kicad, kicad-packages3d, and kicad-doc (FESCo #2762),

  • HTTP parsing library llhttp (FESCo #3115),

  • Automatic Let’s Encrypt SSL tool certbot (FESCo #3124),

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

  • Python user space tool for the kernel’s DAMON framework python-damo (FESCo #3389),

  • Docker plugins docker-compose, docker-buildx, and docker-buildkit (FESCo #3394),

  • The image editor gimp (FESCo #3511),

  • Python type checker and language server ty (FESCo #3564),

  • WebKitGTK web rendering engine (FESCo #3565),

  • Docker server and command line client (moby-engine, docker-cli) and rootlesskit for unprivileged users (FESCo #3602),

  • containerd container runtime (FESCo #3603),

  • docker distribution container registry (FESCo #3604),

  • go2rpm Go specfile generator (FESCo #3610).

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 ABI 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 normativa 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

  • Estable por Karma: mínimo +1, predeterminado +3

  • Inestable por Karma: máximo -1, predeterrminado -3

  • Estable por Tiempo (días): mínimo 7, predeterminado 7

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.

  • Estable por Karma: mínimo +2, predeterminado +3

  • Inestable por Karma: máximo -1, predeterrminado -3

  • Estable por Tiempo (días): mínimo 14, predeterminado 14

Problemas o cuestiones con Actualizaciones

In an effort to learn from any mistakes made, in the event of a update causing a widespread or serious problem for Fedora users, please file a FESCo ticket. FESCo will discuss and try and work to prevent the issue from happening again. A past record of such issues can be found at Updates Lessons.

OpenQA prueba las actualizaciones de rutas criticas y compone artefactos para candidatos Rawhide/ramificados 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 ›