Linee Guida di Rilascio di Gentoo Linux

1.4 2006-01-06 Introduzione

Obbiettivi principali

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

Panoramica sul Rilascio

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

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.

C'è l'architettura nella lista di rilascio? Contattare il Responsabile delle Operazioni di Rilascio se non c'è. La lista di rilascio sarà inviata dal Responsabile delle Operazioni all'inizio del processo di rilascio. È disponibile anche nella pagina delle informazioni di rilascio per il rilascio specificato. Le funzionalità che sono state progettate nella Roadmap delle funzionalità del rilascio applicabile all'architettura sono state completate? Tutte le funzionalità che sono relative all'architettura devono essere complete per il rilascio. Contattare il Responsabile delle Operazioni se ci sono giustificate circostanze che bloccano il completamento di queste funzionalità. I pacchetti base applicabili elencati nella pagina delle informazioni di rilascio sono utilizzati? Se applicabili all'architettura, certi pacchetti base devono essere utilizzati per mantenere la consistenza. La documentazione di Installazione è aggiornata? Il Coordinatore di Rilascio di Architettura deve essere sempre in contatto con il Referente per la Documentazione dell'Ingegneria di Rilascio per assicurare che la documentazione rilasciata sia sincronizzata con il rilascio. Tutti i bug del rilascio precedente sono stati risolti in questo rilascio? Ripulire il bugzilla dai bug dell'ultimo rilascio. Risolverne quanti più possibile. Lo scopo è la perfezione. I bug saranno assegnati all'alias release@gentoo.org. I bug di un rilascio non dovranno essere marcati come RESOLVED finchè un rilascio con la correzione viene resa disponibile. Test di Regressione Le immagini dei CD e gli stage compilano e girano come ci si aspetta su ognuna delle sottoarchitetture supportate? Riferirsi alla sezione Guida ai Test di Regressione per istruzioni su come far girare propriamente un test di regressione di Gentoo. Il Progetto di Documentazione Gentoo (GDP-Gentoo Documentation Project, ndt) ha tutte le informazioni necessarie richieste per la documentazione del rilascio? Il GDP richiede una lista di tutti i kernel avviabili di ogni CD avviabile, una lista di tutte le opzioni di avvio di ogni CD avviabile, l'output di find su un CD montato per ogni categoria (sia i CD avviabili che quelli contenenti Pacchetti), e l'output difind su un CD di installazione Universale/Minimale avviato. Le informazioni possono essere inviate al Referente per l'Ingegneria di Rilascio del GDP, che è elencato nella Pagina del Release Engineering Project (ndt in inglese), o al Responsabile delle Operazioni di Rilascio. I formati degli specfile dei CD di Installazione e dei Pacchetti sono seguiti? I formati per i CD di installazione avviabili e i CD dei pacchetti non avviabili specificano un essenziale gruppo base di pacchetti che mantengono la compatibilità e la consistenza tra tutte le architetture. È essenziale che il gruppo base di pacchetti specificato venga usato.

Linee Guida	Descrizione

La Transizione da Sviluppo/Controllo Qualità a Rilascio Finale

Il Processo di Transizione

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.

La 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:

I requisiti della lista di controllo della fase di sviluppo/Controllo Qualità sono completi? Tutti i requisiti specificati nella lista di controllo della fase di sviluppo/Controllo Qualità sono completi, come specificati e in forma corretta? Tutti i componenti necessari per il rilascio sono presenti? Si prega di fare riferimento alla lista dei componenti necessari per il rilascio. Layout I CD di Installazione,i CD dei Pacchetti, e gli stage sono tutti conformi alle convenzioni nelle attribuzioni dei nomi e di layout impostate dall'Ingegneria di Rilascio? Le note di rilascio sono in forma corretta e disponibili sia online che nel CD di Installazione? Assicurarsi che le note di rilascio siano presenti nelle posizioni specificate dalla convenzione di layout.

Linee Guida	Descrizione

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.

Risorse

Componenti Necessari per un Rilascio

I seguenti componenti sono necessari per un rilascio ufficiale:

CD di Installazione Avviabili Questo include sia l'immagine del CD di Installazione Universale che quella Minimale che gli utenti possono usare per avviare una vasta varietà di hardware per lo scopo finale di installare Gentoo Linux. Ci sono due tipologie per i CD di Installazione avviabile, quello Universale e quello Minimale. Un CD di installazione Universale contiene un insieme di stage3 per tutte le sottoarchitetture supportate così come i distfile necessari all'installazione da stage3 senza una connessione di rete. Un CD di Installazione Minimale contiene solamente i componenti necessari per avviare un sistema. Fare riferimento alle specifiche di layout e al formato dello specfile di Catalyst per il layout richiesto e ai pacchetti base di entrambi i CD. Entrambe le immagini sono necessarie per un rilascio ufficiale. CD dei Pacchetti Un CD non avviabile che contiene un insieme di pacchetti Gentoo Reference Platform (GRP) usati per un'installazione senza collegamento alla rete. Un utente non deve aver bisogno di una connessione a Internet per installare quando si usa questo disco. Prego riferirsi alle specifiche di layout per il layout del CD dei Pacchetti, e al formato dello specfile di Catalyst per una lista dei pacchetti richiesti. CD Live Avviabile Un'Immagine di un CD Live avviabile con l'Installer Gentoo Linux può essere un sostituto per l'esigenza di un CD di Installazione Universale e un CD dei Pacchetti. Questo è il solo caso nel quale un CD di Installazione Universale e un CD dei Pacchetti possono non essere presenti in un rilascio di una data architettura pur considerandola completa e ufficiale. Stage di Installazione Gli archivi degli Stage 1, 2, e 3 possono essere usati per installare Gentoo Linux. Note di Rilascio Le Note che seguono il formato specificato dall'Ingegneria di Rilascio che particolareggiano aspetti importanti riguardanti il rilascio. DIGEST e CONTENTS (contenuti, ndt) È necessario che sia l'hash MD5 che quello SHA1 vengano generati per tutti i supporti di rilascio. Questi hash sono creati automaticamente da catalyst, e devono essere inclusi nel supporto. Un file CONTENTS deve essere generato per i seguenti supporti: CD di Installazione Minimale (avviato), CD di Installazione Universale (sia avviato che non avviato), CD dei Pacchetti, e CD Live.

Componenti	Descrizione

Guida ai Test di Regressione

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.

CD di Installazione Universale Avviabileinstall-${arch}-universal-${relver}.isoinstall-x86-universal-2005.1.isoCD di Installazione Minimale Avviabileinstall-${arch}-minimal-${relver}.isoinstall-alpha-minimal-2005.1.isoCD Live Avviabilelivecd-${arch}-${relver}.isolivecd-x86-2005.1.isoCD dei Pacchettipackages-${subarch}-${relver}.isopackages-pentium4-2005.1.isoStage di Installazionestage{1,2,3}-${subarch}-${relver}.tar.bz2stage3-ppc-2005.1.tar.bz2 Gli Stage di Installazione che sono di differente tipo di rilascio, come quelli hardened o quelli selinux. stage{1,2,3}-${subarch}-${reltype}-${relver}.tar.bz2stage2-athlon-xp-selinux-2004.0.tar.bz2Note di Rilascio${arch}-release-notes.xml sparc-release-notes.xml, situato nel CVS a gentoo/xml/htdocs/proj/en/releng/release/${relver}/${arch} (in inglese, ndt) Il formato corrente e i tool di autogenerazione possono essere trovati nel CVS a gentoo/src/relnotes.

Nome del Componente	Convenzione di Attribuzione Nome	Esempio

Il CD di installazione Universale Avviabile deve aderire al seguente standard di layout:

/distfiles Directory dove tutti i distfile necessari sono immagazzinati per installare da un archivio stage3 senza connessione di rete. /docs Directory dove risiedono le note di rilascio e il Manuale. Il Manuale ha la propria struttura di directory,/docs/handbook/{html,pdf,txt}, poichè ogni sottodirectory sta al posto del rispettivo formato del Manuale. Le versioni finali sia delle note di rilascio sia del Manuale saranno linkate nella pagina delle informazioni di rilascio. /boot (/isolinux on x86/amd64)Directory autogenerata per il bootloader./snapshots Directory contenente la snapshot usata per compilare i componenti di rilascio. /stages Directory contenente gli archivi di stage3 per ogni sottoarchitettura supportata. /zisofs (facoltativa) Directory autogenerata per il runtime di zisofs. Applicabile solamente alle architetture che usano lo schema di compressione zisofs. Considerare l'uso di zisofs solamente se squashfs non è disponibile per l'architettura a causa di problemi tecnici, come kernel panic.

Directory	Descrizione

Il CD di Installazione Minimale avviabile deve aderire al seguente standard di layout:

/boot (/isolinux on x86/amd64)Directory autogenerata per il bootloader./zisofs (facoltativa) Directory autogenerata per il runtime di zisofs. Applicabile solamente alle architetture che usano lo schema di compressione zisofs. Considerare l'uso di zisofs solamente se squashfs non è disponibile per l'architettura a causa di problemi tecnici, come kernel panic.

Directory	Descrizione

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:

/${categoria}/${pacchetto} Il CD dei Pacchetti sarà fatto nello stesso modo di /usr/portage/packages.

Directory	Descrizione

Il comando per creare la iso del CD dei Pacchetti è:

# cd grp-${subarch}-${relver}/cd2
# mkisofs -R -J -l -V "${subarch} Packages" -o ../packages-${subarch}-${relver}.iso .

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.