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" Para estes terá que se certificar com a equipa ou com o maintainer qual a política, porque algumas pessoas pretendem manter tudo em aberto para sempre e alguns "wontfix" deverão manter-se abertos porque se existirem funcionalidades ou erros que são frequentemente requeridos, então seria uma tolice fechá-los para que alguns os volte a abrir em breve mas, muitos são erros que estão marcados "moreinfo" e nunca chegam a gerar resposta ou estão marcados como "wontfix" devem ser fechados porque não existe trabalho sobre os mesmos Não existem linhas de orientação na documentação sobre isto de modo que decidi arbitrariamente um ano após quem submeteu ser avisado e não ter devolvido resposta poderemos considerar talvez que a pessoa que submeteu está ausente Provavelmente poderá ser um espaço curto, mas as pessoas podem ficar zangadas porque foi uma contribuição para os relatórios de erros e que o mesmo não deveria ser apagado de ânimo leve Se tiver a certeza que um erro não tem realmente utilidade para ninguém então, faça o mesmo número"-done" com a explicação claro Então, um exemplo Vamos fazer uma pesquisa "wontfix" não tocado desde o ano passado, perl incluir "wontfix" ignorar criado ou modificado no passado ano ou mais ou menos e ver a equipa perl Todos estes erros são de diferentes pacotes mas são todos correspondem ao mesmo critério e podemos ordená-los pela última data de modificação muitos deles foram esquecidos por alguns anos e, bem, o próximo passo é começar a ler os relatórios E já que eu preparei um pouco mesmo que não muito Eu seleccionei um e aqui está um que pode ser lido ok eu não irei ler completamente com vocês hoje, mas podem ver que a conclusão é a fonte considerou que não é um erro Foi informado em 2010 e assim já houve tempo suficiente para deixar as pessoas saber [riso] e foi fechado na fonte Então, o relatório de erro na fonte onde diz "It does according to the man page" "closing" Então, a fonte fechou-o e nós devemos fazer o mesmo Então, eu fiz e não irei mostrar agora, mas enviei este email mesmo antes de vir para cá para número_do_erro"-done" assunto: nós usamos um assunto tipo de relatório de erro, para que as pessoas saibam do que se trata e justifico que estou a fechá-lo e então a minha mensagem standard "Olá, estou a fechar este erro porque foi marcado não reproduzível durante alguns anos sem resposta Se tiver alguma razão para apontar como um problema, por favor sinta-se livre para o voltar a abrir ou pedi-lo a mim" Isto porque nem toda a gente que submete erros conhece todas as subtilezas de servidor de controlo e nem todos sabem como reabrir um erro e assim ao pedirem para reabrir pois um erro pode ser um pouco demais , e então se eu o fechar e não tiver sido uma boa ideia, eles podem pedir-me a mim para o reabrir, e assim ninguém se perde no processo Por vezes, existem relatórios de erro que provavelmente deveriam ser fechados ou fundidos ou outra coisa, mas não têm a certeza absoluta Não há pressa, a maior parte deles estão à espera há muito tempo de qualquer forma por isso demore alguns dias, semanas, meses ou anos como acontece, e talvez na próxima vez que abrir este erro, o mesmo estará mais claro de modo a lidar com ele pois tem mais experiência ou com uma mente limpa Pode também pedir opiniões dos maintainers, se eles estão dispostos a ajudar ou para outros amigos ou membros do grupo Atenção a questão sobre o ponto anterior de não fechar erros aleatoriamente, se o ou a maintainer não tiver tempo para triar os seus erros eles poderão não ter necessariamente tempo para explicar-lhes sendo o caso do mesmo querer o erro fechado ou não É por isso que é bom trabalhar em equipa porque é mais provável ter alguém disponível que o possa ajudar em caso de dúvidas Outra parte importante é dizer que o está a fazer porque se as pessoas não perceberem o que está a fazer, eles podem reagir mal Certifique-se que todos recebem a informação que precisam porque se fechar um erro quem o reportou recebe a informação mas se adicionar uma marcação, eles não, e outras pessoas podem responder ao relatório de erro a dizer que também têm o mesmo problema, e não recebem a informação por isso às vezes às vezes tem que verificar quem forneceu a informação para o relatório e garantir que o copiou para os mails que estiver a enviar, para que tenham a informação Não escreva uma novela quando fechar ou triar erros mas dê toda a informação para que as pessoas possam entender o que está a fazer, para que tenham um pouco de contexto e não tenham que ler todo o tópico de conversa para saber o porquê de você estar a fazer isto no exemplo que dei anteriormente copiei o assunto do relatório de erro para que saibam sobre o relatório de erro disse o seu estado e que tinha tomado a decisão eles tem uma ideia do que se passa e pode ter mensagens genéricas não precisa de inovar todas as vezes, apenas copiar e colar e talvez alterar poucas palavras e como apenas fez um copy-paste não demora muito tempo, escreva algumas palavras simpáticas ajuda [gargalhadas e aplausos] Cuidado, podem existir dragões Eu deixei de fechar erros no passado dois meses depois de ter fechado um do Ian Jackson e foi uma má ideia e foi uma ideia tão má perdi o meu entusiasmo por alguns meses Se conhecer uma pessoa como o Ian Jackson Se tudo indicar que um erro deve ser fechado ou marcado talvez fechem apenas o "tab" ignorem pensem apenas que não existe vocês sabem voçês certamente têm melhores coisas para fazer com a vossa vida vocês têm mesmo, de verdade Eu tenho que ser franca, este é ele, mas existem provavelmente outros como ele mas continuem Existem também pessoas muito simpáticas à volta de Debian, alguns com que se pode trabalhar falar e que são prestáveis e agradáveis e muito acolhedoras e lembrem-se: triagem de erros é divertida recompensadora e fácil Assim que se iniciar E é isto. [aplausos] Alguém tem perguntas? Penso que não, mas [Q] Olá, voçês têm algumas outras histórias reais das vossas aventuras de correcção de erros? [risos] [A] OK, Eu não Eu devia ter aberto os relatórios Eu fechei um erro com mais de dez anos Foi de certo modo engraçado Algumas pessoas que o submeteram escreveram-me pedindo para o reabrir por isso não foi uma proposta técnica É É útil propor para reabrir relatórios Muitas pessoas agradecem-me, o que é sempre agradável Os meus amigos maintainers por vezes ficam ciumentos quando posso dizer "Eu fechei 20 erros hoje" [risos] e eles dolorosamente fecham um Eu irei mantê-los ... actualizados com novas histórias de triagem de erros [Q] A partir do IRC, de Peyaro O que faz com os erros marcados "patch" com um patch enviados na ultima mensagem mas sem resposta do maintainer? [A] OK você verifica se o maintainer está activo nos seus pacotes Se está, então tente contactá-lo de novo e de novo se não responder a nada, então deverá declará-lo "missing in action" (desaparecido de acção" Terá que lhe escrever Bem se o mesmo não fizer devidamente o seu trabalho pode propor ajudá-lo ou encontrar alguém que o ajude a fazer um non-maintainer upload Acho eu mas triagem significa ajudar os maintainers também não tem não é o sítio correcto para começar a chateá-lo sobre o facto de que não está a fazer o trabalho correctamente Eles provavelmente têm razões para [Questão ininteligível]