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 | 1849 |
1 files changed, 0 insertions, 1849 deletions
diff --git a/it_IT.ISO8859-15/articles/committers-guide/article.sgml b/it_IT.ISO8859-15/articles/committers-guide/article.sgml deleted file mode 100644 index a33df813b4..0000000000 --- a/it_IT.ISO8859-15/articles/committers-guide/article.sgml +++ /dev/null @@ -1,1849 +0,0 @@ -<?xml version="1.0" encoding="iso-8859-15" standalone="no"?> -<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.2-Based Extension//EN" - "../../../share/sgml/freebsd42.dtd" [ -<!ENTITY % entities PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Entity Set//IT" "../../share/sgml/entities.ent"> -%entities; -]> - -<!-- - The FreeBSD Italian Documentation Project - - $FreeBSD$ - Original revision: 1.219 ---> - -<article lang="it"> - <articleinfo> - <title>Guida del Committer</title> - - <authorgroup> - <author> - <surname>The FreeBSD Italian Documentation Project</surname> - </author> - </authorgroup> - - <copyright> - <year>1999</year> - - <year>2000</year> - - <year>2001</year> - - <year>2002</year> - - <year>2003</year> - - <year>2004</year> - - <holder>The FreeBSD Italian Documentation Project</holder> - </copyright> - - <legalnotice id="trademarks" role="trademarks"> - &tm-attrib.freebsd; - &tm-attrib.cvsup; - &tm-attrib.ibm; - &tm-attrib.intel; - &tm-attrib.sparc; - &tm-attrib.general; - </legalnotice> - - <pubdate>$FreeBSD$</pubdate> - - <releaseinfo>$FreeBSD$</releaseinfo> - - <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> - - &trans.it.alex; - </abstract> - </articleinfo> - - <sect1 id="admin"> - <title>Dettagli Amministrativi</title> - - <informaltable frame="none" orient="port" pgwide="1"> - <tgroup cols="2"> - <tbody> - <row> - <entry><emphasis>Host con il Repository - Principale</emphasis></entry> - - <entry><hostid role="fqdn">ncvs.FreeBSD.org</hostid></entry> - </row> - - <row> - <entry><emphasis>Metodi di Accesso</emphasis></entry> - - <entry>&man.ssh.1;, solo protocollo 2</entry> - </row> - - <row> - <entry><emphasis>CVSROOT Principale</emphasis></entry> - - <entry><hostid - role="fqdn">ncvs.FreeBSD.org</hostid><literal>:</literal><filename>/home/ncvs</filename> - (guarda anche la <xref linkend="cvs.operations"/>).</entry> - </row> - - <row> - <entry><emphasis>&a.cvsadm; Principali</emphasis></entry> - - <entry>&a.peter; e &a.markm;, così come &a.joe; e &a.marcus; - per i <filename>ports/</filename></entry> - </row> - - <row> - <entry><emphasis>Mailing List</emphasis></entry> - - <entry>&a.doc-developers;, &a.doc-committers;; - &a.ports-developers;, &a.ports-committers;; - &a.src-developers;, &a.src-committers;. (Ogni repository di - progetto ha le sue mailing list -developers e -committers. Gli - archivi per queste liste possono essere trovati nei file - <filename>/home/mail/<replaceable>repository-name</replaceable>-developers-archive</filename> - e - <filename>/home/mail/<replaceable>repository-name</replaceable>-committers-archive</filename> - sul cluster di <hostid - role="domainname">FreeBSD.org</hostid>.)</entry> - </row> - - <row> - <entry><emphasis>Report mensili del Core Team</emphasis></entry> - <entry><filename>/home/core/public/monthly-report</filename> - sul cluster di <hostid - role="domainname">FreeBSD.org</hostid>.</entry> - </row> - - <row> - <entry><emphasis>Tag CVS Degni di Nota</emphasis></entry> - - <entry><literal>RELENG_4</literal> (4.X-STABLE), - <literal>RELENG_5</literal> (5.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 del progetto. Per &man.ssh.1; - è permesso solo il protocollo 2. - 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" pgwide="1"> - <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>doceng@</entry> - - <entry>doc/, www/, documentazione src/</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> - - <sect2> - <title>Regolamento dell'attività del <filename>doc/</filename> - committer in <filename>src/</filename></title> - - <itemizedlist> - <listitem> - <para>I doc committer possono effettuare commit riguardanti modifiche - alla documentazione sui file src, come pagine man, README, - database dei fortune, file dei calendari, e correzioni sui commenti - senza l'approvazione di un src committer, prestando la solita - attenzione e cura ai commit.</para> - </listitem> - - <listitem> - <para>I doc committer possono effettuare commit riguardanti piccole - modifiche e correzioni ai sorgenti, come correzioni per la - compilazione, piccole funzionalità, ecc., con un - <quote>Approved by</quote> di un src committer.</para> - </listitem> - - <listitem> - <para>I doc committer possono cercare di ottenere il commit bit sui - src acquisendo un mentore, che proporrà il doc committer al - core. Una volta approvato, verrà aggiunto al file - <filename>access</filename> ed inizierà il normale periodo - sotto la guida del mentore, che implica l'aggiunta di - <quote>Approved by</quote> per un certo periodo.</para> - </listitem> - - <listitem> - <para><quote>Approved by</quote> può essere usato solamente - se l'approvazione è di un src committer senza mentore — - i committer ancora sotto la guida di un mentore possono fornire al - più un <quote>Reviewed by</quote> ma non un - <quote>Approved by</quote>.</para> - </listitem> - </itemizedlist> - </sect2> - </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.cvsadm; sono i <quote>proprietari</quote> del repository CVS e - sono responsabili delle sue modifiche dirette allo scopo di ripulire o - sistemare dei gravi abusi di CVS da parte di un committer. - Nel caso dovessi causare qualche problema al repository, - diciamo una errata operazione di <command>cvs import</command> o - <command>cvs tag</command>, invia un messaggio al membro responsabile - fra i &a.cvsadm;, come stabilito nella tabella qui sotto, (o chiama uno - di loro) ed esponi il problema. Per questioni molto importanti che - interessano l'intero albero CVS—non solo un'area - specifica—puoi contattare i &a.cvsadm;. <emphasis>Non</emphasis> - contattare i &a.cvsadm; per copie di repository o altre cose che possono - gestire i team più specifici.</para> - - <para>Gli unici che hanno il - permesso di manipolare direttamente i bit del repository sono i - <quote>repomeister</quote>. Per questo non ci sono shell di login - disponibili sulle macchine del repository, tranne che per i - repomeister.</para> - - <note> - <para>A seconda dell'area interessata del repository CVS, dovresti - mandare la tua richiesta a uno dei seguenti indirizzi email:</para> - - <itemizedlist> - <listitem> - <para>ncvs@ - a proposito di <filename - role="directory">/home/ncvs</filename>, il repository dei - src</para> - </listitem> - - <listitem> - <para>pcvs@ - a proposito di <filename - role="directory">/home/pcvs</filename>, il repository dei - port</para> - </listitem> - - <listitem> - <para>dcvs@ - a proposito di <filename - role="directory">/home/dcvs</filename>, il repository dei - doc</para> - </listitem> - - <listitem> - <para>projcvs@ - a proposito di <filename - role="directory">/home/projcvs</filename>, il repository dei - progetti di terze parti</para> - </listitem> - </itemizedlist> - </note> - - <para>L'albero CVS è attualmente diviso in quattro repository - differenti, ovvero <literal>doc</literal>, <literal>ports</literal>, - <literal>projects</literal> e <literal>src</literal>. Questi vengono - ricomposti sotto un unico <literal>CVSROOT</literal> quando vengono - distribuiti tramite <application>CVSup</application> per la convenienza - dei nostri utenti.</para> - - <note> - <para>Nota che il modulo <literal>www</literal> che contiene i sorgenti - del <ulink url="http://www.FreeBSD.org">sito web di FreeBSD</ulink> - è contenuto all'interno del repository - <literal>doc</literal>.</para> - </note> - - <para>I repository CVS sono ospitati sulle macchine repository. - Attualmente, ognuno dei repository elencati qui sopra risiede sulla stessa - macchina fisica, <hostid role="hostname">ncvs.FreeBSD.org</hostid>, ma - per permettere la possibilità di averne ognuno su una macchina - diversa in futuro, ci sono diversi nomi di host che i committer - dovrebbero utilizzare. Inoltre, ogni repository risiede in una - directory differente. La seguente tabella racchiude la situazione.</para> - - <table frame="none" id="cvs-repositories-and-hosts"> - <title>Repository CVS, Host e Directory di &os;</title> - - <tgroup cols="3"> - <thead> - <row> - <entry>Repository</entry> - - <entry>Host</entry> - - <entry>Directory</entry> - </row> - </thead> - - <tbody> - <row> - <entry>doc</entry> - - <entry>dcvs.FreeBSD.org</entry> - - <entry>/home/dcvs</entry> - </row> - - <row> - <entry>ports</entry> - - <entry>pcvs.FreeBSD.org</entry> - - <entry>/home/pcvs</entry> - </row> - - <row> - <entry>projects</entry> - - <entry>projcvs.FreeBSD.org</entry> - - <entry>/home/projcvs</entry> - </row> - - <row> - <entry>src</entry> - - <entry>ncvs.FreeBSD.org</entry> - - <entry>/home/ncvs</entry> - </row> - </tbody> - </tgroup> - </table> - - <para>Le operazioni sul CVS sono fatte da remoto impostando la variabile di - ambiente <envar>CVSROOT</envar> a <hostid - role="fqdn">ncvs.FreeBSD.org</hostid><literal>:</literal><filename>/home/ncvs</filename> - e la variabile <envar>CVS_RSH</envar> a <command>ssh</command>, e - quindi effettuando le appropriate operazioni di check-out/check-in. - Molti committer definiscono degli alias che si espandono nella corretta - invocazione di <application>cvs</application> per il repository - appropriato. Per esempio, un utente di &man.tcsh.1; può aggiungere - le seguenti righe al suo <filename>.cshrc</filename> per questo - scopo:</para> - - <programlisting>alias dcvs env CVS_RSH=ssh cvs -d <replaceable>user</replaceable>@dcvs.FreeBSD.org:/home/dcvs -alias pcvs env CVS_RSH=ssh cvs -d <replaceable>user</replaceable>@pcvs.FreeBSD.org:/home/pcvs -alias projcvs env CVS_RSH=ssh cvs -d <replaceable>user</replaceable>@projcvs.FreeBSD.org:/home/projcvs -alias scvs env CVS_RSH=ssh cvs -d <replaceable>user</replaceable>@ncvs.FreeBSD.org:/home/ncvs</programlisting> - - <para>In questo modo è possibile fare tutte le operazioni di - CVS localmente ed usare <command><replaceable>X</replaceable>cvs - commit</command> per effettuare il commit sull'albero CVS ufficiale. - 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> - - <note> - <para>Per favore <emphasis>non</emphasis> usare <command>cvs - checkout</command> o <command>update</command> con la macchina con il - repository ufficiale impostata come CVS Root per tenere aggiornato il - tuo albero dei sorgenti. CVS da remoto non è ottimizzato per la - distribuzione via rete e richiede un grande sovraccarico di lavoro e di - amministrazione sul lato server. Utilizza il nostro metodo di - distribuzione avanzato <command>cvsup</command> per ottenere i bit del - repository, ed esegui solamente l'operazione di - <command>commit</command> sull'host con il repository. - Forniamo un'estesa rete di mirror cvsup per questo scopo, così - come diamo accesso al <hostid>cvsup-master</hostid> se hai veramente - bisogno di essere aggiornato alle ultime modifiche. - Il <hostid>cvsup-master</hostid> ha la potenza necessaria a gestire - questa cosa, il repository principale no. &a.kuriyama; è a capo - del <hostid>cvsup-master</hostid>.</para> - </note> - - <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/"></ulink>. - 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>. La directory - <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" pgwide="1"> - <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, puoi aggiornarlo 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" pgwide="1"> - <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" pgwide="1"> - <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_5 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><filename role="package">textproc/cdiff</filename></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.cvsadm;).</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 oppure - salvalo in un file prima di effettuare il commit ed usa l'opzione - <option>-F</option> di CVS per leggere il messaggio di commit da - quel file, cioè:</para> - - <screen>&prompt.user; <userinput>vi logmsg</userinput> -&prompt.user; <userinput>cvs ci -F logmsg shazam</userinput></screen> - - <para>Questo è il metodo più veloce per passare un - messaggio di commit a CVS ma devi stare attento quando modifichi - il file <filename>logmsg</filename> prima del commit, perché - CVS non ti darà la possibilità di modificare il - messaggio quando effettuerai realmente il commit.</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>Aggiungi la tua entity di autore in - <filename>doc/en_US.ISO8859-1/share/sgml/authors.ent</filename>; - questo dovrebbe essere fatto per prima cosa, visto che l'omissione - di questo commit farà in modo che i prossimi commit - romperanno la compilazione del ramo doc/.</para> - - <para>Questo è un compito relativamente semplice, ma rimane una - buona prima prova delle tue abilità con CVS.</para> - </listitem> - - <listitem> - <para>Aggiungi te stesso alla sezione <quote>Developers</quote> della - <ulink url="&url.articles.contributors.en;/index.html">Contributors - List</ulink> e - rimuovere te stesso dalla sezione <quote>Additional - Contributors</quote>.</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>Dovresti aggiungere la tua chiave PGP o GnuPG in - <filename>doc/share/pgpkeys</filename> (e se non ce l'hai, dovresti - creartene una). Non dimenticare di effettuare il commit del file - <filename>doc/share/pgpkeys/pgpkeys.ent</filename> aggiornato.</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/share/pgpkeys/README">README</ulink> - per maggiori informazioni.</para> - - <note> - <para>È importante avere una chiave PGP/GnuPG aggiornata nel - Manuale, visto che potrà essere richiesta per - l'identificazione del committer, ad esempio dai &a.admins; per - il recupero dell'account. Un portachiavi completo degli utenti - <hostid role="domainname">FreeBSD.org</hostid> è disponibile - su <ulink - url="&url.base;/doc/pgpkeyring.txt">http://www.FreeBSD.org/doc/pgpkeyring.txt</ulink>.</para> - </note> - </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> - - <para>A causa dell'intenso carico per la gestione dello SPAM che - arriva ai server di posta centrali che processano le mailing list, i - server front-end fanno alcuni controlli e non fanno passare alcuni - messaggi in base a questi controlli. Al momento l'unico controllo - attivo è la verifica sulla correttezza delle informazioni DNS - dell'host che si connette, ma questo potrebbe cambiare. Alcune - persone accusano questi controlli di respingere email valide. Se - vuoi disabilitare questi controlli per la tua email puoi creare - un file chiamato <filename>~/.spam_lover</filename> nella tua - directory home su <hostid - role="fqdn">freefall.FreeBSD.org</hostid>.</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 è responsabile di insegnarti le regole e le - convenzioni del progetto e guidare i tuoi primi passi nella - comunità dei committer. È anche personalmente responsabile - delle tue azioni durante questo periodo iniziale. Fino a quando il tuo - mentore non decide (e lo annuncia con un commit forzato su - <filename>access</filename>) che sei diventato pratico e pronto per - effettuare commit da solo, non dovresti effettuare commit senza aver - prima ottenuto la revisione e l'approvazione del tuo mentore, e dovresti - documentare l'approvazione con una riga <literal>Approved by:</literal> - nel messaggio di commit.</para> - - <para>Tutti i commit <filename>src</filename> 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="pref-license"> - <title>Licenza Preferita per i Nuovi File</title> - - <para>Attualmente il &os; Project suggerisce di usare il seguente testo - come schema di licenza preferito:</para> - -<programlisting>Copyright © <Year> <Author>. All rights reserved. - -Redistribution and use in source and binary forms, with or without -modification, are permitted provided that the following conditions -are met: -1. Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. -2. Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in the - documentation and/or other materials provided with the distribution. - -THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND -ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -ARE DISCLAIMED. IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE -FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -SUCH DAMAGE.</programlisting> - - <para>Il progetto &os; scoraggia fortemente la cosiddetta clausola - pubblicitaria nel nuovo codice. A causa del grande numero di - contributi al progetto &os;, osservare questa clausola per molti - fornitori commerciali è diventato difficile. Se hai codice - nell'albero con la clausola pubblicitaria, pensa a rimuoverla. - In pratica, considera di usare la licenza qui sopra per il tuo - codice.</para> - - <para>Il progetto &os; scoraggia completamente nuove licenze e variazioni - sulle licenze standard. Nuove licenze richiedono l'approvazione di - <email>core@FreeBSD.org</email> per risiedere nel repository principale. - Più licenze differenti vengono usate nell'albero, più - problemi possono essere causati a chi desidera utilizzare questo codice, - tipicamente da conseguenze non previste di una licenza strutturata - male.</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> - - <para>Non mettere in dubbio le intenzioni di qualcuno che non è - d'accordo con te. Se vedono una soluzione differente dalla tua per un - problema, o anche un problema diverso, non è perché sono - stupidi, perché hanno una dubbia origine, o perché stanno - cercando di distruggere il tuo duro lavoro, la tua immagine personale, o - FreeBSD, ma semplicemente perché hanno una visione differente del - mondo. La diversità è una buona cosa.</para> - - <para>Dissenti onestamente. Argomenta la tua posizione con i suoi meriti, - sii onesto sui difetti che può avere, e sii disponibile a guardare - le loro soluzioni, o anche le loro visioni del problema, con mente - aperta.</para> - - <para>Accetta le correzioni. Possiamo tutti sbagliare. Se hai fatto un - errore, scusati e vai avanti con la tua vita. Non picchiarti, e - sicuramente non picchiare gli altri per il tuo sbaglio. Non sprecare - tempo imbarazzandoti o recriminando, risolvi solo il problema e vai - avanti.</para> - - <para>Chiedi aiuto. Cerca (e dai) revisioni dagli altri. Uno delle cose - in cui dovrebbe eccellere il software open source è il numero di - occhi che lo scrutano; questo non è vero se nessuno - revisionerà il codice.</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="&url.base;/support.html">http://www.FreeBSD.org/support.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:freebsd-doc:</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.</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.doceng;</term> - - <listitem> - <para>doceng è il gruppo responsabile dell'infrastruttura - per la realizzazione della documentazione, approva i nuovi committer - della documentazione, e assicura che il sito web di FreeBSD e la - documentazione sul sito FTP siano aggiornati rispetto all'albero - CVS. Non è un organo di risoluzione dei conflitti. - La maggior parte delle discussioni relative alla documentazione - prendono posto sulla &a.doc;. Maggiori dettagli riguardanti il - team doceng possono essere trovati nel suo <ulink - url="http://www.FreeBSD.org/internal/doceng.html">statuto</ulink>. - I committer interessati a contribuire - alla documentazione dovrebbero familiarizzare con il <ulink - url="&url.books.fdp-primer.en;/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.scottl;</term> - <term>&a.kensmith;</term> - <term>&a.hrs;</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>Hiroki è 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 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="&url.base;/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>Tutti i committer sono iscritti a -developers. 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/id_dsa.pub</filename> o - <filename><envar>$HOME</envar>/.ssh/id_rsa.pub</filename>) - alla persona che ti sta configurando come committer in modo che possa - inserirla nel file - <filename><replaceable>tualogin</replaceable></filename> su - <hostid>freefall</hostid>.</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="archs"> - <title>Supporto per Diverse Architetture</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>Sfortunatamente, non ci sono molti benefici derivanti dall'essere un - committer. Il riconoscimento di essere un progettista di software - competente è probabilmente l'unica cosa che sarà di tuo - vantaggio a lungo termine. Ciononostante, ci sono comunque alcuni - benefici:</para> - - <variablelist> - <varlistentry> - <term>Accesso diretto al <hostid>cvsup-master</hostid></term> - - <listitem> - <para>Come committer, puoi chiedere a &a.kuriyama; accesso diretto - a <hostid role="fqdn">cvsup-master.FreeBSD.org</hostid>, - fornendo l'output della tua chiave pubblica tramite - <command>cvpasswd - <replaceable>yourusername</replaceable>@FreeBSD.org - freefall.FreeBSD.org</command>. Nota: devi specificare - <hostid>freefall.FreeBSD.org</hostid> sulla riga di comando si - <command>cvpasswd</command> anche se il server attuale è - <hostid>cvsup-master</hostid>. L'accesso al - <hostid>cvsup-master</hostid> non dovrebbe essere abusato visto che - è una macchina carica di lavoro.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Un abbonamento gratuito al set da 4 CD o DVD</term> - - <listitem> - <para><ulink url="http://www.freebsdmall.com">FreeBSD Mall, - Inc.</ulink> offre un abbonamento gratuito al set da 4 CD o DVD a - tutti i committer di FreeBSD. Le informazioni su come ottenere il - prodotto gratuitamente vengono spedite a - <email>developers@FreeBSD.org</email> dopo ogni release.</para> - </listitem> - </varlistentry> - </variablelist> - </sect1> - - <sect1 id="misc"> - <title>Domande Generali</title> - - <para>Traduzione in corso</para> - </sect1> -</article> |