QA/Bugzilla/Fields/Status/RESOLVED
TDF LibreOffice Document Liberation Project Blog comunitari Weblate Nextcloud Redmine Ask LibreOffice Donazione
Scopo di questa pagina
Questa pagina riguarda lo stato RESOLVED del campo Status in Bugzilla. È dedicato a spiegare e chiarire lo scopo dei molteplici stati RESOLVED, nonché a descrivere i passaggi che il QA può/prenderà nell'affrontare i bug RESOLVED.
Il significato di RESOLVED
Ci sono diversi sottostati per RESOLVED:
FIXED
Questo bug è stato corretto da un particolare aggiornamento. Dovrebbero esserci uno o più tag target:<LO version X.y.z> nella lavagna, ognuno dei quali indica una versione/ramo di LibreOffice in cui sarà incluso questo aggiornamento.
Esempi:
- 'Blue 1' è impostato sullo stesso colore di 'Sky Blue 1' - tdf#86511
- Lavagna: target:4.5.0 target:4.4.0.0.beta2
Se non sapete quale aggiornamento ha corretto un bug -- usate invece RESOLVED WORKSFORME.
INVALID
Qualcosa in questa segnalazione di bug non è valida o non viene calcolata. Ad esempio, se qualcuno invia un rapporto come questo, lo risolveremo come INVALID:
Sono un tricheco Sono un tricheco e penso che tutti dovrebbero saperlo. I passaggi di riproduzione stanno mangiando pesce.
In precedenza, usavamo lo stato RESOLVED INVALID come un catch-all per varie famiglie di bug, inclusi bug che erano rimasti nello stato NEEDINFO per oltre sei mesi e che volevamo mettere da parte. Ora abbiamo lo stato #INSUFFICIENTDATA che si adatta meglio a quelle categorie di bug.
WONTFIX
Questo potrebbe essere un bug, ma non abbiamo intenzione di risolverlo per qualche motivo (che di solito è dettagliato in un commento quando il bug viene risolto come WONTFIX). Esempi inclusi:
- Un bug che non riguarda nessun utente reale
DUPLICATE
Questo bug è un duplicato di un altro bug già presente nel sistema
Siete pregati di non usare questo valore se la stessa persona ha segnalato due volte lo stesso identico problema, in quanto creerebbe distorsioni alle misurazioni statistiche. Piuttosto, chiudete i duplicati come "INVALID".
WORKSFORME
In stenografia, WORKSFORME è scritto "WFM".
Qualcuno in QA ha testato questo bug utilizzando i passaggi forniti e/o i documenti di prova è in grado di riprodurlo in una vecchia versione, ma non nella versione corrente.
Stesso ambiente di riproduzione
Se avete lo stesso ambiente del segnalatore di bug (ad esempio stesso sistema operativo, stessa versione di LibreOffice), ci sentiamo molto più sicuri nel contrassegnare un bug come WFM. Se non avete lo stesso ambiente (ad esempio la stessa versione LO, ma sono su Windows e voi siete su macOS), verificate se qualcuno nel canale QA/IRC ha lo stesso ambiente e può ricontrollare il vostro lavoro.
La decisione di chiudere un bug come WFM senza un riscontro di chi lo ha segnalato originariamente o di chi lo ha confermato viene presa valutando caso per caso. Normalmente è opportuno lasciare agli altri un po' di tempo per eseguire delle prove. Il tempo passato dalla segnalazione e della sua ultima conferma deve essere preso in considerazione.
Il motivo per cui un bug è WFM nello stesso ambiente di riproduzione potrebbe essere che il profilo utente era corrotto. Assicurati di chiedere al segnalatore di bug di testare LibreOffice in modalità provvisoria e vedere se il ripristino del profilo utente (dopo backup) risolve il problema.
Risolto in una versione più recente
Se un bug sparisce in master ma non in una delle branch delle versioni attualmente mantenute (vedere il Piano di rilascio), il bug viene considerato risolto e quindi sarà contrassegnato come WFM.
Esempi:
- tdf#74300 - Base:Database "La casella "Posizione e dimensione" non si disegna, ma mostra invece cosa c'è sotto
- tdf#79289 - FILEOPEN: Le forme DOCX si trasformano in cornici e riempiono lo sfondo non mantenuto
Se sappiamo quale commit ha risolto il problema, va bene chiedere all'autore (sviluppatore) se è possibile eseguire il backport della correzione. Se non sappiamo quale commit ha corretto il bug, dobbiamo scoprirlo. Possiamo aggiungere la parola chiave bibisectRequest ed aggiungere alla lavagna backportRequest:<active branch>. Questo indicherà che dobbiamo fare un "inverso" bibisect (per capire quando il bug è stato risolto, invece di quando il bug è stato introdotto).
Esempio di lavagna:
backportRequest:4.2 backportRequest:4.3
Una volta che un bug è stato corretto su tutti i rami attivi di LibreOffice (tramite backport o rami che raggiungono EOL), o se uno sviluppatore nega la richiesta di backport (commentando la segnalazione su gerrit), il tag backportRequest:Xy può essere rimosso e sostituito con backportDenied:X.y.
Se il commit che ha corretto il bug è stato identificato, la segnalazione può essere indicata risolta come "FIXED", o "DUPLICATE" se quel commit chiude una altra segnalazione che sostanzialmente descriveva lo stesso problema.
MOVED
Usato, quando Bugzilla non è il posto giusto per il report.
NOTABUG
Il "problema" descritto dal segnalatore di bug fa parte del comportamento previsto di LibreOffice. Esempi:
- Una funzione funziona come previsto tdf#85643
- Errori di arrotondamento che si verificano a causa dell'aritmetica in virgola mobile su valori interi - tdf#86174
NOTOURBUG
C'è un problema qui, ma non è un problema in LibreOffice.
Esempi:
- LibreOffice legge/scrive correttamente il formato del file, ma alcuni altri software no tdf#81854
- Excel ha un bug di data di vecchia data che non può risolvere a causa di problemi di compatibilità con le versioni precedenti tdf#86996
- C'è una limitazione con il software al di fuori del nostro controllo tdf#85652 redmine#845
INSUFFICIENTDATA
Come richiesto in una chiamata ESC, questo stato è stato aggiunto per comprendere i bug che sono stati abbandonati o non dispongono di dati sufficienti per procedere con il triage e la correzione dei bug.
Esempi:
- L'utente non è disposto a condividere un documento privato con nessuno e non possiamo riprodurlo
- Il bug rimane nello stato NEEDINFO per più di 6 mesi
Ragionamento:
- Al momento contrassegniamo i bug abbandonati come RESOLVED WORKSFORME, o RESOLVED INVALID, ma un valore di stato aggiuntivo potrebbe aiutarci a essere più precisi nell'indicare il motivo per cui un bug è stato accantonato.
- Uno stato aggiuntivo ci permetterebbe di essere più diplomatici con gli utenti difficili ed evitare i potenziali negativi di "INVALID" o "WORKS FOR ME" su tali bug
Denominazione:
- Sono stati proposti alcuni nomi per questo stato:
- ABANDONED
- INSUFFICIENT_DATA (Red Hat bugzilla)
- EXPIRED (Launchpad)
- Il trattino basso tra le due parole "INSUFFICIENT_DATA" è stato rimosso per corrispondere allo stile degli stati RESOLUTION esistenti in Bugzilla