Como rastrear um bug que causou um acidente e foi relatado via apport / whoopsie?


52

Antes, quando um programa falhava, especialmente quando um usuário usava um pré-lançamento do Ubuntu, o apport podia ser usado para abrir um relatório de erro. O usuário pode rastrear o bug, ver se ele afetou outras pessoas, ajudar a corrigi-lo etc.

No Precise 12.04, esse comportamento e fluxo de trabalho foram alterados. Como descobri no Bug # 993450 "O Apport falha ao enviar o relatório de erros" , por padrão, o apport não abre mais um relatório de erros (e é complicado, mas não impossível fazê-lo). Ao mesmo tempo, as pessoas estão percebendo um novo processo de "whoopsie", conforme descrito em O que é o processo de 'whoopsie' e o que ele faz? .

Depois de pesquisar um pouco mais, descobri esse projeto, que descreve todo o processo: ErrorTracker - Ubuntu Wiki . (Não mencionou whoopsie ou margarida, então eu os adicionei - por favor, corrija-me se eu entendi errado).

Uau - isso parece um ótimo trabalho para otimizar e melhorar o processo de relatório de falhas.

Fico com a seguinte pergunta: como um usuário aprende qual é o status do problema? O projeto agora tem esse requisito

O usuário deve ter uma maneira de verificar novamente o status do relatório de falha; por exemplo, tenha algum ID de relatório que eles possam ver para ver estatísticas e / ou qualquer bug associado #. Por exemplo, forneça um número de série no momento do arquivamento que eles podem carregar através de uma página da web posteriormente.

o que parece não implementado. Enquanto isso, há algo disponível?

E como um desenvolvedor entra no jogo? Ir para https://daisy.ubuntu.com apenas fornece uma mensagem de erro "Tipo de conteúdo incorreto".

Por fim, sugiro documentar as alterações no comportamento do apport nas notas de versão. Deve ser do interesse de qualquer pessoa que esteja tentando ajudar o Ubuntu.


Respostas:


45

Obrigado pelo seu interesse no projeto rastreador de erros do Ubuntu .

No Precise 12.04, esse comportamento e fluxo de trabalho foram alterados. Como descobri no Bug # 993450 "O Apport falha ao enviar o relatório de erros", por padrão, o apport não abre mais um relatório de erros (e é complicado, mas não impossível fazê-lo).

O Apport nunca criou relatórios de erros após o lançamento. Quando uma liberação ainda está em desenvolvimento, você pode usar o apport para arquivar bugs do Launchpad (e relatórios de erros).

Em uma versão final lançada do Ubuntu, agora mostramos caixas de diálogo de erro. Esta é uma grande melhoria de um programa "indo embora" sem nenhum feedback e o usuário ficando imaginando o que aconteceu.

As estatísticas dos dados coletados quando as pessoas optam por enviar esses relatórios são exibidas em http://errors.ubuntu.com .

Fico com a seguinte pergunta: como um usuário aprende qual é o status do problema? O projeto agora tem esse requisito

O usuário deve ter uma maneira de verificar novamente o status do relatório de falha; por exemplo, tenha algum ID de relatório que eles possam ver para ver estatísticas e / ou qualquer bug associado #. Por exemplo, forneça um número de série no momento do arquivamento que eles podem carregar através de uma página da web posteriormente.

Eu vou remover isso. Essa nunca foi a intenção. A interface do usuário é cuidadosa para não fazer promessas sobre a obtenção de comentários sobre o relatório.

Estes não são relatórios de erros.

Nossa intenção é reduzir o tempo que leva para os desenvolvedores encontrarem os problemas mais urgentes, coletar as informações necessárias para corrigi-los e obter as correções para os usuários.

Resolvemos o problema de encontrar os problemas mais prementes. Essa é a primeira página do http://errors.ubuntu.com .

A coleta das informações necessárias rapidamente e sem envolver um longo ciclo de feedback com os usuários que estão enfrentando o problema é abordada em melhorias em fundações-q-bucketing . O plano é permitir que os desenvolvedores se conectem ao processo de coleta de informações do lado do servidor. Se eu precisar de / var / log / syslog, mas ele ainda não estiver disponível, basta alterar uma configuração em http://errors.ubuntu.com e a próxima pessoa que tiver o erro a adicionará automaticamente aos dados que estão enviando.

Obter correções para os usuários rapidamente é abordado em foundations-q-updates-from-crash-reports . Quando os usuários enviam um relatório de erros e esse erro já foi corrigido e lançado, uma caixa de diálogo será exibida perguntando se eles gostariam de atualizar para a versão do software que corrige o problema que acabaram de enfrentar.

E como um desenvolvedor entra no jogo? Ir para https://daisy.ubuntu.com apenas fornece uma mensagem de erro "Tipo de conteúdo incorreto".

http://daisy.ubuntu.com não se destina a ser usado por seres humanos. Está lá para o daemon de relatório de erros (whoopsie) enviar relatórios para.

Seria absolutamente maravilhoso para outras pessoas se envolverem. Atualmente sou o único hacker em tempo integral.

Existem quatro partes no sistema.

  • Apport , que fornece a interface do usuário da área de trabalho.
  • Whoopsie , que pega os relatórios (e core dumps) criados pela Apport e os empurra para o servidor do rastreador de erros, Daisy.
  • Daisy , que coleta relatórios de Whoopsie e os processa. Este é o coração do serviço. É o que transforma os arquivos principais em relatórios reformulados e gera as estatísticas que você vê em http://errors.ubuntu.com .
  • Erros , que é um site baseado no Django, que fornece uma visão legível dos dados e uma API RESTful para trabalhar com eles.

Há um conjunto de scripts um pouco desatualizado no diretório setup / em lp: daisy que deve lhe dar uma idéia de como as peças se encaixam. Eu tenho trabalhado em juju encantos para substituir isso. O objetivo é um único comando para implantar toda a infraestrutura na nuvem para teste e desenvolvimento.

Você pode encontrar meu endereço de e-mail no Launchpad se tiver mais perguntas sobre desenvolvimento.

Mais informações:


"As estatísticas dos dados coletados quando as pessoas optam por enviar esses relatórios aparecem no errors.ubuntu.com ." Isso não está correto, apenas se o seu aplicativo estiver escrito em uma linguagem de programação suportada. Por exemplo, nenhum programa escrito em mono tem erros relatados lá. Isso é discriminatório ao extremo. Ubuntu deve fornecer um mesmo campo de jogo e não excluir programas com base no idioma que estão escritos no.
trampster

2
Acho que você perdeu a parte em que ele está trabalhando sozinho, companheiro. Não há problema em oferecer suporte a idiomas populares primeiro.
Vadim Peretokin

5
De fato, o @Vadi está correto. Não há nada de discriminatório nisso. Se alguém quiser intensificar e implementar o suporte Mono, analisarei e mesclaremos com prazer sua ramificação de apport.
Evan

4

Para visualizar relatórios de seu próprio sistema, tente isso, conforme documentado em https://bugs.launchpad.net/ubuntu/+source/apport/+bug/994921/comments/43

xdg-open https://errors.ubuntu.com/user/`sudo cat /var/lib/whoopsie/whoopsie-id`

Sem permissões especiais no Launchpad, você não pode visualizar os relatórios reais, mas pode ver os programas em que foram relatados e pode usar os IDs fornecidos para se referir a eles ao conversar com desenvolvedores que possuem as permissões adequadas.


Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.