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 Karma requirements (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.

This necessarily means that stable releases will not closely track the very latest upstream code for all packages. We have Rawhide for that.

Updates should be carefully considered with respect to their dependencies. An update that required (or provided) a new Python ABI, for example, would almost certainly not be allowed. ABI changes in general are very strongly discouraged, they force larger update sets on users and they make life difficult for third-party packagers. Additionally, updates that convert resources or configuration one way (i.e., from older → newer) should be approached with extreme caution as there would be much less chance of backing out an update that did these things.

Whenever possible packagers should work with upstream to come up with stable branch releases or common patches for older releases, particularly when updating would require large dependency chain updates.

Repositories available: fedora updates updates-testing

Durante este período:

Exceptions

Some classes of software will not fit in these guidelines. If your package does not fit in one of the classes below, but you think it should be allowed to update more rapidly, propose a new exception class to FESCo and/or request an exception for your specific update case.

Note that you should open this dialog before you build or push updates. In the event that an issue is raised in the middle of an update already in progress, make sure you turn off autokarma pushes — this can be done while the update is pending in Bodhi.

The following things would be considered in a exception request.

Things that would make it more likely to grant a request:

  • The package is a "leaf" node. Nothing depends on it or requires it.

  • The update fixes a security issue that would affect a large number of users.

  • The update doesn’t change ABI/API and nothing needs to be rebuilt against the new version.

  • The update fixes serious bugs that many Fedora users are encountering.

Things that would make it less likely to grant a request:

  • The update converts databases or resources one way to a new format.

  • The update requires admin intervention for the service to keep working (config file format changes, etc.)

  • The update causes behavior changes (something that was denied is allowed, etc.)

  • The update changes the UI the end user sees (moves menus or buttons around, changes option names on command line)

  • The update fixes bugs that no Fedora user has reported nor would affect many Fedora users (i.e., fixes for other platforms or configurations).

Exceptions list

The following packages have been granted exceptions for the following reasons:

KDE

Refer to the KDE update policy for more details.

kernel package
  • Time and resource constraints prevent the kernel maintainers from backporting all the bug fixes, security fixes and new hardware enablement we would need to maintain older, no longer supported kernels.

  • Additionally, multiple kernels can be installed/booted, allowing users to boot older kernels in the event newer ones fail to work, and allowing time for kernel maintainers to fix any critical bugs in new kernels on older stable releases.

Rust -devel packages

This exception covers all Rust -devel packages, i.e. rpms with Rust sources. Those packages are used to build packaged Rust binaries and are not directly usable by users.

Other packages

These packages are allowed to update in stable releases:

  • 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).

Security fixes

If upstream does not provide security fixes for a particular release, and if backporting the fix would be impractical, then the package maintainer(s) MUST open a FESCo ticket for approval to rebase the package to a version that upstream supports.

Package maintainers MUST:

  • Avoid Major version updates, AI breakage, or API changes if at all possible

  • Avoid changing the user or developer experience if at all possible

FESCo will review the ticket in a timely manner and give guidance as to how the package maintainer(s) should proceed. Several common items that would make it less likely for FESCo to grant a rebase request are listed below. Please note, however, that this list is not exhaustive.

  • The update requires user or administrator intervention to keep working

  • The update requires configuration files or databases or other resources to convert to a new format

  • The update causes policy or behavior changes (such as when something that was previously denied is now allowed, etc.)

  • The update changes the way the end user interacts with the user interface (such as moving menus or buttons to a new location, changing names of command-line arguments, etc.)

  • The rebase only addresses issues that are likely to affect a subjectively small number of Fedora users

Packages with Exceptions Granted
  • kernel

Interoperability

If a package primarily serves to interoperate with hardware or network protocols, and the interface changes, then a package may be rebased if necessary. This includes network games, IM protocols, hardware music players, cell phones, etc. These packages may also be updated to add support for new devices or formats in compatible ways.

Examples of this type of package:

Database packages

Packages like virus scanners and spam filters typically have two components: a rules engine and a database. The database is expected to update frequently (sometimes not through the normal OS update mechanisms), but the rules engine is usually fairly static. However, if the maintained database changes to require a new version of the rules engine, then the package may be a candidate for rebasing.

Examples of this type of package:

Examples

  • Mozilla releases Firefox 4.0.1 with a security fix. Fedora 12 is shipping with 3.0.7, and though the bug is also present there, the fix in 4.0.1 does not apply because that part of the browser has been completely rewritten. Rebasing to 4.0.1 would be allowed since this is a security fix.

  • automake releases a new version that changes some warning conditions to errors. This would break the build process for existing packages, and would not be allowed.

  • AOL changes their instant messenger protocol in a way that requires an update to libpurple. The only upstream version of libpurple that supports the new protocol is an ABI break relative to the version in the current Fedora release. Rebasing would be allowed since this is an interoperability requirement.

  • Abiword releases a new version that adds compatibility with WordStar 4.0 documents. It also completely updates the user interface to use pie menus. This would be a feature enhancement with a major user experience change, and would not be allowed.

  • WebKit requires an update to solve a security problem. This requires updating Midori to a version with some minor menu layout changes. This would be a judgment call based on how intrusive the changes are (removing the File menu would be rude, but moving the plugin configuration menu item would be acceptable).

  • Firefox releases an update that only contains changes for other platforms. This update could be pushed to Rawhide (to keep up with the latest version), but should not be pushed to stable releases, as it does no good to our users and wastes resources to build, update, mirror, and download to our users.

  • Terminal fails to build from source when tested in a mass rebuild. An updated package should be pushed to Rawhide. Fixes for stable releases should be tested and even committed, but unless there is a problem with the previous existing build in the stable release, no update should be issued. This update would not change any user facing functions of the package.

  • KDE upstream releases a new major version, and at the same time stops supporting the older release that is in Fedora N and Fedora N-1. This release includes a large number of bugfixes, mixed with enhancements and security fixes. An exception for this type of update would need to consider: ability to backport major fixes/security issues, type and amount of bugs fixed, ability to not update other parts of Fedora for this update (i.e., avoid Qt or other base library ABI changes), amount of testing and end user visible changes. An exception like this would be on a case by case basis, based on all the above.

Karma requirements

This section describes the requirements for an update before it may be pushed from updates-testing to fedora or updates. The requirements are based on (the sum of) Bodhi karma points and the number of days the update has spent in updates-testing repository.

The push may be either by the maintainer, or automatically by Bodhi:

  • The update becomes eligible for being pushed manually after reaching the minimum "Stable by Karma" threshold for Critical path updates (yes, the same limit applies to both types of updates), OR the minimum "Stable by Time" threshold.

  • The update will be pushed automatically by Bodhi after reaching the configured "Stable by Karma" threshold, OR the configured "Stable by Time" threshold, if enabled ("Auto-request stable based on karma?" and "Auto-request stable based on time?").

  • If the update has any negative karma, the automatic push is disabled.

  • If the update reaches the "Unstable by Karma" threshold, it will be unpushed, i.e. removed from the updates-testing repository.

The maintainer is free to set the thresholds, but they cannot be lower than the minimum values described below, enforced by Bodhi. The defaults are adequate for most packages, so usually there is no need to modify the thresholds.

Security updates are subject to the same thresholds as other updates.

Non-critical path update thresholds

Critical path and EPEL update thresholds

"Critical path" updates contain at least one critical path package. Changes to this definition may only be made by FESCo or their delegate.

Problems or issues with Updates

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 tests critpath updates in stable releases and compose artifacts for Rawhide/branched composes/release candidates.

Fedora CI runs tests on all Bodhi updates. If package maintainers have marked the tests as blocking, the Bodhi update will be blocked from going stable.