Nasce um Pingüim

Quando você pega a caixinha com a nova versão de sua distro predileta, provavelmente não faz a mínima idéia do trabalho que dá para criá-la. São meses de empacotamento, testes, correção de bugs, centenas de CD's com betas que vão pro lixo... Conheça um pouco mais do processo de desenvolvimento de uma distro, e descubra que a participação da comunidade é muito mais importante do que você imaginava

Assim como a produção de um espetáculo, o ciclo de desenvolvimento de uma distribuição envolve projetos, decisões técnicas e infra-estrutura que passam despercebidas aos olhos do usuário final - e é esse seu objetivo: que um produto integrado, funcional e bem-acabado permita que o usuário concentre-se em suas aplicações.

Os meses que separam um lançamento estável do seguinte, entretanto, são de intensa movimentação nos bastidores. Etapas de projeto, implementação, testes, correção de problemas, revisões, documentação e homologação de soluções fazem parte do dia-a-dia do desenvolvedor. Nesse intervalo, o conjunto de pacotes que compõe uma distribuição de desenvolvimento é constantemente atualizado e testado, tendo seu desempenho monitorado através de um sistema de controle de defeitos (ou “bug tracker”).

O CD desta edição traz uma amostra de uma distribuição do Conectiva Linux em desenvolvimento, incluindo subsistemas que deverão fazer parte da próxima distribuição estável, tais como KDE 3, Kerberos, sistema de arquivos ext3 e suporte a LVM na instalação. Dois pontos importantes devem ser frisados com respeito a essa distribuição: o primeiro é o caráter experimental de seus pacotes, que restringe seu uso apenas a desenvolvedores (nunca, em hipótese alguma, utilize distribuições experimentais em sistemas de produção, ou seja, servidores e máquinas que precisam estar funcionando sem problemas); e o segundo é o ritmo acelerado de correção de problemas encontrados em pacotes que pode fazer com que muitos dos defeitos existentes na data de fechamento desta edição da RdL já tenham sido corrigidos (antes de relatar um defeito, verifique se ele ainda existe na versão atual do pacote.)

Como contribuir

O modelo de desenvolvimento de projetos Open Source permite que usuários tornem-se desenvolvedores, e o mesmo aplica-se ao desenvolvimento do Conectiva Linux e outras distribuições. Usuários podem contribuir reportando ou corrigindo bugs, mantendo pacotes ou mesmo enviando sugestões. Para tanto, é necessário manter uma distribuição de desenvolvimento atualizada pelos snapshots diários e abrir tickets no bug tracker da distribuição.

Bug tracking

O bug tracker do Conectiva Linux pode ser acessado no endereço bugzilla.conectiva.com/. Cada notificação de defeito é realizada através de um ticket, que é utilizado para acompanhar o trabalho de correção do defeito. Cada ticket é associado a um pacote, sendo-lhe atribuídos graus de severidade e prioridade, um desenvolvedor responsável pela correção do defeito, um estado e eventualmente uma resolução.

Embora os tickets sejam revisados e eventualmente reclassificados, é importante saber as definições dos graus de severidade ao abrir um ticket:

• Blocker: bloqueia o desenvolvimento da distribuição. Bugs com essa classificação são raros. Exemplo: defeito no compilador C.
• Critical: travamentos, perda de dados, memory leaks graves.
• Major: perda significativa de funcionalidade.
• Minor: perda menor de funcionalidade onde um workaround simples pode ser aplicado.
• Trivial: problemas cosméticos, erros de digitação ou tradução, etc.

Snapshots da distribuição

Muitos usuários, desenvolvedores ou não, muitas vezes preferem utilizar as versões mais recentes de cada programa, tão logo um pacote seja criado. Fazendo isto, os usuários podem realimentar dados importantes sobre o estado da distribuição naquele momento. Note, contudo, que distribuições de desenvolvimento são instáveis e muitos pacotes podem não ter passado por uma etapa extensiva de testes que caracteriza uma distribuição estável e podem, portanto, conter erros que comprometam a funcionalidade do sistema. Vale o aviso: ao testar um novo projeto de avião, não o faça num vôo comercial. Da mesma forma, não utilize snapshots da distribuição em sistemas de produção. De fato, não utilize snapshots da distribuição! A menos, é claro, que você esteja disposto a contribuir com relatos de bugs, porque eles inevitavelmente ocorrerão.

Se isso não servir para intimidá-lo, seja bem-vindo ao clube de desenvolvedores e acompanhe o desenvolvimento atualizando sua distribuição para snapshots disponíveis periodicamente.

Mas o que é, exatamente, o Snapshot?

Nos meses que separam uma versão estável da seguinte, uma distribuição está em contínua evolução. Periodicamente, uma cópia da base de pacotes disponível naquele instante é disponibilizada para o público na forma de um snapshot. Isso não quer dizer que o snapshot se tornará a próxima distribuição estável, mas que provavelmente grande parte daquela base de pacotes, no momento em que houver o freeze pré-lançamento, se tornará a próxima distribuição estável. De qualquer forma, acompanhar os snapshots da distribuição permite que se tenha uma boa idéia dos rumos que estão sendo tomados e quais novidades podem ser esperadas da próxima distribuição estável.

Qualidade do snapshot

O nível de qualidade de um produto complexo como uma distribuição Linux não pode ser obtido trivialmente de medidas diretas de suas partes, e realizar testes de regressão em todos os seus componentes é inviável. Avaliações de qualidade realizadas por usuários finais, por outro lado, não seguem metodologias rigorosas e podem ser afetadas por critérios subjetivos adotados por cada avaliador. Como é possível, então, obter um único valor escalar que possa expressar o estado de uma distribuição, provendo uma realimentação instantânea a seus desenvolvedores e permitindo que esforços sejam concentrados na melhoria deste índice de qualidade?

A página do snapshot do Conectiva Linux (snapshot.conectiva.com/) apresenta um “percentual de qualidade” do atual estado da árvore de desenvolvimento da distribuição. Por métodos usuais, não há uma maneira de medir quantitativamente a qualidade de uma distribuição, existem muitas variáveis envolvidas e muitas são desconhecidas. É possível, contudo, avaliar a qualidade baseando-nos em um conjunto de parâmetros, e diferentes escolhas do conjunto de parâmetros podem resultar em diferentes valores de qualidade. Por exemplo, um excelente produto do ponto de vista de desenvolvedores pode ser considerado um produto de qualidade questionável por um usuário final, e vice-versa. O que é, então, o “percentual de qualidade” exibido na página?

O percentual de qualidade, chamado de “índice snapshot”, é uma forma de obter um valor aproximado da qualidade da distribuição do ponto de vista de seus usuários. Ele é baseado nas seguintes premissas:

1. Quanto mais bugs, menor a qualidade.
2. Alguns bugs são piores que outros.
3. Bugs prioritários devem ser resolvidos primeiro.
4. Bugs que não são percebidos pelo usuário final não influem na qualidade.
5. Usuários afetados por bugs vão reportá-los ao sistema de bug tracking.
6. A qualidade não é fruto de uma amostragem instantânea, podendo ser afetada por longos períodos de baixa qualidade.

Dos itens citados, a premissa 5 é o elo mais fraco na cadeia: o sistema depende grandemente da realimentação dos usuários para produzir valores mais significativos.

Instalando o snapshot

De posse dessa informação, como instalar o snapshot? Snapshots são usualmente atualizados a partir de distribuições estáveis, embora CDs instaláveis (como o desta edição da RdL) possam estar disponíveis eventualmente. Para fazer a atualização a partir de uma distribuição estável, basta adicionar a seguinte linha em seu /etc/apt/sources.list:

rpm ftp://ftp.conectiva.com/pub/conectiva snapshot/i386 main extra kde gnome games

e realizar a atualização utilizando apt-get update; apt-get dist-upgrade. Naturalmente o KDE ou o Gnome não precisam estar presentes na linha adicionada ao arquivo sources.list caso não haja interesse em instalar pacotes dessas duas categorias.

Tenha em vista, contudo, que upgrades de pacotes de um snapshot para outro podem falhar, podendo requerer intervenção manual para recuperar a consistência do sistema. Apenas são garantidos upgrades a partir de uma versão estável para a seguinte.

Conselho final: pense bem no que você vai fazer! Snapshots não são suportados! Você provavelmente encontrará bugs! Se algo errado acontecer, você estará abandonado à própria sorte!

Abrindo tickets no bugzilla

O snapshot é um ambiente propício para o surgimento e reprodução de bugs, portanto esteja preparado para abrir tickets no bugzilla. Para tanto, é necessário criar uma conta no sistema (bugzilla.conectiva.com/createaccount.cgi) e cadastrar o defeito no produto Conectiva Linux.

Tickets podem ser abertos em inglês ou português. Ao relatar um defeito, é importante incluir a versão do pacote e quaisquer outras informações relevantes, bem como um procedimento para reproduzir o problema relatado.

Ciclo de vida de um bug

A evolução de estados de um ticket acompanha seu ciclo de correção:

• tickets são abertos pelo usuário (new);
• o ticket é, em seguida, revisado e atribuído a um desenvolvedor pelo coordenador da equipe de desenvolvimento (assigned);
• o desenvolvedor corrige o problema e o declara resolvido (resolved);
• o usuário que relatou o problema verifica a correção e fecha o ticket se o resultado for satisfatório (closed) ou reabre o ticket caso o problema persista (reopened).

  Mantendo pacotes

  Manter pacotes é, sem dúvida, uma das atividades mais interessantes para um usuário interessado no desenvolvimento da distribuição. Manter um pacote exige alguma dedicação, bom conhecimento da distribuição e comunicação constante com os demais membros da equipe de desenvolvimento.

  Os parágrafos a seguir contêm informações genéricas que podem ser aplicadas a diferentes distribuições. Políticas específicas com recomendações e procedimentos para o Conectiva Linux podem ser obtidas em www.conectivalinux.org/developers/.

  No caso do Conectiva Linux, os mantenedores devem possuir uma chave GPG para assinar pacotes a serem enviados para o sistema de testes e um endereço de e-mail para contato. Um alias@conectivalinux.org será fornecido para cada mantenedor. Interessados em manter pacotes podem obter maiores informações diretamente no site www.conectivalinux.org/.

  Filosofia de empacotamento

  A grande maioria das distribuições modernas de Linux oferece componentes de software na forma de pacotes. Pacotes são, em última instância, apenas uma forma conveniente de distribuir e instalar programas, desobrigando o administrador a manter um ambiente de desenvolvimento sempre preparado e garantindo homogeneidade nos diversos sistemas em que o pacote for instalado.

  Os princípios gerais de empacotamento independem do sistema empregado: um pacote sempre contém uma carga útil (payload) e um conjunto de metadados, que pode conter desde uma simples lista dos arquivos a ser instalados (para facilitar uma posterior desinstalação) até informações detalhadas de configuração ou dependências entre pacotes. Payload e metadados são agrupados em um único arquivo utilizando algum formato pré-existente ou criado para esse fim, tais como ar(1), cpio(1) ou tar(1).

  
  
    $ ar t lvm-common_1.4.deb
  
    debian-binary
  
    control.tar.gz
  
    data.tar.gz
  

  Exemplo: um pacote .deb e seu conteúdo examinado com ar(1).

  Dependências

  Os dois formatos de pacote atualmente predominantes, RPM e Debian, confiam nas informações de dependência contida em seus pacotes para garantir funcionamento após a instalação ou atualização de um sistema. Enquanto parece óbvio que um pacote contendo executáveis linkados a bibliotecas dinâmicas necessite dessas bibliotecas para funcionar, muitas vezes o layout de dependências em uma distribuição não é trivial. Pacotes mais complexos devem ser construídos com cuidado para que dependências desnecessárias não sejam adicionadas e, ao mesmo tempo, não permitir que dependências legítimas sejam excluídas. Como definir, então, o layout de dependências correto para um pacote?

  Como foi dito anteriormente, um pacote é um meio conveniente de distribuição e instalação. Quando um pacote passa a prescindir dessa conveniência, seja por tornar obrigatória a instalação de componentes opcionais ou por impedir o usuário de desfrutar de alguma característica importante do produto em questão, o layout de dependências precisa ser repensado. O mesmo vale para a atualização de um pacote: queremos que o sistema continue funcionando após uma atualização de um conjunto de pacotes para suas versões mais recentes.

  É consenso entre a maioria das distribuições que componentes de desenvolvimento devem ser empacotados em separado, por serem claramente opcionais. De forma equivalente, documentação volumosa, exemplos e plug-ins geralmente merecem seus próprios pacotes. O Conectiva Linux tem levado esse conceito à risca ao manter em pacotes separados quaisquer bibliotecas estáticas que não sejam essenciais para um ambiente de desenvolvimento regular, uma vez que essas bibliotecas são usualmente grandes e raramente utilizadas.

  Manutenção

  Após uma visão geral das questões envolvidas no empacotamento, o que se espera de um mantenedor de pacotes de distribuições em geral e do Conectiva Linux em particular? Basicamente, o que se segue:

  • Pacotes devem ser mantidos atualizados, desde que estáveis. Para isso, é importante que o mantenedor acompanhe o desenvolvimento do produto e esteja familiarizado com o ritmo dos seus desenvolvedores. Muitas vezes é interessante fazer o backport de características existentes nas versões experimentais para uma versão estável.
  • Pacotes devem ser cuidadosamente integrados à distribuição. Isso muitas vezes implica em pequenos patches e outras alterações no pacote para que ele se ajuste às regras da distribuição, tais como padrões de documentação e configuração, layout do filesystem, políticas de segurança, internacionalização, restrições de licença ou criação de sub-pacotes. Isso tudo exige, naturalmente, um conhecimento razoável da distribuição à qual o pacote se destina.
  • Um mantenedor deve ser capaz de corrigir pequenos problemas no produto, quando possível, enviando seus patches para os desenvolvedores. Esses patches devem ser portados para versões mais recentes quando da atualização do pacote.
  • O mantenedor deve procurar resolver problemas abertos no sistema de bugtracking contra seus pacotes, seja corrigindo bugs, encaminhando o ticket a pessoas melhor qualificadas para resolver o problema ou repassando as informações obtidas para os desenvolvedores.
  • O mantenedor deve garantir que o pacote possa ser atualizado com o mínimo impacto. Isso é especialmente importante em distribuições que utilizam sistemas de atualização como o APT.

  Vale repetir que essas são regras genéricas. A documentação contendo as regras específicas para cada distribuição deve ser consultada para obtenção de maiores detalhes.

  Mantendo uma distribuição

  Você está pronto para manter sua própria distribuição? Confira nos itens abaixo alguns dos requisitos necessários para manter uma distribuição dentro de bons padrões de qualidade.

• Sistema de instalação: pode-se utilizar um programa de instalação escrito para outra distribuição, mas muitas vezes é necessário personalizar o instalador ou resolver problemas de usuários com configurações ou necessidades específicas. Para isso, dispor de um instalador desenvolvido para sua distribuição confere uma maior autonomia na inclusão de novos recursos (por exemplo, instalação com LVM) ou solução de problemas (por exemplo, erros de instalação com determinadas controladoras SCSI).
• Atualização de pacotes: espera-se de uma distribuição recém-lançada que ela contenha a última versão de cada pacote disponibilizado. Isso, contudo, nem sempre é possível ou desejável: muitas vezes versões mais antigas são necessárias para o correto funcionamento de outros pacotes, ou versões recentes podem conter bugs. É papel do distribuidor saber quais são as versões estáveis de cada pacote e não distribuir as versões mais recentes quando isso for seguro.
• Correções de problemas de segurança: sempre que forem detectados problemas de segurança em pacotes disponibilizados em versões recentes da sua distribuição, faz-se necessária uma ação rápida para disponibilizar pacotes corrigidos e alertar os usuários afetados.
• É essencial acompanhar listas de segurança e manter contato com outros distribuidores para estar ciente de quaisquer problemas de segurança que possam afetar a sua distribuição.
• Bug tracker: usuários devem ter facilidade em notificar o distribuidor sobre quaisquer problemas que venham a ser encontrados na distribuição, bem como enviar sugestões de melhoria e acompanhar o andamento de ocorrências anteriormente notificadas.
• Controle de qualidade: embora muitos problemas venham a ser detectados apenas por usuários finais, é imprescindível que pacotes importantes sejam exaustivamente testados e garantidos contra erros grosseiros de construção, empacotamento ou execução. Correções para problemas reportados por usuários devem ser testadas para garantir que o problema foi corrigido e para evitar a introdução de novos problemas.
• Canais de comunicação com os usuários: usuários da distribuição devem ser ouvidos para que o distribuidor obtenha uma realimentação. Além de um sistema de bug tracking como o descrito acima, listas de discussão, newsgroups, canais de IRC ou outros meios de comunicação são muito importantes.
• Canais de comunicação com outros distribuidores: manter-se em contato com desenvolvedores de outras distribuições permite o compartilhamento de soluções, patches e layouts de pacotes, evitando duplicação de esforços e perda de tempo.
• Especialistas em subsistemas importantes: kernel, X, kde, etc. são subsistemas que requerem conhecimento profundo dos programas em questão e seus componentes, muitas vezes exigindo um grande investimento em manutenção. Ter um especialista mantendo os pacotes mais importantes da sua distribuição faz com que problemas relatados possam ser resolvidos com maior rapidez e confiabilidade.
• Hardware para as plataformas suportadas: pode parecer um requisito trivial, mas muitas vezes os distribuidores não dispõem do hardware apropriado para reproduzir um problema relatado por um usuário. (Você perceberá isso quando os usuários reclamarem que a sua distribuição não funciona em sistemas de 8 processadores com dezenas de gigabytes de RAM e duas controladoras SCSI DAC 960.)
• Suporte: distribuições comerciais costumam oferecer contratos de suporte a seus usuários, necessitando, portanto, de infra-estrutura e de uma equipe de suporte treinada para atendê-los.

Listas de discussão - snapshot-users

Questões referentes ao snapshot do Conectiva Linux podem ser discutidas na lista snapshot-users. Para inscrever-se, use o formulário disponível em distro.conectiva.com/mailman/listinfo/snapshot-users/. Para esta lista também são enviados relatórios diários dos pacotes disponíveis, bem como avisos sobre problemas importantes detectados no snapshot do dia. Se você tiver o snapshot instalado, é importante assinar esta lista para manter-se informado sobre eventuais problemas que possam afetar à distribuição.

Outro conselho é instalar o pacote apt-listchanges: ele listará os changelogs dos pacotes a atualizar, dando a chance de abortar o processo caso alguma alteração o desagrade. Recomenda-se também que as atualizações sejam freqüentes, dada a volatilidade dos pacotes do snapshot, novas versões (possivelmente com problemas corrigidos) são disponibilizadas diariamente.

Snapshots de outras distribuições

Várias distribuições abrem seu processo de desenvolvimento ao público, oferecendo constantemente snapshots e betas de versões em desenvolvimento. Veja como é feito o processo em algumas delas.

Debian: Há três distribuições. Stable é a versão estável, pronta para uso geral. Testing é a distribuição que está em testes e se tornará a próxima versão estável. Unstable é a distribuição instável, onde novos pacotes estão sendo adicionados. O processo de desenvolvimento segue o seguinte ciclo: Pacotes novos são adicionados à distribuição instável. Caso não haja bugs graves marcados contra estes pacotes por um determinado período de tempo, os pacotes entram na distribuição de testes. Quando um certo número de pacotes e todos os objetivos para a nova versão são alcançados, a distribuição em testes é congelada (entra em freeze), e é proibida a adição de novos pacotes, e apenas a correção de bugs em pacotes já existentes é permitida. Ao se sentirem satisfeitos com a qualidade da distribuição de testes, após várias versões beta e “release-candidates” (candidatos a versão final), a distribuição em testes é promovida a estável e uma nova versão do Debian é lançada. Cada versão possui o nome de um personagem de um filme da Pixar (atualmente, Toy Story). A distribuição estável se chama Potato (O Sr. Cabeça de Batata do filme), a em testes é Woody (o Cowboy) e a instável se chama Sid. Interessados em participar devem acessar www.debian.org/devel/join/, onde há informações sobre listas de discussão, pacotes que precisam de mantenedores, como enviar novos pacotes, etc.

Mandrake: Há uma versão em constante desenvolvimento, chamada Cooker, a qual eventualmente entra em freeze e após algumas versões beta se torna a nova distribuição estável. Assim que uma nova distribuição é lançada, a Cooker sai do “freeze” e o desenvolvimento continua do ponto onde parou. A Mandrake fornece listas de discussão para os interessados em participar, seja com a contribuição de pacotes, tradução, verificando relatórios de bugs ou mesmo testando versões beta. Interessados devem acessar www.linux-mandrake.com/en/cookerdevel.html, onde podem obter FAQs e informações detalhadas sobre o processo de desenvolvimento e sobre como participar das listas de discussão.

Comunidade A Conectiva é dita uma distribuição comercial no sentido em que baseia o seu negócio nos serviços, consultoria e treinamento agregados a sua distribuição Linux, que é 100% Software Livre. Segundo, Wanderlei Antonio Cavassin, Gerente de Desenvolvimento do CL e um dos acionistas fundadores da Conectiva, a ampla participação no desenvolvimento é uma das maiores vantagens do Software Livre; é o que o torna de fato competitivo frente a tecnologias proprietárias. “Assim ao mantermos uma comunidade de desenvolvedores participando ativamente, estamos reforçando a competitividade do próprio Linux”, conta. Cavassin diz que a própria Conectiva faz parte desta comunidade, sendo que todo o trabalho é realizado para melhoria do Linux e revertido para a própria comunidade (incluindo outras distribuições). “Programadores que submetem patches (consertos para problemas) são os mais requisitados; no entanto, tradutores e testadores são muito bem-vindos”, conclui.

Tem algo a dizer sobre o Beta?

Através da lista de discussão aberta exclusivamente para a versão em desenvolvimento do Conectiva Linux, você pode manter-se informado sobre o que está sendo melhorado no software. Haverá troca de informações sobre erros, características e novidades no sistema.

É importante ressaltar que a finalidade da lista não é prestar suporte, mas apenas servir como um canal de troca de informações entre a Conectiva e os desenvolvedores. Há listas específicas para troca de experiências entre usuários. A Linux-BR é uma delas. O único assunto da lista beta é o desenvolvimento de versões futuras do Conectiva Linux.

• Para assinar a lista, mande um e-mail vazio para: beta-subscribe@bazar.conectiva.com.br e aguarde o e-mail de confirmação.
• Para cancelar a sua assinatura, mande um e-mail vazio para: beta-unsubscribe@bazar.conectiva.com.br e aguarde instruções.

Resolvendo problemas de empacotamento

Apresentamos uma rápida descrição de um problema real de empacotamento ocorrido durante um ciclo de desenvolvimento do Conectiva Linux, envolvendo a biblioteca GD. GD é uma biblioteca de manipulação gráfica que pode ser utilizada para geração de imagens em tempo de execução para scripts CGI e similares, e é utilizada por diversos outros pacotes tais como php4, linuxconf, mrtg e webalizer. O problema de dependências descrito a seguir ilustra um dos muitos tipos de problema que podem ocorrer no momento da geração de pacotes para uma distribuição, e foi selecionado para este estudo de caso por mostrar como um pequeno erro em um pacote pode causar um grande impacto em outros pacotes. Confira:

O problema:

Por ser utilizado por um número razoável de outros pacotes, seria ideal que a libgd estivesse disponível como uma biblioteca dinâmica. O pacote upstream da libgd, entretanto, disponibiliza apenas uma biblioteca estática.

A solução:

Optou-se, neste caso, por alterar o pacote de modo que uma biblioteca dinâmica fosse gerada a partir dos objetos contidos na biblioteca estática. A biblioteca foi gerada, e os pacotes dependentes da nova biblioteca foram reconstruídos.

O erro:

Após a geração dos novos pacotes, foi observado que eles dependiam não da libgd, mas de seu pacote de desenvolvimento, libgd-devel! O problema foi causado pela falta de um soname[1] na biblioteca, utilizado pelo runtime linker para determinar a versão correta da biblioteca a ser utilizada.

A correção:

O soname faltante foi adicionado à biblioteca e os novos arquivos foram corretamente distribuídos entre os subpacotes libgd1 e libgd-devel. Contudo, o problema não se limita ao pacote: informações incorretas de dependência estão contidas em todos os pacotes que dependem dessa biblioteca. Foi necessário, então, reconstruir todos os pacotes da lista de dependências reversas da libgd para eliminar a dependência incorreta.

Muitas vezes, determinar quais pacotes são afetados por um erro pode ser uma tarefa espinhosa. Para isso, ferramentas como o dm (sf.net/projects/pkgtools) podem ser bastante convenientes.

Como reportar um bom bug

De nada adianta testar o software, encontrar bugs, e na hora de reportá-los ao bugzilla preencher relatórios vagos ou, na pior das hipóteses, completamente inúteis. Veja abaixo algumas dicas que facilitam a vida dos desenvolvedores:

Tente reproduzir o problema - Isso ajuda o desenvolvedor a determinar exatamente quais passos levam ao bug e dá a ele uma idéia do que pode estar errado.

Acompanhe seu bug - Geralmente os desenvolvedores adicionam comentários ao seu relatório, pedindo mais detalhes ou que algum teste seja executado. Um bom acompanhamento acelera o processo e auxilia muito na resolução do problema.

Detalhe bem suas descrições - Muitos relatórios são simplesmente ignorados, pois não contêm detalhes suficientes para que o bug seja reproduzido e encontrado. Veja um exemplo:

Péssimo: “O instalador dá pau na minha máquina!”

Bom: “O instalador do Beta 1, versão wakko@2002.01.05-20.08, cai quando mando testar o modo de vídeo 1024x768x32 Bits de cor em uma máquina com uma placa de vídeo SiS 6360 com 2 MB de RAM compartilhada”

Claudio Matsuoka - claudio@conectiva.com.br