# L'importanza del Bug Report

## alexzndr

Salve a tutti! Dopo una discussione con motaboy, e' nata l'idea di scrivere questo post il cui scopo dovrebbe essere quello di "sensibilizzare" ed esortare gli utenti al bug report.

Premetto che queste righe per molti voi potranno sembrare banali e scontate, in quanto gia' a conoscenza dell'argomento; putroppo altrettanti, (facendo una previsione molto positiva) sottovalutano molto questo aspetto e un po' per pigrizia, un po' anche per cattiva informazione, privano gli sviluppatori di informazioni che invece potrebbero essere importantissime per la risoluzione di errori e per uno sviluppo ottimale del software.

Tutto cio' dovrebbe essere ancora amplificato quando la distro di cui si parla e' gentoo; distro che vanta di una comunita' molto attenta, viva ed esigente. Senza perderci in troppe parole, per capire quanto sia importante questo legame tra sviluppatori e utenza "comune" , vi riporto un breve passaggio tratto dall'intervista al team di sicurezza di gentoo:

 *Quote:*   

> 
> 
> "In che modo venite a sapere dei problemi di sicurezza? Mailing list? Allarmi? Vengono fatti test all'interno del team?
> 
> Ci affidiamo ai nostri utenti per la notifica di quante più vulnerabilità possibile. [cut] "

 

Se qualcuno volesse leggere il testo completo: http://www.gentoo.org/news/it/gwn/20050214-newsletter.xml

Detto cio', credo ci sia poco altro da spiegare sul ruolo fondamentale che investe il bug report e anche se nel caso sopracitato si parla prettamente di sicurezza, l'argomento interessa anche tutti gli altri aspetti del software.

Ovviamente questo non voul dire che all'apparire di un problema, la prima cosa da fare e' considerarlo bug e segnalarlo, altrimenti invece di aiutare gli sviluppatori, li avvicianiamo soltanto a una crisi di nervi; cerchiamo quindi di capire quando e' effettivamente il caso di aprire un bug report.

In questo caso parlero' solo di https://bugs.gentoo.org/ ma la stessa cosa vale anche per tutti gli altri sistemi di bug tracking tipo http://bugzilla.gnome.org/, http://bugs.kde.org/ etc. E' comunque piu' corretto riportare i bugs relativi ai singoli pacchetti su bugs.gentoo.org. Saranno poi i developer gentoo incaricati di gestire il package segnalato a riportare, se del caso, il baco ai developers del package stesso; cio' perche' puo' accadere di riportare bugs dovuti non tanto a un problema del pacchetto stesso, ma a cose relative a gentoo (ad esempio flag di compilazione).

NB:Nel caso in cui si stiano utilizzando CFLAGS spinte, e' buona cosa vedere se il problema sussiste dopo aver ricompilato il pacchetto con CFLAGS piu' leggere.

Ammettiamo  di avere un problema di partenza (di qualunque tipo, da un crash frequente a una compilazione fallita)

1) La prima cosa da fare e' quella di effettuare una ricerca approfondita in https://bugs.gentoo.org/ . Approfondita nel senso che la ricerca  non va fatta soltanto nella classica finestrella "enter a bug number", ma va effettuata nel Query bugs report (solitamente in basso a sinistra) e cosa di fondamentale importanza, e' quella di effettuare la ricerca anche tra i bug che hanno come status CLOSED.

2) Se la ricerca precedente non ha portato a niente di concreto, possiamo ampliarla sia sul forum che su google.

[quando si effettua una ricerca, sarebbe corretto riportare parte di un errore che abbiamo ricevuto come output, oppure provando varie combinazioni di quelle che si possoono considerare parole chiave del problema]

3) Se neanche le ricerche precedenti  hanno portato a nessun buon risultato possiamo, mi correggo DOBBIAMO, aprire un bug report.

Ora non mi sto a soffermare sul come andrebbe aperto un bug, in quanto utilizzando la action "new" veniamo introdotti in una procedura guidata che spiega precisamente cosa va fatto e cosa non va fatto con tanto di esempi. Tra i vari step che vengono consigliati, uno dei primi e' cercare se il bug esiste gia' e consiglio di rieffettuare ancora la ricerca al fine di evitare di creare un duplicato, dato che gia' ce ne sono tantissimii! Se comunque qualcuno volesse leggere qualcosa in piu' ecco dei link che approfondiscono l'argomento:

http://www.mozilla.org/quality/bug-writing-guidelines.html

http://www.mozilla.org/quality/help/beginning-duplicate-finding.html

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

NB: nel caso in cui il passo 1) non abbia portato a nulla, mentre cercando nel forum o in qualsiasi altro modo abbiamo risolto il problema, e'  DOVEROSO aprire un bug report in cui specifichiamo il problema e chiaramente proponiamo la soluzione! Se la pigrizia ci impedisce di fare questo, di sicuro non dobbiamo andarne fieri, non dimenticandoci mai che uno dei maggiori punti di forza del successo del software open source, si basa proprio sul coinvolgimento e sulla collaborazione da parte tutti! Anche se non si e' programmatori, anche se non si hanno conoscenze tecniche esagerate, in questo semplice modo tutti possiamo e dobbiamo contribuire allo sviluppo!!!

Ciao ciao

edit: aggiunte le osservazioni di Sparker e xlyzLast edited by alexzndr on Thu Apr 21, 2005 1:03 pm; edited 2 times in total

----------

## =DvD=

Ottimo!

----------

## fedeliallalinea

 *=DvD= wrote:*   

> Ottimo!

 

Quoto in pieno ottimo lavoro alexzndr

----------

## lavish

Bene alexzndr, ci stava questo topic! Ma motaboy non è un pò stressato dall'ultimo che avevo aperto io? (che sì è rivelato invalid)  :Laughing: 

Io fossi in te marcherei il fatto di stare attneti a non duplicare bugs perchè circa la metà dei reports su buzilla sono dups

Ottimo lavoro comunque!  CIauu!

Ah a proposito... per aiutare di più BISOGNA STARE TUTTI IN ~ !  :Razz: 

----------

## gutter

Davvero una cosa utile.

----------

## Dhaki

Ottimo lavoro!!

Quoto lavish in pieno, usate ~x86  :Laughing: 

----------

## motaboy

si ma ricordatevi di non mischiare gcc 3.3.x con gcc 3.4.x come gia' detto tante volte.

----------

## xoen

Ottimo.

Per aiutare i programmatori non si deve necessariamente essere programmatori, si può aiutare con un bug report, tradurre, creare un icona, un idea, ecc, ecc, ecc...

 *Quote:*   

> 
> 
> Basta poco, che ce vo?!
> 
> 

 

----------

## alexzndr

Intanto grazie a tutti!

Concordo con lavish sul fatto che ci sono un sacco di duplicati e tutto cio' chiaramente perche' le ricerche prima di aprire un bug non vengono effettuate abbastanza approfonditamente; anzi spesso credo che non vengano proprio eseguite!! (aggiungo qualcosa al post precedente)

Ciao ciao

----------

## mouser

Ottimo ottimo......

scrivere un bel programma e' faticoso, ma ancora piu' faticoso e' plasmarlo ed ottimizzarlo cosi' da trasformarlo da un programma "stressante" (con un po' di bug) ad un programma "utile".

E con i bugreport questo passaggio viene accelerato!

Non sono molto d'accordo sul tenersi il sistema ~x86...... io lo tengo come x86, poi, quando voglio provare (e magari nel frattempo testare un po') un software, lo installo come ~x86.

Ovviamente questo IMHO

Ciriciao

mouser  :Wink: 

----------

## Dece

Un ottimo bug report howto  :Smile: 

Per quanto riguarda ~x86 quoto mouser: anche secondo me è meglio concentrarsi sul test di pochi programmi alla volta, con un intero sistema ~x86 ci sarebbero veramente troppe cose potenzialmente instabili  :Wink: 

Ciao

----------

## Sparker

In caso di errore di compilazione é buona norma riprovare con CFLAGS meno spinte prima di aprire un bug report

----------

## fedeliallalinea

 *Sparker wrote:*   

> In caso di errore di compilazione é buona norma riprovare con CFLAGS meno spinte prima di aprire un bug report

 

Osservazione importante visto che se le flags sono spinte la prima cosa che domandano e' di ricompilare con delle flags leggere

----------

## xlyz

ricordo a tutti che anche i bachi relativi a singoli package vanno riportati su bugs.gentoo.org

saranno poi i developer gentoo incaricati di gestire il package segnalato a riportare, se del caso, il baco ai developers del package stesso

in passato troppe volte sono stati riportati come bachi problemi relativi a flag di compilazione e altre cosette tipiche di gentoo, per cui non sempre i bug reports di gentooisti sono benvenuti

----------

## fctk

mmh...

si potrebbe tradurre l'howto di alexzndr in inglese e indicarlo ogni qual volta qualcuno posta un errore di compilazione senza dire "premetto che ho guardato su bugs.gentoo.org". sono molti quelli che postano errori senza guardare sui bugs o senza dire di aver fatto una ricerca...

----------

## alexzndr

Putroppo con l'inglese sono abbastanza monodirezionale  :Wink:  (inglese -> italiano)

Nel frattempo ho modificato il primo post aggiungendo le osservazioni di Sparker e xlyz

----------

## fctk

 *alexzndr wrote:*   

> 1) La prima cosa da fare e' quella di effettuare una ricerca approfondita in https://bugs.gentoo.org/ . Approfondita nel senso che la ricerca  non va fatta soltanto nella classica finestrella "enter a bug number", ma va effettuata nel Query bugs report (solitamente in basso a sinistra) e cosa di fondamentale importanza, e' quella di effettuare la ricerca anche tra i bug che hanno come status CLOSED.

 

mmh... questa cosa mi lascia perplesso... io di solito inserisco il nome del pacchetto che da errori di compilazione dove c'è scritto:

 *Quote:*   

> Enter a bug # or ALL followed by some search terms:
> 
> Example: ALL pop3d

 

è giusto così o qualcosa mi sfugge?

----------

## alexzndr

La differenza sta nel fatto che utilizzando il query bug report puoi visualizzare

non solo gli status open, ma tutti gli altri e in particolare i closed!

----------

## fctk

io di solito per velocizzare la ricerca di bug uso questo plugin: http://mycroft.mozdev.org/download.html?name=gentoo&submitform=Find+search+plugins

ciò che mi chiedo è: questo plugin fa una ricerca sufficientemente approfondita? dai miei test sembra di sì, e cioè a me pare che cerchi anche tra i bug closed..

----------

## fctk

http://www.gentoo.org/doc/en/bugzilla-howto.xml

https://forums.gentoo.org/viewtopic-t-365040.html

----------

