Por Ednei Pacheco em 25 de fevereiro de 2011 às 12h18
No mundo do Software Livre, as novidades e inovações chegam frequentemente. Enquanto que os softwares proprietários tradicionais levam meses e anos para serem atualizados, os softwares livres recebem melhorias incrementais em tempos mais curtos. Por isto, encontramos grandes mudanças entre as versões do Microsoft Office, mas poucas diferenças perceptíveis nos softwares equivalentes, como OpenOffice.org. Empolgante, não? Nem tanto. Infelizmente, tais práticas - apesar de garantirem constantes melhorias - trazem alguns inconvenientes bem indesejáveis...
Preview do Firefox 4, disponível em versão beta.
Uma distribuição GNU/Linux clássica - composta do kernel Linux, das ferramentas & bibliotecas do Projeto GNU, do servidor gráfico X.org e do ambiente gráfico (geralmente o GNOME e o KDE), além de uma variedade interessante de aplicativos - requer que toda estas peças funcionem harmoniosamente em conjunto. Para isto, uma série de testes são feitos para garantir este objetivo, os quais se iniciam desde a definição dos parâmetros de compilação à correção dos erros encontrados. Vejam bem: não estamos falando de 3 ou 4 aplicativos que teimam em funcionar bem só porque uma biblioteca mudou de versão, mas de um repositório inteiro! Para se ter uma ideia de tão complexa que é esta manutenção, saibam que mesmo as mais enxutas distribuições possuem de centenas a milhares de pacotes.
Debian, a distribuição dotada da mais vasta coleção de pacotes...
Para simplificar a manutenção dos repositório, os desenvolvedores geralmente criam procedimentos técnicos (variados) que, de uma maneira ou de outra, "congelam" determinadas versões de pacotes - sejam aplicativos, bibliotecas, ferramentas e outras categorias de softwares - com a versão atual da distribuição, para evitar a quebra de pendências ao substituí-los por novas versões. Por exemplo, a versão atual do Ubuntu ainda mantém o Xfce 4.6, mesmo embora a versão 4.8 tenha sido recentemente lançada. Entretanto, as correções de bugs e de segurança das versões constantes nos repositórios continuam sendo aplicadas, já que elas dificilmente afetam as pendências de pacotes. Embora tais procedimentos facilitem bastante a manutenção dos repositórios de pacotes, eles ainda trazem alguns inconvenientes...
Ubuntu: a cada 6 meses, um novo "parto"...
Em geral, as distribuições são obrigadas a manterem os seus lançamentos em prazos curtos, que geralmente variam de 4 a 9 meses (sendo um semestre a média geral). Além dos usuários terem a (óbvia) inconveniência de ter que ficar fazendo upgrades do sistema constantemente, tal prática afeta bastante a certificação e o suporte de muitas aplicações: no caso das proprietárias, estas geralmente são compiladas e distribuídas para funcionarem sob determinadas versões de distribuição, por serem baseadas na versão X do kernel Linux, na versão Y das bibliotecas do sistema e na versão Z do ambiente gráfico, e assim por diante. Se os mesmos pacotes forem instalados em uma nova versão da distribuição, que certamente terá atualizado muitos pacotes da infraestrutura, muito provavelmente teremos as indesejadas quebras de pendências e de compatibilidades.
Se optarmos por adotar lançamentos à médio e longo prazo, mas mantendo os procedimentos de "congelamento" das versões de pacotes, teremos o inconveniente de ter uma distribuição que rapidamente caminha para a obsolência. Em termos de Software Livre, 2 ou 3 anos são um tempo considerado longo demais para que um sistema fique "congelado", sem receber novos recursos e funcionalidades. Inclusive, continuarão os problemas ao realizarmos o upgrade para as versões mais novas das distros em uso e seus respectivos pacotes, pois muito provavelmente teríamos que atualizar pacotes que estão à 2 ou 3 versões atrás da versão atual, o que pode trazer mais problemas relacionados à quebras de pendências e outras incompatibilidades, tal como já conhecemos.
Por fim, temos o famoso esquema "rolling release", onde os repositórios das distribuições são atualizados continuamente, tendo os seus pacotes testados e adicionados, conforme são lançados. Este método tem como objetivo, evitar os problemas e inconvenientes causados pelo lançamentos de curto, médio e longo prazo das distribuições, substituindo-os pela manutenção de snapshots: estes, são apenas cópias feitas do estado do repositório, no exato momento em que são utilizados para a criação de imagens de instalação da distribuição. Por outro lado, o repositório de pacotes destas distribuições se tornam uma espécia de laboratório de testes contínuo, onde os pacotes recém-acrescentados sem sempre são devidamente testados, tal como acontecem com as distribuições clássicas que optam pelo método de "congelamento". Assim, os aplicativos recém-atualizados podem comprometer com mais facilidade, todo o funcionamento do sistema.
Antes de tudo, devemos levar em consideração que a manutenção de um vasto repositório - mesmo com todas as suas dificuldades, inconvenientes e limitações - por si só, já é um feito de grande dimensões. Porém, também deveremos reconhecer que grande parte destes problemas, são causados devido à sincronização em relação ao lançamentos dos softwares, onde os desenvolvedores definem os seus calendários conforme os interesses. Mas, se houvesse uma oportunidade de montar uma espécie de super-calendário, bem definido e padronizado, com o objetivo de sincronizar todo o processo de desenvolvimento, teste, preparo e lançamento de distribuições, que vantagens poderíamos ter? Eis, a ideia central deste artigo: a criação de um novo calendário anual de novidades e inovações para o Software Livre!
Pessoalmente, acredito que a criação um novo calendário de lançamentos, com o prazo definido de 1 ano e com as datas de lançamentos pré-determinadas, seria o ideal para as distribuições. Tal processo, bem ajustado e minuciosamente definido, poderia resolver uma série de problemas iniciais. Para começar, eliminaríamos o pouco intuitivo sistema de versões baseados em números (tal como o modelo utilizado pelo Ubuntu), adotando o ano de lançamento para diferenciar uma distribuição antiga da nova. Acaso vocês sabem quando foi lançado o Fedora 12? Quanto ao Ubuntu, saberiam contabilizar quantas versões foram lançadas desde então?
A seguir, teremos que fixar das datas de lançamentos e outros eventos. Neste caso, o desenvolvimento das versões alphas e betas seriam concentrados nos primeiros meses à metade do ano, ao passo que a finalização das versões RC (Release Candidate), RTM (Release to Manufacture) e estáveis ficariam concentradas em épocas determinadas, estas geralmente próximas ao final de ano. Enquanto isso, as versões estáveis já lançadas seriam mantidas continuamente, como uma espécie de sistema rolling release. Assim, teríamos um tempo muito maior para realizar os testes necessários e garantir a estabilidade geral do sistema! Porém, algumas mudanças no calendário de lançamento dos componentes essenciais deverão ser providenciadas...
Tal como está, o kernel Linux poderia manter um sistema contínuo de lançamentos a cada 3 ou 4 meses. Assim, as distribuições poderiam promover pequenos updates em sua infraestrutura, gerando imagens do tipo snapshot para aquela versão anual específica. Assim, um usuário que desejasse utilizar a distribuição corrente, mesmo que esta tenha sido lançada 10 meses depois, precisaria baixar apenas as atualizações feitas à partir do terceiro snapshot feito, baseado na mais recente versão do kernel Linux. O mesmo se dá para com o servidor gráfico X.org, que certamente deverá possuir algum sistema de sincronização do seu desenvolvimento com o kernel Linux: além do fato de novas GPUs, IGPs e drivers serem constantemente desenvolvidos, o KMS (Kernel Mode Setting) certamente deverá receber uma atenção especial. Já para as demais bibliotecas do sistema, elas ficariam livres para definirem um cronograma adequado de lançamento, desde que procurem estar atentas ao processo de desenvolvimento do kernel Linux.
Já os ambientes gráficos, as suas novas versões seriam lançadas anualmente; mas felizmente, não haveria a necessidade de modificar o sistema de numeração de versões que são adotados atualmente (p. ex. GNOME 3.0, KDE 4.6 e Xfce 4.8), embora a adoção do ano-base ainda fosse mais interessante de utilizar. Entretanto, estes deverão ser disponibilizados com pelo menos um mês de antecedência, para que as distribuições pudessem ter o tempo necessário para integrá-las ao sistema e o seu repositório. Na prática, não mudaria muito daquilo que vem sendo praticado atualmente: por exemplo, a distribuição Ubuntu sempre foi lançada um mês depois de estar disponível a última versão estável do GNOME.
Por fim, as aplicações poderiam manter o ciclo de desenvolvimento que vêm sendo feito desde então, porém com uma ressalva: o lançamento das novas versões deverá ser feito com no máximo um ano após a versão corrente (sendo mantido preferencialmente este prazo), para facilitar o trabalho dos empacotadores de softwares das distribuições. Inclusive, a popular suíte de escritório LibreOffice.org e no navegador WEB Firefox teriam papéis fundamentais neste novo calendário, ao disponibilizar as novas versões dentro de um cronograma pré-estabelecido. Assim, possibilitariam os desenvolvedores a integrarem melhor tais aplicações nos ambientes gráficos disponíveis (especialmente aquelas que utilizam outras bibliotecas gráficas que não sejam a GTK). Aqueles que já usaram o antigo OpenOffice.org no KDE, sabem perfeitamente do que estou falando...
Um esboço do calendário anual de desenvolvimento conforme proposto, ficaria definido mais ou menos assim, como mostra a tabela à seguir. Só para notificar, este seria apenas um mero esboço!
Data | Evento |
|---|---|
Janeiro | Manutenção dos pacotes e da distribuição recém-lançada (correções e updates típicos de produtos recém-lançados). Liberação das versões de teste e RC do kernel, X.org e libs. |
Fevereiro | Lançamento da última versão estável do kernel Linux, do servidor gráfico X.org e outras bibliotecas importantes. |
Março | 1o. snapshot da distro corrente (2011.1). Disponibilidade das versões alpha e/ou beta dos ambientes. |
Abril | Liberação das versões de teste e RC do kernel, X.org e libs. |
Maio | Lançamento da última versão estável do kernel Linux, do servidor gráfico X.org e outras bibliotecas importantes. |
Junho | 2o. snapshot da distro corrente (2011.2). Disponibilidade das versões alpha e/ou beta dos ambientes. |
Julho | Liberação das versões de teste e RC do kernel, X.org e libs. |
Agosto | Lançamento da última versão estável do kernel Linux, do servidor gráfico X.org e outras bibliotecas importantes. |
Setembro | 3o. snapshot da distro corrente (2011.3). Disponibilidade da versão release candidate dos ambientes. |
Outubro | Liberação das versões de teste e RC do kernel, X.org e libs. Lançamento final dos ambientes gráficos (KDE & GNOME). Lançamento da versão RC da distribuição (2012). |
Novembro | Lançamento da última versão estável do kernel Linux, do servidor gráfico X.org e outras bibliotecas importantes. Lançamento da versão RTM da distribuição (2012). |
Dezembro | Lançamento oficial da distribuição (2012). |
Quem ficaria responsável pela manutenção do calendário? Bem, uma instituição neutra - voltada exclusivamente para o desenvolvimento do Linux como a Linux Fundation -, certamente seria a candidata mais adequada, para definir e organizar este novo calendário. Inclusive, conhecendo o grandioso ecossistema chamado Software Livre, o modelo de calendário final certamente será algo bem mais complexo, do que está sendo proposto.
Por Ednei Pacheco
