From Fedora Project Wiki
(Created page with '{{autolang}} == Quali tipi di bug sono considerati ''release blockers''? == I problemi che riguardano i sottosistemi nel percorso critico (grafica, installer, rete) sono soggett...')
 
No edit summary
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{autolang}}
{{autolang}}


== Quali tipi di bug sono considerati ''release blockers''? ==
; Quali tipi di bug sono considerati ''release blockers''?  
I problemi che riguardano i sottosistemi nel percorso critico (grafica, installer, rete) sono soggetti a minime tolleranze poichè la loro risoluzione tramite aggiornamenti sarebbe troppo dirompente.
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.


== Why aren't sound or audio bugs considered blocker bugs? ==
; Cosa vuol dire ''Target Release Tracker'' bug?  
Sound issues have a very high barrier to being release blockers, because they can be fixed well with an update.


== I have identified a bug that I believe is a blocker. Is it okay if I just add it? ==
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.
If you have reviewed the blocker criteria for the release and believe your bug meets the criteria, definitely add it.  When in doubt add it to the blocker list.  Better to add it and have it removed versus never getting a thorough review.


== What is the ''Target'' Release tracker bug for? ==
= Per sviluppatori (e curiosi) =
The ''Target'' tracker is a ''nice to have fixed'' list of bugs for a release.  It is a convenient way to separate them from all the other open bugs a maintainer may be following.


== Is there a list of all the blocker bugs for a release? ==
== Esiste una lista di tutti i blocker bugs di una release? ==
Yes, [[BugZappers/HouseKeeping/Trackers| Tracker Bugs]].
Si, vedi [[BugZappers/HouseKeeping/Trackers| Tracker Bugs]].


== What about hardware and local configuration dependent issues? ==
== 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.


Many bugs are not universal: they only affect certain hardware or software components, or certain configurations or combinations of hardware and software components. When a bug causes a criterion not to be met in some but not all cases, the teams involved in the release process will make a judgement as to whether the impact of the bug is severe enough to consider the release as a whole not to meet the release criteria. This judgement will be based on multiple factors:
== 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.


* The amount of users, overall, the issue is estimated likely to affect
* The ease with which the issue can be worked around by documentable configuration changes
* The difficulty involved in fixing the issue: whether there is a significant chance that attempting to fix the issue could cause more serious problems


[[Category:QA]]
[[Category:QA]]
[[Category:Italiano]]
[[Category:Da revisionare]]

Latest revision as of 15:17, 28 January 2012

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.