Qual é o público do Fedora?

Se você tem frequentado a lista de discussão do Fedora recentemente, deve ter reparado que as coisas andam meio agitadas. As discussões chegaram a um ponto em que os moderadores tiveram que intervir fechando tópicos, e muitos participantes devem ter cancelado sua inscrição em prol da relativa calmaria e polidez de listas como a linux-kernel. É fácil classificar essa situação como mais uma guerra de flames no Fedora, mas a discussão envolve questões bastante sérias desta vez. Resumindo, parece que o Projeto Fedora ainda não sabe ao certo quem são seus usuários, ou como dar a esses usuários o que eles querem.

O Fedora tem um ciclo de lançamentos pequeno, com duas versões novas por ano. Com o suporte de apenas um ano, os usuários do Fedora precisam atualizar o sistema a cada doze meses, do contrário ficarão sem atualizações de segurança. Presume-se que os usuários do Fedora sejam pessoas com um interesse relativamente grande em ter o software mais recente em seus sistemas, e que não sejam avessos a atualizar esse software com uma frequência no mínimo moderada. Só que tudo tem limite.

Em outubro, os usuários do Fedora 11 tiveram uma surpresa desagradável quando uma atualização de rotina incluiu uma nova versão do Thunderbird, com comportamento sensivelmente diferente. Em janeiro veio outra atualização do Thunderbird, que criou mais problemas para vários usuários. Em março, alguns usuários do KDE também foram surpreendindos por uma “atualização estável” que migrou o KDE para a versão 4.4.0, causando uma certa quebradeira no sistema de alguns usuários. Todos esses casos (e alguns outros) geraram tópicos com bate-boca na lista do Fedora.

É verdade que o Fedora não economiza nas atualizações: uma olhadinha rápida na caixa de email do LWN lista 600 atualizações de pacotes para o Fedora 11, e isso tudo só no mês passado. Segundo o cronograma, esta versão do Fedora deve chegar ao fim da linha em poucos meses. Muitas dessas atualizações envolvem alterações expressivas, enquanto outras foram consideradas “inúteis”. Inúteis ou não, essas atualizações todas compõem uma agitação e tanto para uma distribuição que já passou da metade de seu curto período de vida. É difícil evitar a quebradeira com as mudanças vindo nessa velocidade toda.

No meio dessa discussão, os interessados em elaborar soluções construtivas se preocupavam com dois pontos: (1) quais tipos de atualizações estáveis são apropriadas a uma versão do Fedora e (2) como minimizar a quantidade de regressões e outros problemas causados pelas atualizações.

Quanto ao primeiro problema, parece que alguns mantenedores do Fedora acreditam (provavelmente com bons motivos) que seus usuários querem “atualizações aventureiras”, e por isso eles acham que faz sentido incluir versões novas dos programas nas atualizações da distribuição. Outros descrevem a visão de um Fedora “rolling update”, que seria uma distribuição que vai seguindo naturalmente as atualizações dos desenvolvedores de cada software. Alguns se perguntam por que o Fedora perde tempo lançando versões novas se o que importa para a distro é estar sempre fazendo essa atualização natural dos programas; segundo eles, os usuários que quiserem aventuras podem encontrá-la no Rawhide.

Foram feitas várias sugestões na página wiki de propostas de ciclo de vida das versões; outras foram postadas na lista de discussão. Essas sugestões variam de versões praticamente “congeladas” a ideias que fazem com que as novas versões se pareçam com uma versão um pouco menos apressada do Rawhide. Essa decisão é muito importante para o Fedora, e é preciso encará-la. Do contrário, o Fedora vai continuar tendo mantenedores agindo cada qual à sua maneira. Dada essa necessidade, é uma pena que o projeto não pareça ser capaz de discutir a questão em sua própria lista; no momento, parece ser impossível que se chegue a algum consenso.

O segundo problema contorna a questão de quais atualizações devem ser feitas, e se preocupa apenas com a qualidade dessas atualizações. A discussão é parcialmente motivada pelo fato de que o sistema disponível no Fedora para a avaliação das atualizações propostas, o Bodhi, muitas vezes é ludibriado por atualizações que seguem direto para os usuários. O fato é que as fases de teste e votação que supostamente deveriam se dar no Bodhi não vêm ocorrendo na maioria das vezes, e a qualidade da distribuição sofre como resultado disso. Por esse motivo, alguns desenvolvedores do Fedora estão buscando maneiras de incrementar o sistema.

Matthew Garrett postou uma proposta de uma nova política, que impossibilitaria os desenvolvedores de lançarem as atualizações de pacotes diretamente no fluxo de atualizações. Em vez disso, as atualizações teriam que permanecer no sistema Bodhi até receberem um valor mínimo de carma igual a 3; a única exceção seria para atualizações de segurança. Desabilitando a passagem direta dessas atualizações, a nova política garantiria que todos os pacotes no fluxo de atualizações já tivessem sido testados por alguns usuários, e que esses usuários estariam satisfeitos com os resultados.

Obviamente, a proposta não foi aceita por todos. Alguns desenvolvedores não apreciam a imposição de mais burocracia em seu fluxo de trabalho. A resposta de Karel Zak é muito esclarecedora nesse sentido:

É bom notar que, na verdade, o kernel acumulou um bom número de regras nos últimos dez anos, muitas vezes em resposta a debates que lembram muito esse que está ocorrendo agora na comunidade do Fedora. O período de tempo para o lançamento de versões estáveis, os requisitos para aprovação, a política contra regressões e afins são todos focados principalmente na melhoria da qualidade de cada lançamento. O kernel também tem camadas de desenvolvedores que contam com algo semelhante a um poder de veto sobre alterações potencialmente problemáticas, uma forma de criação dinâmica de regras que falta ao Fedora.

Ok, então pode ser que as regras façam sentido; só que isso não quer dizer que alguma proposta específica também faça. Muitos desenvolvedores acham que pouquíssimos usuários testariam os pacotes no Bodhi, e que uma enorme quantidade de atualizações ficaria mofando por lá indefinidamente. Como Tom Callaway observou, os obstáculos para a obtenção desses pontos de carma são expressivos. Uma alternativa foi sugerida: após 14 dias sem carma negativo, um pacote poderia seguir para o fluxo de atualizações. Outras propostas incluem a exigência de testes de regressão ou requisitos separados (mais rigorosos) para pacotes “críticos”; consulte esta página para ver o conteúdo de todas essas propostas.

Uma reunião bastante belicosa do FESCO foi realizada sobre o assunto no dia 9 de março. Aparentemente, a conclusão foi a de pensar mais a fundo sobre a proposta de Bill Nottingham, que envolve testes de regressão e a exigência de carma positivo para todos os pacotes críticos e componentes importantes; os outros poderiam seguir adiante após uma semana no repositório updates-testing. Parece que em breve haverá outra reunião. Se alguma solução concreta vai sair daí nós ainda não sabemos.

A “solução concreta” provavelmente é mais importante do que a política específica a ser adotada no momento. Muitos projetos grandes e bem-sucedidos passam ocasionalmente por períodos em que tentam determinar quais são seus objetivos e qual a melhor maneira de alcançá-los. Se conduzidas corretamente, essas discussões podem fazer com que o projeto tenha um foco maior e alcance mais sucesso, mesmo que as coisas fiquem quentes nesse meio tempo. Só que para que haja um bom resultado, é preciso encontrar uma maneira de pôr um fim à discussão com uma conclusão clara. As instituições que governam o Fedora devem ser capazes de fazer isso; até que elas ajam, o Fedora corre o risco de sair na foto como uma organização de bate-bocas que não tem uma ideia clara do que está tentando fazer.