Política de atualizações

O Fedora tem políticas diferentes para cada um de seus ramos (branches). Este documento descreve para os mantenedores que tipo de atualizações devem ser criadas em pacotes para cada um dos vários ramos do Fedora existente. Em caso de dúvidas ou esclarecimentos, envie um tíquete FESCo ou discuta na lista devel. Em geral, as versões devem ir de menos conservadoras (Rawhide) para mais (a versão estável mais antiga com suporte). Este documento tenta descrever quando e que tipo de atualizações os mantenedores devem enviar para os usuários do Fedora em seus vários ramos. O Visão das atualizações de versão estável da Diretoria do Fedora inclui mais discussão e filosofia de alto nível, enquanto este documento é mais um guia prático. Consulte o Package update HOWTO para as etapas técnicas sobre como fazer push de atualizações. O Fedora Release Life Cycle fornece uma visão geral mais detalhada do processo de desenvolvimento.

Requisitos de atualizações comuns para todas as versões do Fedora

Alguns critérios se aplicam a qualquer atualização de qualquer ramo/versão do Fedora:

Atualizando pacotes interdependentes

Quando um pacote atualizado requer um ou mais outros pacotes, os pacotes devem ser enviados juntos como uma única atualização. Por exemplo, se o pacote A depende dos pacotes B e C, e você deseja atualizar para uma nova versão do pacote A que requer novas versões de B e C, você deve enviar uma única atualização contendo as versões atualizadas de todos os três pacotes. É uma má ideia enviar três atualizações separadas, porque se a atualização do pacote A for estável antes das atualizações dos pacotes B e C, isso causará problemas de dependência. Há informações sobre como enviar atualizações de vários pacotes no package update HOWTO e informações sobre o uso de tags laterais para atualizações múltiplas no Rawhide Gating/multi-builds.

Atualizações consumíveis

As atualizações do Bodhi devem ser criadas apenas para compilações que se espera que sejam qualificadas para serem colocadas em estáveis. Os mantenedores não devem usar os estados de teste do Bodhi para testar as atualizações que eles nunca pretendem fazer por push. Este tipo de teste deve ser feito no Copr ou outros repositórios públicos separados. Consulte a equipe de QA para obter mais assistência de teste.

Rawhide

Rawhide é a árvore de desenvolvimento sempre em andamento. As atualizações de pacotes criadas para Rawhide são compostas todos os dias e enviadas a todos os seus usuários. Novas compilações nesta árvore também são adicionadas à raiz da compilação (ou seja, outros pacotes compilados a partir deles). Esta árvore tem como objetivo atender aos critérios básicos de lançamento para qualquer composição bem-sucedida para que os mantenedores possam integrar suas alterações com todos os outros.

Repositórios disponíveis: rawhide

Desde que a mudança Gating Rawhide Packages foi introduzida, as atualizações de pacotes no Fedora Rawhide precisam passar na verificação antes de chegarem aos repositórios Rawhide. Isso é implementado como uma verificação para a atualização do Bodhi, que verifica se a atualização satisfaz a política de Gating. Veja o Rawhide Gating/Single Builds e o Rawhide Gating/Multi Builds para obter detalhes.

Atualmente, a política de gating padrão está vazia, portanto, uma atualização do Rawhide pode passar, independentemente dos resultados do teste. O mantenedor do pacote pode optar pelo gating de um pacote, configurando políticas de gating individuais, consulte o link:https: Gating].

Assim que uma construção é concluída, uma atualização Bodhi é criada automaticamente. A atualização é usada para coletar resultados de teste. Se os testes de gating passarem, a atualização será marcada como estável após alguns minutos, tornada estável e será adicionada à composição noturna seguinte.

Para atualizações de pacotes Rawhide, os mantenedores DEVEM:

  • não enviar nenhuma compilação sabidamente quebrada (quebra o conjunto de pacotes buildroot padrão, etc.). Isso causa trabalho adicional para outros mantenedores que tentam integrar suas mudanças.

  • Quando uma atualização proposta contém uma alteração de ABI ou API: notifique com uma semana de antecedência a lista devel e os mantenedores diretamente (usando o apelido nomedopacote-owner@fedoraproject.org) cujos pacotes dependem do seu para reconstruir ou se oferecem para fazer essas reconstruções para eles.

  • Use uma tag lateral ao lidar com construções em massa de muitos pacotes, para que eles possam chegar ao mesmo tempo. Veja o Rawhide Gating/Multi Builds.

  • Sinta-se à vontade para lançar a versão mais recente dos pacotes, desde que eles não quebrem. Também tenha em mente quando o próximo lançamento do Fedora será ramificado e esteja bastante confiante de que haverá um lançamento estável o suficiente a tempo para o próximo lançamento do Fedora. Caso contrário, você pode ter que voltar para uma versão mais antiga e estável após a ramificação, o que pode envolver épocas e outros inconvenientes.

  • Depois que um pacote é adicionado à composição e essa composição é concluída e sincronizada com os espelhos mestres, normalmente ele não será desmarcado (untagged). Isso é necessário para permitir que outros dependam da build, uma vez que ela se torne visível. Em casos excepcionais, a_releng_ pode desmarcar pacotes.

  • Se aprovado pelo FESCo, envie versões de pré-lançamento de pacotes de baixo nível. O FESCo aprova certos pacotes, incluindo (mas não se limitando a) glibc e gcc, para fornecer versões de pré-lançamento aqui. Os benefícios dos primeiros testes no mundo real e da colaboração upstream nesses pacotes principais excedem em muito os riscos que eles podem apresentar.

Fluxo de atualizações

Versão ramificada

Uma versão ramificada (branched) para parte do ciclo de desenvolvimento. Ela começa como um fork do Rawhide e eventualmente se torna a próxima versão estável. Todas as composições ramificadas com sucesso devem atender aos critérios básicos de lançamento.

Versões ramificadas usam o sistema de feedback de atualização (Bodhi): a princípio, assim como Rawhide (atualizações são criadas automaticamente quando uma compilação termina, os testes são executados e as compilações são automaticamente enviadas para a próxima composição), mas depois da Ativação do updates-testing, elas passam a usá-lo da mesma forma que as versões estáveis (os mantenedores devem criar atualizações e enviá-las para teste, etc).

Existem várias fases pelas quais uma versão ramificada passa que afetam as atualizações que podem e devem ser feitas. Em geral, os mantenedores devem ter em mente que esta árvore está sendo estabilizada para a próxima lançamenta, portanto, as alterações devem ser cuidadosas e consideradas, visando a estabilidade.

Após a ramificação, há três congelamentos (freezes): Congelamento pós-ramificação, Congelamento beta e Final Freeze.

Congelamento pós-ramificação

Uma vez que a nova versão é ramificada do Rawhide, o fluxo de atualizações através do Bodhi é interrompido até que haja uma composição ramificada bem-sucedida. Chamado de _ Post-branch Freeze_ em inglês, esse período geralmente dura apenas alguns dias. A engenharia de lançamento pode passar algumas atualizações para estável para que a composição seja concluída, mas, caso contrário, todas as atualizações são pausadas até que esta composição ramificada inicial seja concluída. Isso é para ter certeza de que temos uma composição sobre a qual construir e não estamos lidando com problemas para receber novas atualizações antes de estarmos prontos para elas.

Antes da ativação do updates-testing

Por um curto período de tempo após a ramificação, mas antes do Congelamento beta, a versão ramificada funciona como Rawhide: as compilações enviadas por empacotadores são consideradas estáveis (stable) após passar por qualquer teste de gating por meio de uma atualização Bodhi e são enviadas para o repositório fedora diretamente na próxima composição noturna. Não há restrições além daquelas para Rawhide neste ponto, mas os mantenedores DEVEM pensar sobre a estabilização a partir deste ponto, e ter certeza de que seus pacotes estarão em boas condições antes do lançamento estável.

Repositórios disponíveis: fedora

Ativação do updates-testing

Neste ponto, o sistema de atualização Bodhi é alterado para a versão ramificada para se comportar como faz para versões estáveis (veja abaixo) em vez de Rawhide. Deste ponto em diante, os mantenedores devem criar atualizações antes que os pacotes se tornem disponíveis para os usuários e as atualizações passem pelo updates-testing para permitir feedback. As atualizações são movidas do repositório updates-testing para o repositório fedora após os requisitos de carma (karma) apropriados serem alcançados. Bodhi define padrões razoáveis para o carma e impõe requisitos mínimos para atualizações. Karma requirements para atualizações são descritos abaixo.

Repositórios disponíveis: fedora, updates-testing

Os mantenedores DEVEM:

  • Evitar alterações de ABI/API sempre que possível. Se for inevitável, use uma tag lateral para reconstruir os pacotes.

  • Evitar qualquer alteração que quebra composições de mídia Live, mídia de instalação ou teste.

  • Obter todos os pacotes necessários para as mudanças planejadas para esta versão.

Congelamento beta

Conhecido como beta freeze em inglês, esse congelamento está programado para ocorrer pelas três semanas anteriores à data de lançamento, mas dura até que o lançamento seja assinado, mesmo se atrasado. Durante o congelamento, as compilações não serão marcadas como stable e movidas do updates-testing para o fedora (e, portanto, incluídas nas composições de marco da versão), exceto para aqueles aprovados pelo processo de bug bloqueador ou processo de bug de exceção de congelamento da equipe de QA do Fedora. Uma vez que a versão beta é feita, o congelamento é levantado. A página Milestone freezes fornece mais detalhes e é a referência canônica em caso de qualquer conflito.

Assim que o congelamento beta começa, estamos tentando estabilizar as principais versões de software que serão enviadas com a versão final do sistema operacional. Grandes atualizações podem ser toleradas, mas quebrar coisas para os primeiros testadores deve ser evitado, se possível.

Durante este período:

  • All updates pulled into the release MUST fix an accepted blocker or freeze exception bug.

  • All updates still go to updates-testing.

Repositórios disponíveis: fedora, updates-testing

Beta to Final Freeze

This is the time between the Beta release and the Final Freeze. The branched tree should now be stabilized and prepared for release. Major changes should be avoided during this period. Bear in mind that in most cases, the state your package has reached in the stable fedora repository at the time of the Final Freeze is the state it will be in for the final release.

Repositórios disponíveis: fedora, updates-testing

Final Freeze

This freeze leads to the creation of the final release. It is similar to the Congelamento beta described above and follows the same update rules.

The updates repository is enabled at some point during this time, and packages other than freeze exception / blocker fixes are queued for so called "zero day" updates, meaning they will be available in the updates repository at the time of the release (day zero).

Repositories available: fedora, updates, updates-testing

Durante este período:

  • All updates pulled into the release MUST fix an accepted blocker or freeze exception bug.

  • All updates still go to updates-testing.

  • Once the updates repository is available, builds marked as stable will go there instead of to fedora.

Stable Releases

Philosophy

Releases of the Fedora distribution are like releases of the individual packages that compose it. A major version number reflects a more-or-less stable set of features and functionality. As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time.

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:

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.

KDE

Refer to the KDE update policy for more details

girara and zathura

These packages are allowed to update in stable releases together. See this FESCo ticket.

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. By way of information, 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.

FESCo will be less likely to grant a rebase request if:

  • 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: libopenraw, libimobiledevice, calibre, pilot-link

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: spamassassin, clamav

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

Stable by Karma: minimum +1, default +3, between Ativação do updates-testing and Congelamento beta
                       minimum +2, default +3, after Congelamento beta
Unstable by Karma: maximum -1, default -3 + Stable by Time (days): minimum 3, default 3, between Ativação do updates-testing and Congelamento beta
                       minimum 7, default 7, after Congelamento beta

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.

Stable by Karma: minimum +1, default +3, between Ativação do updates-testing and Congelamento beta
                       minimum +2, default +3, after Congelamento beta
Unstable by Karma: maximum -1, default -3 + Stable by Time (days): minimum 3, default 3, between Ativação do updates-testing and Congelamento beta
                       minimum 14, default 14, after Congelamento beta

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.