Todos os erros no Ubuntu têm ciclos de vida. Além disso, cada um deles tem um "Status" que ajuda a explicar qual é o seu ciclo de vida. No Ubuntu, cada bug à medida que seu ciclo de vida continua tem vários status definidos.
Embora tudo isso esteja documentado em detalhes extraordinários no Guia de Triagem , (por enquanto, não tenho muito tempo para escrever esse processo em texto, mas posteriormente) publicarei os "Fluxogramas" fornecidos por o Bug Squad para isso ( clique aqui para obter a fonte dos fluxogramas ). Cada status (nesse meio tempo) pode ser explicado na documentação Bugs / Status BugSquad , mas eu os documentei aqui também.
(Observe que as informações abaixo podem estar desatualizadas com a documentação no wiki, você deve consultar o wiki para obter as informações mais atualizadas.)
A seguir, é apresentada uma descrição de cada indicador de status de um bug:
- Novo:
- Os erros são enviados com esse status
- Eles às vezes carecem de informações e
- Todos eles devem ser sem triagem
- Incompleto:
- Se você precisar fazer perguntas ao repórter, defina o bug como Incompleto
- Peça ao remetente que forneça todas as informações necessárias em um comentário e certifique-se de se inscrever no relatório de erros para obter atualizações por e-mail.
- Alguns erros nunca são respondidos pelo remetente (também chamado de "pôster original" ou "OP"). Esses erros serão expirados automaticamente pelo Launchpad em 60 dias, contados a partir do dia em que foi definido como incompleto. Não há necessidade de agir sobre eles (e, na verdade, alterar o bug reiniciará o período de validade). Observe que isso se aplica ao projeto Ubuntu (ou seja, às tarefas de erro que possuem "(Ubuntu)" em seu nome). Outros projetos podem ou não ter um conjunto de expiração automática de erros incompleta.
- Se alguém, incluindo você, comentar sobre o bug, o relógio de expiração de 60 dias será redefinido.
- Opinião:
- O status 'opinião' significa que há uma diferença de opinião em relação a um bug específico e as pessoas são livres para continuar a discussão, mas os mantenedores do projeto ou pacote precisam passar para outro trabalho e estão considerando o problema encerrado. A idéia é que os bugs possam ser marcados como fechados, para que os desenvolvedores não estejam perdendo tempo com eles, mas a discussão ainda pode estar em andamento.
- Esse status 'opinião' é considerado um experimento e será monitorado de perto.
- Inválido:
- Esse status deve ser usado quando o relatório de bug não contém informações adequadas para determinar se é um bug ou não, mesmo que seja resolvido para o repórter
- Isso também deve ser usado se o problema relatado não for um bug, mas, por exemplo, erro do usuário
- Ele deve ser usado de maneira conservadora, pois os erros marcados como inválidos não são mais exibidos nas pesquisas padrão
- Certifique-se de verificar três vezes um bug antes de invalidá-lo
- Expirado:
- Esse status é semelhante a Inválido, mas destina-se especificamente a bugs incompletos por muito tempo. (Veja acima.)
- Esse status pode ser configurado apenas usando o launchpadlib ou a interface de email.
- Como erros inválidos, erros expirados não aparecem nas pesquisas padrão.
- Confirmado :
- Outro repórter experimentou o mesmo bug, isso pode vir na forma de um bug duplicado ou um comentário de bug
- Bugs confirmados exigem confirmação de alguém que não seja o repórter original
- Isso ajuda a garantir que o bug seja aplicável ao Ubuntu em geral, e não seja um problema com o sistema do repórter, portanto ...
- Por favor, não confirme seus próprios erros!
- Triaged:
- Um membro do UbuntuBugControl acredita que o relatório descreve um bug genuíno com detalhes suficientes para que um desenvolvedor possa começar a trabalhar em uma correção. (veja também a dica abaixo)
- Use-o quando tiver certeza de que deve ser analisado por um desenvolvedor e tiver informações suficientes
- Embora não seja um requisito, o status da tarefa Ubuntu de um bug será triado antes que ocorra o encaminhamento upstream
- Com bugs sobre linux Triaged significa que o bug foi testado com o kernel da linha principal upstream
- Em progresso:
- Se você estiver trabalhando para corrigir um bug, defina-o como Em andamento para que as pessoas saibam o que está acontecendo
- Os bugs em andamento devem ser atribuídos à pessoa que trabalha neles
- Correção confirmada:
- Tarefa de bug do Ubuntu: as alterações estão pendentes e serão carregadas em breve (é o que PENDINGUPLOAD estava no Bugzilla)
- Correção confirmada também é usada quando existe um pacote atualizado em um repositório proposto
- Correção confirmada não deve ser usada quando um patch é anexado a um bug
- Tarefa de bug upstream: a correção está no CVS / SVN / bzr ou confirmada em algum lugar
- Correção lançada:
- Tarefa de bug do Ubuntu: uma correção foi carregada em um repositório oficial do Ubuntu
- NB: Isso não inclui o proposto, ou seja, o proposto
- Por favor, não hesite em adicionar um changelog como um comentário, para que as pessoas saibam em qual versão do pacote um bug foi corrigido
- Se um bug for corrigido no release de desenvolvimento atual, ele será corrigido. Se o bug também precisar ser corrigido em um release estável, use o link "Target to release" para indicá-lo para esse release.
- Tarefa de bug upstream: um tarball de lançamento foi anunciado e está disponível ao público
- Não será corrigido:
- Às vezes, esse status é usado quando a correção de bug é muito controversa
- É mais frequentemente usado para erros com um destino de release que não será corrigido nesse release em particular, mas poderá ser corrigido posteriormente
- Também pode ser usado para solicitações de recursos que os desenvolvedores não desejam implementar
(a formatação será um pouco diferente da wiki, pois a formatação aqui é mais limitada)
Perguntas e respostas relacionadas:
Valor de importância: como são decididos os valores de importância dos bugs do Ubuntu