#!/bin/bash
for file in `dir -d *.sqlite` ; do
./sqlite3-3.6.16.bin "$file" "VACUUM"
done
A seconda del voto, si prende la riga che serve, tramite css. Qualcuno vede come la cosa sia idiota? No?
Il rettangolo invece di farlo scrollare in verticale lo sposto in orizzontale e ottengo la stessa identica cosa! Lo sviluppo del codice di Mozilla si basa sulla presenza e sulla coesistenza di diversi elementi, ognuno con la propria importanza. Sono necessari i progettisti software per stabilire in che direzione far evolvere il codice, i programmatori per implementare tale visione, gli scrittori
per documentare sia il codice sia le applicazioni, esperti di sviluppo web per modificare e migliorare l'offerta dei siti relativi a Mozilla. In ultimo, solo per l'ordine naturale dello sviluppo software ma non meno importanti, sono necessari gli utenti finali: solo loro infatti possono mettere alla frusta un prodotto e ricreare le situazioni di utilizzo più astruse.
Gli utenti finali sono gli unici in grado di superare gli schemi mentali dei progettisti software e dei programmatori, utilizzando nei modi più impensabili un software, solitamente in un modo assolutamente non previsto dal progetto originale. Mentre la fase di test pensata prima della scrittura del codice serve a verificare la correttezza del software (cioè che funzioni effettivamente come previsto), l'utilizzo da parte dell'utente finale, o meglio ancora dell'utonto
, permette di verificare la robustezza del codice (ovvero che quanto scritto, anche se usato impropriamente, non generi problemi).
Per questo motivo diventa fondamentale l'apporto di tutti noi, anche semplici utilizzatori, nella ricerca, segnalazione e correzione dei bug. Al livello più semplice basta attivare TalkBack ed inviare i dati collezionati sui crash a mozilla.org (senza alcun rischio di compromettere i propri dati personali e privati), o utilizzare lo strumento Reporter per segnalare i siti che non si visualizzano correttamente con i prodotti Mozilla. Ancora, è possibile condividere le proprie esperienze in positivo o in negativo sui forum, fare pubblicità, prestare il proprio aiuto ad altri utenti come noi. Ma è possibile fare ancora un passo in più: segnalare i difetti trovati su Bugzilla, il database degli orrori errori di Mozilla!
L'unico prerequisito imprescindibile per poter compiere questo passo è la conoscenza della lingua Inglese, meglio ancora se arricchita dalla conoscenza dei termini tecnici propri dell'informatica: ciò non dovrebbe essere particolarmente complicato, visto che l'Italiano li ha adottati quasi tutti nell'uso comune (basti pensare a download, browser, plugin, ecc.).
Più si utilizza un prodotto software, più lo si conosce a fondo e più se ne scoprono i limiti ed i punti di forza. Questo è vero per un qualsiasi software, indipendentemente dalla sua complessità. Nel caso dei prodotti Mozilla, ciò è facilmente verificabile: un uso semplice di un programma come Thunderbird, ad esempio, può rendere felici molti utenti; appena si cominciano ad usare a fondo le caratteristiche e le funzionalità del programma per andare oltre le operazioni più semplici, ecco che si comincia a sentire il bisogno di modificare le Preferenze, magari anche quelle nascoste, e poi di ampliare la gamma delle funzionalità di base utilizzando le estensioni. E più funzioni si utilizzano e più testing del software si realizza...
In un mondo perfetto il software dovrebbe permettere l'evoluzione degli utenti senza il minimo intoppo, ma purtroppo ciò non è mai vero: prima o poi ci si imbatte in un problema. A volte è possibile aggirarlo, altre volte invece si viene completamente bloccati: in entrambi i casi è molto probabile che ci si trovi di fronte ad un bug, ovvero un errore di programmazione. Perché dico è probabile
? Perché talvolta gli utenti vogliono compiere delle operazioni che non sono state nè previste nè pensate per essere eseguite nel modo da loro voluto: quindi siamo di fronte ad un limite o nella progettazione del software o nella conoscenza del software stesso da parte dell'utente.
Prendiamo in considerazione il caso di un vero e proprio bug: come dobbiamo comportarci? Per esperienza personale, prima di lanciarsi a scrivere un bel bug report su Bugzilla, conviene fare una serie di prove da soli ed in compagnia... Da soli possiamo controllare più volte se è possibile riprodurre il bug in maniera consistente, cercando di segnare tutti i passi necessari per riprodurlo. In certi casi può essere prezioso eseguire lo stesso test con un profilo pulito, in modo da evitare problemi dovuti alla stratificazione
delle diverse versioni dello stesso programma. Se siamo ancora convinti di trovarci a quattr'occhi con un bug, chiediamo a qualcun altro di verificare se riesce a riprodurre il problema con la nostra sequenza di passi: se la risposta è affermativa, possiamo cominciare a pensare di spostarci su Bugzilla per il passo successivo.
È comunque possibile che ci siamo ritrovati in una condizione in cui non esiste un vero e proprio bug, ma piuttosto una carenza strutturale
del programma. Sempre sottoponendo tale limitazione all'analisi e all'opinione di altre persone (più una funzione è utile a diverse classi di utenti e più è semplice chiederne l'implementazione), possiamo farci un'idea di cosa andare a chiedere ai programmatori di Mozilla. Cito un esempio: per molte persone la possibilità di estrarre allegati divisi tra messaggi di posta o newsgroup diversi è una necessità imprescindibile prima di passare all'utilizzo di un programma di posta Mozilla. Possiamo quindi spostarci su Bugzilla per sottoporre la nostra richiesta di miglioria o RFE (Request For Enhancement) ed incrociare le dita sperando che qualcuno si offra di implementarla (ad esempio la citazione precedente è in Bugzilla dal Novembre del 2000).
Armati di tutte le nostre informazioni, puntiamo il browser su https://bugzilla.mozilla.org. Cominciamo a guardarci intorno e a fare ricerche con alcune parole chiave che possono essere uguali o simili a quelle che intendiamo usare noi; questo è un altro passo fondamentale per fare un buon bug report: dobbiamo assicurarci che nessuno lo abbia già fatto prima! Dovremo andare a spulciare tutti i bug che anche lontanamente somigliano al nostro, e se ne troviamo uno che corrisponde, verifichiamo che riporti tutte le informazioni in nostro possesso: anche se non creiamo un nuovo bug report, possiamo riportare le informazioni aggiuntive in nostro possesso, un aiuto in più per chi dovrà sistemare il problema. Creando un duplicato di un bug esistente, provochiamo un inutile spreco di risorse per tutto il sistema.
Altro passaggio fondamentale è avere un proprio account su Bugzilla: crearlo è semplicissimo e basta avere un account di posta elettronica valido. Superato questo scoglio, è giunto quindi il momento di creare un nuovo bug report: puntiamo sul pulsante New e via, riempiamo bene tutti i campi che vengono proposti dal modulo. Assicuriamoci di aver selezionato il componente esatto (cioè a quale parte di Mozilla si riferisce il bug), scegliamo un Summary sufficientemente semplice per descrivere il problema ma che contenga diverse parole chiave (in modo che chi viene dopo di noi non fatichi a trovarlo se vuole segnalare lo stesso problema), e abbondiamo con i particolari nei Details.
Quando ci sembra di aver dato tutte le informazioni possibili e pertinenti, possiamo fare clic su Submit: dopo alcuni istanti bugzilla ci avviserà che sono stati fatti i cambiamenti necessari per il bug XXXXXX
. È possibile controllare come Bugzilla ha impostato alcuni campi automatici del bug: certamente lo stato del bug sarà UNCONFIRMED, cioè non confermato, perché il vostro rapporto deve essere analizzato da qualche altro volontario (e si spera esperto del componente) che deve verificare la correttezza di quanto avete scritto, della descrizione del problema dell'esattezza del componente assegnato. Alcuni altri campi riempiti in automatico sono il QA Contact
(ovvero colui che dovrebbe analizzare il vostro report e confermarlo), Reporter
che dovrebbe essere impostato al vostro account e Assigned To
che di solito indica quale sviluppatore dovrebbe sistemare il problema (il condizionale è d'obbligo, in quanto sono tutti o quasi volontari).
Un ultimo campo da impostare con accortezza è Severity
: di norma è bene lasciarlo impostato a Normal, ma esistono le dovute eccezioni. Se ad esempio il vostro bug report riguarda magari un refuso nell'interfaccia grafica, o in una finestra di dialogo, insomma, riguarda qualcosa di davvero semplice, è bene impostare il campo a Trivial. Se invece stiamo aprendo una richiesta di miglioria, dobbiamo impostare il tutto a Enhancement. Ancora, se crediamo di avere individuato un problema che compremette la sicurezza del prodotto e del suo utilizzatore, dobbiamo impostare il campo a Security: questa categoria è un po' particolare, in quanto viene presa in carico da un team speciale che analizza il report e decide quanto è grave la falla e se renderla segreta fino a quando non viene trovata e applicata una soluzione al problema. Impostare correttamente questo campo faciliterà l'analisi altrui e, col tempo, vi farà guadagnare rispetto da parte degli sviluppatori che leggono i vostri bug report...
Nella maggior parte dei casi, entro pochi giorni il nostro bug passa da UNCONFIRMED a NEW: questa è la certezza che non abbiamo scritto grosse stupidaggini, e che non sembra esserci un bug precedente uguale al nostro. In caso contrario, o il bug non è stato neanche esaminato (cosa che spesso accade per certi componenti), oppure viene subito chiuso come DUPLICATE di un altro bug. Se siamo particolarmente fortunati, lo status passa subito ad ASSIGNED: questo significa che uno sviluppatore ha deciso di prendersi il nostro bug in carico e di lavorarci sopra: non accade spesso, ma se succede, significa che abbiamo trovato davvero un bel buco!
È anche possibile che il nostro bug evolva
in maniera radicale: succede a volte che descriviamo come bug un sintomo di un problema molto più grosso. Non stupiamoci quindi se in fase di analisi da parte di altre persone il tutto subisca modifiche ed aggiustamenti, oppure che il bug acquisisca delle dipendenze: Depends on significa che se non vengono sistemati prima altri bug, il nostro non può essere risolto, mentre Blocks significa che se non viene sistemato il nostro bug, altri non hanno speranza. Può anche capitare che il nostro Summary venga ritoccato per descrivere meglio il problema o renderlo più facilmente individuabile tramite ricerche, magari cambiando le parole chiave, oppure può accadere che vengano individuati dei duplicati del nostro report, oppure ancora che il nostro bug venga considerato (e chiuso) come duplicato di un altro.
Può anche succedere che vengano richiesti maggiori dettagli o magari delle prove particolari a chi ha descritto il bug, quindi il nostro lavoro non è finito una volta che abbiamo fatto clic su Submit... Notiamo che in tutti i bug c'è una lista CC: possiamo aggiungere il nostro indirizzo email alla lista in modo che ogni volta che avviene una qualche modifica al bug, verremo avvisati tramite posta elettronica. È utile ad esempio nel caso trovassimo un bug che ci interessa particolarmente, oppure nel caso scovassimo un bug simile a quello che volevamo riportare. Possiamo avere il polso
della situazione dei bug che più ci interessano senza dover andare a controllare tutte le volte su Bugzilla. Non è necessario aggiungersi alla lista CC di un bug se il bug lo abbiamo creato noi oppure lo abbiamo votato (una possibilità data da Bugzilla ma che su mozilla.org non ha alcun valore), o ancora se siamo le persone assegnate a risolverlo o ne siamo il responsabile di qualità.
Può rivelarsi utile a volte allegare al bug anche una o più schermate grafiche che descrivano meglio o isolino il problema: nulla di più semplice. Generiamo lo screenshot sul nostro computer, torniamo nel bug e facciamo clic su Create new attachment: si apre un nuovo modulo in cui dobbiamo specificare il nome della schermata, darne una piccola descrizione ed istruire Bugzilla sul tipo di file che stiamo allegando. Spesso è più sicuro specificare manualmente il tipo di file senza utilizzare il riconoscimento automatico di Bugzilla che non sempre sembra essere all'altezza del compito, specialmente se si tratta di immagini o di codice (X)HTML.
Se il nostro bug ha risvegliato l'interesse di qualche programmatore, può arrivare il giorno in cui in esso compare una patch, ovvero un insieme di modifiche al codice sorgente di Mozilla che dovrebbe risolvere il problema segnalato. Possiamo dare un'occhiata alle modifiche proposte facendo clic su View accanto all'allegato contenuto nella lista Attachments: ciò che compare a video non è altro che una patch in formato diff, programma diffusissimo in ambito Unix/Linux per lo sviluppo di software. A noi non sembra altro che del testo: le cose che dobbiamo notare sono le righe precedute da -
e da +
: le prime sono le righe eliminate, mentre le seconde sono le righe aggiunte al sorgente di Mozilla. Spesso molte modifiche che toccano numerosi file vengono condensate all'interno di un unico file di diff, e ciò permette di capire quanto un bug può influire sui sorgenti di Mozilla.
È anche possibile che nessuno si interessi al nostro bug: che fare? Se la difficoltà del problema non è insormontabile, potremmo anche pensare di sistemare da soli il tutto... A prima vista può sembrare un'impresa irrealizzabile, ma non è così. Abbiamo due possibilità: trasformare il nostro computer in un sistema di sviluppo in grado di generare le nostre personali versioni dei prodotti Mozilla (al fine di portare avanti i nostri test), oppure usare alcuni strumenti via web per cercare di generare una patch. Nel secondo caso, è possibile usare programmi particolari come PatchMaker e sfruttare servizi web di Mozilla come lxr per cercare di generare una patch corretta da sottoporre a scrutinio su Bugzilla. È una soluzione adatta nel caso di problemi davvero semplici, magari relativi a refusi del testo, ma molto scomoda per le modifiche più complesse, specie se fatte al codice sorgente di Mozilla.
L'altra soluzione possibile (creare un sistema di sviluppo) richiederà un po' di tempo all'inizio affinché tutto funzioni a dovere, ma è uno sforzo che di solito va fatto una sola volta. Per nostra fortuna è possibile reperire informazioni dettagliate su come procedere sul sito mozilla.org per varie piattaforme, e ci sono diversi newsgroup in cui poter chiedere aiuto in caso di bisogno. Portata a termine questa impresa, siamo davvero padroni del campo: possiamo cominciare a sperimentare e prendere dimestichezza con il sistema di sviluppo, il cvs e il diff un poco alla volta (sempre seguendo le ottime informazioni disponibili su mozilla.org), magari partendo dai file (X)HTML, per poi passare ai .dtd e .properties, poi ai .js e .xul fino a cimentarsi con i file .cpp.
A poco a poco creare patch diventerà una (sana) abitudine: ma una volta creata una patch e inserita su Bugzilla che succede? Dovremo innanzitutto chiedere a qualcuno esperto di revisionarla (impostando il campo review
della patch a ? ed inserendo poi l'indirizzo email del supervisore). La scelta del supervisore va fatta cum grano salis: deve essere una persona che conosce abbastanza il codice che andiamo a toccare e, come gentilezza, dovremmo cercare di chiedere la review a qualcuno che non ha una coda
di richieste troppo lunga (per non oberarlo di lavoro). Ancora una volta il sito di mozilla.org ci viene in aiuto; possiamo controllare la lista dei module-owner (ovvero coloro che sono responsabili eclusivi di una parte del sorgente Mozilla) e dei peer-reviewer (altre persone esperte del modulo in questione), e scegliere in base a questo elenco.
Se la scelta non è stata felice, dopo un po' di tempo potremo cambiare supervisore, oppure verremo informati del tempo necessario prima che la revisione venga portata a termine. La revisione può concludersi sostanzialmente in tre modi:
Se riusciamo ad ottenere un bel r+, a seconda del tipo di patch può essere necessario richiedere anche un sr+ (super-review), in genere dal module-owner in persona: questo si rende necessario quando il codice modificato è parecchio, oppure si cambia radicalmente aspetto o fisionomia di una parte del sorgente. Ottenuto, se necessario, anche il sr+, possiamo chiedere a qualcuno di inserire la nostra patch nell'albero dei sorgenti di Mozilla. Controllando la pagina di tinderbox (macchine che preparano a getto continuo versioni di test dei prodotti Mozilla), potremo verificare se la nostra patch è stata inserita senza procurare danni (nel commento al checkin comparirà la vostra email/il vostro nome accanto a p= oppure dopo Patch by, ed i nomi di chi ha accordato r+ ed eventuale sr+): siamo entrati nella storia di Mozilla! :-)
Tutto finito? Quasi... Solitamente chi ha effettuato il checkin imposta il bug anche a FIXED, e ciò segnala che il problema dovrebbe essere risolto. Altre persone addette alla verifica (come ad esempio il QA Contact), possono quindi verificare in una nightly successiva all'introduzione della patch che il problema sia stato effettivamente risolto, e possono cambiare ancora lo stato del bug a VERIFIED FIXED: questo è lo stato ultimo di un bug su Bugzilla, e significa che il problema è stato del tutto risolto e può essere archiviato.
A volte succede però che la verifica non sia positiva, e quindi lo stato del bug viene posto a REOPENED, ovvero c'è ancora del lavoro da fare. Di solito ciò accade quando la patch ha risolto solo in parte il problema, oppure ne ha generati di nuovi che prima non c'erano (chiamati regressioni) e ne ha portati alla luce di nuovi ma molto simili (per cui sembra superfluo aprire un altro bug). In questi casi o vengono fornite nuove patch, oppure si decide di fare un backout, cioè di togliere dall'albero dei sorgenti di Mozilla la patch inserita in precedenza: di solito serve sempre tutta la trafila di revisione, anche nel caso di backout.
Chiuso il discorso? Non ancora... Un altro caso particolare sono i bug risolti a ridosso di una versione stabile di Gecko, oppure abbastanza importanti da dover far parte della prossima versione minore di un programma Mozilla (ad esempio far parte di Firefox 1.5.0.2). I bug che appartengono a questa categoria non vengono posti a RESOLVED quando la patch viene inserita nell'albero dei sorgenti principale di Mozilla (trunk): l'autore della patch attiva il flag a=? oppure blocking x.x.x? e, con una breve spiegazione, motiva questa sua richiesta. I drivers (ovvero la ristretta cerchia di sviluppatori che coordina il rilascio delle versioni ufficiali dei prodotti Mozilla) analizzano la richiesta e danno o meno il loro consenso. Una volta presa la decisione, il bug passa a VERIFIED FIXED, ma in caso di consenso favorevole, la patch viene inserita anche nell'albero di sviluppo stabile (branch), così da far parte della prossima versione ufficiale del prodotto. Il bug in quest ultimo caso acquista una piccola scritta nel campo Keywords, solitamente fixedx.x.x. Ok, ora abbiamo davvero finito! :-)
Sotto a cercare e/o sistemare il prossimo bug!
Un grazie alle persone che mi hanno spinto ed aiutato a scrivere questo documento, in ordine sparso:
