Questa pagina vuole essere un breviario sulle consuetudini principali che regolano le attività di sviluppo di Ubuntu. Non ha la pretesa di essere esaustiva, bensì un primo punto di riferimento per chi volesse avvicinarsi al mondo dello sviluppo di Ubuntu.
La qualità prima di tutto
Prima di caricare qualsiasi patch o debdiff, è necessario controllarne scrupolosamente il contenuto alla ricerca di eventuali errori od omissioni che possono ritardare il processo di upload o apportare problemi di varia natura. Nel caso insorga un dubbio su qualsiasi aspetto inerente l'attività, nel canale #ubuntu-motu è sempre possibile avere supporto da chi è tecnicamente più competente in materia.
Contattare il manutentore
Prima di effettuare merge e sync, è buona norma contattare la persona che ha seguito il precendente upload per coordinare gli sforzi. I motivi principali sono:
- evitare di duplicare il lavoro
- discussione su una o più modifiche
- essere a conoscenza di eventuali attività da svolgere sul pacchetto
Il primo punto è autoesplicativo. Siccome nella stragrande maggioranza dei casi la procedura di merge/sync è seguita da chi ha gestito il precedente upload, è probabile che una nuova richiesta sia in preparazione e il lavoro fatto finora su quel pacchetto diventa ridondante.
Il secondo punto indica che una o più modifiche inserite possono essere rimosse ed è in corso una discussione a riguardo con altri MOTU (in IRC, in mailing list, e così via). Chi ha seguito il merge/sync in passato dovrebbe essere a conoscenza della situazione e contattarlo evita di preparare un debdiff con modifiche non volute.
Il terzo punto è applicabile solitamente ai manutentori dei pacchetti. A volte il manutentore desidera caricare una nuova versione, non seguendo logiche strettamente correlate ai merge/sync. Coordinando le attività si evita di caricare una versione "intermedia" che non ha motivo di esistere.
Verificare il pacchetto
Ogni modifica introdotta può generare scompensi in un pacchetto. Onde evitare errori di compilazione (in gergo failed to build from source o FTBFS) o di esecuzione, è buona norma tentare la compilazione con strumenti del calibro di pbuilder per scongiurare problemi che necessitano un nuovo upload e testare in prima persona il pacchetto per vedere se è installabile e se viene correttamente eseguito (in gergo builds, installs, runs o b/i/r).
Controllare lo stato di avanzamento
Una volta che il pacchetto è stato caricato, è indispensabile seguire il percorso di sviluppo:
- stato della compilazione
- posizionamento nella coda di upload
- gestione del bug
- feedback dagli utenti
Il processo di compilazione richiede da pochi minuti a diverse ore, a seconda della dimensione e del tipo di pacchetto che si è caricato. Launchpad notifica automaticamente via email chi ha effettuato l'upload, di eventuali problemi di compilazione, ma è sempre buona cosa controllare l'esito del processo di compilazione nella propria pagina dei pacchetti o direttamente in quella del sorgente stesso.
Altra operazione da eseguire, di solito trascurata ma importantissima, è verificare in quale coda è stato immesso il pacchetto attraverso la pagina https://launchpad.net/ubuntu/versione/+queue. Se il pacchetto è stato inserito nella coda New, un membro del team Ubuntu Archive Administrators deve revisionarlo manualmente prima di autorizzare l'ingresso nei repository. E' possibile contattare direttamente uno dei membri, con cortesia e gentilezza, chiedendo di prendere visione del pacchetto. La stessa procedura si applica nel caso in cui il pacchetto sia stato inserito nella coda Rejected: il pacchetto non farà mai parte di Ubuntu e necessita un nuovo upload non appena risolti i motivi per il quale è stato respinto. Quando il pacchetto viene inserito nella coda Done, il processo di upload è terminato con successo.
Una volta espletati con successo i due punti precedenti, l'eventuale bug aperto può essere marcato come Fix Released, eventualmente rimuovendo l'utente assegnato.
Non appena il pacchetto sarà disponibile nei repository, gli utenti avranno l'opportunità di installarlo ed usarlo. È consigliabile controllare la presenza di nuovi bug per il pacchetto caricato, almeno nei giorni immediatamente successivi all'upload, per scongiurare problemi legati alle modifiche introdotte e porvi rimedio, se necessario.
Documentare le modifiche
Ogni modifica introdotta deve essere riportata in modo dettagliato nel file debian/changelog.
Per ogni modifica, occorre creare una nuova voce di un elenco puntato (indicato dal simbolo *), in cui viene riportato un breve ma esaustivo sommario delle modifiche introdotte, eventualmente seguito dal bug presente in Launchpad a cui si vuol dare soluzione, usando la sintassi (LP: ######)
Inserire tali informazioni nel changelog, anche se può sembrare inutile, è fondamentale per far risaltare eventuali modifiche da rimuovere durante un merge o annullare una o più modifiche che, purtroppo, sono risultate inutili o dannose. Molte volte gli sviluppatori rifiutano di eseguire l'upload in mancanza di voci di changelog incomplete o inadeguate.
