QA/Bugzilla/Fields/Status/RESOLVED

    From The Document Foundation Wiki
    < QA‎ | Bugzilla‎ | Fields‎ | Status
    This page is a translated version of the page QA/Bugzilla/Fields/Status/RESOLVED and the translation is 100% complete.

    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
    
    Note pin.svg

    Nota:
    Prima di richiedere l'aiuto di un altro contributore, siete pregati di provare ad eseguire da soli il lavoro di Bibisect per individuare quale commit ha corretto un bug!

    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