Domande frequenti (FAQ) per gli Arch Tester x86 di GentooQueste 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. Domande generali riguardo l'Arch Testing.
Come preparare il proprio sistema per i pacchetti di test.
Cose da fare giorno per giorno.
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 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. 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?
Alcuni utili suggerimenti:
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:
Cose a cui non si ha acceso in qualità di AT:
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. I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike. |
|