Obrigado pelo seu interesse no projeto rastreador de erros do Ubuntu .
A partir do Precise 12.04, esse comportamento e fluxo de trabalho foram alterados. Como descobri no Bug # 993450 "O Apport não envia um relatório de bug", por padrão o apport não abre mais um relatório de bug (e é estranho, mas não impossível fazê-lo).
O Apport nunca criou relatórios de erros após o lançamento. Quando uma versão ainda estiver em desenvolvimento, você pode usar o apport para arquivar bugs do Launchpad (e relatórios de erro).
Em uma versão final do Ubuntu, agora mostramos diálogos de erro. Essa é uma grande melhoria em relação a um programa que "vai embora" sem qualquer feedback e o usuário fica se perguntando o que aconteceu.
As estatísticas dos dados coletados quando as pessoas escolhem enviar esses relatórios aparecem no link .
Fico com esta questão: como um usuário aprende qual é o status do problema? O blueprint agora tem esse requisito
O usuário deve ter alguma maneira de verificar o status do relatório de falha; por exemplo. tem algum ID de relatório que eles podem ver para ver estatísticas e / ou qualquer bug associado #. Por exemplo. fornecer um número de série no momento da apresentação que eles podem carregar através de uma página da web mais tarde.
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 qualquer feedback sobre o relatório.
Estes não são relatórios de bugs.
Nossa intenção é reduzir o tempo que os desenvolvedores demoram para encontrar os problemas mais prementes, 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 link .
Coletar as informações necessárias rapidamente e sem envolver um longo ciclo de feedback com os usuários que estão enfrentando o problema é abordado em foundations-q-bucketing-improvements . 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 ainda não tiver sido fornecido, altero uma configuração no link e a próxima pessoa que apresentar o erro adiciona-o automaticamente aos dados que estão enviando.
Obter correções para os usuários rapidamente é abordado em fundações-q-atualizações- de relatórios de falhas . Quando os usuários enviam um relatório de erros e esse erro já foi corrigido e liberado, 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 experimentar.
OE como um desenvolvedor entra no jogo? Ir para o link apenas fornece uma mensagem de erro "Tipo de Conteúdo Incorreto".
link 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 que outras pessoas se envolvessem. Eu sou atualmente o único hacker em tempo integral.
Existem quatro partes no sistema.
- Suporte , que fornece a interface de usuário da área de trabalho.
- Whoopsie , que recebe relatórios (e core dumps) criados pelo Apport e os coloca no servidor do rastreador de erros, Daisy.
- Daisy , que coleta relatórios do Whoopsie e os processa. Este é o coração do serviço. É o que transforma os arquivos principais em relatórios rastreados e gera as estatísticas que você vê no link .
- Erros , que é um site baseado em Django que fornece uma visão humana legível dos dados e uma API RESTful para trabalhar com ele. / li>
Há um conjunto de scripts um pouco desatualizado no diretório setup / em lp: daisy que deve fornecer alguma ideia de como as peças se encaixam. Eu tenho trabalhado em encantos de juju para substituir isso. O objetivo é um único comando para implantar toda a infraestrutura na nuvem para testes e desenvolvimento.
Você pode encontrar meu endereço de e-mail no Launchpad se tiver mais dúvidas sobre desenvolvimento.
Mais informações: