Olá Obrigado por estarem aqui Espero que alguns de vós achem interessante, mas maior parte de voçês já conhecem, provavelmente. Então trata-se de uma conversa sobre triagem e encerramento de erros (bugs) Eu sou a Solveig e aqui está a minha informação de contacto. Eu uso software livre desde os meus 10 anos Foco-me especialmente em questões de privacidade. Contribuo para o Tails que é um derivado da distribuição Debian e fui à última DebConf e gostei muito iniciei a triagem de erros porque não sou uma programadora, mas existem muitas maneiras de contribuir para Debian Então, triagem de erros é uma pequena tarefa mas ajuda Debian como um todo Então ... Então, aqui é onde pode ver o sistema de triagem de erros Debian, aqui pode introduzir um numero de erro e procurar pelo seu número Muitos maintainers têm demasiado trabalho e não querem ter que ligar com todos os seus relatórios de erros Alguns pacote com alta popularidade acumulam muitos relatórios de erros como o kernel, ou o firefox (Iceweasel) e por vezes os maintainers por alguma razão, não têm tempo para lidar com todos os seus relatórios de erros Assim alguns deles apenas ficam apenas no sistema de triagem de erros sem se lidar com eles Assim quando os triar garanta que estão num estado em que alguma coisa possa ser feita com eles de modo que os maintainers podem ter a garantia que tenham actualizados os relatórios de erros, para que vejam mais eficazmente o que podem fazer e os utilizadores que procurem erros similares a estes possam encontrá-los e assim os maintainers ficam com mais tempo para os corrigir efectivamente e vai querer triar erros porque é fácil não tem que escrever código não precisa de fazer a administração do sistema apenas precisa de saber ler e escrever e-mails [riso] É recompensador porque os maintainers, ou a maior parte ficam contentes que os ajudamos Os autores dos relatórios ficam também contentes por serem contactados de volta, e assim ganha grande quantidade de feedback e é divertido Acaba por ler sobre um software que não fazia a ideia de existir Não consegue entender mesmo depois de ler, o que é suposto o software fazer e realmente não percebe, enquanto que efectivamente alguém o escreveu Isso é de malucos, é realmente [gargalhada] e claro, salva "gatinhos" [aplausos] Existem variadas operações que pode efectuar nos relatórios de erros Estas são duas das mais úteis páginas de documentação a página wiki sobre relatórios de erros e os comandos de controle do servidor que são um pouco exóticos, quero eu dizer, trata-se de uma página gigante com muitos comandos a enviar para o controle de servidor e realmente muita coisa a fazer, para lhe indicar o que é mais útil fazer Bem, dos mais usados Pode tentar reproduzir os relatórios de erro Mais à frente irei detalhar Pode criar etiquetas nos relatórios de erro quando os mesmo não são reproduzíveis pode fundir (merge) relatórios de erro encaminhá-los a montante (upstream) e lidar com montante e lidar com quem submete e, quase me esquecia, pode fechar relatórios de erro, que é a melhor parte Então, ao reproduzi-los por vezes, recebe relatórios de erros que não são tocados à anos e provavelmente estão já resolvidos, ou talvez não, mas na dúvida o relatório ficará ali e ninguém o irá tocar o relatório de erro porque existe uma probabilidade alta de o mesmo não se aplicar mais assim poderá testar se o mesmo ainda ocorre Existem também novos relatórios de erros que são apenas reportados por uma pessoa de modo que se não estiverem marcados "confirmed" ou "pending" e se puder [falha na bateria do microfone] Se novos relatórios de erros não estejam confirmados pode tentar ver se consegue reproduzi-los e em caso afirmativo, confirmá-los Se puder reproduzir relatórios antigos ou novos de erros não confirmados ainda então escreva "nnn" para identificar o número de relatório de erro e envie para @bugs.debian.org e marque-o Então este é o primeiro dos comandos estranhos Assim, pesquise o número do relatorio de erro número de versão confirme qual a versão e marque-o "confirmed" e "thanks", porque o controlo de servidor é muito educado de modo que se não agradecer cada vez que escrever um comando, torna-se uma chatiçe Então, outro modo de triar um relatório de erro é tentar reproduzi-lo e vamos dizer que não funcionou Se não o puder reproduzir e já esteja corrigido Então veremos mais tarde como fecha-lo Se não o puder reproduzir mas não tem a certeza que esteja corrigido porque talvez não tenha a mesma configuração de quem o relatou ou talvez não tem a certeza que seguiu os mesmos passos para o testar Se não tem a certeza, então marque-o "unreproducible" ou "moreinfo" e deste modo irá informar quem o relatou e o maintainer, que nem todos encontram o relatório de erro que poderá ser só por si informação Por vezes poderá fundir (merge) relatórios e isto especialmente verdadeiro para novos relatórios porque caso contrário é onde ficam para sempre duplicados Então Colocá-los no mesmo pacote e com o mesmo nível de severidade e estado são operações diferentes e está detalhado na documentação e no final pode fundir o resultado É engraçado Todas as mensagens serão colocadas junto, por isso por vezes terá que pesquisar um pouco podem existir mais que dois relatórios "colados" Por isso por vezes estão realmente não "colados" mas fundidos Depois de algum tempo, poderão existir três ou quatro se as pessoas continuam a abrir o mesmo relatório Por isso por vezes é engraçado Outro modo é fazer um reporte enviar um reporte para a fonte (upstream) porque Debian é um conjunto de pacotes não desenvolvidos para Debian, mas para em formato de código fonte e empacotados sim para Debian assim de existir um relatório de erro a ocorrer em Debian, na maioria dos casos ocorre no código fonte deste modo pode pesquisar a monitorização do relatório do envio de modo a perceber se já existe relatórios semelhantes se existirem por vezes os mesmos têm uma forma de contornar ou por vezes do lado da fonte é informado que não é possível corrigi-lo por não o consideram um erro ou quando é o caso a informação deverá ser colocada na monitorização de erros Debian e se o erro já existe do lado da fonte, então a monitorização de erros Debian deverá já saber de modo que você terá que comunicar ao BTS Existe também um comando estraguei o modo de o mostrar , mas ok Este é o comando "forwarded" e o número de erro em Debian e o número de erro no código fonte e novamente "obrigado" porque é sempre educado Existem outras coisas que pode fazer do lado do código fonte Por vezes deste lado não têm o número de erro sendo obviamente um erro deles e assim se puder reproduzir o erro, deverá abrir um relatório de erro na fonte que é na maioria dos casos um problema porque tem que registar uma conta pessoal ou encontrar a monitorização do relatório de erro Mas é divertido Mas poupa tempo ao maintainer e quem reportou o erro vê mais hipóteses do erro ser resolvido Se abrir o erro na monitorização do erro na fonte terá que marcá-lo como forwarded como já vimos anteriormente Por vezes o lado da fonte diz que já está corrigido e os mesmo deverão comunicar à monitorização de erros Debian que está corrigido terão que dizer qual a versão e talvez o maintainer poderá actualizar o seu pacote para dar a versão corrigida e por vezes existe um 'patch' de código fonte que não está aplicado e assim deverá revê-lo e/ou testá-lo e comunicar se funciona ou não Se funcionar pode também trazê-lo para o sistema de monitorização de erros debian marcar o erro com "patch" Existe também trabalho com quem reporta existe um grande percentagem de erros marcado com "moreinfo" Alguém comunicou "Não funciona" e do nosso lado temos que saber porque não funciona Às vezes surge uma nova versão empacotada e poderá voltar a surgir o erro, ou talvez não mas terá que saber ou alguém comunicou "Eu irei testar esta versão ou esta configuração" e/ou "Irei comunicar à fonte" e nada aconteçe e por vezes fica nesta situação "a aguardar informação" durante muito tempo Eu escrevi um ano ou um lançamento porque é o que eu considero começar a ser muito tempo Assim que eu encontro alguns destes, eu fecho alguns erros que não são tocados para mais de dez anos que é um record Assim pode ajudar enviando um email para a pessoa que necessita de informação às vezes é quem reportou , outras vezes o maintainer, outras vezes a fonte e outras vezes outra pessoa qualquer a dizer que "Eu posso fazer isso" ou "Pode reproduzir o erro?" para que o relatório de erro ganhe um estado onde possa ter visibilidade do estado actual e que se possa decidir o que fazer com ele Então a parte complicada é não fechar erros aleatoriamente Como iremos ver mais tarde, pode ser perigoso Pode pesquisar por pacotes que possuem muitos relatórios de erros e perguntar ao maintainer se ajuda é bem vinda ou pode procurar por uma boa equipa Debian é constituído por uma composição de variadas equipas A maior parte delas são verdadeiramente hospitaleiras a novos contribuintes porque necessitam de ajuda e as que conheci são simpáticas e numa equipa, terá a certeza que existe suficientes pacotes, de modo que existem muitos pacotes para fazer triagem e muitas pessoas para responder às questões Eu triei erros a partir da equipa de perl, de jogos da X strike force todas eles muito simpáticas Eu recomendo-as para voçês Eu tentei, mas não consegui realmente entender nada, mas se entender alguma coisa os erros do kernel precisam de trabalho também Na documentação sobre triagem de erros adicionei uma secção sobre equipas que necessitam ajuda Então, se estiver numa equipa que precisa de triagem, adicione-se aqui Se quiser triar veja aqui quem necessita de ajuda e não precisa entender nada sobre o que eles fazem para triar os erros Quero dizer não sei programar em Perl de modo que Perl é ... O X strike force não está escrito em Inglês mas ok os jogos , eu poderia tentar reproduzi-los ou alguns deles outros, na verdade não, mas às vezes, pode ser o estado de um erro sem entender a sua essência Pode ver que se alguém perguntou sobre informação há um ano atrás, o erro tem que ser sinalizado (pinged) ou considerar que não irá haver nenhum evento mesmo que não entenda o erro pode ver qual o estado do erro Uma ferramenta fabulosa é a última versão do motor de busca de erros da base de dados Debian Parece-se como isto Por favor ignorem isto Então, se seleccionarem a versão podem adicionar muitos filtros tipos de erros Bom de facto também inclui as equipas aqui e quando tiver terminado, clica procurar É verdadeiramente útil E como podem ver, a minha não aparece como devia aparecer Critérios para erros que foram perdidos Se os ignorar os que foram mexidos ou criados no último ano e seleccionar ou "wontfix" ou "moreinfo" ou "upstream" or "unreproducible" a seguir escolhem uma equipa e irá encontrar muitos erros perdidos poderá começar a lê-los e ver os seus estados Se não forem reproduzíveis se o erro estiver já corrigido Bom, ou a nova versão corrige o erro ou o erro foi já corrigido de qualquer forma porque foi uma questão de configuração De qualquer forma não acontece novamente Assim poderá fechá-lo E aqui está o número de erro novamente "done@bugs.debian.org" e tem que identificar qual a versão que foi corrigida Então, se calhar foi corrigido entretanto mas , pelo menos, informe "esta versão actual de certeza está corrigida" para que a BTS saiba qual a versão afectada e principalmente qual a versão não afectada Existe uma boa página de documentação sobre isso Então, fecho de relatórios de erros é apenas sobre enviar um email para "done@bugs.debian.org" Isto foi para "unreproducible" OK, "moreinfo" or "wontfix"