Le migliori pratiche per contrassegnare un bug come risolto in Bugzilla?

Question

Le migliori pratiche per contrassegnare un bug come risolto in Bugzilla?

#1 da (2 voti)

5

Mi chiedo quale sia il modo migliore per gestire la situazione di contrassegnare un bug come risolto e fornire una versione del componente / prodotto in cui è possibile trovare questa correzione.

Contesto

Per un progetto su cui sto lavorando, stiamo utilizzando Bugzilla per il monitoraggio dei problemi, e abbiamo il seguente:

Un prodotto "A" con un numero di versione come vA.B.C.D,

Questo prodotto "A" ha i seguenti componenti:

Componente "C1" con un numero di versione come vA.B.C.D,
Componente "C2" con un numero di versione come vA.B.C.D,
Componente "C3" con un numero di versione come vA.B.C.D.

Internamente teniamo traccia di quali versioni del componente sono state utilizzate per generare il prodotto A versione vA.B.C.D.

Esempio: prodotto "A" versione v1.0.0.0 è stato prodotto dal componente "C1" v1.0.0.3, componente "C2" v1.3.0.0 e componente "C3" v2.1.3.5.

E la versione "A" del prodotto v1.0.1.0 è stata prodotta dal componente "C1" v1.0.0.4, dal componente "C2" v1.3.0.0 e dal componente "C3" v2.1.3.5.

Ogni componente è un repository SVN.

La persona responsabile della generazione del prodotto "A" ha accesso solo alla cartella dei tag dei componenti diversi in SVN e non al trunk di ciascun repository di componenti.

problema

Ora il problema è il seguente, quando viene rilevato un bug nel prodotto "A" e che il bug è correlato al componente "C1", viene scelta la versione del prodotto "A" (ad esempio v1.0.0.0 ), e questa versione consente allo sviluppatore di sapere quale versione del componente "C1" ha il bug (qui sarà v1.0.0.3). Viene creato un rapporto bug.

Ora diciamo che lo sviluppatore responsabile del componente "C1" corregge il bug, quindi quando il bug sembra essere corretto e dopo alcuni test e convalida, lo sviluppatore genera un nuovo tag per il componente "C1", con la versione v1 .0.0.4. Al momento, lo sviluppatore del componente "C1" deve aggiornare il bug report, ma quale è il migliore da fare:

Segna il bug come risolto / risolto e aggiungi un commento che dice "Questo bug è stato corretto nei tag v1.0.0.4 del componente C1"?
Conserva il bug come assegnato, aggiungi un commento che dice "Questo bug è stato corretto nei tag v1.0.0.4 del componente C1, aggiorna questo stato di bug a risolto per la prossima versione del prodotto che verrà generata con il versione più recente (v1.0.0.4 di C1) "?
Un altro modo possibile per affrontare questo problema.

In questo momento il problema è che quando un componente del prodotto CX è fisso, non è sicuro in quale versione futura del prodotto A sarà incluso, quindi non è possibile dire in quale versione del prodotto sarà risolto, ma è possibile dire in quale versione del componente CX è stato risolto. Quindi, quando è necessario contrassegnare un bug come risolto, quando la versione del prodotto A include la versione fissa di CX, o solo quando il componente CX è stato riparato?

Grazie per i tuoi commenti e idee personali su questo!

development-process issue-tracking versioning bug-report

posta Vincent B. 05.07.2012 - 04:18

fonte

1 risposta

Leggi altre domande sui tag development-process issue-tracking versioning bug-report

Strumento di visualizzazione e manutenzione dei dati basato su GIS Crea auto-suggerimento di editor di codice (come IntelliSense)

score 2 · Accepted Answer

Correzione del componente e integrazione del componente fisso nel prodotto sono due attività diverse.

Potrebbero esserci molti modi per gestirli, ma indipendentemente da ciò che si sceglie, è meglio fare attenzione che la differenza di cui sopra sia facile da capire da parte di coloro che usano bug tracker.

La soluzione semplice potrebbe essere semplicemente utilizzare bug separati per queste attività separate.

Ticket 1234. Fix < problema specifico > nel componente "C1".
Ticket 1235. Correzione integrale di < ticket 1234 > nel prodotto "A".

In questo modo, si ottiene una descrizione chiara di ciò che dovrebbe essere fatto, è possibile assegnare, assegnare priorità e pianificare i ticket in modo indipendente, tenendo conto del fatto che integration può iniziare dopo che la correzione del componente è stata completata .

Inoltre, in questo modo è possibile gestire più "dipendenze multi-livello", come prima è necessario correggere un componente della libreria X, quindi integrare e regolare il componente C1 e solo successivamente integrare nel prodotto A.

That is a good idea indeed, however it means more process and overhead for "one" bug. Providing a specific format for the bug summary could make the management simpler ([INT. FIX] "summary of the bug previously reported")...

Per completezza nota che anche l'approccio sopra ("un bug, due fasi") può essere praticabile, specialmente se la maggior parte dei tuoi bug si integra in quel modo (versione particolare di component - > product ).

L'ho visto fatto in almeno due diversi progetti e ha funzionato bene. In genere ci voleva del tempo prima che i nuovi arrivati del team si abituassero al flusso di lavoro e in caso di integrazione più complicata, abbiamo usato bug separati per tracciarlo, ma questo è un aspetto secondario.

^{Oltre allo stato aggiuntivo ( INT.FIX nella citazione precedente), i punti che vale la pena considerare per il "ciclo di vita dei bug a due fasi" sono campi dedicati per versioni di componenti e prodotti, nonché per ingegneri responsabili. Questi non sono però una questione di vita o di morte - se non ci sono campi dedicati, i dati rilevanti possono essere estratti dalla cronologia delle modifiche ai bug o inseriti nei commenti.}

E, dato che hai menzionato overhead , la mia ferma convinzione è che qualsiasi overhead sostanziale che potrebbe essere correlato al bug tracking significa che qualcosa non va nel bug tracker o nella gestione del progetto, o entrambi.