de Finibus Bonorum et Malorum



Reclamações recentes

Entendendo os Releases da Debian

O ciclo de lançamentos do Debian não é usual.

A maioria das distribuições de Linux segue um de dois caminhos. Algumas delas seguem uma frequência bem definida, com uma nova versão lançada de acordo com um período específico. Por exemplo, a cada seis meses é lançada uma nova versão de Ubuntu. Outras distribuições, no entanto, escolhem datas de lançamento com base em outros critérios, como por exemplo as datas de lançamentos de softwares considerados importantes, como o kernel, X.Org, Kde e GNOME. Um exemplo desse tipo de ciclo é a Red Hat.

A Debian, entretanto, é bem particular com relação a esse tópico (pra variar). Mas, antes de entrar nisso, ajuda entender um pouco mais sobre as versões do Debian primeiro.

O que são os lançamentos do Debian

Sempre existem três versões do Debian:

  • Unstable é a porta de entrada de software no Debian. Qualquer versão nova de um programa, ou novos programas, são incluídos primeiro aqui. Isso significa que a Sid (como ela é chamada) normalmente se mantém atualizada com relação ao software que oferece. Isso também quer dizer que ela pode conter muitos bugs e outros problemas, então normalmente ela é recomendada para desenvolvedores e mantenedores (embora qualquer um possa usar, se quiser).
  • Testing está sempre um pouco atrás da Sid. Os pacotes chegam depois de passar um certo número de dias na unstable. O número de dias depende do tipo de pacote, mas no geral isso significa que software que entra na testing passou por um mínimo de testes e pode conter alguns consertos de bugs. Tudo que entra na distribuição acaba aqui, onde passa por testes extensivos (pelo uso mais generalizado) – daí o nome de testing.
  • Stable é a versão oficial. Ela contém software que foi testado à exaustão, e não recebe upgrades. Na imensa maioria, as atualizações que chegam à Stable são correções de segurança, e a Debian tem uma equipe dedicada somente a isso. Então, se segurança e/ou estabilidade são essenciais, esta é a versão mais recomendada.

Os nomes dos lançamentos Debian são tirados dos personagens dos filmes Toy Story, da Pixar. Tanto a testing quanto a stable recebem novos codinomes quando o lançamento acontece, mas a unstable sempre se chama Sid (o vizinho que quebrava todos os brinquedos).

Mantenedores e desenvolvedores da Debian usam a unstable para criar novos pacotes, e depois os enviam para os repositórios, onde eles entram na Sid. Dependendo do seu desempenho com o tempo, o pacote então é “promovido” para a testing, onde pode alcançar um número maior de pessoas. Mas ele não entra na stable; esse é um processo diferente.

O processo de Congelamento

Durante o ciclo de lançamento, a testing acumula as versões mais recentes de software que tenha sido minimamente testado, vindo da unstable, até que a Equipe de Lançamento (um grupo de desenvolvedores Debian responsáveis por fazer os lançamentos, entre outras coisas) declara o Freeze (congelamento) da testing.

O processo de congelamento é o que prepara a testing para ser lançada como a nova stable. Durante as três fases do processo, a migração de pacotes da unstable para a testing fica cada vez mais específica. Isso não significa necessariamente que a testing mude pouco, mas que a natureza das mudanças se torna cada vez mais específica.

Transition

A transição é a primeira fase do congelamento. Nesse períoso as regras são mais permissivas que mais adiante, mas nenhuma transição grande é permitida; os pacotes não podem ser atualizados para versões major superiores, e outras mudanças muito grandes nos programas não são mais aceitas, nem mudanças de bibliotecas. Fora isso, as regras de migração (passagem de um pacote da unstable para a testing) permanecem quase as mesmas.

Por exemplo, o kernel do Linux 5.0 – que foi lançado em 4 de Março – não teria entrado na Buster a menos que tivesse sido lançado alguns dias antes de 12 de Janeiro, que foi quando a transição começou.

Soft freeze

Durante o congelamento “leve”, as coisas começam a ficar mais difíceis. Pacotes só entram na testing depois de passar dez dias na unstable, e normalmente somente correções menores são permitidas. Nenhum pacote fonte é permitido, o que significa que nenhum código novo entra. A migração em geral começa a acontecer de forma manual para alguns pacotes.

Tomando como exemplo o GNOME 3.32 – que saiu em 13 de Março –, ele não teria entrado mesmo se fosse lançado alguns dias antes, já que a mudança do 3.30 para o 3.32 foi maior que o permitido durante essa fase. (ATENÇÃO: isso é especulação da minha parte).

Full freeze

O congelamento total é a fase final, e se preocupa principalmente com eliminar todos os bugs que sejam considerados Críticos ao Lançamento: qualquer bug classificado como serious, grave ou critical. Para detalhes sobre a severidade dos bugs, veja isto.

A esta altura, as únicas mudanças permitidas nos pacotes são as que corrijam bugs RC, com correções a bugs importantes sendo opcionais. Além disso, os pacotes têm que passar pelo Autopkgtests, o que significa que os sistemas de compilação da Debian conseguem compilar e montar o pacote automaticamente sem erros. Finalmente, qualquer pacote só entra na testing se for revisado manualmente – não há mais checagem automática.

Quando chega ao full freeze, a testing fica assim o tempo que precisar. Idealmente, uma nova Stable só é lançada quando o número de bugs RC chega a zero. No entanto, as coisas nunca são assim tão simples; alguns bugs são mais resilientes que outros, e uma correção pode não ser possível. Em algum momento, quando o número de bugs RC é baixo, os desenvolvedores marcam esses bugs com uma de duas tags: buster-can-defer ou buster-will-remove. A primeira significa que a correção vai ser adiada para um lançamento pontual ou para a próxima stable. A outra significa que esse pacote não pode entrar na stable com esse bug, então ele é removido do lançamento (e talvez volte se o bug for corrigido).

O Lançamento

Quando esse momento chega, uma data é estabelecida e a Equipe de Lançamento planeja o lançamento. Por exemplo, a Stretch foi planejada para 17 de Junho de 2017. Depois disso, correções de bug finais podem entrar, desde que respeitem o deadline definido pela equipe.

Os Arquivos são assinados, correções finais são feitas, os últimos bugs são adiados ou os pacotes removidos, e o lançamento acontece. Nos arquivos, os links “stable”, “oldstable” e “testing” são reconstruídos de acordo para apontar para os diretórios corretos, e um novo diretório é criado, onde é feita uma cópia da testing no momento do lançamento, e o processo começa todo de novo.

Viva! Um novo Debian nasceu!

Comentários finais

Este post contém informações que eu encontrei na documentação da própria Debian. Isso inclui, mas não se limita a, a política de congelamento, as páginas do wiki sobre a Testing e os Lançamentos, e os arquivos das listas de discussão relacionadas ao assunto (como debian-announce, debian-devel-announce e debian-release).

Mesmo assim, isso envolveu um pouco de suposição, já que não é claro nem óbvio como ou quando certas coisas são decididas. Isso inclui, por exemplo, o que leva ao congelamento, ou como a Equipe de Lançamento decide que é hora de dar um ponto final na “dança” daqueles últimos bugs (ou como eu comecei a chamar, “ou vai ou racha”). Eu não me atreveria a deixar entender que conheço intimamente o ciclo de lançamentos da Debian, nem seus pormenores; sou apenas um usuário e aficcionado da Debian há vinte anos, então considere este texto como uma visão externa.

No nomento da escrita, a Buster está no freeze há 117 dias, e se passaram 1 ano e 11 meses desde o lançamento da Stretch. O tempo “médio” entre lançamentos é mais ou menos dois anos, então estamos, provavelmente, próximos de um novo lançamento. Essa proximidade incentivou minha iniciativa em criar uma maneira de seguir esse lançamento, mesmo que seja imprecisa; falarei a respeito no meu próximo post.


Comentários

  1. […] Pouco mais de um ano atrás, eu publiquei uma série de posts sobre o ciclo de lançamentos da Debian, ao que se seguiu um exercício sobre como um pequeno script python poderia ser usado para acompanhar o número de bugs relacionados a ele. […]

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *