No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{autolang}} | {{autolang}} | ||
; Quali tipi di bug sono considerati ''release blockers''? | |||
Sono detti ''release blockers'' quei problemi che riguardano i sottosistemi nel processo di sviluppo critico (grafica, installer, rete), che sono soggetti a minime tolleranze agli errori (vedi bug), poichè la loro risoluzione tramite aggiornamenti sarebbe troppo dirompente/destabilizzante. | |||
; Cosa vuol dire ''Target Release Tracker'' bug? | |||
Una ''Target Release Tracker'' è una lista dei desideranda, ossia dei bug che sarebbe piacevole risolvere per una release. Si tratta di un modo conveniente per tenere separati ''alcuni'' bug da tutti gli altri aperti. | |||
= | = Per sviluppatori (e curiosi) = | ||
== Esiste una lista di tutti i blocker bugs di una release? == | |||
Si, vedi [[BugZappers/HouseKeeping/Trackers| Tracker Bugs]]. | |||
== Come mai i bug relativi al sistema audio non sono ''blocker bugs''? == | |||
Perchè per i problemi audio si assume una maggiore tolleranza ai bug, potendoli risolvere abbastanza bene con un aggiornamento. | |||
== | == Individuato un potenziale blocker. Cosa fare? == | ||
Se il potenziale blocker soddisfa il relativo criterio per la release, aggiungerlo alla lista dei blocker, anche in caso di dubbio: meglio aggiungerlo e prenderlo nella dovuta considerazione, (per poi eventualmente rimuoverlo), piuttosto che trascurarlo e ritrovarlo in una release. | |||
== E per i problemi dipendenti da HW e da configurazioni locali? == | == E per i problemi dipendenti da HW e da configurazioni locali? == | ||
Molti bug non sono universali, ma interessano solo alcuni componenti HW o SW, o loro certe configurazioni o combinazioni particolari. Quando un bug viola un criterio in alcuni ma non tutti i casi, i team coinvolti nel processo di sviluppo della release, | Molti bug non sono universali, ma interessano solo alcuni componenti HW o SW, o loro certe configurazioni o combinazioni particolari. Quando un bug viola un criterio in alcuni ma non tutti i casi, i team coinvolti nel processo di sviluppo della release, analizzano il grado di incidenza del bug, valutando se è sufficientemente severo da interessare l'intera release. La fase di valutazione dipende da diversi fattori, tra i quali: | ||
* Numero stimato di utenti che potrebbero essere interessati | * Numero stimato di utenti che potrebbero essere interessati | ||
* Facilità con cui rimediare una soluzione, attraverso modifiche documentate, | * Facilità con cui rimediare una soluzione, attraverso modifiche documentate, alla configurazione | ||
* Difficoltà nel trovare una soluzione definitiva, nel caso in cui ciò comporti come effetto maggiori e più seri problemi. | * Difficoltà nel trovare una soluzione definitiva, nel caso in cui ciò comporti come effetto maggiori e più seri problemi. | ||
[[Category:QA]] | [[Category:QA]] | ||
Revision as of 17:29, 17 August 2010
- Quali tipi di bug sono considerati release blockers?
Sono detti release blockers quei problemi che riguardano i sottosistemi nel processo di sviluppo critico (grafica, installer, rete), che sono soggetti a minime tolleranze agli errori (vedi bug), poichè la loro risoluzione tramite aggiornamenti sarebbe troppo dirompente/destabilizzante.
- Cosa vuol dire Target Release Tracker bug?
Una Target Release Tracker è una lista dei desideranda, ossia dei bug che sarebbe piacevole risolvere per una release. Si tratta di un modo conveniente per tenere separati alcuni bug da tutti gli altri aperti.
Per sviluppatori (e curiosi)
Esiste una lista di tutti i blocker bugs di una release?
Si, vedi Tracker Bugs.
Come mai i bug relativi al sistema audio non sono blocker bugs?
Perchè per i problemi audio si assume una maggiore tolleranza ai bug, potendoli risolvere abbastanza bene con un aggiornamento.
Individuato un potenziale blocker. Cosa fare?
Se il potenziale blocker soddisfa il relativo criterio per la release, aggiungerlo alla lista dei blocker, anche in caso di dubbio: meglio aggiungerlo e prenderlo nella dovuta considerazione, (per poi eventualmente rimuoverlo), piuttosto che trascurarlo e ritrovarlo in una release.
E per i problemi dipendenti da HW e da configurazioni locali?
Molti bug non sono universali, ma interessano solo alcuni componenti HW o SW, o loro certe configurazioni o combinazioni particolari. Quando un bug viola un criterio in alcuni ma non tutti i casi, i team coinvolti nel processo di sviluppo della release, analizzano il grado di incidenza del bug, valutando se è sufficientemente severo da interessare l'intera release. La fase di valutazione dipende da diversi fattori, tra i quali:
- Numero stimato di utenti che potrebbero essere interessati
- Facilità con cui rimediare una soluzione, attraverso modifiche documentate, alla configurazione
- Difficoltà nel trovare una soluzione definitiva, nel caso in cui ciò comporti come effetto maggiori e più seri problemi.