Produção: Raphaël Hertzog
Tradução: Roberto Bechtlufft
O Debian Testing é a distro usada pelos desenvolvedores para preparar a próxima versão estável do Debian. Esse continua sendo o propósito principal do Testing, mas muitos usuários acabaram adotando essa versão, já que ela oferece um bom equilíbrio entre estabilidade e novidades. Só que há alguns problemas em se usar o Debian Testing... e foi para reduzir ou eliminar esses problemas que o projeto CUT (sigla em inglês para "Testing de utilização constante") foi criado.
Sobre as versões Testing e Unstable do Debian
O Debian Unstable é a distribuição na qual os desenvolvedores incluem as novas versões de seus pacotes. O problema é que muitas vezes alguns pacotes não podem ser instalados a partir do Unstable, por causa de mudanças em outros pacotes ou transições ainda não concluídas envolvendo bibliotecas.
O Debian Testing, por sua vez, é gerenciado por uma ferramenta que garante a consistência de toda a distribuição, buscando atualizações no Unstable apenas se o pacote tiver sido devidamente testado (geralmente por dez dias), não tiver bugs críticos, estiver disponível para todas as arquiteturas suportadas e não quebrar outros pacotes presentes na distro. A equipe de lançamento controla a ferramenta e oferece "dicas" para ajudá-la a encontrar um conjunto de pacotes que possa fluir do Unstable para o Testing.
Essas regras também garantem que pacotes que entrem no Testing estejam razoavelmente livres de bugs "matadores" (como aqueles que impedem o sistema de iniciar, ou o X de abrir). Isso torna o Testing muito atraente para usuários interessados em obter versões novas do seu software regularmente sem ter que lidar com os maiores problemas associados a essa prática. Mesmo assim, vários desenvolvedores do Debian não aconselham que as pessoas usem o Testing. Por quê?
Os problemas do Testing
Software que some do mapa: a equipe de lançamento usa o Testing para preparar a próxima versão estável, e de tempos em tempos remove pacotes dele. Isso acontece para que outros pacotes possam migrar do Unstable para o Testing, ou quando um pacote tem bugs que já vêm de longa data e ainda não foram resolvidos. A equipe de lançamento também remove pacotes a pedido dos mantenedores, quando estes julgam que não será possível dar suporte (em termos de segurança) à versão atual por dois anos ou mais. A equipe de segurança também faz esse tipo de pedido regularmente.
Um grande atraso nas correções importantes e atualizações de segurança: mesmo com os dez dias de atraso no Unstable, sempre pintam bugs chatos (e bugs de segurança não são exceção) que só são descobertos depois que o pacote já migrou para o Testing. O mantenedor pode subir um pacote corrigido rapidamente para o Unstable, e até sinalizar sua urgência para que o pacote migre antes da hora, mas se os pacotes forem pegos no meio de uma grande transição na distro, ele só vai migrar para o Testing depois que a transição for concluída. Às vezes, passam-se semanas até que isso aconteça.
O atraso pode ser evitado com uploads diretos para o Testing (por meio do testing-proposed-updates), mas esse mecanismo quase nunca é usado, a não ser durante um freeze, quando correções de bug imperam.
O Testing nem sempre pode ser instalado: como o Testing evolui diariamente, às vezes as atualizações "quebram" as imagens de instalação mais recentes (especialmente as imagens para netbooks, que baixam tudo via internet). Os pacotes do instalador do Debian (d-i) geralmente são corrigidos rapidamente, mas eles não seguem automaticamente para o Testing porque a nova combinação de pacotes do d-i pode ainda não ter sido validada. Colin Watson resumiu o problema:
Demora muito para levar novidades no código do instalador para o Testing, e os problemas ficam por lá sem solução por um tempão. [...] O problema com o desenvolvimento do d-i atualmente é mais a grande lentidão no lançamento de suas versões. [...] Hoje, temos que optar entre usar o Stable (muito defasado), o Testing (que seria ótimo, a não ser por eventuais quebradeiras e pela demora de uma semana para corrigir qualquer falha) ou o Unstable (que quebra o tempo todo).
A história do CUT
O CUT tem suas raízes em uma velha proposta de Joey Hess, que apresentou a ideia de que a versão estável não seria o único produto do Debian, e de que com um pouco de trabalho, o Testing também poderia ser uma escolha adequada para usuários finais. Como ninguém se dispôs a trabalhar nisso, não tivemos progressos perceptíveis nos últimos três anos.
Mas há pouco tempo, Joey levantou o assunto do CUT novamente lista de discussão debian-devel, e Stefano Zacchiroli (líder do projeto Debian) o desafiou a montar uma apresentação informal sobre o CUT na Debconf10. Ela acabou sendo a apresentação informal de maior público (vídeo aqui), o que mostra que há muita gente interessada no assunto. Foi aberto um wiki especialmente para o projeto, e foram criados um projeto no Alioth com uma lista de discussão.
As ideias do CUT
Dentre todas as ideias, duas abordagens principais foram discutidas. A primeira é a de criar snapshots do Testing regularmente em momentos em que ele esteja notoriamente funcionado bem. Esses snapshots receberiam o nome de "cuts". A segunda é a criação de uma distribuição Testing aprimorada, com foco nas necessidades dos usuários que querem uma distribuição funcional, com atualizações diárias. Seu nome seria "rolling".
Os snapshots do Testing
Há um consenso geral de que snapshots regulares do Testing são uma necessidade. Eles são a única maneira de garantir que a mídia de instalação gerada vá continuar funcionando até o próximo snapshot. Se os testes do snapshot não revelarem nenhum grande problema, ele vira o "cut" mais recente. Para facilitar as coisas, o codinome oficial seria baseado na data. Por exemplo, "cut-2010-09" seria um cut gerado em setembro de 2010.
A periodicidade ainda não foi decidida, mas o objetivo é agressivo: no mínimo um cut a cada seis meses, mas lançamentos mensais foram sugeridos. Para que se chegue a uma conclusão, muitos aspectos precisam ser levados em conta.
Um deles (talvez o mais importante) é o suporte à segurança. Como a equipe de segurança já está sobrecarregada de trabalho, é difícil jogar mais trabalho para ela e dizer que os cuts vão contar com o mesmo suporte das versões estáveis. Não ter suporte oficial em termos de segurança parece ruim, mas não é necessariamente problemático como pode parecer. O histórico do Testing em termos de segurança geralmente é melhor do que o do Stable (veja o tracker de segurança), já que as correções vão chegando naturalmente junto com as novas versões de software de terceiros. O Stable ainda recebe correções de segurança consideradas de grande importância antes do Testing, mas de modo geral há menos problemas de segurança no Testing do que no Stable.
Como é só questão de tempo para que versões corrigidas venham naturalmente de seus projetos de origem, lançamentos mais frequentes de cuts implicam em usuários obtendo correções de segurança mais cedo. Mas Stefan Fritsch, que já esteve envolvido com a equipe de segurança do Debian Testing, também já vivenciou os problemas que todo mundo experimenta ao tentar contribuir com atualizações de segurança:
As atualizações no testing-security geralmente só são úteis por poucas semanas, até uma versão corrigida migrar do Unstable. No Stable, as atualizações circulam por alguns anos, motivando uma preparação mais demorada.
Logo, se é difícil formar uma equipe de segurança especializada, a provisão de atualizações de segurança terá que ficar por conta do mantenedor do pacote. Geralmente o mantenedor sobe rapidinho os pacotes corrigidos para o Unstable, mas não fiscaliza se os pacotes chegam ao Testing. E não dá para culpá-lo: o Testing foi criado para a preparação da próxima versão estável, e portanto não há pressa alguma em se transportar para ele as correções, exceto quando o lançamento da versão estável está perto.
O CUT pode ajudar nesse sentido, justamente por mudar a premissa: o Testing terá usuários próprios, e esses usuários merecem correções de segurança tanto quanto os usuários da versão estável.
Outro aspecto a ser considerado na periodicidade dos lançamentos é a quantidade de trabalho associada às versões oficiais: o teste de atualizações da versão anterior, a redação das notas de versão e a preparação das imagens de instalação. Deve ser difícil cuidar disso todos os meses. Nesse ritmo, também é impossível incluir uma nova versão do kernel em cada cut (as versões costumam sair a cada dois ou três meses), e o suporte a hardware novo que essas novas versões trazem vale a pena para muitos usuários.
Resumindo, snapshots periódicos resolvem o problema do Debian Testing nem sempre poder ser instalado, e podem mudar a percepção dos mantenedores em relação ao Testing para que tenham uma maior preocupação com as atualizações de segurança do Testing e dos cuts. Só que isso não resolve o problema dos pacotes que desaparecem. É preciso mais alguma coisa para resolver esse problema.
Outra distribuição de atualização infinita?
Lucas Nussbaum comentou que a ideia de snapshots periódicos do Debian não é nova:
Qual seria a diferença em relação a outras distribuições com ciclo de lançamento de seis meses, e mais especialmente em relação ao Ubuntu, que já é meio que um snapshot do Debian com extras?
Na visão de Lucas, o CUT seria interessante se fosse capaz de proporcionar a uma distribuição de atualização infinita, como o Debian Testing, um "fluxo constante de lançamentos dos projetos associados". Para ele, isso seria "algo único no mundo do software livre". Os snapshots poderiam ser usados como ponto de partida para a instalação inicial, mas o sistema instalado apontaria para a distribuição de atualização infinita e os usuários atualizariam sempre que quisessem. Nessa situação, o suporte à segurança dos snapshots não seria tão importante, porque o importante seria a situação da distribuição de atualização infinita.
Se o Testing fosse usado como distribuição de atualização infinita, o problema dos pacotes desaparecerem continuaria sem solução, mas poderia ser resolvido com uma nova distribuição de atualização infinita que funcionaria como o Debian Testing, mas com regras adaptadas. Os cuts seriam, então, snapshots dessa nova distribuição, e não do Testing. A proposta básica é a de fazer uma cópia do Testing e tornar a incluir os pacotes que foram removidos por não serem apropriados para um lançamento a longo prazo, já que eles seriam perfeitamente aceitáveis para uma versão de atualização constante (o exemplo mais recente é o Chromium).
Daí, podemos ir além: no estágio de freeze (quando novos recursos param de ser adicionados), o Testing não é mais atualizado automaticamente, tornando-se impróprio para alimentar a distribuição de atualização infinita. Nesse caso, a distribuição seria reconfigurada para obter atualizações do Unstable, porém usando as mesmas regras do Testing.
Dada a periodicidade dos lançamentos, é provável que apenas um pequeno subconjunto de arquiteturas seja suportado oficialmente. Isso não chega a ser problema, porque geralmente os usuários que querem tecnologia de ponta são os de desktops i386/amd64 (talvez armel em tablets e outros produtos móveis semelhantes). Essa iniciativa, caso concretizada, abre as portas para ainda mais possibilidades: se uma distribuição de atualização infinita for configurada exatamente como o Testing, porém apenas com um subconjunto de arquiteturas, é provável que alguns pacotes migrem para a versão de atualização infinita antes de migrarem para o Testing, onde arquiteturas de menor destaque geram um atraso por problemas na compilação automática (ou têm problemas com o conjunto de ferramentas).
Pode ser positivo para os usuários estar à frente do Testing, mas isso também é problemático em diversos níveis. Para começar, o gerenciamento da versão de atualização infinita fica muito mais complicado, pois o trabalho de gerenciamento da transição realizado pela equipe de lançamento não pode ser reutilizado do jeito que está. Além disso, pode surgir uma competição entre as duas distribuições, dificultando o lançamento de uma versão estável, por exemplo, se os mantenedores pararem de se preocupar com a migração para o Testing quando a migração para a distribuição de atualização infinita for concluída.
Essa distribuição certamente é uma boa ideia, mas as regras que a governarem precisam ser criadas para evitar conflitos no processo de lançamento da versão estável. Concluindo, a mera existência da distribuição de atualização infinita finalmente resolveria o problema de marketing que aflige o Testing: seu nome não indicaria um software que não está pronto para ser usado diariamente.
Conclusão
Ninguém sabe ainda se o CUT vai mesmo sair, mas ele começou bem: Joerg Jaspert, da equipe ftpmaster, disse que o novo servidor pode abrigar outra distribuição, e já existe gente trabalhando na proposta. Talvez as coisas comecem a acontecer rapidamente. Já existe até um plano de implementação para a questão dos snapshots do projeto. A distribuição de atualização infinita pode ser lançada mais tarde, quando estiver pronta. As duas abordagens podem complementar uma à outra e trazer algo útil para vários tipos de usuários.
A proposta global é atraente: ela lidaria com o problema da defasagem do Debian Stable por meio da criação de versões intermediárias. Quem precisar de algo mais recente por causa do suporte a hardware pode começar instalando um cut e seguindo as versões lançadas dali em diante até a próxima versão estável. E os usuários que quiserem sempre contar com a última versão de todo software podem usar a distro de atualização infinita depois de instalar um cut.
Do ponto de vista dos usuários, há similaridades com os lançamentos normais e de suporte estendido do Ubuntu. Mas do ponto de vista do desenvolvimento, o processo a ser seguido seria bem diferente, e as limitações impostas para se manter uma distribuição utilizável seriam pesadas. Com o CUT, qualquer mudança em larga escala precisa ser desenvolvida de forma que possa acontecer progressivamente, de forma transparente para seus usuários.
ORIGEM CRIACIONAL: Hardware
Vivamos a LIBERADE com total DIGNIDADE!
pela partilha!
