Aiuto! Di cosa parlano questi sviluppatori?

di Asa Dotzler

Contenuti


Introduzione

Innanzitutto, ci sono alcuni termini che dovresti conoscere

CVS
dove vengono conservati i file del sorgente di Mozilla
tree (albero)
un gruppo di file in CVS
pull
scaricare un tree da CVS
check in
aggiornare dei file in CVS con una nuova versione per correggere dei bug
trunk (tronco)
il gruppo principale, la linea principale di sviluppo dei file in CVS dove avviene il lavoro
tip (punta)
la versione più aggiornata dei file del trunk in CVS
tag
un insieme di file con una versione definita, che permette di scaricare da CVS i file del sorgente come erano al momento della creazione del particolare tag
branch (ramo)
una copia dei file del trunk, ospitato in cvs.mozilla.org, che può continuare ad essere sviluppata in modo indipendente dal trunk
cut a branch (tagliare o far deviare una diramazione)
fare una copia dei file del trunk per creare un branch.
freeze (congelamento)
un periodo in cui il tree non è aperto ai check in o in cui i check in devono ricevere una particolare approvazione.
fork (biforcazione)
una copia del codice sorgente, ospitata al di fuori di cvs.mozilla.org, che è stata fatta divergere nello sviluppo in modo significativo dal trunk.

Torna ai contenuti

Come funziona lo sviluppo di Mozilla?

Come la maggior parte di voi sa, mozilla.org crea delle “build” compilando il codice sorgente più volte al giorno (chiamate nightly, visto che in genere vengono sfruttate le macchine lasciate libere durante la notte). Queste sono il risultato di un “pull” del codice sorgente dal server cvs.mozilla.org. Le nightly build regolari sono un pull del “tip” del trunk in CVS. Questo significa che le nightly build includono tutte le modifiche più recenti incluse (“checked in”) nel tip. A mozilla.org lo sviluppo viene interrotto ogni giorno per creare queste build e verificare che le modifiche apportate con i check in del giorno prima non abbiano creato ulteriori problemi ed eventualmente per identificarne le cause.

Ad intervalli di approssimativamente 5 settimane noi drivers@mozilla.org assumiamo il controllo del trunk per alcuni giorni in modo da stabilizzare l’applicazione, creando un “branch” di breve durata. Tutti i check in durante questo periodo di “freeze” richiedono l’approvazione da parte dei drivers@mozilla.org. Nonappena riusciamo ad ottenere una build stabile e abbiamo raccolto un gruppo ristretto di bug che consideriamo come i più importanti per la milestone (= pietra miliare, la versione di rilascio – n.d.T.), viene creato un branch. Subito dopo il cut del nuovo branch, il trunk viene riaperto allo sviluppo, in modo che gli sviluppatori non abbiano più la necessità di richiedere il permesso per ogni modifica. Alcuni sviluppatori lavorano di concerto con i drivers@mozilla.org per cercare di correggere i bug che ancora impediscono il rilascio della milestone, incorporandoli poi nel branch. Nel frattempo la maggioranza degli sviluppatori è tornata a concentrarsi allo sviluppo del trunk. Una volta che i driver pensano che la milestone sia pronta per il pubblico uso e consumo, viene creato un release tag nel branch. Questo tag è un marcatore che identifica la versione di tutti i file richiesti per creare la build finale della milestone. Viene quindi creata una build dal tag creato e le persone che erano impegnate nella milestone ritornano a lavorare sul trunk. Grosso modo queste sono le basi su cui avviene lo sviluppo del trunk e dei branch.

Torna ai contenuti

Come si pone tutto ciò in confronto alle release commerciali?

Un distributore commerciale può portare avanti il suo lavoro sul codice di Mozilla in vari modi, in privato o in pubblico. Entrambi i processi mostrano i loro vantaggi e svantaggi.

Mantenendo lo sviluppo privato un distributore commerciale può eseguire un pull da cvs.mozilla.org, lavorare a porte chiuse e (per rispettare i termini della nostra licenza sul codice sorgente) rendere disponibile le modifiche ai file di Mozilla una volta rilasciato il prodotto. Penso che il vantaggio principale per questo tipo di sviluppo sia che il distributore commerciale può utilizzare il proprio processo di sviluppo, invece di quello utilizzato da mozilla.org. Questo gli da la libertà di effettuare modifiche che non verrebbero accettate all’interno del codice di Mozilla. Esistono diversi svantaggi con questo metodo. Primo, il distributore commerciale non ha accesso alle risorse di mozilla.org quali tinderbox, le nightly build di Mozilla, e i controlli effettuati dall’intera comunità sul prodotto. Secondo, il distributore commerciale può creare modifiche al proprio codice sorgente, tali da renderlo incompatibile con il trunk di Mozilla. Questo creerà maggiori difficoltà per il distributore commerciale nel applicare le correzioni e le aggiunte successivamente apportate al trunk e viceversa riutilizzare le modifiche apportate al proprio codice nel trunk di mozilla.org. I vari distributori possono utilizzare questo metodo dosando differentemente l’entità della parte privata del lavoro. Alcuni di questi creano un “fork” ad ogni milestone di Mozilla, o il più frequentemente possibile, cercando di mantenere il proprio tree molto simile a quello di Mozilla. Questo rende molto più agevole l’interscambio di correzioni tra i due. Lo sviluppo di Penzilla della OEone è un buon esempio di questo tipo di fork. I loro sviluppatori hanno lavorato per un po’ sul codice di una milestone, quindi hanno portato i risultati dei loro sforzi su di una milestone successiva. Altri distributori commerciali creano una volta per tutte un fork, spingendo tale codice in una direzione radicalmente diversa dallo sviluppo di Mozilla. Lo sviluppo di Komodo della Active State è un buon esempio di quest’altro tipo di fork. In entrambi i casi, il fruitore del codice è tenuto a rendere pubbliche tutte le modifiche apportate ai file di Mozilla, una volta rilasciato il prodotto completo. Un fork a cui siano state fatte modifiche radicali, una volta si desideri integrare nuovamente il codice con quanto sviluppato nel frattempo da mozilla.org, può trovare un percorso assai difficile, tale a volte da rendere tale strada non più conveniente.

Seguendo il processo pubblico, i distributori commerciali apportano le proprie modifiche al tree di Mozilla. Queste modifiche devono passare attraverso due livelli di approvazione da parte di mozilla.org (review e super-review da parte di sviluppatori addetti alla verifica di parti specifiche del codice), e durante i freeze, un processo di approvazione atto a ammettere solo correzioni critiche. Queste modifiche possono essere applicate (effettuare il land di una modifica) al trunk o ad un branch di Mozilla. In entrambi i casi le modifiche vengono rese pubbliche attraverso l’archivio in cvs.mozilla.org. Le milestone di Mozilla sono appetibili per un distributore commerciale in quanto parte del lavoro di stabilizzazione è già avvenuto nel branch. Ciò rende più facile creare una release commerciale stabile da un branch. Può capitare che una release commerciale sia costituita dal codice di un milestone tag e qualche modifica marginale. Un esempio di questo tipo è Beonex Communicator. Altri distributori commerciali hanno la necessità di apportare un gran numero di modifiche o alcune modifiche profonde per progetti a lungo termine, quindi continuano a lavorare sul branch di una milestone anche dopo che mozilla.org ha finito di lavorarci sopra. Per Netscape 6.1 ad esempio, Netscape ha continuato ad apportare check in tramite CVS nel branch pubblico di Mozilla 0.9.2, dopo che questa era già stata rilasciata da mozilla.org. Tale lavoro sul branch sfociò nel tag CVS 0.9.2.1, utilizzato come base per il prodotto commerciale di Netscape. Il vantaggio più evidente di questo tipo di sviluppo è che le modifiche, essendo disponibili pubblicamente prima che il prodotto commerciale sia pronto, rendono la loro integrazione progressiva nel trunk molto più facile. Un secondo vantaggio è che altri distributori commerciali possono partecipare e trarre vantaggio dagli sviluppi che nel frattempo avvengono nel branch della propria release. Red Hat, ad esempio, è stata in grado di integrare una build di 0.9.2.1 (il tag di Mozilla equivalente a Netscape 6.1) in una delle loro release. Le release create da questo tag sono risultate decisamente più stabili e curate della precedente milestone 0.9.2.

Torna ai contenuti

Quindi qual è il ruolo di Netscape?

Netscape continua a partecipare allo sviluppo nella forma pubblica. Finito lo sviluppo di 0.9.4, da cui è stata ricavato Netscape 6.2, i loro sviluppatori hanno lavorato contemporaneamente sul trunk di Mozilla e sul branch 0.9.4. Netscape avrebbe potuto semplicemente prelevare il tag di 0.9.4 ed effettuare tutto il lavoro in un proprio fuori da occhi indiscreti (realizzando un piccolo fork), ma ciò sarebbe alla fine risultato per Mozilla un’occasione mancata. Se loro avessero creato un fork privato, sarebbe poi risultato ben più faticoso per mozilla.org riportare qualsiasi modifica nel branch di 0.9.4, di cui possono trarre beneficio altri distributori e sviluppatori. Nonostante la licenza obblighi a rendere pubbliche tali modifiche, il lavoro svolto sul sorgente di Mozilla probabilmente non sarebbe stato direttamente reintegrabile in cvs.mozilla.org. In aggiunta a distributori commerciali quali RedHat e OEone, ne esistono altri per cui risulta utile sviluppare plug-in e altre componenti aggiuntive (ad esempio Sidebar e temi) compatibili con le release commerciali maggiori. Avendo accesso al tag di Mozilla su sono basate cui tali release facilita grandemente il lavoro di sviluppo.

I processi produttivi e le licenze di Mozilla consentono diversi approcci al fine di arrivare ad un prodotto finale basato su Mozilla. Tenere traccia dei bug e del lavoro di sviluppo su branch multipli può risultare difficoltoso, il nostro flusso di lavoro ed i nostri strumenti dovranno evolvere per supportare questo tipo di sviluppo, ma è un netto vantaggio per la comunità degli sviluppatori e per i distributori commerciali quando tutto ciò avviene mantenendo il lavoro in cvs.mozilla.org tramite un processo pubblico. Netscape ha la necessità di compiere un lavoro di stabilizzazione sul codice di Mozilla prima del rilascio di Netscape 6.x ed ha la necessità di compiere in pubblico la maggior parte di tale lavoro su branch disponibili pubblicamente.

Torna ai contenuti

Ho altre domande…

Spero che questo sia servito a spiegare in parte quello è la vita e la gestione dei branch di Mozilla. Se hai altre domande, sentiti libero di unirti alla discussione sempre in corso nei gruppi di discussione della comunità di mozilla.org e chiedere ulteriori informazioni. Io e gli altri partecipanti faremo del nostro meglio per rispondere alle tue domande.