quarta-feira, 25 de abril de 2007

Insanifying, Parte I

Segundo dia da competição. Os doze primeiros classificados do Qualifying foram divididos em quatro equipes, conforme a sua posição no ranking do dia anterior: 1-5-9, 2-6-10, 3-7-11 e 4-8-12. Assim, as equipes ficaram uniformemente balanceadas para os próximos dois dias de desafios.

A organização do evento contactou diferentes entidades relacionados ao mundo do Software Livre a fim de buscar auxílio para a definição dos problemas que seriam propostos durante as duas fases do Insanifying. Porém, apenas o projeto Debian topou em participar, através das presenças de Felipe Augusto van de Wiel e de Otávio Salvador.

O primeiro desafio nesse dia foi entender o que precisaria ser feito e como seria a avaliação. O Felipe e o Otávio começaram explicando que, diferente do Qualifying (quando havia um sistema de avaliação para verificar se os nossos programas geravam a saída esperada), o Insanifying teria uma avaliação mais subjetiva. Na prática, isso significaria que ao invés de apenas certo e errado, teríamos uma escala de 0 a 100 para avaliar as soluções apresentadas. Além disso, diversos critérios seriam levados em consideração:

  • legibilidade: o código segue as condutas de programação do projeto.
  • funcionalidade: verificação se a solução realmente faz o que tem de fazer.
  • desempenho: solução executa em menos tempo que as demais.
  • apresentação do grupo da solução: entrosamento do grupo, oratória e resposta de perguntas.

Em seguida, enquanto ainda estávamos agrupados em um círculo, quatro problemas foram apresentados. Além disso, nos foi dito que, ao concluir estes problemas iniciais, poderíamos resolver qualquer um dos bugs marcados como release critical do Debian. Obviamente nenhuma das equipes conseguiu resolver todos os problemas no tempo disponível... :-/

O primeiro deles era o bug #417850: trata-se de uma falha que ocorre apenas no tty1, quando a tecla Caps Lock está ativa e algumas teclas específicas são pressionadas, fazendo com que sejam exibidos caracteres minúsculos, ao invés dos correspondentes maiúsculos esperados.

O segundo problema era o bug #411585, referente ao pacote cdebconf, responsável por armazenar as respostas informadas pelo usuário durante a instalação de pacotes no sistema. Por algum motivo, os valores armazenados não eram excluídos da base de respostas ao remover as questões, fazendo com que eu uma eventual nova instalação, o valor anterior seja utilizado e não o valor definido como padrão para aquela questão específica.

O terceiro problema era referente a um bug existente no próprio sistema de triagem de bugs do projeto Debian. A página que lista os bugs para um determinado pacote contém uma opção para listar aqueles que já foram arquivados. Entretanto, mesmo quando esta opção é ativada, apenas os bugs ativos são exibidos, fazendo com que não seja possível listar os que se encontram arquivados. Mais tarde ficamos sabendo que se tratava do bug #398017.

O quarto e último problema parecia o mais assustador. O pacote parted é usado no gerenciamento de partições de discos. A tarefa consistia em implementar o suporte ao redimensionamento de partições do tipo RAW. Posteriormente também descobrimos que se tratava de um bug já reportado, o #419473.

Após o anúncio dos problemas, as equipes tinham 3 computadores a sua disposição, todos rodando o Debian 4.0, codinome Etch, que havia sido lançado uma semana antes. Era permitido o uso de notebooks, bem como quaisquer outros dispositivos eletrônicos. Também era permitido que o competidor saísse da Arena, desde que os outros dois membros da equipe permanecessem no local.

A primeira coisa que a minha equipe fez foi instalar o Gaim (que agora chama-se Pidgin) e configurá-lo para usar as nossas contas do Gmail pelo protocolo Jabber. Com isso poderíamos trocar links e outras informações mais rapidamente entre nós.

Nesse ponto também tomamos outra decisão que influenciaria no nosso trabalho colaborativo. Iríamos utilizar o serviço de documentos e planilhas do Google. A grande vantagem é que os três membros da equipe poderiam editar a documentação gerada simultaneamente, sem causar conflitos de edição. Isso também evitaria que algum crash em um dos computadores ocasionasse perda nos nossos dados.

Por incrível que pareça, nós ainda não temos a menor idéia de como foi o nosso desempenho nessa fase. A única coisa que temos consciência é que trabalhamos excessivamente no primeiro problema, cerca de 3/4 do total. O tempo passou voando e quando nos demos conta, partimos para tentar resolver o segundo e o terceiro problemas, para garantir uma pontuação mais equilibrada. Provavelmente obtemos algo próximo a pontuação máxima no segundo problema, pois identificamos o que estava gerando o comportamento indesejado e fornecemos um patch para corrigí-lo, inclusive com um teste unitário.

No terceiro, também encontramos onde possivelmente o erro era gerado, mas em função dos scripts serem escritos em Perl, aliado ao parco conhecimento da nossa equipe nessa linguagem e a complexidade para reproduzir um ambiente onde poderíamos testar o nosso progresso, acabamos não conseguindo avançar o suficiente para podermos considerar o problema como resolvido. Não chegamos a estudar o último problema, pois numa análise superficial nós o consideramos muito complexo. Mais tarde é que fomos descobrir que ele, na verdade, era rasoavelmente simples, pois já havia um patch existente e bastava formatar o disco de uma das máquinas para verificar o seu funcionamento em uma partição RAW.

Segundo a organização, a idéia inicial era que o Insanifying durasse 24 horas ininterruptas. Porém, em função de restrições impostas pela administração do local do evento, esse plano foi cancelado. Mesmo assim, e em função dos meus apelos no dia atual e anterior em relação à comida, foi providenciado pizza e refrigerante para garantir a alimentação dos competidores... :-)

No término do dia, enquanto eu ainda estava saboreando a pizza, fui entrevistado pelo pessoal da imprensa, que estava muito interessado em saber o que havia acontecido durante a primeira etapa do Insanifying.

0 comentários: