public inbox for gentoo-docs-it@lists.gentoo.org
 help / color / mirror / Atom feed
From: Paolo Palana <nsr2@tiscali.it>
To: gentoo-docs-it@lists.gentoo.org
Subject: [gentoo-docs-it] aggiornato arq testers faq
Date: Mon, 05 Jun 2006 21:01:55 +0200	[thread overview]
Message-ID: <44847FA3.7040008@tiscali.it> (raw)

[-- Attachment #1: Type: text/plain, Size: 151 bytes --]

Attachment #88462
<http://bugs.gentoo.org/attachment.cgi?id=88462&action=edit> to Bug
#135664 <http://bugs.gentoo.org/show_bug.cgi?id=135664> Created


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: arch-testers-faq.xml --]
[-- Type: text/xml; name="arch-testers-faq.xml", Size: 12501 bytes --]

<?xml version='1.0' encoding="UTF-8"?>

<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">


<!-- $Header: /var/www/www.gentoo.org/raw_cvs/gentoo/xml/htdocs/proj/en/base/x86/arch-testers-faq.xml,v 1.8 2006/05/23 22:58:05 halcy0n Exp $-->


<guide link="/proj/it/base/x86/arch-testers-faq.xml">
<title>FAQ per gli Arch Tester x86 di Gentoo </title>

<author title="Autore">
  <mail link="halcy0n@gentoo.org">Mark Loeser</mail>
</author>
<author title="Editore">
  <mail link="fox2mike@gentoo.org">Shyam Mani</mail>
</author>
<author title="Traduttore">
  <mail link="nsr2@tiscali.it">Paolo Palana</mail>
</author>

<abstract>
Questo documento è la bibbia degli Arch Tester x86.
</abstract>

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>

<version>1.1</version>
<date>2006-01-16</date>

<chapter>
<title>Introduzione</title>
<section>
<body>

<p>
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.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Domande</title>
<section>
<title>Principi fondamentali</title>
<body>

<p>
Domande generali riguardo l'Arch Testing.
</p>

<ul>
  <li><uri link="#whoat">Chi è un Arch Tester?</uri></li>
  
  <li><uri link="#whyat">Perchè Gentoo ha bisogno di Arch Testers?</uri></li>
  
  <li>
    <uri link="#basicsk">Quali sono le conoscenze di base necessarie per
     divetare un AT?</uri>
  </li>
  <li>
     <uri link="#basicsys">Quali sono i minimi requisiti di sistema, se
     ce ne sono?</uri>
  </li>
  <li>
    <uri link="#x86at">Cosa siginfica fare parte del team Arch Tester x86?</uri>
  </li>
  <li>
     <uri link="#atwhat">Cosa devo fare in qualità di AT? Quali sono i miei
     ruoli/responsabilità?</uri>
  </li>
  <li>

   <uri link="#athow">Come posso essere coinvolto con il team e come posso
   iniziare ad aiutare?</uri>
  </li>

</ul>

</body>
</section>
<section>
<title>Prepararsi</title>
<body>

<p>
Come preparare il proprio sistema per i packages di test.
</p>

<ul>
  <li>
    <uri link="#stchroot">Non utilizzo il ramo stabile x86, la mia box è ~x86.
    Come posso mettere a punto un chroot x86?</uri>
  </li>
  <li>
     <uri link="#kernelv">Utilizzo un kernel instabile. Potrebbe generare
     problemi mentre testo i pacchetti?</uri>
  </li>
</ul>

</body>
</section>
<section>
<title>Lavorare Lavorare Lavorare!!!</title>
<body>

<p>
Cose da fare giorno per giorno.
</p>

<ul>
  <li>
    <uri link="#steptest">Quali sono i passi che devo seguire mentre testo
    un pacchetto?</uri>
  </li>
  <li><uri link="#powers">Di quali superpoteri verrò in possesso in qualità
  di AT?</uri></li>
  <li><uri link="#whomct">Chi devo contattare in caso di guai?</uri></li>
  <li>
    <uri link="#methct">Quale è la maniera migliore per contattare i
    maintainer/sviluppatori?</uri>
  </li>
</ul>

</body>
</section>
</chapter>

<chapter>
<title>Le basi</title>
<section>
<body>

<p>
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.
</p>

</body>
</section>
<section id="whoat">
<title>Chi è un Arch Tester??</title>
<body>

<p>
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.
</p>

</body>
</section>
<section id="whyat">
<title>Perchè Gentoo ha bisogno di Arch Testers?</title>
<body>

<p>
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.
</p>

</body>
</section>
<section id="basicsk">
<title>Quali sono le conoscenze di base necessarie per divetare un AT?</title>
<body>

<p>
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.
</p>

</body>
</section>
<section id="basicsys">
<title>Quali sono i minimi requisiti di sistema, se ce ne sono?</title>
<body>

<p>
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.
</p>

</body>
</section>
<section id="x86at">

<title>Cosa siginfica fare parte del team Arch Tester x86?</title>
<body>

<p>
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.
</p>

</body>
</section>
<section id="atwhat">
<title>Cosa devo fare in qualità di AT? Quali sono i miei
ruoli/responsabilità?</title>
<body>

<p>
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 <c>FEATURES="collision-protect"</c>.
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.
</p>

</body>
</section>

<section id="athow">
<title>Come posso essere coinvolto con il team e come posso iniziare ad aiutare?</title>
<body>

<p>
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. 
</p>

<p>
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.
</p>


<ul>
 <li>
    <uri link="http://tinyurl.com/obcta">All x86 bugs</uri>
 </li>
 <li>
    <uri link="http://tinyurl.com/cpdjk">Security related x86 bugs</uri>
 </li>
</ul>
	      
<p>
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'<uri link="http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild quiz</uri> e successivamente per un periodo di 30 giorni verrete
seguiti da un mentore.
</p>

</body>
</section>

</chapter>

<chapter>
<title>Preapariamoci</title>
<section>
<body>

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

</body>
</section>
<section id="stchroot">
<title>Sulla mia macchina non girano pacchetti stabili, è una "~x86".
Come posso configurare un chroot x86?</title>
<body>

<p>
Per maggiori informazioni su come settare un ambiente chroot consultare la
<uri link="chroot.xml">Chroot Guide</uri>
</p>

</body>
</section>
<section id="kernelv">
<title>Sto utilizzando un kernel instabile. Potrebbe generare problemi durante
il test dei pacchetti?</title>
<body>

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

</body>
</section>
</chapter>

<chapter>
<title>Lavorare Lavorare Lavorare!!!</title>
<section>
<body>

<p>
Domande su come organizzare il vostro lavoro su base giornaliera trovano
risposta in questa sezione.
</p>

</body>
</section>
<section id="steptest">
<title>Quali sono i passi che devo seguire mentre testo un pacchetto?</title>
<body>

<ol>
  <li>Assicurarsi che tutti i pacchetti nel sistema/chroot siano stabili.</li>
  <li>
    Impostare <c>FEATURES="collision-protect"</c> in <path>/etc/make.conf</path> e
    usare un insieme di <c>CFLAGS</c> "sano".
  </li>
  <li>
    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.
  </li>
</ol>

</body>
</section>
<section id="powers">
<title>Di quali superpoteri verrò in possesso in qualità di AT?</title>
<body>

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

<p>
Cose a cui si ha accesso in qualità di AT:
</p>

<ul>
  <li>
    Elevati privilegi in  <uri link="http://bugs.gentoo.org">Gentoo
    Bugzilla</uri> 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.
  </li>
  <li>Accesso in sola lettura al repository cvs di gentoo-x86</li>
</ul>

<warn>
L'acceso in sola lettura non è ancora implementato per gli AT. Questo potrebbe
essere sul punto di essere implementato. Nel frattempo si può usare
<c>emerge --sync</c> un volta al giorno per tenere la propria versione locale
aggiornata.
</warn>

<p>
Cose a cui non si ha acceso in qualità di AT:
</p>

<ul>
  <li>
     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.
  </li>
</ul>

</body>
</section>
<section id="whomct">
<title>Chi devo contattare in caso di guai?</title>
<body>

<p>
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
<path>ChangeLog</path>, ma se non è cosi si può usare <uri link="http://sources.gentoo.org/">ViewCVS</uri>
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.
</p>

</body>
</section>
<section id="methct">
<title>Quale è la maniera migliore per contattare i maintainer/sviluppatori?</title>
<body>

<p>
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 <uri link="http://dev.gentoo.org/devaway/">devaway</uri>
per essere sicuri che la persona che si sta cercando di contattare non sia
assente.
</p>

</body>
</section>
</chapter>
</guide>


             reply	other threads:[~2006-06-05 19:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-05 19:01 Paolo Palana [this message]
2006-06-08 19:52 ` [gentoo-docs-it] aggiornato arq testers faq Stefano Rossi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44847FA3.7040008@tiscali.it \
    --to=nsr2@tiscali.it \
    --cc=gentoo-docs-it@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox