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

Domande generali riguardo l'Arch Testing.

• Chi è un Arch Tester?
• Perchè Gentoo ha bisogno di Arch Testers?
• Quali sono le conoscenze di base necessarie per divetare un AT?
• Quali sono i minimi requisiti di sistema, se ce ne sono?
• Cosa siginfica fare parte del team Arch Tester x86?
• Cosa devo fare in qualità di AT? Quali sono i miei ruoli/responsabilità?
• Come posso essere coinvolto con il team e come posso iniziare ad aiutare?

Come preparare il proprio sistema per i packages di test.

• Non utilizzo il ramo stabile x86, la mia box è ~x86. Come posso mettere a punto un chroot x86?
• Utilizzo un kernel instabile. Potrebbe generare problemi mentre testo i pacchetti?

Cose da fare giorno per giorno.

• Quali sono i passi che devo seguire mentre testo un pacchetto?
• Di quali superpoteri verrò in possesso in qualità di AT?
• Chi devo contattare in caso di guai?
• Quale è la maniera migliore per contattare i maintainer/sviluppatori?

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.

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

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.

Bisogna essere in grado di modificare ebuilds 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.

E' 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 bugs anche nei pacchetti già marcati stabili.

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

Bisogna aiutare gli arch devs 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="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.

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 i Developers chiedeono aiuto nel testare un pacchetto e si potrà provare ad aiutare chiunque vogliate.

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

• All x86 bugs
• Security related x86 bugs

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.

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

Per maggiori informazioni su come settare un ambiente chroot consultare la Chroot Guide

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

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

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".
3. Dopo aver emerso il pacchetto è bene eseguirlo assicurandosi che le funzionalità di base funzionino correttamente. Se il pacchetto è una libreria emergere un paio di pacchetti che fanno uso di quella libreria per assicurarsi che continuino tranquillamente a lavorare con la nuova versione.

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 mantainers dei pacchetti, con altri arch team etc.
• Accesso in sola lettura al repository cvs di gentoo-x86

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

• Fare il commit di fix per gli ebuilds. E' necessario trovare il mantainer o un altro developer con l'accesso che faccia questo per voi.

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 manteiner o con il gruppo incaricato della manutenzione del pacchetto (se il manteiner non è la stessa persona che ha causato il problema). Se tutto questo non bastasse bisogna informare della siztuazione un developer x86 cosi che possa gestirla al meglio fino a quando non ci sarà qualcuno disponibile per gestiela in maniera adeguata.

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. Si controlli devaway per essere sicuri che la persona che si sta cercando di contattare non sia assente.