Linee Guida di Rilascio di Gentoo LinuxUn rilascio di Gentoo Linux dovrebbe impegnarsi a dare due cose: alta qualità e poco stress. Le linee guida illustrate in questo documento sono un tentativo di promuoverle entrambe seppur mantenendole all'interno di una scadenza. Per i Coordinatori di Rilascio delle Architetture, il processo di rilascio è binario; c'è il tempo speso nello sviluppo e nel Controllo Qualità ("QA", ovvero "Quality Assurance", ndt) e quello del processo finale di rilascio speso facendo gli ultimi controlli di qualità per il rilascio. Durante l'intero processo, i Coordinatori dell'Ingegneria del Rilascio (Release Engineering, ndt) e del Rilascio di Architettura (Architecture Release, ndt) lavoreranno in stretto contatto su ogni aspetto del rilascio. Un aspetto critico del processo di rilascio è la comunicazione. Se ci sono domande o commenti riguardanti qualsiasi parte del processo di rilascio, i Coordinatori del Rilascio di Architettura dovranno contattare i Responsabili delle Operazioni di Rilascio, i cui indirizzi email possono essere sempre trovati nella pagina del progetto Release Engineering (in inglese, ndt). Informazioni specifiche sul rilascio possono sempre essere trovate sulla pagina delle informazioni di rilascio, che è http://www.gentoo.org/proj/en/releng/release/${relver}/releng/${relver}.xml (in inglese, ndt),dove ${relver} è la versione del rilascio (es. 2005.1). 2. Fase di Sviluppo/Controllo Qualità Processo della Fase di Sviluppo/Controllo Qualità I Coordinatori di Rilascio di Architettura spenderanno molto del loro tempo in questa fase perchè la fase finale di rilascio prende solo una piccola percentuale del tempo impiegato su un rilascio. La differenza di tempo non è un'indicazione che il processo finale di rilascio sia meno importante della fase di sviluppo/controllo qualità, ma piuttosto una comprensione che molti dei Controlli per la Qualità del rilascio saranno fatti nella fase di sviluppo/controllo qualità. La fase finale di rilascio ha i propri Controlli Qualità necessari che saranno coperti più avanti in questa guida. Nell'intera fase di sviluppo/Controllo Qualità si dovranno correggere e chiudere i bug, affrontare la lista di Richiesta di funzionalità per l'imminente rilascio, e assicurarsi costantemente che il rilascio sia conforme alle linee guida del Controllo Qualità disposte dall'Ingegneria di Rilascio. È fortemente raccomandato che il Coordinatore di Rilascio di Architettura imposti un ciclo di build programmato in modo che i bug e i Controlli Qualità possano essere effettivamente gestiti durante l'intero processo. Per esempio, build settimanali o bi-settimanali danno al Coordinatore di Rilascio di Architettura un "allarme" su cosa stia succedendo con il loro rilascio. Durante questa fase, l'Ingegneria di Rilascio è disponibile tutte le volte per qualsiasi cosa. Se ci sono domande o preoccupazioni, richieste di hardware o di risorse, o qualsiasi altra cosa, si prega di contattare il Responsabile delle Operazioni di Rilascio. Linee Guida della fase di Sviluppo/Controllo Qualità Le seguente linee guida del Controllo Qualità dovranno essere osservate costantemente durante questa fase del rilascio. Fare questo assicurerà che l'architettura da rilasciare sarà infatti rilasciata per tempo e completa. L'Ingegneria di Rilascio si riserva il diritto di bloccare il rilascio se una qualsiasi delle architetture non sia conforme a queste linee guida di Controllo Qualità. Questo assicura un aspetto consistente per la distribuzione alla base dell'utenza.
3. La Transizione da Sviluppo/Controllo Qualità a Rilascio Finale La transizione dalla fase di sviluppo/Controllo Qualità alla fase finale di rilascio non può considerarsi interamente definibile da una data. La transizione ha luogo quando le linee guida del Controllo Qualità per la fase di sviluppo/Controllo Qualità sono state conseguite pienamente. In quel momento, l'architettura da rilasciare è pronta per lo spostamento alla fase finale di rilascio. Il Processo Finale di Rilascio La fase finale di rilascio del processo di rilascio è la parte più raffinata di tutto ciò che si è fatto fino a questo punto. Lo scopo finale di questa fase è avere i componenti di rilascio di alta qualità sul principale mirror almeno cinque giorni prima della data di rilascio così che i componenti di rilascio abbiano abbastanza tempo per essere organizzati, o propagati, sugli altri mirror. La lista di controllo finale del Controllo Qualità consiste nei seguenti punti:
Quando il Coordinatore del Rilascio di Architettura ritiene che i propri componenti di rilascio soddisfino o superino le linee guida del Controllo qualità, li caricherà sulla macchina temporanea dell'Ingegneria di Rilascio e informerà l'Ingegneria di Rilascio in modo che il processo di approvazione finale possa iniziare. L'approvazione finale dall'Ingegneria di Rilascio consiste nel riesaminare punto per punto la lista di controllo finale di Controllo Qualità e un controllo del digest di ogni componente del rilascio. Supponendo che i componenti del rilascio passino l'approvazione finale dall'Ingegneria di Rilascio, saranno firmati dalla chiave GPG dell'Ingegneria di Rilascio, e posizionati nell'appropriata locazione che si trova nella macchina dell'Ingegneria di Rilascio per dare spazio al Referente per l'Infrastruttura di Rilascio per la propagazione al mirror principale. Solo quando i componenti di rilascio soddisfano sia il Controllo Qualità della fase di sviluppo/Controllo Qualità che i Controlli Qualità finali, essi saranno caricati sui mirror per essere rilasciati. Se un qualsiasi componente non è a posto, l'Ingegneria di Rilascio lavorerà con il Coordinatore del Rilascio di Architettura per riparare il componente difettoso. Per avere un rilascio puntuale, è imperativo che il Coordinatore del Rilascio di Architettura si assicuri che tutti i Controlli Qualità siano soddisfatti prima dell'approvazione dell'Ingegneria di Rilascio. L'approvazione dell'Ingegneria di Rilascio dovrà essere l'ultimo controllo a cui i componenti sono sottoposti, non il primo. Componenti Necessari per un Rilascio I seguenti componenti sono necessari per un rilascio ufficiale:
I test di Regressione sono un aspetto chiave del Controllo Qualità. Il processo dei test di regressione è svolto facendo girare un insieme completo di test che emulano scenari di mondo reale. Fare i test di regressione non è necessariamente difficile, ma impiega molto tempo. Una buona porzione del processo di rilascio deve esser spesa facendo i test di regressione in quanto è il modo migliore per identificare bug ed errori di scrittura. La procedura dei test di regressione è piuttosto diretta. Per ogni CD di Installazione/CD Live, seguire le istruzioni di installazione alla lettera. Una volta completa, provare una completa installazione GRP usando il Manuale di Installazione. Una volta completa, riavviare il processo usando una differente sottoarchitettura o insieme di GRP. Lo scopo è percorrere il Manuale di Installazione tante più volte possibile. Più è la casualità introdotta dai pacchetti, dai metodi e sottoarchitetture, maggiori sono le possibilità che i bug siano identificati prima del rilascio finale. Convenzioni nell'Attribuzione dei Nomi e Layout dei CD di Installazione/CD Live/CD dei Pacchetti CD di Installazione/CD Live/CD dei Pacchetti e gli stage devono aderire alle seguenti convenzioni sull'attribuzione dei nomi, dove ${arch} è la principale architettura, ${subarch} è la sottoarchitettura, ${reltype} è uno speciale identificatore di tipo, e ${relver} è il numero di versione del rilascio.
Il CD di installazione Universale Avviabile deve aderire al seguente standard di layout:
Il CD di Installazione Minimale avviabile deve aderire al seguente standard di layout:
Entrambi i CD di Installazione possono usare un'ampia varietà di kernel per assicurare la compatibilità all'utente. I kernel saranno chiamati gentoo-${kver}-${special_opt}, dove ${kver} è la principale versione del kernel, come 2.6, e ${special_opt} è un identificativo speciale e opzionale, come nofb. Un esempio di un nome di kernel con un identificativo speciale saràgentoo-2.6-nofb. Entrambi i CD di Installazione avviabili conterranno uno standard motd (Messaggio del Giorno) nel filesystem avviato sul CD. Il motd sarà la prima cosa che un utente vedrà dopo aver ottenuto un prompt del loro ambiente del CD, e conterrà importanti informazioni. Questo file è generato da catalyst. Il CD dei Pacchetti deve aderire al seguente standard di layout:
Il comando per creare la iso del CD dei Pacchetti è:
Formato degli Specfile di Catalyst del CD Live e del CD dei Pacchetti Formatodello specfile di Catalyst livecd-stage1 sia per i CD di Installazione Universali avviabili che per quelli Minimali. Formatodello specfile di Catalyst livecd-stage2 sia per i CD di Installazione Universali avviabili che per quelli Minimali. Formatodello specfile di Catalyst per il CD dei Pacchetti. I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike. |
|