O Fedora e o suporte a longo prazo

A notícia de que a Wikipedia estava migrando do Red Hat e do Fedora para o Ubuntu mexeu com a turma do Fedora. O período relativamente curto de 13 meses de suporte do Fedora foi apontado como o maior culpado em uma discussão gigantesca na lista fedora-devel. Algumas pessoas gostariam que o Fedora oferecesse um suporte maior para que pudesse ser usado em ambientes de produção, mas isso indica uma falta de entendimento daquilo que o Fedora se propõe a fazer.

A idéia de suportar o Fedora além do período padrão de “dois lançamentos e mais um mês”, que costuma bater em uns 13 meses, não é nova. Essa era a idéia do projeto Fedora Legacy. Infelizmente, o Fedora Legacy encerrou operações no final de 2006, em grande parte devido à falta de interessados na manutenção dos pacotes. É por isso que os pedidos por uma versão LTS (long term support, ou suporte a longo prazo) do Fedora são recebidos com bastante ceticismo.

Um desses pedidos veio em resposta às notícias sobre a Wikipedia. Patrice Dumas descreveu a necessidade:

O Fedora não é voltado ao uso em ambientes de produção, nem àqueles que não podem reinstalar todo ano. Seu objetivo é totalmente diferente, como resumiu Jon Stanley:

Muitos acreditam que aqueles que querem um “Fedora LTS” estariam melhor servidos com o Red Hat Enterprise Linux (RHEL) ou, se não estiverem dispostos a pagar por uma distribuição com suporte, com um derivado do RHEL como o CentOS ou o Scientific Linux. O problema é que eles não contam com a diversidade de pacotes do Fedora. Uma versão estável também congelaria alguns pacotes importantes em uma versão específica, oferecendo apenas backports de correções de segurança, o que definitivamente não é o procedimento adotado pelo Fedora no período de suporte. Dumas quer um um meio termo:

O projeto Extra Packages for Enterprise Linux (EPEL, ou Pacotes Extras para o Enterprise Linux) pretende preencher essa lacuna, mantendo pacotes adicionais, além dos mantidos pela Red Hat, para as distribuições compatíveis com o RHEL. Mas esses pacotes também vão acabar parando em uma versão que, com o tempo, se tornará obsoleta, ao menos para aqueles que queiram seguir os projetos upstream mais de perto. E claro, mesmo com o EPEL, não há tantos pacotes disponíveis para as distribuições corporativas como há para o Fedora.

Parece a tensão clássica entre a tecnologia de ponta e a estabilidade, como descrita por Stanley. Embora ainda não esteja claro como resolver o problema, há gente clamando pela ressurreição do Fedora Legacy. Poucos se opõem à idéia de um suporte contínuo ao Fedora (se for possível encontrar gente suficiente para cuidar disso), mas os detalhes da implementação fazem a situação se arrastar. Há um pouco do problema “o ovo ou a galinha”: é difícil atrair mantenedores de pacotes sem ter um projeto estabelecido, mas também fica difícil convencer o Fedora Engineering Steering Committee (FESCo, ou Comitê Diretor de Engenharia do Fedora) de que o projeto é digno de atenção sem apresentar mantenedores.

Um dos pontos polêmicos é a disponibilidade de infra-estrutura, em especial os servidores e a banda, dos quais qualquer projeto dessa natureza precisa dispor. Parece que o conselho do Fedora não está muito empolgado com a idéia de liberar o uso de infra-estrutura para esse tipo de projeto. Em resposta a um sujeito que disse que a aprovação do conselho não seria necessária, Dumas discordou:

Também há a questão dos tipos de garantia que o projeto ofereceria quanto ao tempo de suporte a versões antigas. Dumas e outros parecem favoráveis a não assumir nenhum compromisso, de modo que os mantenedores suportariam os pacotes pelo tempo que quisessem. Embora a idéia seja interessante (pois certamente reduziria a quantidade de mantenedores necessários) não está claro se resultaria em um serviço realmente útil. A idéia de que ter algumas correções de segurança é melhor do que não ter nenhuma pode ser atraente, mas David Woodhouse diz que é preciso ter cuidado com ela:

Se vamos usar o nome do Fedora, é preciso haver garantias de que ao menos as falhas de segurança de maior prioridade serão corrigidas.

Como o projeto Fedora Legacy original explicou, eles passavam essa impressão, prometendo um suporte que nem sempre eram capazes de fornecer. Por muitos anos, atualizações de problemas de segurança graves foram lançadas tarde, isso quando eram lançadas. Qualquer tentativa nova nesse sentido teria que deixar bem claro o que oferece e como pretende fazer isso. Um projeto que ofereça pouca (ou nenhuma) garantia não seria muito útil, mas fazer promessas que não podem ser cumpridas é bem pior.

Embora haja usuários do Fedora interessados em manter seus sistemas operacionais por mais de um ano, ainda não é certo que haja uma quantidade suficiente dessas pessoas – e uma quantidade suficiente de mantenedores – para fazer do projeto um sucesso. É importante que se chegue a um consenso quanto aos objetivos do projeto, bem como quanto às promessas que ele faria aos que aderissem. É difícil imaginar que o Fedora vá alocar recursos para o projeto sem que isso seja esclarecido. Como disse Shmuel Siegel:

Pelo menos no momento, a ressurreição do projeto Fedora Legacy não parece estar nos planos, e o problema permanece sem solução. Pode ser que a adição de uma quantidade suficiente de pacotes ao EPEL transforme o CentOS num “Fedora LTS”. Vale destacar que embora a preocupação de que usuários LTS estejam migrando para o Ubuntu possa ser verdadeira, o Ubuntu LTS não oferece uma solução ao problema das versões de pacotes que vão se tornando obsoletas lentamente. Pacotes recentes e pacotes estáveis estão em lados opostos, e resolver esse problema é um bocado de trabalho para qualquer distribuição comunitária.