Come vengono classificati i bug e qual è il ciclo di vita di un bug?

Come vengono classificati i bug in Ubuntu e qual è il ciclo di vita di un bug?

Inoltre, "Cosa significa" Stato "di ciascun bug e come viene determinato"

Tutti i bug in Ubuntu hanno cicli di vita. Inoltre, ciascuno di essi ha uno "Status" che aiuta a spiegare qual è il suo ciclo di vita. In Ubuntu, ogni bug man mano che il suo ciclo di vita continua ha diversi stati impostati su di esso.

Mentre questo è tutto documentato in modo straordinario nella Guida al triage , io (per ora, dato che non ho molto tempo per scrivere questo processo in testo, ma in seguito) pubblicherò i "Diagrammi di flusso" forniti da la Squadra bug per questo ( clicca qui per la fonte dei diagrammi di flusso ). Ogni stato (nel frattempo) può essere spiegato nella documentazione BugSquad / Status BugSquad , ma li ho documentati anche qui.

(Nota che le informazioni seguenti potrebbero non essere aggiornate con la documentazione sul wiki, per informazioni più aggiornate, fai riferimento al wiki.)

Di seguito è una descrizione di ciascun indicatore di stato su un bug:

• Nuovo:
  • I bug vengono inviati con questo stato
  • A volte mancano informazioni e
  • Tutti dovrebbero essere non trattati
• incompleta:
  • Se devi porre domande al giornalista, imposta il bug su Incompleto
  • Chiedi al mittente di fornire tutte le informazioni necessarie in un commento e assicurati di iscriverti alla segnalazione dei bug in modo da ricevere eventuali aggiornamenti via e-mail.
  • Ad alcuni bug non viene mai risposto dal mittente (chiamato anche "poster originale" o "OP"). Questi bug scadranno automaticamente da Launchpad tra 60 giorni, conteggiati dal giorno in cui sono stati impostati incompleti. Non è necessario agire su di essi (e, in realtà, la modifica del bug riavvierà il periodo di scadenza). Si noti che questo vale per il progetto Ubuntu (vale a dire, quelle attività di bug che hanno "(Ubuntu)" nel loro nome). Altri progetti possono avere o meno impostare automaticamente la scadenza dei bug incompleta.
  • Se qualcuno, incluso te, commenta il bug, l'orologio di scadenza di 60 giorni viene ripristinato.
• Opinione:
  • Lo stato di "opinione" significa che esiste una differenza di opinione su un particolare bug e le persone sono libere di continuare la discussione, ma i responsabili del progetto o del pacchetto devono passare ad altri lavori e stanno considerando il problema chiuso. L'idea è che i bug possono essere contrassegnati come chiusi, quindi gli sviluppatori non stanno perdendo tempo su di essi, ma la discussione può ancora essere in corso.
  • Questa "opinione" di stato è considerata un esperimento e sarà attentamente monitorata.
• Non valido:
  • Questo stato deve essere utilizzato quando la segnalazione di bug non contiene informazioni adeguate per determinare se si tratta di un bug anche se è stato risolto per il giornalista
  • Questo dovrebbe essere usato anche se il problema segnalato non è affatto un bug, ma ad esempio un errore dell'utente
  • Dovrebbe essere usato in modo conservativo poiché i bug contrassegnati come Invalid non vengono più visualizzati nelle ricerche predefinite
  • Assicurati di controllare tre volte un bug prima di invalidarlo
• Scaduto:
  • Questo stato è simile a Invalid, ma è specifico per i bug che sono stati incompleti per troppo tempo. (Vedi sopra.)
  • Questo stato può essere impostato solo tramite launchpadlib o l'interfaccia e-mail.
  • Come i bug non validi, i bug scaduti non vengono visualizzati nelle ricerche predefinite.
• Confermato :
  • Un altro giornalista ha riscontrato lo stesso errore, questo può presentarsi sotto forma di un errore duplicato o di un commento sull'errore
  • I bug confermati richiedono la conferma di qualcuno diverso dal reporter originale
  • Questo aiuta a garantire che il bug sia applicabile a Ubuntu in generale e non un problema con il sistema del reporter, quindi ...
  • Si prega di non confermare i propri bug!
• triaged:
  • Un membro di UbuntuBugControl ritiene che il rapporto descriva un vero bug in modo sufficientemente dettagliato che uno sviluppatore potrebbe iniziare a lavorare su una correzione. (vedi anche il suggerimento sotto)
  • Usalo quando sei sicuro che debba essere esaminato da uno sviluppatore e abbia abbastanza informazioni
  • Sebbene non sia un requisito, lo stato dell'attività di Ubuntu di un bug verrà tracciato prima che si verifichi qualsiasi inoltro a monte
  • Con bug su Linux Triaged significa che il bug è stato testato con il kernel mainline upstream
• In corso:
  • Se stai lavorando per correggere un bug, impostalo su In corso in modo che le persone sappiano cosa sta succedendo
  • I bug in corso dovrebbero essere assegnati alla persona che ci lavora
• Correzione impegnata:
  • Attività bug di Ubuntu: le modifiche sono in sospeso e saranno presto caricate (è ciò che PENDINGUPLOAD era in Bugzilla)
  • Fix Committed viene utilizzato anche quando esiste un pacchetto aggiornato in un repository proposto, ovvero proposto da hardy
  • Fix Committed non deve essere usato quando una patch è collegata a un bug
  • Attività di bug a monte: la correzione è in CVS / SVN / bzr o impegnata in qualche posto
• Correzione rilasciata:
  • Attività bug di Ubuntu: una correzione è stata caricata in un repository ufficiale di Ubuntu
  • NB Questo non include -proposto cioè resistente proposto
  • Non esitare ad aggiungere un log delle modifiche come commento, così le persone sanno in quale versione del pacchetto è stato corretto un bug
  • Se un bug è stato corretto nella versione di sviluppo corrente, è Fix Release. Se il bug deve anche essere corretto in una versione stabile, utilizzare il collegamento "Destinazione per rilasciare" per nominarlo per quella versione.
  • Attività bug a monte: è stato annunciato un rilascio tarball ed è pubblicamente disponibile
• Non risolto:
  • Questo stato viene talvolta utilizzato quando la correzione di bug è troppo controversa
  • Viene spesso utilizzato per i bug con un target di rilascio che non verrà risolto in quel particolare rilascio ma potrebbe essere corretto in seguito
  • Può anche essere utilizzato per richieste di funzionalità che gli sviluppatori non vogliono implementare

(la formattazione differirà leggermente dalla wiki poiché la formattazione qui è più limitata)

Domande e risposte correlate:
Valore di importanza: come vengono decisi i valori di importanza dei bug di Ubuntu