MondoZilla

TB3rc1 dopo il weekend

2009-11-07T09:40:00.004+01:00

Lunedì è il grande giorno per la RC1 di TB3, ma il lavoro di rifinitura non si concede alcuna pausa, tanto che è stata sistemata quasi una decina di bug inerenti il codice di TB e del lato posta in genere.
Un po' di lavoro è finito anche nel sistema di gestione dei componenti aggiuntivi, e nella gestione in breakpad (il tool che manda a mozilla dati sui crash dell'applicazione) della lista delle estensioni segnalando quelle la cui compatibilità è stata forzata. Finalmente anche in mozilla hanno capito che il sistema delle estensioni e dei plugin va messo in ordine e la sua sicurezza va rafforzata: bravi. E bravi anche per aver chiuso un altro buco di sicurezza nel parser HTML. Ritocchino al tema Vista di FF, e sono state riviste alcune API che erano cambiate tra 1.9.1 e 1.9.2 senza effettuare il doveroso cambio di ID. Infine, è stao tolto del codice inutile dal gestore di download.

Buon weekend!

Mobile = benefici per tutti

2009-11-04T07:24:00.003+01:00

E' innegabile che il grosso lavoro che si sta facendo sulle versioni mobile sta aiutando non poco anche le versioni tradizionali di tutti i prodotti mozilla: questo e soprattutto questo bug hanno fatto guadagnare tantissimo tempo nello startup delle applicazioni oltre alla versione mobile. Un altro indubbio vantaggio è che per forza di cose sono stati costretti a mettere mano ad una parte di codice che si usa sempre e che non veniva più toccata dal 2001, ovvero il fastload, cioé quella parte di codice che serve a precaricare ed interpretare gran parte dell'interfaccia grafica delle applicazioni mozilla. Per capirsi, è quella parte di codice che genera e gestisce i file .mfl o .mafl. Quando sarà completato questo bug, ci saremo liberati di una delle parti di codice mozilla più oscure e meno mantenute dagli albori del progetto, e rimarrà solo Composer (e si spera per poco).
Altra modifica interessante: se esiste una copia di backup funzionante, ora il file prefs.js viene eliminato e sostituito. Sono state fatte alcune modifiche al toolkit, e si è tentato di sistemare senza successo un bug sui margini dei popup. Un po' di lavoro sparso su TB (il secondo bug me lo sono beccato spesso), ritocchino importante alla navigazione anonima del solito Marco, modifiche al blocco popup, all'anteprima di stampa e chiuso un buco di sicurezza.
Passando alle modifiche specifiche per piattaforma, tante modifiche sono arrivate e altre ne stanno per arrivare in casa OS/2 nello stesso bug, jemalloc ora ha un problema in meno su Linux, e il codice plugin di Mac è un po' più solido.

Fuori altri due

2009-11-01T08:08:00.003+01:00

Visto che ormai erano lì, sono stati sistemati altri due crash, cosa che non ci dispiace affatto.
Velocizzato il codice layout in chiave mobile, e aggiunto il link ai diritti anche in TB.
E dopo aver reso compatibile Lightning con SM2 ora tocca all'altro grande assente: Firebug. Direi che con la versione 2.0.1 prossima ventura non ci sono più scuse per non provare questo software.

Eppoi si dice "solido"!

2009-10-31T07:41:00.002+01:00

Giornate fruttuose come questa vanno ricordate: era un pezzo che non si vedeva la soluzione di ben sei crash, di cui tre in TB, e di un hang! Direi che il codice da oggi è più solido, ed è il segnale che la nuova riunione settimanale incentrata proprio sui crash bug sta dando i suoi preziosi frutti.
Ci sono due novità da segnalare oggi: la prima è la nuova versione di sqlite (3.6.16.1) inglobata nei sorgenti per sistemare un altro crash, e soprattutto l'aggiunta della priorità alle schede durante il caricamento dalla rete: questo significa che la scheda in vista verrà caricata un po' prima rispetto a quelle non visibili. Mi sembra una cosa simpatica, specie in chiave mobile. In questo campo è stata anche sistemata una regressione delle prestazioni. Inoltre è stato risolto un problema con la navigazione anonima che implicava delle perdite di dati.
Modifiche al codice che gestisce le informazioni sulla pagina, alle intestazioni dei messaggi in TB e al codice SVG.
PS: Qualcuno che gira da queste parti si è anche avventurato in bugzilla! Bravo! :)

Shhhhhh!!!!

2009-10-23T11:15:00.004+01:00

Stanotte è stata attivata l'opzione di default smil.svg dopo una lunga attesa, e questo è il risultato:
Il resto arriverà, magari non subito, ma arriverà.

Tenendo d'occhio la concorrenza

2009-09-16T09:20:00.002+01:00

Ieri/oggi è uscita la versione stabile di Chrome3: mi pare evidente la voglia di "recuperare" il numero di versione rispetto agli altri, ma non posso non notare come l'aggiornamento di chrome sia molto, ma molto più "amichevole" (nel senso che avviene dietro le quinte senza spaventare l'utente e senza impedirgli di lavorare) e più rapido di quello di FF. Direi che sarà un aspetto da curare nelle prossime versioni. E sempre riguardo la concorrenza, da oggi è possibile far girare i mochitest anche su IE8.
Una patch di oggi rende incompatibile FF 3.7 (o come lo chiameranno per allora) con MacOS 10.4: cambiamento annunciato, ma pur sempre doloroso. Restano invece compatibili e quindi usabili le versioni 3.5 e futura 3.6, quindi c'è tempo per aggiornarsi. Nonostante questo oggi hanno sistemato la compatibilità di breakpad (il programma di report dei crash) con i processori PPC.
Diversi cambiamenti sono stati fatti per far funzionare meglio Fennec su WinCE, specie con poca memoria.
Aggiornata la libreria liboggz, risolto un problemino con i file molto grandi nel codice di rete, risolto un altro problema con le date in JS, il tutto mentre si sta lavorando alacremente per sistemare un problema di sicurezza che chiamano "frame poisoning".

In arrivo una nuova beta di TB3

2009-09-12T11:25:00.002+01:00

Mi pare assolutamente evidente che la nuova beta di TB3 sarà molto, molto interessante, se non altro perché oltre ai cambiamenti strutturali di cui vi ho parlato ieri, sono seguiti oggi una vera e propria marea di cambiamenti visuali... Sarà una versione da vedere e da provare con attenzione direi. E' rimasto comunque il tempo per sistemare un paio di problemi nell'interprete JavaScript e un bel buco di sicurezza nel decoder delle immagini GIF.

Un cambiamento importante

2009-09-11T09:18:00.004+01:00

Purtroppo non trovo mai il tempo di scrivere ogni giorno, nonostante ci siano ancora diverse cose grosse che si "agitano" nei sorgenti di mozilla, ma alcune volte gli eventi sono troppo grossi per lasciarseli sfuggire: da oggi entrano a far parte dei sorgenti mozilla altre due librerie molto note nel mondo OSS, protovis e jQuery. Nello specifico, si tratta di aggiunte per TB3, ma credo che ben presto verranno propagate anche altrove, specie per incrementare l'utilizzo di animazioni nell'interfaccia senza dover riscrivere tutto da capo. Di certo TB3 diventerà una bella base su cui mettere su estensioni anche belle graficamente oltre che complesse, in bocca al lupo!
Approfitto per segnalare un altro po' di cosucce: sistemati alcuni problemini grafici con Qt, sistemati altri problemi con il session restore, tolto per ora di mezzo gloda su SM (su TB3 è diventato di default da un paio di giorni), sistemato un problema col salvataggio delle pagine in SM, nuove icone qute per TB3 sotto Vista, rimosso un controllo di sicurezza inutile in JS, sistemato un buco di sicurezza, aumentata di 8 volte la velocità di rendering del testo sotto WinCE (cairo per Fennec, con altre ottimizzazioni in arrivo), abilitato Satchel (memorizzazione e autocompletamento dei moduli del toolkit) per TB3 e risolto un crash SVG.

Leccornia

2009-09-01T13:17:00.004+01:00

Un post velocissimo per segnalare che ora anche SM2 può usare le schede dal lato Posta, proprio come TB3, grazie alla chiusura del bug cui ha lavorato Mnyomyr (aka Karsten Düsterloh): una semplice patch di 270Kb... Questo spiana la strada all'utilizzo di Lightining in SM2, in un prossimo futuro.

Edit: aggiungo anche che è stata implementato in SM2 il drag&drop delle mail in formato .eml (finalmente...).

E ora in vacanza!

2009-08-04T06:15:00.003+01:00

Ultimo aggiornamento fino a fine mese, causa meritatissime ferie.
Sistemato l'uso del nuovo password manager con Composer (SM). Lavoro certosino sul Mac per sistemare diversi problemi di refresh delle finestre/barre/layout. Risolto un bel crash nel decoder video, e sistemata la ricerca dei nomi con apostrofo nella rubrica. Finalmente ora si può compilare tutto su Vista e seguenti senza usare UAC, ed è stato sistemato un problema con il sistema di build MSYS. Lavori in corso sull'autosync di TB3.
Visto che c'erano hanno sistemato anche un paio di buchi di sicurezza (quelli trovati al Defcon? Boh!).
Buone vacanze!

Aggiornamento pre-vacanziero

2009-08-03T13:36:00.002+01:00

Visto che al lavoro non mi danno tregua, me la prendo da solo...
Ho giusto il tempo per un po' di segnalazioni. In TB, l'avviso della mancanza degli allegati ora è fatto con una barra di notifica, ora è possibile navigare nel testo con le combinazioni Mela+... di MacOS, il popup identificativo è più leggibile nei temi rtl, modificati i menu contestuali per l'apertura nelle schede, risolto un problema con una libreria JS e le barre di scorrimento, rimossi alcuni #include dell'era protozoica, e sembra essere sistemato un problema di SM con lo ShellService.
Ma la cosa più evidente è la nuova versione di libvorbis che è stata integrata per risolvere un problema di sicurezza, ma come al solito mancano ulteriori dettagli.

Finalmente roba succulenta!

2009-07-21T06:17:00.003+01:00

Era da un po' che non riuscivo a trovare il tempo di fare una bella carrellata di bugfix, e temo che continuerò a farne poche per un po', ma oggi ci sono state diverse leccornie da riportare...
Cominciamo con la ristrutturazione completa delle strutture dati che gestiscono le immagini, ora completamente stravolte e quindi incompatibili con 1.9.1: davvero una patch enorme (280Kb!) che ha segato via due strutture e >3000 linee e ne ha rimesse >2000, una discreta sforbiciata. Vedremo se la vastità dei cambiamenti produrrà problemi collaterali.
Altra novità è l'ennesima revisione dell'interfaccia per ciclare le tab con Ctrl+Alt, sempre più affinata ma ancora nascosta: giocate con browser.ctrlTab.previews e browser.allTabs.previews. Strano vero come una funzione delle schede viene così affinata con tanto lavoro quando un po' di tempo fa sempre da mozilla si diceva che le schede erano morte...
Altra cosa interessante, segnalata da più parti, è la perdita di cookie dopo un po' di tempo: si sta cercando una soluzione definitiva, ma non è ancora del tutto a posto. Altra soluzione non ancora definitiva ma in sviluppo è il cambiamento per evitare che TB e SM bombardino l'utente di richieste di password quando si usa una password generale: TB3 ha usato un trucco per aggirare il problema, e forse lo farà anche SM2 se questa modifica non verrà accettata per 1.9.1.
Si lavora ancora per rimuovere la compatibilità con Win16 (sic!). Il sistema di update non metteva a posto i permessi dei file in maniera corretta. Un pezzo di sistema di build adesso viene ricreato anche su Win32. E' stato modificato anche un precedente fix per aderire alle specifiche HTML5 (in pratica è stato disfatto ciò che era stato sistemato prima).
Sistemati un paio di bug che riguardano la ricerca nei messaggi in locale del lato posta e anche il compartamento della posta riguardo i messaggi eml esterni. Sistemati alcuni fastidiosi warning.
Ora la geolocalizzazione può essere ricordata, dimenticata, disabilitata nella finestra Informazioni sulla pagina anche di SM2.

Rapido per leccarsi le orecchie

2009-07-16T16:04:00.002+01:00

Prendendo spunto da questo post, ecco come mettere a dieta FF 3.5 sotto linux.
Scaricate da qui l'eseguibile di sqlite, scompattatelo nel vostro profilo di FF, e create un file di testo (ad esempio inifx.sh) dentro di esso con questo contenuto:

#!/bin/bash
for file in `dir -d *.sqlite` ; do
./sqlite3-3.6.16.bin "$file" "VACUUM"
done

Mettete i permessi ad entrambe i file con un chmod 755, e lanciate lo script (ad esempo: ./inifx.sh).
Il disco frullerà un po', e alla fine vedrete che dieta! :)
Ovviamente fate il tutto a vostro rischio e pericolo!!!

Ma la scorsa settimana?

2009-06-08T14:33:00.001+01:00

NO COMMENT! :)

Prolungamento a domenica

2009-05-23T07:06:00.002+01:00

Le build per RC cominceranno da domenica, visto che la lista di blocker piuttosto lunga (quasi 60) si è quasi polverizzata, e si vuole quindi fare sedimentare un attimo tutti i cambiamenti.
Sono stati resi accessibili i controlli per l'audio/video, è stato corretto un crash con i plugin, risolta una regressione con firebug e un'altra con greasemonkey e la nuova finestra di dialogo Pulisci cronologia è stata sistemata meglio. Nuova versione di NSS (3.12.3), che prevede altri certificati root preinstallati e che genera simboli di debug quando serve come tutto il resto del codice.
Le informazioni sul locale sono state spostate altrove per poter avere prodotti localizzati in più lingue, e semplificare altrove.
Altro passo avanti per la compilazione automatica delle versioni localizzate di TB/SM/Calendar, che ora forniscono anche dati sul changeset di Mercurial da cui sono state compilate.
Ed è stato trovato del tempo per sistemare anche un paio di buchi di sicurezza, tanto per gradire.

Parecchia roba succulenta

2009-05-20T01:45:00.004+01:00

Si procede spediti verso la RC, e quindi ritroviamo parecchia carne al fuoco, a cominciare da ben tre buchi di sicurezza sigillati. Inoltre sono stati risolti due crash, il primo in places (grazie Marco!) e il secondo nei widget XUL. Sempre in places, abbiamo visto sistemare le query della cronologia, passate secondi a millisecondi, l'impossibilità di cancellare i segnalibri smart e di operare sul campo data (ancora grazie Marco!), mentre la navigazione anonima ha guadagnato una bella finestra di dialogo che compare senza far diventare il sistema una lumaca. Migliorato anche il cycle collector, sistemato il comportamento del localStorage con i cookie, corretto un problema di drag and drop nella navigazione a schede, risolto un problema con il sito di Procter&Gamble, risolto un altro problema con la geolocalizzazione, e sistemati i controlli video HTML5 nei temi RTL (da destra a sinistra).
Risolto un problema col tema per XP e una regressione nella gestione del colore di Windows 7.
Il plugin per supportare Java sotto Mac OS è stato aggiornato (e ha permesso di risolvere parecchi problemi).
Per SM, forse è stato risolto un problema di test che fallivano ad intermittenza, e una modifica al sistema di build Windows è stata adottata anche per le versioni definitive di FF, visto che semplifica tutto il processo di rilascio.
Per TB, oltre ad essere state inserite una pletora di patch riguardanti calendar, è stata introdotta e gestita una preferenza per chiudere la finestra dei messaggi invece di passare al prossimo quando si elimina il messaggio (interessante... speriamo venga portata su SM), è stato sistemato lo scaricamento dei messaggi per singolo account anche quando viene usata la cartella globale, e il tema Windows ha guadagnato nuove icone più standard per la lista dei messaggi.

Viva la RC! :)

2009-05-18T10:39:00.002+01:00

Per fortuna che siamo vicini alla Rc, altrimenti questi ci cambiavano gecko 2 giorni prima del rilascio della 3.5! :) Oggi hanno messo dentro una enorme patch che sistema un bug del lontano 2002 nel codice che gestisce le tabelle, e chiude anche ben 21 sottobug, credo sia un record!
Una bella notizia è che un altro crash con il plugin flash è stato eliminato, e un'altra bella notizia è che è stato chiuso un bel leak in places.
Nel mentre, si prepara SM2 a ricevere il trattamento l10n, cioè a gestire le build automatiche localizzate...
A proposito, la RC di FF 3.5 dovrebbe vedere la luce lunedì prossimo, se tutto va bene.

Nuova grafica in arrivo, ma...

2009-05-15T15:38:00.006+01:00

Ok, la nuova grafica del logo di Firefox mi sembra davvero carina, e trovo bella l'idea di esaltare l'aspetto "fire". Ma visto che ultimamente ho messo un po' le mani dentro il tema modern di SM2, che deve utilizzare parecchia roba dei temi di FF, capisco bene perché alcuni sviluppatori si siano rifiutati di mettere le mani dentro il toolkit... Non vi sto ad elencare la quantità di icone duplicate, o inserite in formati diversi che oramai è diventato quasi impossibile togliere a causa dell'utilizzo che ne fanno alcune estensioni, ma forse sarebbe il caso di fare un po' di pulizia.
In alcuni casi poi, certe scelte sono di una stupidità che rasenta l'idiozia. Facciamo un bell'esempio pratico fornitomi oggi su IRC. Prendiamo l'immagine che serve per dare il "rating" delle estensioni:
A seconda del voto, si prende la riga che serve, tramite css. Qualcuno vede come la cosa sia idiota? No?
Seguitemi!
Per prendere un pezzo dell'immagine tramite css devo fare un rettangolo "visibile", giusto? Ma allora che bisogno c'era di fare un'immagine così grande? Se metto tutto su una riga, non ottengo lo stesso identico risultato con un'immagine ben più piccola?
Ed ecco a voi la soluzione:Il rettangolo invece di farlo scrollare in verticale lo sposto in orizzontale e ottengo la stessa identica cosa!
Vediamo le differenze: la prima immagine è 78x108 per un totale di 4516 byte, la seconda invece è 120x12 per 878 bytes, cioè un quinto esatto.
Altro esempio: il file con le iconcine per il download manager e per lo scaricamento degli update è identica (buttons.png o downloadButtons.png a seconda del tema), quando basta modificare una sola voce del file jar.mn usato per creare la build per impacchettare una sola copia del file (e modificare il riferimento nel css): 2288 (o 3244) byte inutili. Vi ricordo che le immagini sono già compresse, quindi è tutto peso che togliete direttamente dall'installer, e al momento di caricare l'applicazione.

E due!

2009-05-07T11:08:00.002+01:00

Vi ripropongo un altro articolo che può tornare utile a chi si vuole avvicinare a bugzilla, l'applicazione che tratta tutti i bug di mozilla, piccoli, grandi o solo presunti. Lo faccio prima che cambino alcune carte in tavola, almeno la base c'è.
________________________

1. Aiutiamo Mozilla

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.).

2. La scoperta di un bug

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).

3. Primi passi su Bugzilla

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...

4. Evoluzione di un bug

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.

5. Vita da patch

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:

r+: significa che è andata a buon fine e che il revisore non ha nulla da eccepire
r+ soggetta a modifiche: significa che la revisione è stata positiva, ma a condizione che vengano effettuate le modifiche proposte nel commento
r-: significa che è abbiamo scritto qualcosa di davvero pessimo e tocca ricominciare da capo...

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! :-)

6. Risolto!

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!

7. Ringraziamenti

Un grazie alle persone che mi hanno spinto ed aiutato a scrivere questo documento, in ordine sparso:

Iacopo Benesperi
Francesco Lodolo
Giuliano Masseroni
Michele Dal Corso

Uno di due

2009-05-07T10:44:00.002+01:00

Un veloce aggiornamento per informarvi che la geolocalizzazione sta ricevendo gli ultimi numerosi ritocchi prima dell'uscita ufficiale di FF3.5. Tolto di mezzo anche del codice inutile per Mac, corretto il funzionamento degli acceleratori con OS X, sistemata la resa dei colori di alcuni file PNG, risolto anche un problema con i feed RSS, e modificato il funzionamento dei prefetch DNS con i server SOCKS. Chiuso anche un buco di sicurezza (relativo a Java? Mah... Detesto non poter legger subito i dettagli).

Rifiniture a tutto

2009-05-05T05:33:00.003+01:00

Tolto di mezzo un file usato per il vecchio filtro antiphishing di FF2, oramai inutilizzato (e così non va più tradotto), e sono stati sistemati due problemi con il recupero delle sessioni, di cui uno specifico per Mac. In SM è stata sistemata la visualizzazione del corpo dei messaggi dei feed, e ora (dopo aver fatto ingoiare le patch necessarie) viene utilizzato il toolkit standard per personalizzare le barre degli strumenti. Invece per TB (e mailnews in generale in certi casi), ci ritroviamo delle icone nuove sotto Linux, l'autocompletamento dei tag ora funziona meglio, l'evidenziazione della sintassi nella visualizzazione del sorgente dei messaggi è stata disabilitata, il funzionamento dell'indicizzazione global data (gloda) è più performante, alcune routine interne del codice IMAP ora consumano meno tempo e memoria per svolgere il loro lavoro e il tema del Mac è migliorato nei sistemi RTL (da destra a sinistra, come l'arabo o l'ebraico).
Fallito invece l'inserimento del nuovo campo di ricerca, integrata con gloda, nella barra degli strumenti di TB3: errori a raffica e patch tolta dopo pochi minuti, nell'attesa di capire meglio cosa è andato storto.

2 "cosette" rapide

2009-04-30T14:46:00.002+01:00

Vorrei fare presente a voi tutti due patch molto interessanti, una che mi è sfuggita qualche giorno fa, e l'altra appena arrivata. La prima è l'implementazione di migliori serializer per il codice XHTML e XML: la prima conseguenza è che sia Composer che la visulaizzazione dei sorgenti dovrebbero generare/far vedere del codice molto più bello a vedersi. La seconda patch invece aggiunge a SM2 la possibilità di gestire i feed dal lato browser, l'ultima grande differenza con FF è sparita: credo che la prima beta di SM2 sarà molto succulenta, e attirerà più di uno sguardo...

FF in orario, TB in ritardo

2009-04-29T10:12:00.002+01:00

Ieri è uscita sia la quarta beta di FF3.5 in perfetto orario, sia l'aggiornamento a FF 3.0.10 che risolve un problema di sicurezza e diversi di stabilità. Una parola, quest'ultima, che ha assunto un significato speciale per il sottoscritto: ieri ho usato FF3.5b4 tutto il giorno, e mi esploso in faccia 4 o 5 volte (in 3 casi mi ha permesso di inviare il dump), appena meno di quanto non mi esploda in faccia (con Flash sperimentale) la mia build casalinga a 64 bit di SM2 (dove breakpad non funziona perché non supporta i 64 bit, complimenti...). E devo dire che la cosa non mi ha affatto reso felice. Oggi la OpenSUSE ha fatto uscire un aggiornamento di gtk2 che dovrebbe sistemare un crash relativo proprio a FF, vedremo oggi come va. Cattive notizie invece in casa TB3: ieri è stato annunciato che ci sono troppi blocker aperti, ovvero bug che impediscono l'uscita di TB3, e quindi hanno rimandato la prossima beta3 "di diverse settimane" senza specificare quante: un brutto colpo, ma che ha permesso la correzione di un bug fatta dal sottoscritto. Nel frattempo vi segnalo altre cosucce interessanti: allargata la finestra della gestione account (così non dovremo farlo nelle localizzazioni, forse), ripuliti alcuni test di leak errati e altri in python, risolto un crash sotto OS/2, e infine è stato risolto uno strano problema per cui quando si mandava in stampa una pagina, venivano ricaricate le applet Java. In ultimo, ma non per importanza, è stato aggiunto il supporto allo scanning delle reti wifi sotto Windows Mobile (Fennec).

Tra alberi e rami

2009-04-28T10:54:00.003+01:00

NB: vi ripropongo un vecchio articolo che però trovo possa essere sempre utile a capire alcuni termini tecnici. Un po' lunghetto, spero di non annoiarvi.

--------------------------------------------------

Una introduzione a tutti i termini utilizzati nel mondo Mozilla quando si parla di versioni dei vari prodotti, con una spiegazione (anche storica) della scelta di alcuni termini.

Il muro linguistico

Capita a volte di appassionarsi a un progetto o a un'idea e spontaneamente essere colti dalla curiosità di saperne di più. Come in tutti i campi, anche nel mondo legato ai computer il più grande ostacolo per i non addetti ai lavori è costituito dalla barriera linguistica: non tanto dalla lingua Inglese, quanto dai termini prettamente tecnici. Come si cerca di superare un attimo le notizie generiche, ad esempio quelle che leggiamo su giornali e riviste, per scendere un po' più nel dettaglio, ci si incaglia subito su termini a prima vista sconcertanti e confusi. Prendendo come base il progetto Mozilla (Firefox e compagnia varia), cercheremo di fare un po' di chiarezza al riguardo, soprattutto per capire meglio come procede lo sviluppo di una base di codice così ampia e complessa, fatta di tanti piccoli pezzi incastrati insieme.

Analogie vegetali

Quando si parla di progetti Open Source, si parla spesso di "albero" e un po' meno spesso di "ramo", specialmente in abbinamento con "di sviluppo" oppure "stabile". Cerchiamo subito di chiarire questi termini. L'albero (in Inglese: "tree", oppure "trunk") non è altro che l'insieme di tutti i codici sorgenti di cui consiste un progetto, e prende tale nome perché la struttura, ovvero come questi codici sono catalogati e messi in relazione gli uni con gli altri, ricorda molto quella quasi gerarchica di un albero: abbiamo una radice (ad es. "mozilla/") che rappresenta la cartella principale che comprende tutti i sorgenti facenti parte del progetto, e quindi i vari tronchi e fusti (ad es. "mail/" per i sorgenti di buona parte di Thunderbird, o "browser/" per buona parte di Firefox). Tale struttura poi si esplica ancora meglio vedendo come i sorgenti sono organizzati in un file system tradizionale fatto di file e cartelle gli uni dentro le altre e così via, come possiamo vedere in figura:

mozilla/[root] (dimensione) (ultima modifica)
│ LEGAL 2k Aug 21 13:10
│ Makefile.in 5k Dec 6 02:10
│ README.txt 9k Mar 13 2004
│ aclocal.m4 687 Dec 20 2005
│ allmakefiles.sh 456k Dec 3 08:10
│ camino.mk 1k Nov 24 2004
│ client.mk 37k Dec 7 17:10
│ configure 638k Dec 4 22:10
│ configure.in 260k Dec 4 22:10
│ embed.mak 2k Sep 13 2005
│ embed.mk 4k Sep 13 2005
│
├───README/ - Dec 8 11:11
│ └───mozilla/ - Apr 19 2006
│  README.build 87 Dec 1 2001
│ README.os2 9k Apr 19 2006
├───accessible/ - Dec 8 11:11
.
.
.
.
└───xulrunner/ - Dec 8 11:11
 │ Makefile.in 1k Oct 5 2005
 │ build.mk 2k Oct 25 16:11
 ├───app/ - Apr 19 2006
 .
 .
 .
 └───stub/ - Apr 19 2006

Ho volutamente tralasciato il termine "ramo" perché esso rappresenta un concetto un po' diverso. Nel campo dello sviluppo di software infatti, un ramo (o "branch") è una versione particolare dell'albero o di parte di esso; spieghiamoci meglio. Durante lo sviluppo di Firefox, gli sviluppatori decidono che è giunta l'ora di fare uscire una nuova versione stabile del browser, diciamo la 2.0: stabiliscono quindi una data e un'ora esatta in cui verrà "tagliato" (in Inglese: "cut") il ramo 2.0 dall'albero principale. Il taglio del ramo consiste nel fare una "fotografia" dello stato attuale dei sorgenti, marcandoli con una stringa particolare: nel caso di Firefox tale stringa è "MOZILLA_1.8.1" che fa riferimento alla versione di Gecko (il motore grafico che genera le pagine a video) utilizzata dal browser. Una volta tagliato un ramo, lo sviluppo continua sia sull'albero principale, detto di sviluppo, sia sul ramo che di solito viene chiamato "stabile", perché in esso non vengono accettati grossi cambiamenti che potrebbero appunto metterne in pericolo la stabilità. Per essere più precisi, in un ramo stabile non vengono più accettate nuove funzionalità, né riscritture o miglioramenti delle funzionalità esistenti, ma solo le correzioni ai bug che non mettano a rischio la stabilità del codice (talvolta capita che chiudendo un buco da una parte si apra una voragine dall'altra), né sono permesse modifiche a come il software "comunica" con gli utenti (ad es. non è possibile modificare la spiegazione di un errore o il testo che compare in una finestra di avviso). Se gli sviluppatori ritengono che una modifica del trunk sia necessaria sul branch, devono valutarne il rischio ed in alcuni casi preparare una versione specifica della patch (una modifica ai codici sorgenti) da mettere nel ramo. Ciò accade perché lo sviluppo sul trunk non si interrompe mai, e quindi le versioni dello stesso file tra trunk e branch possono risultare anche molto diverse.

Cerchiamo di spiegarci con un esempio pratico.

Al momento della creazione del ramo, supponiamo che il file superBrowser.cpp (un file sorgente in C++ in questo esempio) sia alla versione 1.22: lo sviluppo sul trunk continua ed il file viene aggiornato più volte, cambiando numero di versione (1.23, 1.24, 1.25, ecc.), mentre sul ramo stabile essa rimane alla versione 1.22.0. Un bel giorno uno sviluppatore trova il modo di sistemare un bug che affligge superBrowser.cpp da prima della versione 1.22 (supponiamo un bel crash del browser) e propone una patch per il trunk: la patch viene controllata, approvata e applicata al trunk che ora non va più in crash per quel caso particolare. Gli sviluppatori sono molto soddisfatti della modifica e pensano che sia utile averla anche sul branch stabile: peccato che superBrowser.cpp versione 1.35 sia molto diverso da superBrowser.cpp versione 1.22. Deve quindi essere preparata una patch a partire da superBrowser 1.22 che sistemi lo stesso bug: anche questa patch viene analizzata, testata, approvata ed inserita sul ramo stabile, e superBrowser passa alla versione 1.22.1.

Ciò avviene per tutte le migliaia di file dell'albero! Sembrerebbe a prima vista una cosa complicatissima, ma in pratica non lo è affatto: sono infatti i tool di sviluppo come RCS (revision control system) e CVS (concurrent versioning system) che si prendono cura di gestire tutte le problematiche relative alla varie versioni stabili o meno dei sorgenti.

Eredità storiche

Passiamo ora a un'altra fonte comune di confusione, le versioni "stabili" e le versioni "nightly" degli eseguibili. Le prime altro non sono che le versioni ufficiali rilasciate da Mozilla dei suoi prodotti, ovvero 1.0, 1.5, 2.0 e tutte le relative revisioni di sicurezza (come 1.5.0.8, 2.0.0.1, ecc.). Le revisioni vengono tutte da uno stesso ramo: FF 1.5.0.x deriva dal branch 1.8.0, mentre FF 2.0.0.x deriva dal branch 1.8.1. Per chi è particolarmente curioso oppure impaziente, è possibile provare le versioni nightly. Storicamente, lo sviluppo del software è sempre stato un processo molto lungo e costoso, per cui durante il giorno si preparavano le modifiche al software che poi di notte sarebbero state compilate in una nuova versione da provare il giorno seguente, e così via, ciclicamente. Questo perché il costo dei computer (e la scarsa velocità) era tale che di giorno dovevano funzionare a pieno ritmo, mentre di notte (da qui il nome "nightly") andavano sfruttati in qualche modo per poter rientrare dai costi e per non interrompere mai il loro lavoro principale. Lo sviluppo ed il testing andava fatto nei tempi morti, per evitare di sottrarre del costosissimo tempo macchina al lavoro di tutti i giorni. Attualmente invece i cicli di test e compilazione possono essere portati avanti in contemporanea o addirittura su tante macchine senza grandi costi. La perdurante lunghezza dello sviluppo quindi è data dalla complessità del software; ovvero oggi un programma fa molto, molto di più di un suo equivalente di 10 anni fa, per esempio.

Esistono diverse versioni nightly, a seconda della provenienza:

Trunk: Sono le versioni eseguibili che vengono create tutti i giorni per poter provare l'albero principale di sviluppo. Solitamente sono versioni sconsigliatissime, visto che possono causare perdite di dati ed incompatibilità di diverso genere.
Branch: Sono le versioni di prova che compaiono di frequente prima di una nuova versione ufficiale. Ad esempio, su questo tipo di nightly viene effettuato il test delle localizzazioni dei prodotti.
Experimental: Queste sono versioni particolari del software, in cui viene sviluppata una specifica funzionalità. Di solito i cambiamenti sono talmente complessi e toccano così tanti file che gli sviluppatori preferiscono portare avanti le modifiche in un ramo parallelo, detto appunto "di sviluppo". Quando lo sviluppo sembra aver raggiunto gli obbiettivi fissati, allora il ramo viene riunito all'albero principale (in Inglese: "merged to tip", oppure "merged to trunk"), e le build experimental per quel ramo smettono di essere create.

Va ricordato che qualsiasi tipo di nightly non offre alcuna garanzia circa il suo funzionamento! Potreste installare una versione che non parte nemmeno, che vi distrugge il profilo o che vi formatta l'hard disk: insomma, comunque lo fate a vostro rischio e pericolo, e non pensate di potervi poi lamentare una volta fatto il danno! Dopo questa dovuta precisazione, bisogna dire che attualmente è molto difficile trovare delle versioni nightly così devastanti: nella peggiore delle ipotesi può capitare che per diversi giorni non esca una sola nightly che parte, ma di solito basta tornare alla versione di qualche giorno prima per non aver problemi di sorta.

La parte affascinante dell'installazione delle versioni nightly è la possibilità di provare le nuove funzionalità delle future versioni di Firefox e compagnia prima che il grande pubblico ne venga a conoscenza. Provando e riprovando le varie funzioni è possibile isolare e segnalare i problemi e magari anche suggerire delle modifiche. In un certo senso si diventa protagonisti dello sviluppo di Mozilla, e del suo continuo miglioramento (si spera). Certo, anche questa possibilità ha un costo: si deve rinunciare alla stabilità dei programmi su cui facciamo affidamento tutti i giorni, per vivere sul filo del rasoio (in Inglese: "bleeding edge").

E che c'entra l'alfabeto greco?

Per completare il quadro delle sigle relative alle varie versioni del software, bisogna accennare all'uso che si fa di alcuni caratteri dell'alfabeto greco. Si sente infatti parlare spesso di versioni "alfa" oppure "beta": che cosa indicano? Sempre storicamente, durante lo sviluppo di un software la designazione alfa ha riguardato il periodo che di solito segue una versione stabile e che segna l'inizio dei cambiamenti in vista della versione stabile successiva. E' il periodo in cui gli sviluppatori hanno più mano libera nella creazione del software, in cui non hanno grandi limitazioni e possono permettersi di mettere le mani e devastare, se lo ritengono necessario, tutto il codice che aveva funzionato fino al giorno prima... Insomma, se nella vita del software ci deve essere un periodo di grandi cambiamenti, aggiunte di funzionalità, o riscritture complete o quasi di funzionalità già esistenti, tutte queste prendono il via con le versioni alfa.

Dopo la "furia creativa" del periodo alfa, viene il periodo "beta", in cui si cerca di evitare l'aggiunta di funzionalità nuove, e si passa ad una fase di rifinitura e messa a regime di quanto fatto. Spesso la decisione di passare da alfa a beta coincide col raggiungimento degli obbiettivi di progetto programmati per la nuova versione stabile del software, ovvero quando tutte le nuove funzionalità previste sembrano essere state implementate, magari anche solo parzialmente. Durante la fase beta, il software viene sottoposto a prove sempre più esaustive per correggere il maggior numero di problemi e difetti (nessun software è privo di difetti). Questa viene anche detta la fase di ripulitura: il codice viene mondato dalle scorie dello sviluppo (funzionalità parzialmente implementate o scritte in maniera oscena pur di rispettare i tempi di consegna, ad esempio), vengono eliminati i bachi (difetti, in Inglese: "bug") più fastidiosi e vengono rifiniti per esempio l'interfaccia grafica ed i messaggi verso l'utente. Di solito è la fase più lunga e quella meno amata dagli sviluppatori che già stanno pensando alla loro futura nuova funzionalità (e magari hanno creato un branch sperimentale apposta).

Quando la situazione sembra accettabile, il prodotto sembra usabile e le nuove funzionalità sembrano lavorare a dovere, gli sviluppatori decidono di creare un nuovo branch stabile, come spiegato prima, e tutto il ciclo ricomincia. In passato oltre la fase beta c'era anche la fase "gamma", ovvero la fase di prova definitiva prima dell'uscita della versione ufficiale. Oggi di solito si usa la dicitura "Release Candidate", versione candidata ad essere pubblicata, ovvero la versione che sarà la prossima versione ufficiale a meno che non vengano scoperti problemi che rendano necessaria una ulteriore Release candidate. Nel mondo Microsoft a tale fase spesso ne segue un'altra che si chiama RTM (release to manifacture, ovvero "versione inviata alla produzione"), mentre nel mondo Mozilla in passato è stata indicata da versioni "Pre-Release" o anche "Technology Preview".

Buon approfondimento a tutti!

Eredità

2009-04-23T10:07:00.002+01:00

TB ha ereditato l'icona della ricerca da FF, mettendola a buon frutto. Repulisti anche per il suo codice della barra di stato. Modificato il codice delle temporizzazioni in mailnews.
Sistemato un noioso bug per il debug di Javascript, un altro nella gestione dell'ordinamento dei segnalibri e uno con il download dei file di aggiornamento.
Infine, sistemato un problema con il compilatore JS JIT sotto Sparc.