Ubuntu è costituito da migliaia di componenti diversi, scritti in diversi linguaggi di programmazione.
Ogni componente, sia esso una libreria software, uno strumento, o un'applicazione grafica, è disponibile come pacchetto sorgente.
I pacchetti sorgente nella maggior parte dei casi sono costituiti da due parti: il codice sorgente reale e i metadati.
I metadati includono la dipendenze del pacchetto, il copyright, le informazioni sulle licenze e le istruzioni su come compilare il pacchetto.
Una volta che questo pacchetto sorgente viene compilato, il processo di compilazione fornisce dei pacchetti binari che sono i file .deb che gli utenti possono installare.
Ogni volta che una nuova versione di un'applicazione è rilasciata o quando qualcuno fa una modifica al codice sorgente che passa in Ubuntu, il pacchetto sorgente deve essere caricato nel computer per essere compilato.
I pacchetti binari finali sono poi distribuiti nell'archivio nei vari mirror in diversi paesi.
Gli indirizzi URL presenti in /etc/apt/sources.list puntano ad un archivio o un mirror.
Ogni giorno vengono implementate immagini di CD delle differenti derivate di Ubuntu.
Ubuntu Desktop, Ubuntu Server, Kubuntu ed altri, specificano un elenco dei pacchetti richiesti da montare nel CD.
Queste immagini vengono poi usate per le prove di installazione e quindi fornire un feedback per l'ulteriore pianificazione di rilascio.
Lo sviluppo di Ubuntu dipende moltissimo dalla corrente fase del ciclo di rilascio.
Rilasciamo una nuova versione di Ubuntu ogni sei mesi e questo è reso possibile solo perché abbiamo stabilito rigorose date di freeze.
Per ogni data di freeze che viene raggiunta, gli sviluppatori sono tenuti ad apportare meno modifiche devono essere anche meno intrusive.
Il Feature Freeze è la prima grande data di freeze dopo la prima metà del ciclo di sviluppo.
In questa fase le caratteristiche devono essere in gran parte attuate.
Il resto del ciclo dovrebbe essere focalizzato sulla correzione di bug.
Dopo questo, l'interfaccia utente, la documentazione, il kernel, ecc, sono congelati e viene messa fuori la versione beta che riceve un sacco di test.
Dalla versione beta in poi, vengono fissati solo i bug critici e viene rilasciata la release candidate; se non presenta gravi problemi, diventa la release finale.
Migliaia di pacchetti sorgenti, miliardi di righe di codice centinaia di collaboratori, richiedono un sacco di comunicazione pianificazione per mantenere alti gli standard di qualità.
All'inizio di ogni ciclo di rilascio, abbiamo l'Ubuntu Developer Summit dove gli sviluppatori collaboratori si riuniscono per pianificare le caratteristiche del prossimo rilascio.
Ogni funzione discussa dalle parti interessate viene scritta una specifica che contiene informazioni dettagliate circa la sua ipotesi, l'attuazione, i necessari cambiamenti in altri luoghi, come testarlo e così via.
Questo è svolto tutto in maniera aperta e trasparente, quindi anche se non si può partecipare all'evento di persona, è possibile partecipare da remoto e ascoltare uno Streamcast, chattare con gli assistenti, e sottoscrivere cambiamenti delle specifiche, in questo modo si è sempre aggiornati.
Però non tutti i singoli cambiamenti possono essere discussi in una riunione, soprattutto perché Ubuntu si basa sulle modifiche che sono state apportate in altri progetti.
Questo è il motivo per il quale i collaboratori in Ubuntu rimangono costantemente in contatto.
La maggior parte delle squadre o dei progetti usano mailing list dedicate per evitare confusione estranea.
Per un ulteriore coordinamento immediato, sviluppatori e collaboratori fanno uso della Internet Relay Chat (IRC).
Tutte le discussioni sono aperte e pubbliche.
Un altro strumento importante per quanto riguarda la comunicazione è il report dei bug.
Ogni volta che viene trovato un difetto in un pacchetto o un pezzo di infrastruttura, viene registrata una segnalazione di bug in Launchpad.
Tutte le informazioni sono raccolte in tale relazione compresa la sua importanza, lo stato e il cessionario, aggiornati quando necessario.
Questo lo rende uno strumento efficace per monitorare i bug in un pacchetto o progetto e organizzare il carico di lavoro.
La maggior parte del software disponibile attraverso Ubuntu non è scritto dagli sviluppatori stessi di Ubuntu.
La maggior parte di essa è scritto dagli sviluppatori di altri progetti Open Source e viene poi integrato in Ubuntu.
Questi progetti si chiamano "Upstream", perché il loro codice sorgente fluisce in Ubuntu, dove noi provvediamo "solo" ad integrarlo.
Il rapporto verso gli "Upstream" è di fondamentale importanza per Ubuntu.
Non è solo codice che dagli "Upstream" fluisce verso Ubuntu, ma da Ubuntu ( e altre distribuzioni) verso "Upstream" fluiscono anche gli utenti, le segnalazioni di bug e le patch.
Il più importante Upstream per Ubuntu è Debian.
Debian è la distribuzione su cui è basato Ubuntu molte decisioni di progettazione relative all'infrastruttura del packaging vengono fatte lì.
Tradizionalmente, Debian ha avuto sempre dei manutentori dedicati o squadre di manutenzione per ogni singolo pacchetto.
In Ubuntu ci sono squadre che hanno un interesse anche per un sottoinsieme di pacchetti e naturalmente ogni sviluppatore ha una speciale area di competenza, ma generalmente la partecipazione ( e i diritti di upload) aperta tutti coloro che dimostrano capacità volontà.
Essere in Ubuntu come un collaboratore nuovo non così scoraggiante come sembra può essere un'esperienza molto gratificante.
Non solamente imparare qualcosa di nuovo ed eccitante, ma anche una condivisione della soluzione la risoluzione di un problema per milioni di utenti là fuori.
Lo sviluppo Open Source funziona in un ambiente distribuito con obiettivi diversi diverse aree di interesse.
Per esempio, ci potrebbe essere il caso che un particolare Upstream possa essere interessato lavorare ad una nuova grande caratteristica, mentre Ubuntu, causa della stretta pianificazione del rilascio, potrebbe essere interessato a lavorare alla distribuzione della versione solo con un ulteriore bug fix.
È per questo che facciamo uso di "Sviluppo distribuito", dove il codice è stato lavorato in vari rami che si fondono insieme, dopo le dovute revisioni del codice e sufficienti discussioni.
Nell'esempio citato sopra, avrebbe senso spedire Ubuntu con la versione esistente del progetto, aggiungere i bugfix, passarlo Upstream per il loro prossimo rilascio e rispedirlo (se adatto) nella prossima release di Ubuntu.
Sarebbe il miglior compromesso e una situazione in cui tutti vincono.
Per risolvere un bug di Ubuntu si deve prima ottenere il codice sorgente per il pacchetto, poi lavorare sulla correzione, documentarla affinché sia facile da capire per gli altri sviluppatori e gli utenti, quindi creare il pacchetto per testarlo.
Dopo averlo provato, si può facilmente proporre il cambiamento da inserire nell'attuale versione di rilascio in sviluppo di Ubuntu.
Uno sviluppatore con diritto di upload lo recensirà per voi e poi potrebbe essere integrato in Ubuntu.
Quando si cerca di trovare una soluzione di solito è una buona idea controllare con Upstream e vedere se il problema ( o una possibile soluzione) è già noto e, in caso contrario, fare il vostro meglio per rendere la soluzione uno sforzo condiviso.
Un ulteriore passo potrebbe essere quello di prelevare la modifica applicata a una vecchia, ma ancora supportata, versione di Ubuntu e di inoltrarla Upstream.
I più importanti requisiti per il successo nello sviluppo di Ubuntu e l'avere talento per "far si che le cose funzionino ancora una volta", non avere paura a leggere la documentazione e fare domande, visto che si è un giocatore in una squadra, e godere di alcuni lavori da detective.
Ottimi posti per fare le vostre domande sono ubuntumotumentors@ lists.ubuntu.com e #ubuntu-motu su irc.freenode.net.
Potrai facilmente trovare un sacco di nuovi amici e persone con la tua stessa passione: fare il mondo un posto migliore rendendo migliore il software Open Source.
fonte: Full Circle Magazine - Edizione Speciale Sviluppo Ubuntu
download Versione Completa in PDF
