Esta página preserva um documento do passado do Fedora. Pode não (e provavelmente não) refletir as políticas atuais ou práticas do Projeto Fedora.

A "Visão de Atualizações Estáveis" foi adotada pelo Conselho do Fedora em março de 2010 e é referenciada na atual política de atualizações do Comitê Diretor de Engenharia do Fedora (FESCo). Embora alguns dos fatores de contexto tenham mudado desde então, os fundamentos que orientaram a política do FESCo ainda são relevantes.

Conhecimento

Discussions on March 2010 in various Fedora mailing lists have shown that we currently have a wide variety of positions on what Fedora’s update strategy should look like. These range from a rolling release, to a locked down security-only update solution. The lack of clarity on this issue contributes to confusion among package maintainers and end users alike.

A maioria das pessoas concorda que atualizações quebradas são prejudiciais para a distribuição Fedora e devem ser evitadas.

Poucas pessoas concordam em:

  • How many updates are acceptable for a stable release and how to measure them.

  • O que constitui uma atualização aceitável para uma versão estável.

  • A que custo as atualizações quebradas devem ser evitadas, considerando a troca de atualizações ocasionalmente defeituosas pela velocidade de entrega de novos softwares e pela simplicidade do fluxo de trabalho dos mantenedores.

For these reasons, the Fedora Board is issuing a stable release update vision statement to help guide the creation and implementation of a Fedora Updates policy. This policy is not meant to govern the introduction of new packages.

By creating this statement, it is the Board’s belief that:

  • A satisfação dos usuários finais com nossa distribuição aumentará

  • Os desenvolvedores e os usuários finais terão uma experiência mais sólida com as versões estáveis

  • Os usuários finais e desenvolvedores terão mais tempo para se concentrar em outras áreas no Fedora

Fatores

When creating an updates overview, there are some factors that need to be taken into account. The first, and foremost, is keeping in mind the broad criteria the Board set out for the target audience of the entire Fedora distribution, which describe someone who:

  1. está mudando voluntariamente para o Linux

  2. está familiarizado com computadores, mas não necessariamente é um hacker ou desenvolvedor

  3. provavelmente colaborará de alguma forma quando algo estiver errado com o Fedora, e

  4. deseja usar o Fedora para produtividade geral, seja usando aplicativos de desktop ou um navegador da web.

A shifting platform and visible behavioral changes will affect the user’s productivity because the user must take time away from the desired tasks to discover what has changed, adjust the way they perform supporting tasks, and refocus on their original objectives. Because productivity is postulated as important to this user, this outcome is undesirable. Similarly, dealing with a large number of updates on a regular basis is distracting from the user’s desired productivity tasks.

Updates offered by our built-in tools under the auspices of the Fedora Project are seen as authoritative by users. While a user fitting these criteria is likely to file a bug when something goes wrong, the user does not therefore automatically expect new issues to emerge in a stable release as a result of consuming those updates. When such issues do emerge, the user’s confidence in the platform is undermined.

Another factor to keep in mind is Fedora’s rapid development cycle. A six-month development cycle for a release allows Fedora to integrate the latest and greatest releases from upstream projects into the 'rawhide' distribution and have that body of work available to the user base in a relatively short amount of time. Ideally, this rapid paced release cycle allows both developers and users the chance to focus on a coherent, consistent, and well functioning set of software content per release.

Declaração de missão

Levando em consideração o contexto e os vários fatores mencionados acima, o Conselho acredita que as correntes de atualização devem ser gerenciadas com os seguintes objetivos em mente:

  • Os repositórios de atualizações para versões estáveis da distribuição Fedora devem fornecer aos nossos usuários um fluxo consistente e de alta qualidade de atualizações.

  • As versões estáveis devem proporcionar uma experiência de usuário consistente ao longo de todo o ciclo de vida, e somente corrigir bugs e problemas de segurança.

  • As versões estáveis não devem ser usadas para rastrear de perto as versões upstream quando isso provavelmente mudará a experiência do usuário além da correção de bugs e problemas de segurança.

  • O acompanhamento rigoroso da origem (upstream) deve ser feito sempre que possível no repositório Rawhide, e devemos nos esforçar para enviar nossos patches (correções) de volta para a origem (upstream).

  • More skilled and/or intrepid users are encouraged to use Rawhide along with participating in testing of stable branches during the development and pre-release period.

  • Stable releases, pre-release branches, and Rawhide have a graduated approach to what types of updates are expected. For example, a pre-release branch should accept some updates which a stable release would not, and rawhide would accept updates that are not appropriate for either a stable release or a pre-release.

  • Os membros do projeto devem ser capazes de medir ou monitorar de forma transparente um novo processo de atualizações para medir objetivamente sua eficácia e determinar se o processo de atualizações está alcançando as declarações de visão mencionadas anteriormente.

Implementação

Seguindo a declaração de visão do Conselho do Fedora, a seguinte política foi aprovada e está em vigor desde outubro de 2010:

Updates Policy

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