Todos os bugs no Ubuntu têm ciclos de vida. Além disso, cada um deles tem um "Status" que ajuda a explicar o seu ciclo de vida. No Ubuntu, cada bug, enquanto seu ciclo de vida continua, possui vários status definidos.
Enquanto isso tudo é documentado em detalhes extraordinários no Guia de Triagem , eu irei (por enquanto, como eu não tenho uma quantidade enorme de tempo para escrever este processo em texto, mas eu irei mais tarde) postar os "Fluxogramas" que são fornecidos pelo Bug Squad para isso ( clique aqui para a fonte dos fluxogramas ). Cada status (no tempo médio) pode ser explicado na Bugs / Status BugSquad Documentation , 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).
Segue-se uma descrição de cada indicador de status em um bug:
-
Novo:
- Os bugs são enviados com este status
- Às vezes, eles não têm informações e
- Todos devem ser iniciados
-
Incompleto:
- Se você tiver que fazer perguntas ao repórter, defina o bug como Incompleto
- Peça ao apresentador para fornecer qualquer informação necessária em um comentário, e certifique-se de assinar o relatório de bug para receber atualizações do bug via e-mail.
- Alguns bugs nunca são respondidos pelo apresentador (também chamado de "original poster" ou "OP"). Esses bugs serão automaticamente expirados 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, a alteração do bug reiniciará o período de expiração). Observe que isso se aplica ao projeto Ubuntu (ou seja, aquelas tarefas de bug que possuem "(Ubuntu)" em seu nome). Outros projetos podem, ou não, ter um conjunto de expiração de bug incompleto automático.
- Se alguém, incluindo você, comentar 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 torno de um bug em particular e as pessoas estão livres para continuar a discussão, mas os mantenedores do projeto ou pacote precisam mudar para outro trabalho e estão considerando a questão encerrada. A ideia é que os erros 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, 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
- Deve ser usado de forma conservadora, pois os bugs marcados como Invalid não são mais exibidos nas pesquisas padrão
- Verifique três vezes um bug antes de invalidá-lo
-
Expirado:
- Esse status é semelhante a Inválido, mas destina-se especificamente a bugs incompletos por tempo demais. (Veja acima.)
- Esse status só pode ser definido usando o launchpadlib ou a interface de e-mail.
- Como bugs inválidos, os bugs expirados não aparecem nas pesquisas padrão.
-
Confirmado :
- Outro repórter teve o mesmo erro, isso pode vir na forma de um bug duplicado ou um comentário de bug
- Os 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 um problema com o sistema do relator, portanto ...
- Por favor, não confirme seus próprios erros!
-
Triagem:
- 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 isso quando tiver certeza de que ele deve ser analisado por um desenvolvedor e ter informações suficientes
- Embora não seja um requisito, o status da tarefa do bug de um bug será Triaged antes que qualquer encaminhamento upstream ocorra
- Com bugs sobre o linux Triaged significa que o bug foi testado com o kernel mainstream upstream
-
Em andamento:
- Se você estiver trabalhando na correção de um bug, defina-o como Em andamento para que as pessoas saibam o que está acontecendo
- Em andamento, os bugs devem ser atribuídos à pessoa que trabalha neles
-
Correção confirmada:
- Tarefa do bug do Ubuntu: as alterações estão pendentes e serão enviadas em breve (é o que PENDINGUPLOAD estava no Bugzilla)
- O Fix Committed também é usado quando existe um pacote atualizado em um repositório proposto, por exemplo, hardy-proposed
- O Fix Committed não é usado quando um patch é anexado a um bug
- Tarefa de bug upstream: a correção está em CVS / SVN / bzr ou confirmada em algum lugar
-
Correção liberada:
- Tarefa do bug do Ubuntu: uma correção foi enviada para um repositório oficial do Ubuntu
- N.B. Isto não inclui -proposto, ou seja, hardy-proposto
- Por favor, não hesite em adicionar um changelog como 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 uma versão estável, use o link "Destino para liberar" para nomeá-lo para essa versão.
- Tarefa de bug upstream: um tarball de lançamento foi anunciado e está publicamente disponível
-
não corrige:
- Às vezes, esse status é usado quando a correção do bug é muito controversa
- É mais comumente usado para bugs com um destino de lançamento que não será corrigido nessa versão específica, mas pode 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 do wiki, pois a formatação aqui é mais limitado)
Perguntas e respostas relacionadas:
Importância Valor: Como os valores de importância dos bugs do Ubuntu são decididos