diff options
Diffstat (limited to 'it_IT.ISO8859-15/articles/committers-guide/article.sgml')
| -rw-r--r-- | it_IT.ISO8859-15/articles/committers-guide/article.sgml | 1509 |
1 files changed, 1509 insertions, 0 deletions
diff --git a/it_IT.ISO8859-15/articles/committers-guide/article.sgml b/it_IT.ISO8859-15/articles/committers-guide/article.sgml new file mode 100644 index 0000000000..9744e83a5e --- /dev/null +++ b/it_IT.ISO8859-15/articles/committers-guide/article.sgml @@ -0,0 +1,1509 @@ +<!-- + The FreeBSD Italian Documentation Project + + $FreeBSD$ + Original revision: 1.133 +--> + +<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [ +<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"> +%man; + +<!ENTITY % freebsd PUBLIC "-//FreeBSD//ENTITIES DocBook Miscellaneous FreeBSD Entities//EN"> +%freebsd; + +<!ENTITY % authors PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//EN"> +%authors; + +<!ENTITY % teams PUBLIC "-//FreeBSD//ENTITIES DocBook Team Entities//EN"> +%teams; + +<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//IT"> +%mailing-lists; + +<!ENTITY % translators PUBLIC "-//FreeBSD//ENTITIES DocBook Translator Entities//IT"> +%translators; +]> + +<article lang="it"> + <articleinfo> + <title>Guida del Committer</title> + + <authorgroup> + <author> + <surname>The FreeBSD Italian Documentation Project</surname> + </author> + </authorgroup> + + <pubdate>$FreeBSD$</pubdate> + + <copyright> + <year>1999</year> + + <year>2000</year> + + <year>2001</year> + + <year>2002</year> + + <holder>The FreeBSD Italian Documentation Project</holder> + </copyright> + + <abstract> + <para>Questo documento fornisce informazioni per la comunità dei + committer di FreeBSD. Tutti i nuovi committer dovrebbero leggere + questo documento prima di iniziare, e i committer già esistenti + sono fortemente incoraggiati a riguardarselo di tanto in tanto.</para> + + <para>Traduzione a cura di &a.it.alex;.</para> + </abstract> + </articleinfo> + + <sect1 id="admin"> + <title>Dettagli Amministrativi</title> + + <informaltable frame="none" orient="port"> + <tgroup cols="2"> + <tbody> + <row> + <entry><emphasis>Host con il Repository + Principale</emphasis></entry> + + <entry><hostid>freefall.FreeBSD.org</hostid></entry> + </row> + + <row> + <entry><emphasis>Metodi di Accesso</emphasis></entry> + + <entry>&man.ssh.1;</entry> + </row> + + <row> + <entry><emphasis>CVSROOT Principale</emphasis></entry> + + <entry><filename>/home/ncvs</filename></entry> + </row> + + <row> + <entry><emphasis>&a.cvs; Principali</emphasis></entry> + + <entry>&a.peter; e &a.markm;, così come &a.joe; per i + <filename>ports/</filename></entry> + </row> + + <row> + <entry><emphasis>Mailing List</emphasis></entry> + + <entry>&a.developers;, &a.committers;</entry> + </row> + + <row> + <entry><emphasis>Tag CVS Degni di Nota</emphasis></entry> + + <entry><literal>RELENG_4</literal> (4.X-STABLE), + <literal>HEAD</literal> (-CURRENT)</entry> + </row> + </tbody> + </tgroup> + </informaltable> + + <para>È richiesto l'uso di &man.ssh.1; o &man.telnet.1; con + Kerberos 5 per connettersi agli host con il repository. Questi sono + generalmente più sicuri che un semplice &man.telnet.1; o + &man.rlogin.1; visto che la negoziazione delle credenziali avverrà + sempre in modo cifrato. Tutto il traffico è cifrato di default + con &man.ssh.1;. Insieme a programmi di utilità come + &man.ssh-agent.1; e &man.scp.1;, anch'essi disponibili, &man.ssh.1; + è di gran lunga più conveniente. Se non sai nulla di + &man.ssh.1;, guarda la <xref linkend="ssh.guide">.</para> + </sect1> + + <sect1 id="committer.types"> + <title>Tipi di Bit di Commit</title> + + <para>Il repository CVS di FreeBSD ha un numero di componenti che, se + combinati, supportano i sorgenti di base del sistema operativo, la + documentazione, l'infrastruttura dei port delle applicazioni di terze + parti, e vari programmi di utilità. Quando vengono assegnati i bit + di commit di FreeBSD, vengono specificate le aree dell'albero dove il bit + può essere usato. Solitamente, le aree associate a un bit + corrispondono a quelle di chi ha autorizzato l'assegnamento del bit di + commit. Ulteriori aree di autorità possono essere aggiunte in + seguito: se occorrerà, il committer dovrà seguire le + normali procedure di allocazione del bit di commit per quell'area + dell'albero, chiedendo l'approvazione all'entità appropriata e + possibilmente prendendo un mentore per quell'area per un po' di + tempo.</para> + + <informaltable frame="none"> + <tgroup cols="3"> + <tbody> + <row> + <entry><emphasis>Tipo di Committer</emphasis></entry> + + <entry><emphasis>Responsabile</emphasis></entry> + + <entry><emphasis>Componenti dell'Albero</emphasis></entry> + </row> + + <row> + <entry>src</entry> + + <entry>core@</entry> + + <entry>src/, doc/ soggetta ad appropriata revisione</entry> + </row> + + <row> + <entry>doc</entry> + + <entry>nik@</entry> + + <entry>doc/, src/ documentazione</entry> + </row> + + <row> + <entry>ports</entry> + + <entry>portmgr@</entry> + + <entry>ports/</entry> + </row> + </tbody> + </tgroup> + </informaltable> + + <para>I bit di commit assegnati prima dello sviluppo della nozione di aree + di autorità possono essere usati in molte parti dell'albero. + Tuttavia, il buon senso dice che un committer che non ha mai lavorato + precedentemente in un'area dell'albero chieda una revisione del proprio + lavoro prima di effettuare il commit, chieda l'approvazione del + responsabile appropriato, e/o lavori d'accordo con un mentore. Dato che + le regole sulla manutenzione del codice differiscono a seconda dell'area + dell'albero, questo è per il bene del committer che lavora in + un'area poco familiare tanto quanto per gli altri che lavorano + sull'albero.</para> + + <para>I committer sono incoraggiati a chiedere la revisione del proprio + lavoro come parte del normale processo di sviluppo, indifferentemente + dall'area dell'albero in cui stanno lavorando.</para> + </sect1> + + <sect1 id="cvs.operations"> + <title>Operazioni sul CVS</title> + + <para>Si assume che tu abbia già familiarità con le operazioni + di base di CVS.</para> + + <para>I &a.cvs; sono i <quote>proprietari</quote> del repository CVS e sono + responsabili di <emphasis>tutte</emphasis> le sue modifiche dirette allo + scopo di ripulire o sistemare dei gravi abusi di CVS da parte di un + committer. Nessun altro deve provare a toccare il repository + direttamente. Nel caso dovessi causare qualche problema al repository, + diciamo una errata operazione di <command>cvs import</command> o + <command>cvs tag</command>, <emphasis role="bold">non</emphasis> cercare + di sistemarla da solo! + Invia un messaggio ai &a.cvs; (o chiama uno di loro) ed esponi il problema + ad uno di loro invece. Gli unici che hanno il permesso di manipolare + direttamente i bit del repository sono i + <quote>repomeister</quote>.</para> + + <para>Le operazioni sul CVS solitamente sono fatte loggandosi su + <hostid>freefall</hostid>, assicurandosi che la variabile di ambiente + <envar>CVSROOT</envar> sia impostata a <filename>/home/ncvs</filename>, e + quindi effettuando le appropriate operazioni di check-out/check-in. + Se desideri aggiungere qualcosa di totalmente nuovo (ad esempio dei + sorgenti in contrib, ecc.), deve essere usato <command>cvs + import</command>. Guarda come riferimento la pagina man di &man.cvs.1; + per l'utilizzo.</para> + + <para>Tieni presente che quando usi CVS su <hostid>freefall</hostid>, devi + impostare la tua <literal>umask</literal> a <literal>2</literal>, + così come la variabile di ambiente <envar>CVSUMASK</envar> a + <literal>2</literal>. Questo assicura che ogni nuovo file creato tramite + <command>cvs add</command> abbia i corretti permessi. + Se aggiungi un file o una directory e scopri che il file nel repository + ha i permessi errati (per essere precisi, tutti i file nel repository + dovrebbero essere modificabili dal gruppo <literal>ncvs</literal>), + contatta uno dei meister del repository come descritto sopra.</para> + + <para>Se sei abituato ad usare CVS da remoto e ti consideri abbastanza + pratico di CVS in generale, puoi anche effettuare le operazioni sul CVS + direttamente dalla tua macchina e dai tuoi sorgenti locali. + Ricordati solo di impostare <envar>CVS_RSH</envar> a + <literal>ssh</literal> così da usare un metodo di trasferimento + relativamente sicuro ed affidabile. Se non hai idea del significato di + quello che ho appena detto, allora continua a loggarti su + <hostid>freefall</hostid> ed ad applicare le tue diff con + &man.patch.1;.</para> + + <para>Se devi usare le operazioni <command>add</command> e + <command>delete</command> di CVS come se fosse un'operazione &man.mv.1;, + allora va effettuata una copia nel repository piuttosto che usare + <command>add</command> e <command>delete</command> di CVS. In una + copia nel repository, un <link linkend="conventions">CVS Meister</link> + copierà il/i file nei loro nuovi nomi e/o locazioni e ti + avviserà ad operazione avvenuta. Lo scopo di una copia del + repository è di preservare la cronologia dei cambiamenti del file, + o i log. Noi del FreeBSD Project diamo molta importanza alla cronologia + dei cambiamenti che CVS fornisce al progetto.</para> + + <para>Informazioni di riferimento, tutorial, e FAQ su CVS possono + essere trovate su: <ulink + url="http://www.cvshome.org/docs/">http://www.cvshome.org/docs/</ulink>, + e anche le informazioni contenute nei <ulink + url="http://cvsbook.red-bean.com/cvsbook.html">capitoli di Karl Fogel + da <quote>Open Source Development with CVS</quote></ulink> sono molto + utili.</para> + + <para>&a.des; ha fornito inoltre il seguente <quote>mini manuale</quote> su + CVS.</para> + + <orderedlist> + <listitem> + <para>Effettua il check out di un modulo con il comando + <command>co</command> o <command>checkout</command>.</para> + + <screen>&prompt.user; <userinput>cvs checkout shazam</userinput></screen> + + <para>Questo estrae una copia del modulo <filename>shazam</filename>. Se + non c'è alcun modulo <filename>shazam</filename> nel file dei + moduli, cercherà allora una directory di primo livello chiamata + <filename>shazam</filename>.</para> + + <table frame="none"> + <title>Opzioni utili con <command>cvs checkout</command></title> + + <tgroup cols=2> + <tbody> + <row> + <entry><option>-P</option></entry> + + <entry>Non crea le directory vuote</entry> + </row> + + <row> + <entry><option>-l</option></entry> + + <entry>Estrae solo un livello, non le sottodirectory</entry> + </row> + + <row> + <entry><option>-r<replaceable>ver</replaceable></option></entry> + + <entry>Estrai la versione, il ramo, o il tag + <replaceable>ver</replaceable></entry> + </row> + + <row> + <entry><option>-D<replaceable>data</replaceable></option></entry> + + <entry>Estrai i sorgenti com'erano in data + <replaceable>data</replaceable></entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Esempi pratici su FreeBSD:</para> + + <itemizedlist> + <listitem> + <para>Estrai il modulo <filename>miscfs</filename>, che + corrisponde a <filename>src/sys/miscfs</filename>:</para> + + <screen>&prompt.user; <userinput>cvs co miscfs</userinput></screen> + + <para>Ora hai una directory chiamata <filename>miscfs</filename> + con le sottodirectory <filename>CVS</filename>, + <filename>deadfs</filename>, <filename>devfs</filename>, e + così via. Una di queste (<filename>linprocfs</filename>) + è vuota.</para> + </listitem> + + <listitem> + <para>Estrai gli stessi file, ma con il percorso completo:</para> + + <screen>&prompt.user; <userinput>cvs co src/sys/miscfs</userinput></screen> + + <para>Ora hai una directory chiamata <filename>src</filename>, + con le sottodirectory <filename>CVS</filename> e + <filename>sys</filename>. <filename>src/sys</filename> ha le + sottodirectory <filename>CVS</filename> e + <filename>miscfs</filename>, ecc.</para> + </listitem> + + <listitem> + <para>Estrai gli stessi file, ma elimina le directory vuote:</para> + + <screen>&prompt.user; <userinput>cvs co -P miscfs</userinput></screen> + + <para>Ora hai una directory chiamata <filename>miscfs</filename> + con le sottodirectory <filename>CVS</filename>, + <filename>deadfs</filename>, <filename>devfs</filename>... ma nota + che non c'è nessuna sottodirectory + <filename>linprocfs</filename>, perché non contiene alcun + file.</para> + </listitem> + + <listitem> + <para>Estrai la directory <filename>miscfs</filename>, ma nessuna + delle sue sottodirectory:</para> + + <screen>&prompt.user; <userinput>cvs co -l miscfs</userinput></screen> + + <para>Ora hai una a directory chiamata <filename>miscfs</filename> + con solo una sottodirectory chiamata + <filename>CVS</filename>.</para> + </listitem> + + <listitem> + <para>Estrai il modulo <filename>miscfs</filename> com'è nel + ramo 4.X:</para> + + <screen>&prompt.user; <userinput>cvs co -rRELENG_4 miscfs</userinput></screen> + + <para>Puoi modificare i sorgenti ed effettuare il commit su questo + ramo.</para> + </listitem> + + <listitem> + <para>Estrai il modulo <filename>miscfs</filename> com'era nella + 3.4-RELEASE.</para> + + <screen>&prompt.user; <userinput>cvs co -rRELENG_3_4_0_RELEASE miscfs</userinput></screen> + + <para>Non potrai effettuare il commit delle modifiche, visto che + <literal>RELENG_3_4_0_RELEASE</literal> corrisponde ad un + preciso istante di tempo, non a un ramo.</para> + </listitem> + + <listitem> + <para>Estrai il modulo <filename>miscfs</filename> com'era il 15 + gennaio 2000.</para> + + <screen>&prompt.user; <userinput>cvs co -D'01/15/2000' miscfs</userinput></screen> + + <para>Non potrai effettuare modifiche.</para> + </listitem> + + <listitem> + <para>Estrai il modulo <filename>miscfs</filename> com'era una + settimana fa.</para> + + <screen>&prompt.user; <userinput>cvs co -D'last week' miscfs</userinput></screen> + + <para>Non potrai effettuare modifiche.</para> + </listitem> + </itemizedlist> + + <para>Tieni presente che cvs salva i metadati in sottodirectory chiamate + <filename>CVS</filename>.</para> + + <para>Gli argomenti di <option>-D</option> e <option>-r</option> + sono fissi, che vuol dire che cvs se li ricorderà in seguito, + ad esempio quando farai un <command>cvs update</command>.</para> + </listitem> + + <listitem> + <para>Controlla lo stato dei file estratti con il comando + <command>status</command>.</para> + + <screen>&prompt.user; <userinput>cvs status shazam</userinput></screen> + + <para>Questo visualizza lo stato del file <filename>shazam</filename> o + di ogni file nella directory <filename>shazam</filename>. Per ogni + file, lo stato è uno fra:</para> + + <informaltable frame="none"> + <tgroup cols=2> + <tbody> + <row> + <entry>Up-to-date</entry> + + <entry>Il file à aggiornato e non è stato + modificato.</entry> + </row> + + <row> + <entry>Needs Patch</entry> + + <entry>Il file non è stato modificato, ma c'è una + nuova versione nel repository.</entry> + </row> + + <row> + <entry>Locally Modified</entry> + + <entry>Il file è aggiornato, ma è stato + modificato.</entry> + </row> + + <row> + <entry>Needs Merge</entry> + + <entry>Il file è stato modificato, e c'è una nuova + versione nel repository.</entry> + </row> + + <row> + <entry>File had conflicts on merge</entry> + + <entry>Ci sono stati conflitti l'ultima volta che il file + è stato aggiornato, e non sono ancora stati + risolti.</entry> + </row> + </tbody> + </tgroup> + </informaltable> + + <para>Vedrai anche la versione e la data locale, il numero dell'ultima + versione appropriata (<quote>ultima appropriata</quote> perché + se hai una data, un tag o un ramo fissati, può non essere + l'ultima versione), e i tag, le date o le opzioni applicate.</para> + </listitem> + + <listitem> + <para>Dopo avere estratto qualcosa, aggiornalo con il comando + <command>update</command>.</para> + + <screen>&prompt.user; <userinput>cvs update shazam</userinput></screen> + + <para>Questo aggiorna il file <filename>shazam</filename> o il contenuto + della directory <filename>shazam</filename> all'ultima versione sul + ramo che hai estratto. Se hai estratto un <quote>preciso instante di + tempo</quote>, non fa nulla a meno che i tag non siano stati + spostati nel repository o qualche altra strana cosa sia in + corso.</para> + + <para>Opzioni utili, in aggiunta a quelle elencate sopra, con + <command>checkout</command>:</para> + + <informaltable frame="none"> + <tgroup cols=2> + <tbody> + <row> + <entry><option>-d</option></entry> + + <entry>Estrae ogni directory aggiuntiva mancante.</entry> + </row> + + <row> + <entry><option>-A</option></entry> + + <entry>Scarica l'ultima versione del ramo principale.</entry> + </row> + + <row> + <entry><option>-j<replaceable>ver</replaceable></option></entry> + + <entry>Altre magie (guarda sotto).</entry> + </row> + </tbody> + </tgroup> + </informaltable> + + <para>Se hai estratto un modulo con <option>-r</option> o + <option>-D</option>, l'esecuzione di <command>cvs update</command> + con un argomento differente di <option>-r</option> o + <option>-D</option> o con <option>-A</option> selezionerà un + nuovo ramo, una nuova versione o una nuova data. + L'opzione <option>-A</option> elimina tutti i tag, le date o le + versioni fissate mentre <option>-r</option> e <option>-D</option> ne + impostano di nuove.</para> + + <para>Teoricamente, specificando <literal>HEAD</literal> come argomento + di <option>-r</option> avrai lo stesso risultato di + <option>-A</option>, ma è solo in teoria.</para> + + <para>L'opzione <option>-d</option> è utile se:</para> + + <itemizedlist> + <listitem> + <para>qualcuno ha aggiunto delle sottodirectory al modulo che hai + estratto dopo averlo estratto.</para> + </listitem> + + <listitem> + <para>hai estratto con <option>-l</option>, e dopo cambi idea e + vuoi estrarre anche le sottodirectory.</para> + </listitem> + + <listitem> + <para>hai cancellato delle sottodirectory e vuoi estrarle + nuovamente.</para> + </listitem> + </itemizedlist> + + <para><emphasis>Osserva l'output di <command>cvs update</command> con + cura</emphasis>. La lettera all'inizio di ogni file indica cosa + è stato fatto su di esso:</para> + + <informaltable frame="none"> + <tgroup cols=2> + <tbody> + <row> + <entry><literal>U</literal></entry> + + <entry>Il file è stato aggiornato senza problemi.</entry> + </row> + + <row> + <entry><literal>P</literal></entry> + + <entry>Il file è stato aggiornato senza problemi (vedrai + questo solo quando lavorerai su un repository remoto).</entry> + </row> + + <row> + <entry><literal>M</literal></entry> + + <entry>Il file è stato modificato, ed è stato + fuso senza conflitti.</entry> + </row> + + <row> + <entry><literal>C</literal></entry> + + <entry>Il file è stato modificato, ed è stato + fuso con dei conflitti.</entry> + </row> + </tbody> + </tgroup> + </informaltable> + + <para>La fusione è ciò che avviene quando estrai una copia + di qualche codice sorgente, lo modifichi, quindi qualcun altro + effettua il commit di un'altra modifica, e tu esegui <command>cvs + update</command>. CVS nota che tu hai fatto dei cambiamenti locali, e + cerca di fondere le tue modifiche con quelle fatte tra la versione che + hai originariamente estratto e quella che stai aggiornando. Se i + cambiamenti sono a due parti separate del file, solitamente non ci + saranno problemi (sebbene il risultato possa non essere + sintatticamente o semanticamente corretto).</para> + + <para>CVS stamperà una <literal>M</literal> davanti ad ogni file + modificato localmente anche se non c'è una nuova versione nel + repository, quindi <command>cvs update</command> è adatto + per avere un resoconto di quello che hai cambiato in locale.</para> + + <para>Se appare una <literal>C</literal>, allora le tue modifiche sono + in conflitto con i cambiamenti presenti nel repository (le modifiche + sono sulle stesse righe, o righe vicine, o hai cambiato così + tanto il file locale che <command>cvs</command> non è in grado + di applicare le modifiche al repository). Dovrai allora andare a + modificare il file a mano e risolvere i conflitti; questi saranno + evidenziati da righe di simboli <literal><</literal>, + <literal>=</literal> e <literal>></literal>. Per ogni conflitto, + ci sarà una linea di demarcazione formata da sette + <literal><</literal> e il nome del file, seguita da una porzione di + quello che il tuo file locale conteneva, seguita da una riga di + separazione con sette <literal>=</literal>, seguita dalla porzione + corrispondente presente nella versione del repository, seguita da una + riga di separazione con sette <literal>></literal> e il numero di + versione che stai aggiornando.</para> + + <para>L'opzione <option>-j</option> è un po' voodoo. Aggiorna + il file locale alla versione specificata come se avessi usato + <option>-r</option>, ma non cambia il numero di versione o il ramo + registrato del file locale. Non è realmente utile tranne + quando usata due volte, nel qual caso fonderà le modifiche + tra le due versioni specificate nella copia su cui stai + lavorando.</para> + + <para>Per esempio, supponiamo che ti abbia effettuato il commit di una + modifica a <filename>shazam/shazam.c</filename> in &os.current; e che + più tardi tu voglia effettuare l'MFC. Le modifiche che vuoi + fondere sono nella versione 1.15:</para> + + <itemizedlist> + <listitem> + <para>Estrai la versione &os.stable; del modulo + <filename>shazam</filename>:</para> + + <screen>&prompt.user; <userinput>cvs co -rRELENG_4 shazam</userinput></screen> + </listitem> + + <listitem> + <para>Applica le modifiche tra la ver 1.14 e la 1.15:</para> + + <screen>&prompt.user; <userinput>cvs update -j1.14 -j1.15 shazam/shazam.c</userinput></screen> + </listitem> + </itemizedlist> + + <para>Quasi certamente avrai un conflitto a causa delle righe + <literal>$<!-- blocca l'espansione -->Id<!-- blocca l'espansione + -->$</literal> (o nel caso di FreeBSD, <literal>$<!-- blocca + l'espansione -->FreeBSD<!-- blocca l'espansione -->$</literal>), + quindi dovrai modificare a mano il file per risolvere il conflitto + (rimuovi le righe di separazione e la seconda linea + <literal>$<!-- blocca l'espansione -->Id<!-- blocca l'espansione + -->$</literal>, lasciando la linea <literal>$<!-- blocca + l'espansione -->Id<!-- blocca l'espansione -->$</literal> + originale intatta).</para> + </listitem> + + <listitem> + <para>Guarda le differenze tra la versione locale e quella sul + repository con il comando <command>diff</command>.</para> + + <screen>&prompt.user; <userinput>cvs diff shazam</userinput></screen> + + <para>mostra ogni modifica che hai fatto al file o al modulo + <filename>shazam</filename>.</para> + + <table frame="none"> + <title>Opzioni utili con <command>cvs diff</command></title> + + <tgroup cols=2> + <tbody> + <row> + <entry><option>-u</option></entry> + + <entry>Utilizza il formato diff unificato.</entry> + </row> + + <row> + <entry><option>-c</option></entry> + + <entry>Utilizza il formato diff contestuale.</entry> + </row> + + <row> + <entry><option>-N</option></entry> + + <entry>Visualizza i file mancanti o aggiunti.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Vorrai sempre utilizzare <option>-u</option>, visto che le diff + unificate sono molto più semplici da leggere rispetto a quasi + tutti gli altri formati (in alcune circostanze, le diff contestuali + generate con l'opzione <option>-c</option> possono essere meglio, ma + sono molto più voluminose). Una diff unificata consiste di una + serie di parti. Ogni parte inizia con una riga con due caratteri + <literal>@</literal> e specifica dove si trovano le differenze nel + file e su quante linee si estendono. Questa è seguita da un + certo numero di righe; alcune (precedute da uno spazio) fanno parte + del contesto; altre (precedute da un <literal>-</literal>) sono quelle + eliminate e altre ancora (precedute da un <literal>+</literal>) sono + quelle aggiunte.</para> + + <para>Puoi anche effettuare una diff con una versione differente + rispetto a quella che hai estratto specificando la versione con + <option>-r</option> o <option>-D</option> come per il + <command>checkout</command> o l'<command>update</command>, + o anche visualizzare le differenze tra due versioni arbitrarie + (indipendentemente da quella che hai localmente) specificando + <emphasis>due</emphasis> versioni con <option>-r</option> o + <option>-D</option>.</para> + </listitem> + + <listitem> + <para>Guarda le righe di log con il comando + <command>log</command>.</para> + + <screen>&prompt.user; <userinput>cvs log shazam</userinput></screen> + + <para>Se <filename>shazam</filename> è un file, questo + stamperà un'<emphasis>intestazione</emphasis> con le + informazioni sul file, come la locazione nel repository dove il file + è salvato, a quale versione è l'<literal>HEAD</literal> + per questo file, in quali rami si trova il file, e qualsiasi tag + valido per questo file. Quindi, per ogni versione del file, viene + stampato un messaggio di log. Questo include la data e l'ora del + commit, chi ha fatto il commit, quante righe sono state aggiunte e/o + tolte, e alla fine il messaggio di log che il committer ha scritto + quando ha inviato la modifica.</para> + + <para>Se <filename>shazam</filename> è una directory, allora le + informazioni di log descritte sopra vengono stampate a turno per ogni + file presente nella directory. A meno che tu abbia dato l'opzione + <option>-l</option> a <command>log</command>, vengono stampati anche + i log per tutte le sottodirectory di <filename>shazam</filename>, in + maniera ricorsiva.</para> + + <para>Usa il comando <command>log</command> per vedere la storia di uno + o più file, come è salvata nel repository CVS. Puoi + anche usarlo per vedere il messaggio di log di una versione specifica, + se aggiungi <option>-r<replaceable>ver</replaceable></option> al + comando <command>log</command>:</para> + + <screen>&prompt.user; <userinput>cvs log -r1.2 shazam</userinput></screen> + + <para>Questo stamperà solamente il messaggio di log per la + versione <literal>1.2</literal> del file <filename>shazam</filename> + se è un file, oppure i messaggi di log per le versioni 1.2 di + ogni file sotto <filename>shazam</filename> se è una + directory.</para> + </listitem> + + <listitem> + <para>Guarda chi ha fatto cosa con il comando + <command>annotate</command>. Questo comando visualizza ogni riga del + file o dei file specificati, insieme all'utente che ha modificato + più recentemente quella riga.</para> + + <screen>&prompt.user; <userinput>cvs annotate shazam</userinput></screen> + </listitem> + + <listitem> + <para>Aggiungi nuovi file con il comando <command>add</command>.</para> + + <para>Crea il file, usa <command>cvs add</command> su di esso, quindi + <command>cvs commit</command>.</para> + + <para>In modo analogo, puoi aggiungere nuove directory creandole e poi + utilizzando <command>cvs add</command> su di esse. Nota che non + c'è bisogno di usare il commit sulle directory.</para> + </listitem> + + <listitem> + <para>Rimuovi i file obsoleti con il comando + <command>remove</command>.</para> + + <para>Rimuovi il file, quindi usa <command>cvs rm</command> su di esso, + ed infine <command>cvs commit</command>.</para> + </listitem> + + <listitem> + <para>Effettua il commit con il comando <command>commit</command> o + <command>checkin</command>.</para> + + <table frame="none"> + <title>Opzioni utili con <command>cvs commit</command></title> + + <tgroup cols=2> + <tbody> + <row> + <entry><option>-f</option></entry> + + <entry>Forza il commit di un file non modificato.</entry> + </row> + + <row> + <entry><option>-m<replaceable>msg</replaceable></option></entry> + + <entry>Specifica un messaggio di commit sulla riga di comando + anziché invocare un editor.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Usa l'opzione <option>-f</option> se ti accorgi che hai lasciato + fuori informazioni importanti dal messaggio di commit.</para> + + <para>Buoni messaggi di commit sono importanti. Dicono agli altri + perché hai fatto le modifiche che hai fatto, non solo qui ed + ora, ma per mesi o anni quando qualcuno si chiederà + perché dei pezzi di codice all'apparenza illogici o + inefficienti sono entrati nel file sorgente. È inoltre un + aiuto inestimabile per decidere su quali modifiche va effettuato + l'MFC e su quali no.</para> + + <para>I messaggi di commit devono essere chiari, concisi, e fornire + un ragionevole sommario per dare un'indicazione di cosa è stato + cambiato e perché.</para> + + <para>I messaggi di commit devono fornire abbastanza informazioni + affinché una terza parte possa decidere se la modifica è + rilevante per lei e se debba leggere la modifica stessa.</para> + + <para>Evita di effettuare il commit di più modifiche scollegate + in una volta sola. Questo rende difficile la fusione, e inoltre rende + più complicato determinare quale modifica è colpevole + se salta fuori un bug.</para> + + <para>Evita di effettuare il commit di correzioni di stile o di + spaziatura insieme a correzioni di funzionalità. Questo rende + difficile la fusione, e inoltre rende più complicato capire + quali modifiche alle funzionalità sono state fatte. Nel caso + di file di documentazione, può rendere il lavoro dei gruppi + di traduzione più complicato, visto che diventa difficile per + loro determinare esattamente quali modifiche al contenuto vanno + tradotte.</para> + + <para>Evita di effettuare il commit di cambiamenti a più file + con un unico messaggio generico o vago. Invece, effettua il commit + di un file alla volta (o di piccoli gruppi di file correlati) con un + messaggio di commit appropriato.</para> + + <para>Prima di effettuare il commit, devi + <emphasis>sempre</emphasis>:</para> + + <itemizedlist> + <listitem> + <para>verificare su che ramo stai effettuando il commit, tramite + <command>cvs status</command>.</para> + </listitem> + + <listitem> + <para>revisionare i tuoi cambiamenti, con + <command>cvs diff</command></para> + </listitem> + </itemizedlist> + + <para>Inoltre, devi SEMPRE specificare esplicitamente sulla riga di + comando su quali file deve essere effettuato il commit, in modo da non + toccare incidentalmente altri file non voluti - <command>cvs + commit</command> senza argomenti effettuerà il commit di ogni + modifica nella directory corrente ed ogni sottodirectory.</para> + </listitem> + </orderedlist> + + <para>Suggerimenti e trucchi aggiuntivi:</para> + + <orderedlist> + <listitem> + <para>Puoi inserire le opzioni più comunemente usate nel tuo + <filename>~/.cvsrc</filename>, come in questo caso:</para> + + <programlisting>cvs -z3 +diff -Nu +update -Pd +checkout -P</programlisting> + + <para>Questo esempio dice:</para> + + <itemizedlist> + <listitem> + <para>usa sempre il livello di compressione 3 quando si parla con un + server remoto. Questo è un salvavita quando si lavora su + una connessione lenta.</para> + </listitem> + + <listitem> + <para>usa sempre le opzioni <option>-N</option> (visualizza i file + aggiunti o rimossi) e <option>-u</option> (formato diff unificato) + con &man.diff.1;.</para> + </listitem> + + <listitem> + <para>usa sempre le opzioni <option>-P</option> (elimina le + directory vuote) e <option>-d</option> (estrai le nuove directory) + quando si effettua l'update.</para> + </listitem> + + <listitem> + <para>usa sempre l'opzione <option>-P</option> (elimina le + directory vuote) quando si estrae.</para> + </listitem> + </itemizedlist> + </listitem> + + <listitem> + <para>Usa lo script <command>cdiff</command> di Eivind Eklund per + visualizzare le diff unificate. È un wrapper per &man.less.1; + che aggiunge i codici colore ANSI per far risaltare le intestazioni + delle sezioni, le righe rimosse e quelle aggiunte; il contesto rimane + invariato. Inoltre espande i tab correttamente (i tab spesso appaiono + errati nelle diff a causa del carattere aggiuntivo all'inizio di ogni + riga).</para> + + <para><ulink + url="http://people.FreeBSD.org/~eivind/cdiff">http://people.FreeBSD.org/~eivind/cdiff</ulink></para> + + <para>Semplicemente usalo al posto di &man.more.1; o + &man.less.1;:</para> + + <screen>&prompt.user; <userinput>cvs diff -Nu shazam | cdiff</userinput></screen> + + <para>Alternativamente alcuni editor come &man.vim.1; + (<filename role="package">editors/vim5</filename>) hanno il supporto + al colore e quando vengono usati con l'evidenziazione della sintassi + attiva evidenzieranno molti tipi di file, incluse le diff, le patch, + e i log cvs/rcs.</para> + + <screen>&prompt.user; <userinput>echo "syn on" >> ~/.vimrc </userinput> +&prompt.user; <userinput>cvs diff -Nu shazam | vim -</userinput> +&prompt.user; <userinput>cvs log shazam | vim -</userinput> </screen> + </listitem> + + <listitem> + <para>CVS è vecchio, arcano, complesso e buggato, e a volte + esibisce comportamenti non deterministici che qualcuno sostiene siano + la prova che CVS non sia niente di più di una manifestazione + Newtoniana di una entità ultradimensionale sensibile. + Non è umanamente possibile conoscere ogni dettaglio di CVS, + quindi non essere dispiaciuto di chiedere aiuto all'Intelligenza + Artificiale (&a.cvs;).</para> + </listitem> + + <listitem> + <para>Non lasciare il comando <command>cvs commit</command> nella + modalità di inserimento del messaggio di commit per troppo + tempo (più di 2–3 minuti). Questo blocca la directory in + cui stai lavorando ed impedirà ad altri sviluppatori di + effettuare commit nella stessa directory. Se devi digitare un + messaggio di commit lungo, scrivilo prima di eseguire + <command>cvs commit</command>, e inseriscilo successivamente.</para> + </listitem> + </orderedlist> + </sect1> + + <sect1 id="conventions"> + <title>Convenzioni e Tradizioni</title> + + <para>Come nuovo committer ci sono alcune cose che dovresti fare + all'inizio.</para> + + <itemizedlist> + <listitem> + <para>Aggiungere te stesso alla sezione <quote>Developers</quote> della + <ulink url="../contributors/index.html">Contributors List</ulink> e + rimuovere te stesso dalla sezione <quote>Additional + Contributors</quote>. Una volta fatto ciò, non dimenticarti + di aggiungere la tua entity di autore in + <filename>doc/en_US.ISO8859-1/share/sgml/authors.ent</filename>; + usa le altre voci come esempio.</para> + + <para>Questo è un compito relativamente semplice, ma rimane una + buona prima prova delle tue abilità con CVS.</para> + </listitem> + + <listitem> + <para>Aggiungi una voce per te stesso in + <filename>www/en/news/news.xml</filename>. Guarda le altre voci che + assomigliano a <quote>A new committer</quote> e segui il + formato.</para> + </listitem> + + <listitem> + <para>Se hai una chiave PGP o GnuPG, potresti volerla aggiungere in + <filename>doc/en_US.ISO8859-1/books/handbook/pgpkeys</filename>.</para> + + <para>&a.des; ha scritto uno script di shell per rendere questa + operazione molto semplice. Guarda il file <ulink + url="http://cvsweb.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/pgpkeys/README">README</ulink> + per maggiori informazioni.</para> + </listitem> + + <listitem> + <para>Alcune persone aggiungono una voce per se stessi in + <filename>ports/astro/xearth/files/freebsd.committers.markers</filename>.</para> + </listitem> + + <listitem> + <para>Alcune persone aggiungono una voce per se stessi in + <filename>src/usr.bin/calendar/calendars/calendar.freebsd</filename>.</para> + </listitem> + + <listitem> + <para>Presentati agli altri committer, altrimenti nessuno avrà + idea di chi tu sia o di cosa ti occupi. Non devi scrivere una + biografia completa, basta un paragrafo o due su chi sei e su quello + di cui hai intenzione di occuparti come committer di FreeBSD. + Invialo alla &a.developers; e sarai sulla strada giusta!</para> + </listitem> + + <listitem> + <para>Loggati su <hostid>hub.FreeBSD.org</hostid> e crea un file + <filename>/var/forward/<replaceable>utente</replaceable></filename> + (dove <replaceable>utente</replaceable> è il tuo nome utente) + contenente l'indirizzo e-mail dove vuoi che i messaggi indirizzati a + <replaceable>tuonomeutente</replaceable>@FreeBSD.org siano inoltrati. + Questo include tutti i messaggi di commit così come ogni altro + messaggio inviato alla &a.committers; e alla &a.developers;. Caselle + di posta veramente grandi che hanno preso residenza fissa su + <hostid>hub</hostid> spesso vengono <quote>accidentalmente</quote> + troncate senza preavviso, quindi inoltra o leggi i messaggi in modo da + non perderli.</para> + </listitem> + + <listitem> + <para>Se sei iscritto alla &a.cvsall;, probabilmente vorrai + disiscriverti per evitare di ricevere copie doppie dei messaggi di + commit e della loro evoluzione.</para> + </listitem> + </itemizedlist> + + <para>Tutti i nuovi committer hanno un mentore assegnato a loro per i primi + mesi. Il tuo mentore è più o meno responsabile di + spiegarti ogni cosa ti sia poco chiara ed è anche responsabile + delle tue azioni durante questo periodo iniziale. Se fai un commit + errato, imbarazzerai il tuo mentore e probabilmente dovresti passare + almeno i primi commit a lui prima di agire direttamente sul + repository.</para> + + <para>Tutti i commit dovrebbero andare su &os.current; prima di essere + fusi in &os.stable;. Nessuna nuova caratteristica importante o modifica + ad alto rischio dovrebbe essere fatta sul ramo &os.stable;.</para> + </sect1> + + <sect1 id="developer.relations"> + <title>Relazioni tra Sviluppatori</title> + + <para>Se stai lavorando direttamente sul tuo codice o su codice che è + già stabilito essere di tua responsabilità, allora + c'è probabilmente poca necessità di confrontarsi con altri + committer prima di effettuare un commit. Se vedi un bug in un'area del + sistema che è chiaramente orfana (e ce n'è qualcuna di + queste aree, per nostra vergogna), agisci allo stesso modo. Se, tuttavia, + stai per modificare qualcosa che è chiaramente mantenuto + attivamente da qualcun'altro (ed è solo guardando la mailing list + <literal>cvs-committers</literal> che puoi veramente sapere cosa è + e cosa non è) allora invia le modifiche a lui, come avresti + fatto prima di diventare committer. Per i port, dovresti contattare il + <makevar>MAINTAINER</makevar> specificato nel + <filename>Makefile</filename>. Per altre parti del repository, se non sei + sicuro di chi possa essere il maintainer attivo, potrebbe essere utile + scorrere l'output di <command>cvs log</command> per vedere chi ha + effettuato delle modifiche in passato. &a.fenner; ha scritto un utile + script di shell che può aiutare a determinare chi sia il + maintainer attivo. Questo elenca ogni persona che ha effettuato commit + su un file specifico con il numero di commit che ha fatto. Può + essere trovato su <hostid>freefall</hostid> in + <filename>~fenner/bin/whodid</filename>. Se alle tue richieste non + corrisponde una risposta o se il committer in altro modo dimostra uno + scarso interesse nell'area oggetto della modifica, vai avanti ed effettua + il commit tu stesso.</para> + + <para>Se non sei sicuro di un commit per qualunque motivo, fallo revisionare + da <literal>-hackers</literal> prima di effettuare il commit. Meglio + che sia criticato lì piuttosto che quando è parte del + repository CVS. Se ti capita di effettuare un commit che provoca + controversie, potresti voler considerare l'annullamento delle modifiche + finché il problema sia chiarito. Ricorda – con CVS possiamo + sempre tornare indietro.</para> + </sect1> + + <sect1 id="gnats"> + <title>GNATS</title> + + <para>Il FreeBSD Project utilizza <application>GNATS</application> per + gestire i bug e le richieste di cambiamenti. Assicurati di usare + <command>edit-pr <replaceable>numero-pr</replaceable></command> su + <hostid>freefall</hostid> quando effettui il commit di una correzione o di + un suggerimento trovato in un PR <application>GNATS</application> per + chiuderlo. È inoltre considerato gentile se trovi il tempo di + chiudere ogni PR associato al tuo commit, se esistono. Puoi anche usare + &man.send-pr.1; tu stesso per proporre qualsiasi cambiamento che pensi + debba essere fatto, a seguito di una maggiore revisione da parte di altre + persone.</para> + + <para>Puoi trovare di più su <application>GNATS</application> + su:</para> + + <itemizedlist> + <listitem> + <para><ulink + url="http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html">http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html</ulink></para> + </listitem> + + <listitem> + <para><ulink + url="../../../../support.html">http://www.FreeBSD.org/support.html</ulink></para> + </listitem> + + <listitem> + <para><ulink + url="../../../../send-pr.html">http://www.FreeBSD.org/send-pr.html</ulink></para> + </listitem> + + <listitem> + <para>&man.send-pr.1;</para> + </listitem> + </itemizedlist> + + <para>Puoi far girare una copia locale di GNATS, e poi integrare l'albero + GNATS di FreeBSD in esso tramite CVSup. In seguito puoi usare i comandi + GNATS localmente, o usare altre interfacce, come + <command>tkgnats</command>. Questo ti permette di interrogare il database + dei PR senza bisogno di essere connesso a Internet.</para> + + <procedure> + <title>Utilizzo di un albero GNATS locale</title> + + <step> + <para>Se non stai già scaricando l'albero GNATS, aggiungi questa + riga al tuo <filename>supfile</filename>, e riesegui &man.cvsup.1;. + Nota che siccome GNATS non è sotto + il controllo di CVS non ha tag, quindi se lo stai aggiungendo al tuo + <filename>supfile</filename> esistente deve apparire prima di ogni + voce <quote>tag=</quote> dato che queste rimangono attive una volta + impostate.</para> + + <programlisting>gnats release=current prefix=/usr</programlisting> + + <para>Questo metterà l'albero GNATS di FreeBSD in + <filename>/usr/gnats</filename>. Puoi usare un file + <emphasis>refuse</emphasis> per controllare quali categorie ricevere. + Per esempio, per ricevere solo i PR <literal>docs</literal>, metti + questa riga in <filename>/usr/local/etc/cvsup/sup/refuse</filename> + <footnote> + <para>Il percorso preciso dipende dall'impostazione + <literal>*default base</literal> nel tuo + <filename>supfile</filename>.</para> + </footnote>.</para> + + <programlisting>gnats/[a-ce-z]*</programlisting> + + <para>Il resto di questi esempi assume che tu abbia scaricato solo la + categoria <literal>docs</literal>. Modificali quando è + necessario, a seconda delle categorie che tieni in sincronia.</para> + </step> + + <step> + <para>Installa il port GNATS da + <filename>ports/databases/gnats</filename>. Questo metterà le + varie directory GNATS sotto + <filename>$PREFIX/share/gnats</filename>.</para> + </step> + + <step> + <para>Crea un symlink per le directory GNATS che aggiorni tramite CVSup + sotto la versione di GNATS che hai installato.</para> + + <screen>&prompt.root; <userinput>cd /usr/local/share/gnats/gnats-db</userinput> +&prompt.root; <userinput>ln -s /usr/gnats/docs</userinput></screen> + + <para>Ripeti tante volte quanto necessario, a seconda di quante + categorie GNATS tieni in sincronia.</para> + </step> + + <step> + <para>Aggiorna il file <filename>categories</filename> di GNATS con + queste categorie. Il file è + <filename>$PREFIX/share/gnats/gnats-db/gnats-adm/categories</filename>.</para> + + <programlisting># Questa categoria è obbligatoria +pending:Categoria per i PR errati:gnats-admin: +# +# Categorie di FreeBSD +# +docs:Bug di Documentazione:nik:</programlisting> + </step> + + <step> + <para>Esegui <filename>$PREFIX/libexec/gnats/gen-index</filename> per + ricreare l'indice GNATS. L'output deve essere reindirizzato su + <filename>$PREFIX/share/gnats/gnats-db/gnats-adm/index</filename>. + Puoi fare questo periodicamente da &man.cron.8;, o eseguire + &man.cvsup.1; da uno script di shell che fa anche questo.</para> + + <screen>&prompt.root; <userinput>/usr/local/libexec/gnats/gen-index \ + > /usr/local/share/gnats/gnats-db/gnats-adm/index</userinput></screen> + </step> + + <step> + <para>Verifica la configurazione interrogando il database dei PR. + Questo comando visualizza i PR <literal>docs</literal> aperti.</para> + + <screen>&prompt.root; <userinput>query-pr -c docs -s open</userinput></screen> + + <para>Anche altre interfacce, come quella fornita dal port <filename + role="package">databases/tkgnats</filename>, dovrebbero funzionare + correttamente.</para> + </step> + + <step> + <para>Prendi un PR e chiudilo.</para> + </step> + </procedure> + + <note> + <para>Questa procedura funziona solo per permetterti di visualizzare ed + interrogare i PR localmente. Per modificarli o chiuderli dovrai ancora + loggarti su <hostid>freefall</hostid> e farlo da lì.</para> + </note> + </sect1> + + <sect1 id="people"> + <title>Chi è Chi</title> + + <para>Oltre ai meister del repository, ci sono altri membri e team del + FreeBSD Project che probabilmente arriverai a conoscere nel tuo ruolo di + committer. Brevemente, e senza pretesa di elencarli tutti, questi + sono:</para> + + <variablelist> + <varlistentry> + <term>&a.jhb;</term> + + <listitem> + <para>John è il manager dell'SMPng Project, e ha + autorità sulla progettazione architetturale e + sull'implementazione del passaggio a un sistema di threading e + locking del kernel a grana fine. È anche l'autore + dell'SMPng Architecture Document. Se stai lavorando sullo stesso + sistema, coordinati con John. Puoi imparare di più + sull'SMPng Project dalla sua home page: <ulink + url="http://www.FreeBSD.org/smp/">http://www.FreeBSD.org/smp/</ulink></para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.jake;, &a.tmm;</term> + + <listitem> + <para>Jake e Thomas sono i maintainer del port sull'architettura + sparc64.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.nik;</term> + + <listitem> + <para>Nik supervisiona il <ulink + url="../../../../docproj/index.html">Documentation Project</ulink>. + Oltre a scrivere documentazione mette insieme l'infrastruttura + sotto <filename>doc/share/mk</filename> e i fogli di stile e il + codice relativo sotto <filename>doc/share/sgml</filename>. Se hai + domande su questi sei incoraggiato a inviarle attraverso la &a.doc;. + I committer interessati a contribuire alla documentazione + dovrebbero familiarizzare con il <ulink + url="../../../en_US.ISO8859-1/books/fdp-primer/index.html">Documentation + Project Primer</ulink>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.ru;</term> + + <listitem> + <para>Ruslan è Mister &man.mdoc.7;. Se stai scrivendo una + pagina man e hai bisogno di qualche suggerimento sulla struttura, + o sul linguaggio di markup, chiedi a Ruslan.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.bde;</term> + + <listitem> + <para>Bruce è lo Style Police-Meister. Quando fai un commit + che poteva essere fatto meglio, Bruce sarà lì a + dirtelo. Ringrazia che qualcuno lo sia. Bruce conosce anche molto + bene gli standard applicabili a FreeBSD.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.gallatin;</term> + <term>&a.mjacob;</term> + <term>&a.dfr;</term> + <term>&a.obrien;</term> + + <listitem> + <para>Questi sono gli sviluppatori e i supervisori primari della + piattaforma DEC Alpha AXP.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.dg;</term> + + <listitem> + <para>David è il supervisore del sistema VM. Se hai in mente + una modifica al sistema VM, coordinala con David.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.dfr;</term> + <term>&a.marcel;</term> + <term>&a.peter;</term> + <term>&a.ps;</term> + + <listitem> + <para>Questi sono i principali sviluppatori e supervisori della + piattaforma Intel IA-64, ufficialmente conosciuta come l'Itanium + Processor Family (IPF).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.murray;</term> + <term>&a.steve;</term> + <term>&a.rwatson;</term> + <term>&a.jhb;</term> + <term>&a.bmah;</term> + + <listitem> + <para>Questi sono i membri del &a.re;. Questo team è + responsabile di decidere i tempi delle release e controllare il + processo di release. Durante i periodi di congelamento del + codice, gli ingegneri di release hanno l'autorità finale su + tutte le modifiche al sistema per quel ramo di cui si sta preparando + la release. Se c'è qualcosa che vuoi sia fuso da + &os.current; a &os.stable; (qualsiasi valore queste possano avere + in un dato momento), queste sono le persone con cui devi + parlare.</para> + + <para>Bruce è anche l'autore della documentazione di + release (<filename>src/release/doc/*</filename>). Se effettui il + commit di una modifica che pensi sia degna di menzione nelle note + di release, assicurati che Bruce lo sappia. Meglio ancora, inviagli + una patch con il tuo commento.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.benno;</term> + + <listitem> + <para>Benno è il maintainer ufficiale del port per + PowerPC.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.brian;</term> + + <listitem> + <para>Maintainer ufficiale di + <filename>/usr/sbin/ppp</filename>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.nectar;</term> + + <listitem> + <para>Jacques è il <ulink url="../../../../security/">FreeBSD + Security Officer</ulink> e supervisiona il + &a.security-officer;.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.wollman;</term> + + <listitem> + <para>Se hai bisogno di consigli sulle oscure parti interne delle reti + o non sei sicuro di qualche eventuale modifica al sottosistema di + rete che hai in mente, Garrett è qualcuno con cui parlare. + Garret è inoltre molto esperto sui vari standard applicabili + a FreeBSD.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.committers;</term> + + <listitem> + <para>cvs-committers è l'entità che CVS usa per inviarti + tutti i messaggi di commit. Non devi <emphasis>mai</emphasis> + inviare email direttamente a questa lista. Puoi solamente + rispondere a questa lista quando i messaggi sono brevi e + direttamente correlati a un commit.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>&a.developers;</term> + + <listitem> + <para>developers comprende tutti i committer. Questa lista è + stata creata per essere un forum sulle questioni della + <quote>comunità</quote> dei committer. Esempi sono le + votazioni per il Core, annunci, ecc. Questa lista + <emphasis>non</emphasis> è intesa come posto per la revisione + del codice o come rimpiazzo della &a.arch; o della &a.audit;. + Infatti usarla in questo modo urta il FreeBSD Project dato che + dà l'impressione di una lista privata dove vengono prese le + decisioni generali che influenzano tutta la comunità che usa + FreeBSD senza essere rese <quote>pubbliche</quote>. + Ultimo, ma non per importanza <emphasis>mai e poi mai invia un + messaggio alla &a.developers; mettendo in CC:/BCC: un'altra lista + FreeBSD</emphasis>. + Mai e poi mai invia un messaggio su un'altra mailing list mettendo + in CC:/BCC: la &a.developers;. Fare questo può diminuire + enormemente i benefici di questa lista. Inoltre, non pubblicare o + inoltrare mai email inviate alla &a.developers;. L'atto di inviare + un messaggio alla &a.developers; anziché a una lista + pubblica significa che le informazioni contenute non sono ad uso + pubblico.</para> + </listitem> + </varlistentry> + </variablelist> + </sect1> + + <sect1 id="ssh.guide"> + <title>Guida Rapida a SSH</title> + + <procedure> + <step> + <para>Se stai usando FreeBSD 4.0 o successivo, OpenSSH è incluso + nel sistema base. Se stai usando una release precedente, aggiorna + ed installa uno dei port di SSH. In generale, probabilmente vorrai + prendere OpenSSH dal port <filename + role="package">security/openssh</filename>. Potresti anche voler + estrarre l'ssh1 originale dal port <filename + role="package">security/ssh</filename>, ma sii certo di porre la + dovuta attenzione alla sua licenza. Nota che questi port non possono + essere installati contemporaneamente.</para> + </step> + + <step> + <para>Se non vuoi digitare la tua password ogni volta che usi + &man.ssh.1;, e usi chiavi RSA o DSA per autenticarti, + &man.ssh-agent.1; è lì per la tua comodità. + Se vuoi usare &man.ssh-agent.1;, assicurati di eseguirlo prima di + utilizzare altre applicazioni. Gli utenti X, per esempio, solitamente + fanno questo dal loro file <filename>.xsession</filename> o + <filename>.xinitrc</filename>. Guarda &man.ssh-agent.1; per i + dettagli.</para> + </step> + + <step> + <para>Genera un paio di chiavi con &man.ssh-keygen.1;. Le chiavi + finiranno nella tua directory + <filename><envar>$HOME</envar>/.ssh</filename>.</para> + </step> + + <step> + <para>Invia la tua chiave pubblica + (<filename><envar>$HOME</envar>/.ssh/identity.pub</filename>) + alla persona che ti sta configurando come committer in modo che possa + inserirla nel file <filename>authorized_keys</filename> nella tua + home directory su <hostid>freefall</hostid> (ad esempio, + <filename><envar>$HOME</envar>/.ssh/authorized_keys</filename>). + </para> + </step> + </procedure> + + <para>Ora dovresti essere in grado di usare &man.ssh-add.1; per autenticarti + una volta a sessione. Ti verrà richiesta la pass phrase della tua + chiave privata, e quindi verrà salvata nel tuo agente di + autenticazione (&man.ssh-agent.1;). Se non vuoi più avere la tua + chiave salvata nell'agente, l'esecuzione di <command>ssh-add -d</command> + la rimuoverà.</para> + + <para>Verifica facendo qualcosa come <command>ssh freefall.FreeBSD.org ls + /usr</command>.</para> + + <para>Per maggiori informazioni, guarda <filename + role="package">security/openssh</filename>, &man.ssh.1;, + &man.ssh-add.1;, &man.ssh-agent.1;, &man.ssh-keygen.1;, e + &man.scp.1;.</para> + </sect1> + + <sect1 id="rules"> + <title>Il Lungo Elenco di Regole dei Committer di FreeBSD</title> + + <para>Traduzione in corso</para> + </sect1> + + <sect1 id="ports"> + <title>FAQ Specifiche sui Port</title> + + <para>Traduzione in corso</para> + </sect1> + + <sect1 id="perks"> + <title>Benefici del Lavoro</title> + + <para>Traduzione in corso</para> + </sect1> + + <sect1 id="misc"> + <title>Domande Generali</title> + + <para>Traduzione in corso</para> + </sect1> +</article> |