Linee guida per il rintracciamento di errori o bug¶

Questo documento descrive la procedura standard per la gestione di nuovi problemi all’interno del progetto UBports. Da non conforndersi con la guida per la segnalazione dei bug.

Dove vengono tracciati i bug?¶

Since our quality assurance depends heavily on the community, we try to track issues where the user would expect them, instead of separated by repository. This means, that issues of almost all components that are distributed as with the system-image are tracked in the Ubuntu Touch tracker. An exception of this are click-apps that can be updated independently through the OpenStore.

Molti degli ambienti tengono traccia dei problemi a livello locale. Se non sei sicuro se un repository usa il proprio sistema di tracciamento o no, consulta il file README.md . I repository che non tengono traccia dei problemi a livello locale, hanno il loro sistema di tracciamento bachi disattivato.

Questa pagina riguarda principalmente il sistema di tracciamento di Ubuntu Touch, ma la maggior parte dei princìpi si applicano pure ad altri progetti.

Nota

La praticità batte la purezza! E” possibile che vi siano eccezioni a quanto finora scritto. Qualora ciò accadesse, queste devono essere documentate nel file README.md di ciascun progetto.

Progetti su GitHub¶

To increase transparency and communication, GitHub projects (Kanban-Boards) are used wherever practical. In case of github.com/ubports/ubuntu-touch, a single project is used for all issues. Projects support filtering by labels, so that only issues that belong to a specific team or affect a specific device can be viewed.

Queste sono le colonne standard:

None (awaiting triage): The issue has been approved by a member of the QA team and is awaiting review from the responsible development team. if the issue is a bug, instructions to reproduce are included in the issue description. if the issue is a feature request, it has passed a primary sanity check by the qa-team but has not yet been accepted by the responsible development-team.
Accepted: The issue has been accepted by the responsible development-team. If the issue is a bugreport, the team has decided that it should be fixable and accepts the responsibility. If the issue is a feature request, the team thinks it should be implemented as described.
In fase di sviluppo: una patch è in fase di sviluppo. Normalmente significa che è stato assegnato a uno sviluppatore.
Quality Assurance: The patch is completed and has passed initial testing. The QA team will now review it and provide feedback. If problems are found, the issue is moved back to «Accepted».
Release Candidate: La pezza ha passato il test di QA e è pronta per essere messa in produzione. Nel caso di pacchetti deb che sono inclusi nell’immagine di sistema, la pezza si includerà nella prossima attualizzazione over-the-air o nel canale RC e, se tutto va bene, nel prossimo rilascio del canale stabile.
None (removed from the project): If the issue is open and labeled «help wanted», community contributions are required to resolve the issue. If it’s closed, that means that either a patch has been released on the stable channel (a comment on the issue should link to the patch) or the issue has been rejected (labeled «wontfix»).

Etichette¶

Tutti i problemi - pure quelli chiusi - dovrebbero essere etichettati per permettere l’uso dei filtri globali di GitHub. Ad esempio, questi sono tutti i problemi considerati “migliorie” in @ubports. Consulta le pagine di aiuto di GitHub per ulteriori informazioni nulle ricerche e i filtri.

Ecco una lista di etichette che sono normalmente utilizzate da tutti i repository.

in attesa di conferma: Il bug deve essere confermato e/o gli utenti interessati devono integrarne la documentazione
bug: This issue is a confirmed bug. If it’s reproducible, reproduction steps are described.
opinione: Questo problema ha bisogno di essere approfondito ulteriormente.
miglioria: Questo problema è una richiesta di una nuova funzionalità.
domanda: Questo problema è una richiesta di supporto o una domanda generale.
non valido: Questo problema non può essere confermato o è stato inserito nel sistema di tracciamento sbagliato.
duplicato: Questo problema è stato già riportato altrove. Inserire il collegamento e chiuderlo.
necessita aiuto: Questo problema è pronto per essere preso in carica da uno sviluppatore della comunità.
good first issue: The report contains instructions or hints required to fix it. It is an excellent place for someone new to learn about the project by fixing a real issue.
wontfix: Non ha senso risolvere questo problema, dal momento che si risolverà da solo, o richiederà molto lavoro per la sua soluzione, o non è possibile risolverlo o un componente affettato sarà cambiato presto.

Ulteriori speciali etichette saranno presto definite. Per esempio, eccone alcune usate dal sistema di tracciamento di Ubuntu Touch:

critico (sviluppo): Questo problema critico, che può succedere solo nel canale devel, blocca il rilascio della prossima immagine rc.
critico (rc): Qesto problema critico, che appare nei canali devel e rc, blocca il rilascio della prossima versione stabile. Normalmente, i problemi che non possono essere semplicemente spostato a un prossimo rilascio o che fanno ritardare il rilascio sono etichettati in questo modo.
** dispositivo: [NOME IN CODICE DEL DISPOSITIVO]**: Questo problema affligge solamente uno o più dispositivi specifici.
gruppo [NOME DEL GRUPPO]: Questo problema ricade sotto la disponibilità di un gruppo di lavoro specifico (hal, middleware, UI).

Nota

Se un repository che traccia problematiche locali definisce le proprie etichette, le si deve documentare nel README.md.

Obiettivi stabiliti¶

Gli obiettivi intermedi sono usati solamente per i rilasci delle versioni stabili OTA. In generale, queste tappe sono create per le OTA in lavorazione e il successivo rilascio OTA. L’ETA è stato stabilito, una volta che il lavoro per il rilascio inizia (per 6 settimane dopo la data di avvio), ma può essere adattato in seguito. Guarda la schedulazione del rilascio per ulteriori informazioni.

Assegnatari¶

Per rendere trasparente chi sta lavorando su un problema, gli si deve assegnare uno sviluppatore. Ciò permette l’uso dei filtri globali di GitHub, a modo di lista di cose da farsi. Ad esempio, questo è tutto ciò che è stato assegnato a mariogrip in @ubports.

Agli sviluppatori è richiesto di mantenere delle liste ridotte e di mantenere aggiornato lo stato dei problemi.

Esempi¶

Ciclo di vita dei bachi¶

Nota

Lo stesso principio si applica alle richieste di nuove funzionalità. L’unica differenza è, invece dell’etichetta baco, che gli viene assegnata quella di miglioria. L’etichetta di in attesa di conferma non si può usare per le richieste di nuove funzionalità.

Un Utente può riportare un nuovo bag attraverso il modulo di creazione di nuovi problemi.
Il QA-Team aggiunge l’etichetta needs confirmation (richiesta conferma) e cerca di lavorare con l’utente per la conferma del bug e aggiungere al report le informazioni eventualmente mancanti. Quando il report è completo, verrà aggiunta, accanto al problema, l’etichetta team-label (etichetta del team) e il problema verrà posto nello stato di awaiting-triage-list (lista di attesa) all’interno del progetto, in attesa che bug sia confermato e che l’etichetta venga trasformata in bug.
Il Gruppo interessato farà il test (triage) del problema e lo rigetterà (etichettandolo wontfix, lo chiuderà e lo rimuoverà dal progetto) o lo accettarà. Il gruppo decide se ne troverà una soluzione in casa (spostandolo in «Accettato», «Accepted», e assegnandolo a un membro del gruppo) oppure aspetterà che uno sviluppatore della comunità lo prenda in carico (etichettandolo necessita aiuto, help wanted, rimuovendolo dal tabellone di progetto e fornendone suggerimenti su come risolverlo e dettagli ulteriori su come implementarne la soluzione, qualora fosse necessario). Per problemi non critici ci sono soluzioni triviali, potendolo etichettare pure come buono per primi problemi (good first issue).
Once a developer is assigned and starts working on the issue, it is moved to «In Development». As soon as they have something to show for, the issue is closed and automatically moved to «Quality Assurance» for feedback from the QA team. If necessary, the developer will provide hints on how to test his patch in a comment on the issue.
The QA-Team tests the fix on all devices and provides feedback to the developer. If problems are found, the issue is re-opened and goes back to «Accepted», else it’s moved to «Release Candidate» to be included in the next release.
Qualora non sia già stato fatto, il problema è aggiunto alla prossima «milestone». Una volta che questa è rilasciata, il problema è rimosso dal tabellone di progetto.