Gentoo Logo

Domande frequenti (FAQ) per gli Arch Tester x86 di Gentoo

Indice:

1.  Introduzione

Queste FAQ cercano di dare risposta alle domande più comuni formulate circa l'essere Arch Tester del team x86. Le domande possono essere poste su irc a #gentoo-x86 o via mail all'autore.

2.  Domande

Principi fondamentali

Domande generali riguardo l'Arch Testing.

Prepararsi

Come preparare il proprio sistema per i pacchetti di test.

Lavorare Lavorare Lavorare!!!

Cose da fare giorno per giorno.

3.  Le basi

Questa sezione punta ad essere abbastanza generica e le risposte alle domande poste in questa sezione possono essere valide anche per altri tipi di architetture in Gentoo.

Chi è un Arch Tester??

Un Arch Tester (comunemente riferito con "AT") è un utente fidato e capace di testare un'applicazione per determinare la sua stabilità. Per diventare un AT occorre essere in grado di testare una grande varietà di pacchetti e capire nonché modificare ebuild.

Perché Gentoo ha bisogno di Arch Testers?

Gli Arch Testers sono necessari per aumentare la qualità promessa (Quality Assurance, QA), e per aiutare gli Arch Devs ad assicurare che i pacchetti siano realmente stabili attraverso l' analisi dei pacchetti stessi da parte di terze parti che riferiranno circa i loro risultati. Visto che l'albero (dei sorgenti N.d.T) è molto ampio sono necessarie molte persone per controllare attivamente le cose che non vanno e per aiutare a sistemarle.

Quali sono le conoscenze di base necessarie per diventare un AT?

Bisogna essere in grado di modificare ebuild e di trovare errori che devono essere corretti prima che il pacchetto sia marcato stabile. Ci si aspetta anche che si abbia la possibilità di testare pacchetti fornendo dei buoni bug report in caso di problemi con qualche cosa. Ciò significa che bisogna avere una certa confidenza con lo scripting bash così pure in specifiche aree di Gentoo come ad esempio Portage.

Quali sono i requisiti minimi di sistema, se ce ne sono?

È necessario un sistema o un chroot che faccia solo uso di pacchetti "x86". Questo perché cosi facendo vengono usate librerie realmente stabili per testare i pacchetti ed è possibile cercare bug anche nei pacchetti già marcati stabili. In alternativa è possibile eseguire Gentoo in una macchina dedicata solo al testing o in una macchina virtuale. Programmi adeguati per quest'ultima opzione sono VirtualBox, VMWare o QEmu/KVM, sebbene il suo uso per lavori sull'architettura sia discoraggiato perchè non viene eseguito sull'attuale hardware.

Inoltre si dovrebbe impostare FEATURES="test collision-protect" per individuare i fallimenti dei test e le collisioni nei file tra pacchetti. Alcuni pacchetti non rispettano i valori di LDFLAGS e CFLAGS/CXXFLAGS durante la compilazione, e ciò potrebbe portare ad un loro malfunzionamento. Pertanto bisognerebbe almeno impostare LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu", in modo da far visualizzare a Portage un avvertimento riguardo a ciò.

Cosa significa fare parte del team Arch Tester x86?

Iniziare a far parte del team Arch Tester x86 significa essere pronti a dedicare un po' di tempo ad aiutare Gentoo/x86. Significa anche essere interessati ad aiutare il test di applicazioni che necessitano di essere dichiarate stabili.

Cosa devo fare in qualità di AT? Quali sono i miei ruoli/responsabilità?

Bisogna aiutare gli sviluppatori dell'architettura nel testare i pacchetti. Effettuare il test dei pacchetti richiede molto di più che il semplice fatto che essi compilino. Ci si aspetta che venga verificata la corretta funzionalità almeno delle principali funzioni dell'applicazione. Quando si testa un pacchetto è bene assicurarsi di avere abilitato FEATURES="test collision-protect". Un qualsiasi pacchetto che fallisca nell'emerge con questa feature impostata diventa un obiettivo principale per la QA e non possiamo continuare fino a quando non si risolve.

Come posso essere coinvolto con il team e come posso iniziare ad aiutare?

Per prima cosa si dovrebbero leggere queste FAQ nella loro interezza in maniera tale che si abbia ben chiaro cosa significhi attualmente essere AT. Successivamente si dovrebbe visitare irc.freenode.net ed accedere a #gentoo-x86. Spesso gli Sviluppatori chiedono aiuto nel testare un pacchetto e si potrà provare a dare una mano dove possibile.

La maniera principale per iniziare a dare una mano è guardare ai nostri bug. Di seguito sono riportati un po' di link per i propri bookmark contenenti dei salvataggi di ricerche su bugzilla.

Alla fine dopo che avrete dimostrato un buon livello di impegno e se riteniamo che siate una buona aggiunta per il team vi verrà dato l'ebuild quiz e successivamente per un periodo di 30 giorni verrete seguiti da un mentore.

4.  Prepariamoci

Questa sezione tratta di domande comuni del tipo "come configurare..." per guidarci nella preparazione del nostro sistema e per consentirci di svolgere il lavoro di AT :)

Sulla mia macchina non girano pacchetti stabili, è una "~x86". Come posso configurare un chroot x86?

Per maggiori informazioni su come settare un ambiente chroot consultare la Chroot Guide (in inglese, N.d.T.)

Sto utilizzando un kernel instabile. Potrebbe generare problemi durante il test dei pacchetti?

Sarebbe opportuno usare un kernel stabile al di fuori del chroot, ma questo non è un requisito essenziale.

5.  Lavorare Lavorare Lavorare!!!

Domande su come organizzare il vostro lavoro su base giornaliera trovano risposta in questa sezione.

Quali sono i passi che devo seguire mentre testo un pacchetto?

  1. Assicurarsi che tutti i pacchetti nel sistema/chroot siano stabili.
  2. Impostare FEATURES="collision-protect" in /etc/make.conf e usare un insieme di CFLAGS "sano", come descritto in Guida all'Ottimizzazione della Compilazione.
  3. Scegliere una richiesta dalla lista dei bug citata in precedenza, dove bug di sicurezza e richieste di keywording hanno la priorità assoluta.
  4. Normalmente, tutti i pacchetti necessari sono elencati nella richiesta, ma a volte, le dipendenze vengono dimenticate. Solitamente non crea problemi, ma dovreste tuttavia includerle nel report. Per aggiungere automaticamente tutti i pacchetti necessari nel file package.keywords, può essere utile app-portage/tatt.
  5. Dopo aver compilato il pacchetto con varie combinazioni di USE flag, eseguirlo ed assicurarsi che le funzionalità di base funzionino. Se il pacchetto è una libreria, emergere un paio di pacchetti che usano quella libreria per assicurarsi che funzionino ancora con le nuove versioni (opzione migliore: tutti quelli che dipendono da essa e hanno una versione stabile). Le così chiamate "dipendenze inverse" si trovano in dindex.
  6. Informare il team riguardo i test avvenuti con successo o gli errori che si sono verificati sul bug report corrispondente includendo cosa è stato fatto e su quale piattaforma. In caso di problemi, aggiungere anche l'output di emerge --info.
  7. I problemi che si verificano con la versione attualmente stabile, non saranno un ostacolo per la stabilizzazione, ma vanno comunque segnalati.

Alcuni utili suggerimenti:

  • I tester di architettura non testano solo pacchetti, ma cercano attivamente le soluzioni dove si sono verificati dei problemi. Le fonti importanti di informazione sono i sistemi di controllo di versione e i bug tracker di altre distribuzioni, nonché l'upstream. Segnalare bug agli autori è importante quasi quanto testare pacchetti!
  • Impostare un utente di osservazione in preferences per l'alias di x86@gentoo.org. In questo modo riceverete tutte le email da Bugzilla dirette al team x86.

Di quali superpoteri verrò in possesso in qualità di AT?

Hah. Stavate scherzando quando avete posto questo domanda? Gli AT sono gli schiavi che fanno tutto il lavoro e non hanno poteri ne libertà.......okay, Stavo scherzando :)

Cose a cui si ha accesso in qualità di AT:

  • Elevati privilegi in Gentoo Bugzilla in maniera tale che si possa modificare tutti gli aspetti di un bug. Questo è consentito principalmente affinché si possa essere in grado di ri-assegnare bugs in caso di necessità e coordinarsi con i mantenitori dei pacchetti, con altri arch team ecc.
  • Accesso in sola lettura al repository cvs di gentoo-x86, che non è un privilegio, ma potrebbe tornare utile per gli AT. Vedere ViewCVS per un URL di checkout per l'accesso anonimo.

Cose a cui non si ha acceso in qualità di AT:

  • Fare il commit di correzioni per gli ebuild. È necessario trovare il mantenitore o un altro sviluppatore con l'accesso che faccia questo per voi.

Chi devo contattare in caso di guai?

Se notate dei grossi problemi nell'albero, prima di tutto tentate di contattare la persona che ha causato tali problemi. Questa può essere di norma cercata nel ChangeLog, ma se non è cosi si può usare ViewCVS per vedere chi ha fatto il commit dei cambiamenti. Se non risulta possibile contattare questa persona è bene provare con il singolo mantenitore o con il gruppo incaricato della manutenzione del pacchetto (se il mantenitore non è la stessa persona che ha causato il problema). Se tutto questo non bastasse bisogna informare della situazione uno sviluppatore x86 cosi che possa gestirla al meglio fino a quando non ci sarà qualcuno disponibile per gestirla in maniera adeguata.

Quale è la maniera migliore per contattare i mantenitori/sviluppatori?

Normalmente la maniera più semplice per contattare uno sviluppatore è "pingarlo" su IRC. Se non è in giro su IRC, gli si può spedire una mail. Se si è impossibilitati a contattare il particolare sviluppatore, si cerchi di contattare qualcun'altro nel gruppo (se possibile). Se non c'è nessun gruppo da contattare allora bisogna contattare qualcuno nel team x86 per capire come proseguire. Inoltre, a meno che il problema sia grave, date loro il tempo sufficiente a rispondervi via mail. Controllare devaway per essere sicuri che la persona che si sta cercando di contattare non sia assente.



Stampa

Aggiornato il 17 gennaio 2012

Oggetto: Questo documento è la bibbia degli Arch Tester x86.

Mark Loeser
Autore

Shyam Mani
Editore

Christian Faulhammer
Editore

Paolo Palana
Traduttore

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.