Sincronização de lançamentos

Release synchronization

Autor original: Jonathan Corbet

Publicado originalmente no: http://lwn.net/

Tradução: Roberto Bechtlufft

Para quem ainda não leu, vale a pena dar uma lida no post The Art of Release (em inglês) de Mark Shuttleworth. Ele começa autocongratulando o lançamento do Ubuntu 8.04, dizendo:

Essa afirmação é discutível, mas é verdade que o Ubuntu colocou em circulação uma versão feita para oferecer anos de suporte, e que o fez na data prometida. Claro que isso é apenas parte do trabalho; agora é preciso cumprir a pequena promessa de oferecer suporte à distribuição até 2011. A princípio temos bons sinais: o suporte ao Ubuntu tem sido sólido, e não parece que a distro vá sair de cena tão cedo.

Você deve estar se perguntando se o lançamento sem atrasos do 8.04 é digno de nota. Nossa comunidade fica cada vez mais mal-acostumada; um número cada vez maior de projetos e distribuições são lançados regularmente dentro de um cronograma razoavelmente previsível. Mesmo as novas versões do kernel, que antes atrasavam um ano ou mais, já podem ser previstas com uma margem de poucas semanas. Agora que os lançamentos de softwares livres são mais previsíveis e confiáveis do que, digamos, horários de vôos, porque o lançamento do Ubuntu 8.04 é digno de nota?

A resposta é o comprometimento com o suporte a longo prazo. Teoricamente, uma distribuição com um ciclo de vida tão longo deve ter um cuidado especial em seu preparo. Dá-se um tempo para que componentes importantes tornem-se estáveis para que a distribuição seja mais confiável logo em seu lançamento. Deve-se pensar na seleção de pacotes, com ênfase no suporte a longo termo. Todo o processo exige mais trabalho e um nível mais alto de comprometimento quanto ao bom funcionamento de todas as peças do sistema.

Com o tempo, ficará claro até que ponto o Ubuntu levou todo esse trabalho. O software selecionado para este lançamento certamente não tem tanto tempo de estrada quanto o das versões corporativas do Red Hat e do SUSE. Mas ser mais “antigo” não quer dizer ser “melhor” ou “mais estável,” e vamos tirar a prova vendo como a distribuição se mantém nos próximos três anos.

Enquanto isso, Shuttleworth já afirmou que a próxima versão de suporte a longo prazo será lançada em abril de 2010. Ele afirma que o sucesso do 8.04 permite assumir esse compromisso com quase dois anos de antecedência. Há, no entanto, a possibilidade das coisas mudarem:

A idéia não é nova, mas Shuttleworth para gostar bastante dela. Não há dúvidas de que haveria vantagens em alinhar os lançamentos. Os desenvolvedores do kernel, que sempre fazem um trabalho especial nas versões que serão usadas em grandes distribuições corporativas, poderiam se focar ainda mais em uma versão estável que seria amplamente adotada. Projetos de níveis mais altos também fariam o mesmo. Talvez os distribuidores também pudessem dar um jeito de colaborar na manutenção de longo prazo desses componentes, ao invés de duplicarem os esforços em backports de patches para código antigo. Talvez pudessem até se unir para uma grande festa de lançamento, economizando ainda mais dinheiro.

Ou talvez tudo isso seja uma idéia legal que não conseguirá sobreviver no mundo real. Os lançamentos de distribuições corporativas costumam ser muito propagandeados. O Ubuntu pode ficar muito feliz em compartilhar os holofotes com outras distribuições grandes, mas essa disposição pode não ser recíproca. É difícil imaginar a Red Hat ou a Novell lançando suas grandes distribuições corporativas como apenas mais um lançamento dentro de um mesmo mês.

Também é difícil imaginar o Ubuntu fazendo um acordo com distribuidores corporativos especificando datas de lançamento e as versões de seus componentes principais. O 8.04 saiu com kernel 2.6.24, que na época tinha quase três meses de idade. O Red Hat Enterprise Linux 5 foi lançado no meio de março de 2007, quando o kernel vigente era o 2.6.20, mas a Red Hat preferiu o kernel 2.6.18, que já tinha quase seis meses. Alinhar os cronogramas requer mais do que escolher a data; também requer a adoção de períodos de estabilização parecidos. É claro que o Ubuntu não gostaria de usar versões tão distantes das atuais em nome do alinhamento.

E francamente, é difícil de imaginar o Debian assumindo o compromisso de lançar uma versão no mês combinado.

Por isso fica difícil emplacar um alinhamento de cronogramas das distribuições corporativas. Talvez a melhor abordagem seja tentar afastar as distribuições do modelo de suporte “freeze and backport”, no qual o distribuidor se fixa em uma versão do software e, ao invés de atualizá-lo para novas versões, porta (ou seja, adapta) novidades de versões mais recentes para essa versão “congelada”. É um modelo caro de manter, traz seus próprios riscos e nem sempre se enquadra nas necessidades dos clientes corporativos. Se os distribuidores corporativos acompanhassem as versões mais recentes do software ao invés de fazer backport de partes delas para versões antigas, um alinhamento dos lançamentos pode vir naturalmente.

Créditos a Jonathan Corbet – http://lwn.net/

Tradução por Roberto Bechtlufft <robertobech at gmail.com>