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
está com uma mente mais
limpa naquele dia
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
que era um relatório de erro, e disse
o seu estado
e por isso tomei 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?