doc/fr_FR.ISO8859-1/articles/committers-guide/article.sgml
Chris Costello d7cec802c5 Move mailing-lists.ent out of the Handbook and into the language-specific
share/sgml directories, create a public identifier for it and replace all
SYSTEM references to the file with PUBLIC references.

There was no repo-copy made of these files as there is no important
history to preserve.
2001-06-21 03:38:34 +00:00

1233 lines
62 KiB
Text
Raw Blame History

<!--
The FreeBSD Documentation Project
The FreeBSD French Documentation Project
$FreeBSD: doc/fr_FR.ISO8859-1/articles/committers-guide/article.sgml,v 1.3 2001/06/11 01:18:48 ache Exp $
Original revision: n.nn
-->
<!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V3.1-Based Extension//EN" [
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"> %man;
<!ENTITY % urls PUBLIC "-//FreeBSD//ENTITIES Common Document URL Entities//FR"> %urls;
<!ENTITY % abstract PUBLIC "-//FreeBSD//ENTITIES DocBook Abstract Entities//FR"> %abstract;
<!ENTITY % artheader PUBLIC "-//FreeBSD//ENTITIES DocBook ArtHeader Entities//FR"> %artheader;
<!ENTITY % translators PUBLIC "-//FreeBSD//ENTITIES DocBook Translator Entities//FR"> %translators;
<!ENTITY % authors SYSTEM "../../../en_US.ISO8859-1/books/handbook/authors.ent"> %authors;
<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//FR"> %mailing-lists;
<!ENTITY sgml.todo SYSTEM "../../books/handbook/todo.sgml">
<!ENTITY sgml.in-progress SYSTEM "../../books/handbook/in-progress.sgml">
<!ENTITY rel.current CDATA "3.2">
]>
<article lang="fr">
<artheader>
<title>Le Guide du Nouveau
&ldquo;<foreignphrase>Committer</foreignphrase>&rdquo;</title>
<authorgroup>
<author>
<surname>Projet de Documentation de FreeBSD</surname>
</author>
</authorgroup>
<pubdate>Septembre 1999</pubdate>
<copyright>
<year>1999</year>
<holder>Projet de Documentation de FreeBSD</holder>
</copyright>
<abstract>
<para>Nouveau &ldquo;<foreignphrase>committer</foreignphrase>&rdquo;,
bienvenue dans l'&eacute;quipe de d&eacute;veloppement de FreeBSD&nbsp;!</para>
<para>L'objectif de cette documentation est de vous orienter sur la
fa&ccedil;on d'utiliser CVS sur la machine d'archive centrale de FreeBSD. Il
est pr&eacute;sum&eacute; que vous avez d&eacute;j&agrave; une connaissance de base de CVS,
quoique des informations de r&eacute;f&eacute;rence, des guides et Questions
Fr&eacute;quemment Pos&eacute;es soient disponibles &agrave; l'adresse&nbsp;:
<ulink url="http://www.cyclic.com/cyclic-pages/books.html">http://www.cyclic.com/cyclic-pages/books.html</ulink></para>
<para>Bonne chance, et bienvenue &agrave; bord&nbsp;!</para>
&abstract.license;
&abstract.disclaimer;
&trans.a.haby;
</abstract>
</artheader>
<sect1 id="admin">
<title>D&eacute;tails d'organisation</title>
<informaltable frame="none" orient="port">
<tgroup cols="2">
<tbody>
<row>
<entry><emphasis>Machine d'archive principale</emphasis></entry>
<entry><hostid>freefall.FreeBSD.org</hostid></entry>
</row>
<row>
<entry>
<emphasis>Machine d'archive internationale pour les codes de
cryptographie</emphasis>
</entry>
<entry><hostid>internat.FreeBSD.org</hostid></entry>
</row>
<row>
<entry><emphasis>M&eacute;thode de connexion</emphasis></entry>
<entry>&man.ssh.1;</entry>
</row>
<row>
<entry><emphasis>R&eacute;pertoire CVSROOT</emphasis></entry>
<entry>/home/ncvs</entry>
</row>
<row>
<entry><emphasis>R&eacute;pertoire CVSROOT pour la version internationale
des codes de cryptographie</emphasis></entry>
<entry>/home/cvs.crypt</entry>
</row>
<row>
<entry><emphasis>Administrateurs des archives CVS
principales</emphasis></entry>
<entry>&a.jdp; et &a.peter; ainsi que &a.asami; pour
<filename>ports/</filename></entry>
</row>
<row>
<entry>
<emphasis>Administrateur des archives CVS pour la version
internationale des codes de cryptographie</emphasis>
</entry>
<entry>&a.markm;</entry>
</row>
<row>
<entry><emphasis>Liste de diffusion</emphasis></entry>
<entry><email>cvs-committers@FreeBSD.org</email></entry>
</row>
<row>
<entry><emphasis>Etiquettes CVS importantes</emphasis></entry>
<entry>RELENG_3 (3.x-STABLE), HEAD (-CURRENT)</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>Il vous est demand&eacute; d'utiliser &man.ssh.1; ou &man.telnet.1;
et Kerberos 5 pour vous connecter aux machines d'archive. Ces m&eacute;thodes
sont globalement plus s&ucirc;res qu'un simple &man.telnet.1; ou
&man.rlogin.1; parce que la n&eacute;gociation de l'authentification est
crypt&eacute;e. Par d&eacute;faut &man.ssh.1; crypte toute la session. Les utilitaires
disponibles &man.ssh-agent.1; et &man.scp.1; sont aussi bien plus
pratiques. Si vous ne connaissez pas &man.ssh.1, reportez-vous &agrave; la
<xref linkend="ssh.guide">.</para>
</sect1>
<sect1 id="cvs.operations">
<title>Op&eacute;rations CVS</title>
<para>Les op&eacute;rations CVS se font habituellement en se connectant &agrave;
<hostid>freefall</hostid>, v&eacute;rifiant que votre variable d'environnement
<envar>CVSROOT</envar> est bien positionn&eacute;e &agrave;
<filename>/home/ncvs</filename>, et en effectuant les op&eacute;rations
d'extraction (<foreignphrase>check-out</foreignphrase>) et de mise &agrave;
jour (<foreignphrase>check-in</foreignphrase>) n&eacute;cessaires. Si vous
avez quelque chose d'enti&eacute;rement nouveau &agrave; ajouter (un nouveau logiciel
port&eacute;, du source d'origine externe, etc.), il existe une proc&eacute;dure
appel&eacute;e <quote>easy-import</quote> qui facilite cette op&eacute;ration. Elle
ajoute automagiquement une entr&eacute;e pour le nouveau module, fait ce qu'il
faut via <command>cvs import</command>, etc. &ndash; ex&eacute;cutez-la sans
arguments et elle vous demandera tout ce qu'elle a besoin de
savoir.</para>
<para>Si vous avez la pratique de CVS &agrave; distance et vous consid&eacute;rez
relativement op&eacute;rationnel sur CVS en g&eacute;n&eacute;ral, vous pouvez aussi effectuer
les op&eacute;rations CVS directement depuis votre machine avec une copie
local &agrave; jour des sources. N'oubliez cependant pas de positionner
<envar>CVS_RSH</envar> &agrave; <wordasword>ssh</wordasword> de fa&ccedil;on &agrave;
utiliser un moyen de transmission s&eacute;curis&eacute; et fiable. D'une autre c&ocirc;t&eacute;,
si vous ne savez pas ce que cela veut dire, tenez-vous en s'il vous
pla&icirc;t &agrave; la m&eacute;thode qui consiste &agrave; vous connecter &agrave;
<hostid>freefall</hostid> et mettre en place vos modifications avec
&man.patch.1;.</para>
<para>Si vous avez &agrave; utiliser les op&eacute;rations <command>add</command> et
<command>delete</command> pour faire en fait une op&eacute;ration
<quote>mv</quote>, il faut une copie sur l'archive plut&ocirc;t que votre
commande CVS <command>add</command> suivie d'un
<command>delete</command>. Dans ce cas, un <link
linkend="conventions">Administrateur CVS</link> copiera le(s) fichier(s)
l&agrave; o&ugrave; il(s) doi(ven)t aller et vous avertira une fois qu'il l'aura fait.
Le but de la copie dans les archives est de conserver l'historique des
modifications, la journalisation. Le Projet FreeBSD accorde une grande
importance &agrave; l'historique du projet que CVS nous permet de
conserver.</para>
</sect1>
<sect1 id="conventions">
<title>Conventions et Traditions</title>
<para>Les Administrateurs CVS (Peter Wemm et John Polstra) sont les
<quote>propri&eacute;taires</quote> des archives CVS et sont responsables de
chaque et de <emphasis>toute</emphasis> modification directe de
celles-ci pour mise au propre ou rectification d'erreur CVS d&ucirc;e &agrave; un
<foreignphrase>committer</foreignphrase>. Personne d'autre ne doit
intervenir directement sur les archives. Si vous faites un fausse
manipulation, une importation incorrecte ou vous trompez d'&eacute;tiquette
par exemple, n'essayez <emphasis role="bold">pas</emphasis> de la
rectifier vous-m&ecirc;me&nbsp;! Envoyez imm&eacute;diatement un courrier
&eacute;lectronique ou t&eacute;l&eacute;phonez &agrave; John ou Peter et expliquez leur le
probl&egrave;me. Satoshi Asami est aussi Administrateur CVS pour la partie
<filename>ports/</filename> de l'arborescence. Mark Murray est
l'administrateur des archives internationales pour les logiciels de
cryptographie, en Afrique du Sud.</para>
<para>Si vous &ecirc;tes nouveau <foreignphrase>committer</foreignphrase>, la
premi&egrave;re chose &agrave; faire est de vous ajouter vous-m&ecirc;me &agrave; la liste des
d&eacute;veloppeurs (section 28.2) du Manuel de R&eacute;f&eacute;rence. Extraire le manuel
de r&eacute;f&eacute;rence et ajouter une entr&eacute;e &agrave; la liste est relativement facile,
mais c'est n&eacute;anmoins un bon test initial de vos comp&eacute;tences CVS. Si
vous pouvez le faire, vous n'aurez probablement pas de probl&egrave;mes par
la suite.</para>
<para>L'&eacute;tape suivante consiste &agrave; vous pr&eacute;senter aux autres
<foreignphrase>committers</foreignphrase>, sans quoi ils n'auront aucune
id&eacute;e de qui vous &ecirc;tes et &agrave; quoi vous travaillez. Il n'est pas
n&eacute;cessaire de r&eacute;diger une biographie exhaustive, un paragraphe ou deux
suffiront, pour dire qui vous &ecirc;tes et &agrave; quoi vous comptez travailler sur
FreeBSD. Envoyez-les par courrier &eacute;lectronique &agrave;
<email>cvs-committers@FreeBSD.org</email> et vous serez pr&ecirc;t &agrave; commencer
&agrave; travailler&nbsp;!</para>
<para>N'oubliez pas aussi de vous connecter &agrave;
<hostid>hub.FreeBSD.org</hostid> et de vous y cr&eacute;ez un fichier
<filename>/var/forward/<replaceable>utilisateur</replaceable></filename>
(o&ugrave; <replaceable>utilisateur</replaceable> est votre nom d'utilisateur),
qui contienne votre adresse de courrier &eacute;lectronique principale o&ugrave; vous
souhaitez que le courrier &eacute;lectronique adress&eacute; &agrave;
<replaceable>votre_nom_d_utilisateur</replaceable>@FreeBSD.org vous soit
redirig&eacute;. Les bo&icirc;tes aux lettres vraiment volumineuses qui demeurent en
en permanence sur <hostid>hub</hostid> sont souvent
<quote>accidentellement</quote> tronqu&eacute;es sans avertissement, redirigez
donc votre courrier, ou lisez-le, et vous ne le perdrez pas.</para>
<para>Tous les nouveaux <foreignphrase>committers</foreignphrase> ont un
mentor qui leur est assign&eacute; les premiers mois. Votre mentor est plus ou
moins charg&eacute; de vous expliquer tout ce que vous ne comprenez pas bien et
est aussi responsable de ce que vous faites &agrave; vos d&eacute;buts. Si vous faites
une soummission erron&eacute;e, c'est votre mentor qui sera ennuy&eacute; et vous
devriez probablement vous fixer comme ligne de conduite de faire passer
vos premi&egrave;res soumissions par lui avant de les int&eacute;grer aux
archives.</para>
<para>Toutes les soumissions doivent &ecirc;tre int&eacute;gr&eacute;es d'abord &agrave;
<literal>-CURRENT</literal>, avant d'aller dans
<literal>-STABLE</literal>. Aucune nouvelle fonctionnalit&eacute; ou
modification &agrave; haut risque ne devrait &ecirc;tre int&eacute;gr&eacute;e &agrave; la branche
<literal>-STABLE</literal>.</para>
</sect1>
<sect1 id="developer.relations">
<title>Relations entre d&eacute;veloppeurs</title>
<para>Si vous travaillez directement sur votre propre code ou sur du code
dont il est bien &eacute;tabli que vous avez la responsabilit&eacute;, il n'est
probablement pas n&eacute;cessaire de valider ce que vous allez faire avec
d'autres d&eacute;veloppeurs avant de soumettre du code. Si vous trouvez un
bogue dans un module qui est manifestement orphelin (il y en a
malheureusement quelques uns), cela s'y applique aussi. Si, au
contraire, vous vous appr&ecirc;tez &agrave; modifier quelque chose qui est
activement maintenu par quelqu'un d'autre (ce n'est qu'en surveillant
la &a.cvsall; que vous pourrez vous faire une id&eacute;e de ce qu'il l'est et
de ce qui ne l'est pas), envisagez alors de lui envoyer vos
modifications, tout comme vous l'auriez fait quand vous n'&eacute;tiez pas
<foreignphrase>committer</foreignphrase>. Pour les logiciels port&eacute;s,
vous devriez contacter la personne list&eacute;e comme
<makevar>MAINTAINER</makevar> dans le <filename>Makefile</filename>.
Pour le reste des archives, si vous n'&ecirc;tes pas s&ucirc;r de qui maintient
effectivement tel ou tel module, il peut &ecirc;tre utile de passer en revue
le r&eacute;sultat de <command>cvs log</command> pour voir qui a soumis des
modifications dans le pass&eacute;. Si vous ne trouvez personne, ou si la
personne en charge montre un d&eacute;sinter&ecirc;t pour la partie en question,
allez-y et faites vos modifications.</para>
<para>Si vous avez pour une raison ou une autre des doutes &agrave; propos d'une
soumission que vous envisagez, faites-la d'abord examiner par
<literal>-hackers</literal> avant de l'int&eacute;grer. Il vaut mieux que l'on
vous fasse des remarques alors, qu'une fois qu'elle fera partie des
archives CVS. S'il vous arrive de soumettre quelque chose qui soul&egrave;ve
une controverse, envisagez &eacute;ventuellement de faire marche arri&egrave;re
en attendant que la question soit r&eacute;gl&eacute;e. N'oubliez pas &ndash; avec
CVS, vous pourrez toujours remettre votre modification en
service.</para>
</sect1>
<sect1 id="gnats">
<title>GNATS</title>
<para>Le Projet FreeBSD utilise <application>GNATS</application> pour
enregistrer les rapports de bogues et les demandes de modification. Si
vous effectuez une correction ou une modification d&eacute;crite dans un
PR&nbsp;-&nbsp;<foreignphrase>Problem Report</foreignphrase>, rapport
d'anomalie&nbsp;-&nbsp;<application>GNATS</application>, veillez &agrave;
utiliser
<command>edit-pr <replaceable>num&eacute;ro_de_pr</replaceable></command>
sur <hostid>freefall</hostid> pour le fermer. L'usage veut aussi que
vous preniez le temps de fermer les rapports ayant trait &agrave; vos
soumission, le cas &eacute;ch&eacute;ant. Vous pouvez aussi utiliser vous-m&ecirc;me
&man.send-pr.1; pour proposer les modifications dont vous pensez qu'il
faut les probablement les faire, apr&egrave;s une revue plus extensive par
les autres participants.</para>
<para>Vous trouverez plus d'informations sur
<application>GNATS</application> aux adresses suivantes&nbsp;:</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="http://www.FreeBSD.org/support.html">http://www.FreeBSD.org/support.html</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://www.FreeBSD.org/send-pr.html">http://www.FreeBSD.org/send-pr.html</ulink></para>
</listitem>
<listitem>
<para>&man.send-pr.1;</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="people">
<title>Who's Who</title>
<para>En dehors de Peter Wemm et John Polstra, les administrateurs des
archives, il y a d'autres membres du Projet FreeBSD que vous
rencontrerez probablement dans votre nouvelle fonction de
<foreignphrase>committer</foreignphrase>. Rapidement, et en aucun
cas exhaustivement, ce sont&nbsp;:</para>
<variablelist>
<varlistentry>
<term>&a.asami;</term>
<listitem>
<para>Est le reponsable du catalogue des logiciels port&eacute;s, ce qui
signifie qu'il a le pouvoir de d&eacute;cision en ce qui concerne toute
modification aux logiciels port&eacute;s et &agrave; leurs macros-instructions
de compilation. Il est aussi responsable la gestion des gels du
code entre deux versions.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.bde;</term>
<listitem>
<para>Est l'<foreignphrase>Obersturmbahnfuhrer</foreignphrase> de la
Police du Style. Quand vous soumettez quelque chose que vous
auriez pu faire mieux, Bruce sera l&agrave; pour vous le signaler.
Remerciez-le qu'il y ait quelqu'un pour le faire.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.dg;</term>
<listitem>
<para>Est notre architecte principal et superviseur du syst&egrave;me de
gestion de la m&eacute;moire virtuelle. Si vous envisagez une
modification de ce syst&egrave;me, voyez cela avec David. Si vous &ecirc;tes
pris dans une discussion &acirc;pre et insoluble avec un autre
participant &agrave; propos d'une modification envisag&eacute;e (ce qui,
heureusement, ne se produit pas souvent), il peut aussi
occasionnellement &ecirc;tre n&eacute;cessaire de demander alors &agrave; David
de mettre sa casquette d'Architecte Principal et de prendre la
d&eacute;cision finale.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.jkh;</term>
<listitem>
<para>Est le responsable des versions. Il a la charge de d&eacute;finir les
dates but&eacute;es et de superviser le processus de mise en place de la
nouvelle version. Pendant les gels du code, il a aussi le pouvoir
de d&eacute;cision sur toutes les modifications sur la branche de code
qui est en cours de finalisation. S'il y a quelque chose que vous
voudriez voir reporter de <literal>-CURRENT</literal> dans
<literal>-STABLE</literal> (quelqu'int&eacute;r&ecirc;t que cela puisse avoir &agrave;
un moment donn&eacute;), c'est aussi la personne &agrave; qui il faut en
parler.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.markm;</term>
<listitem>
<para>Mark est le responsable des archives CVS internationales pour
le code de cryptographie, sur
<hostid>internat.FreeBSD.org</hostid> en Afrique du Sud.</para>
<para>Mark supervise la plupart du code de cryptographie&nbsp;; si
vous vous y envisagez des mises &agrave; jour, parlez-en s'il vous pla&icirc;t
d'abord &agrave; Mark.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.steve;</term>
<listitem>
<para>Steve est le responsable non officiel de
<filename>/usr/src/bin</filename>. S'il y a quelque chose
d'important que vous voudriez y voir, vous devriez probablement
envisager d'abord cela avec Steve. Il est aussi administrateur des
&ldquo;<foreignphrase>Problem Report</foreignphrase>&rdquo;, en
coop&eacute;ration avec &a.phk;.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.brian;</term>
<listitem>
<para>Maintient officiellement
<filename>/usr/bin/ppp</filename> et
<application>LPD</application>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&a.wollman;</term>
<listitem>
<para>Si vous avez besoin d'un conseil sur des points obscurs du
code r&eacute;seau ou n'&ecirc;tes pas certain d'une modification que vous
envisagez &agrave; ce sous-syst&egrave;me, c'est avec Garrett qu'il faut en
discuter.</para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
<sect1 id="ssh.guide">
<title>Introduction rapide &agrave; <application>SSH</application></title>
<procedure>
<step>
<para>Mettez &agrave; jour et installez le logiciel port&eacute;
<application>ssh</application> dans
<filename>/usr/ports/security/ssh</filename> (il faut une version
1.2.25 ou post&eacute;rieure).</para>
</step>
<step>
<para>Veillez &agrave; ex&eacute;cuter &man.ssh-agent.1; avant toute autre
application. Les utilisateurs de <application>X</application>, par
exemple, le font habituellement depuis leur fichier
<filename>.xsession</filename> ou
<filename>.xinitrc</filename>. Reportez-vous &agrave; &man.ssh-agent.1;
pour plus de d&eacute;tails.</para>
</step>
<step>
<para>G&eacute;n&eacute;rez une paire de cl&eacute;s avec &man.ssh-keygen.1;. Ces cl&eacute;s
seront cr&eacute;&eacute;es dans le r&eacute;pertoire
<filename><envar>$HOME</envar>/.ssh</filename>.</para>
</step>
<step>
<para>Copiez votre cl&eacute; publique
(<filename><envar>$HOME</envar>/.ssh/identity.pub</filename>)
dans le fichier <filename>authorized_keys</filename> de votre
r&eacute;pertoire utilisateur sur <hostid>freefall</hostid>
(i.e.
<filename><envar>$HOME</envar>/.ssh/authorized_keys</filename>).
</para>
</step>
</procedure>
<para>Vous devriez maintenant pouvoir utiliser &man.ssh-add.1; pour vous
authentifier &agrave; chaque d&eacute;but de session. Il vous demandera la phrase cl&eacute;
pour votre cl&eacute; priv&eacute;e, et l'enregistrera via votre agent
d'authentification (&man.ssh-agent.1;) de fa&ccedil;on &agrave; ce que vous n'ayez
plus &agrave; la retaper &agrave; chaque fois.</para>
<para>Testez en faisant quelque chose du style&nbsp;: <command>ssh
freefall.FreeBSD.org ls /usr</command>.</para>
<para>Pour plus d'informations, reportez-vous &agrave;
<filename>/usr/ports/security/ssh</filename>, &man.ssh.1;,
&man.ssh-agent.1;, &man.scp.1;, et &man.ssh-keygen.1;.</para>
</sect1>
<sect1>
<title>R&eacute;gles &agrave; Suivre par les <foreignphrase>Committers</foreignphrase>
FreeBSD</title>
<orderedlist>
<listitem>
<para>Respectez les autres
<foreignphrase>committers</foreignphrase>.</para>
</listitem>
<listitem>
<para>Discutez de toute modification importante
<emphasis>avant</emphasis> int&eacute;gration.</para>
</listitem>
<listitem>
<para>Respectez les reponsables de la maintenance s'il y en a de
d&eacute;finis par la variable <makevar>MAINTAINER</makevar> du
<filename>Makefile</filename> ou dans le fichier
<filename>MAINTAINER</filename> au premier niveau de
l'arborescence.</para>
</listitem>
<listitem>
<para>N'intervenez jamais directement sur les archives. Demandez au
reponsable de ces archives de le faire.</para>
</listitem>
<listitem>
<para>Toute modification controvers&eacute;e doit, si le responsable de
la maintenance ou l'Architecte Principal le demande, &ecirc;tre annul&eacute;e
jusqu'&agrave; ce que la discussion soit termin&eacute;e. Les modifications pour
des questions de s&eacute;curit&eacute; peuvent &ecirc;tre effectu&eacute;es par l'Officier de
S&eacute;curit&eacute;, malgr&eacute; les souhaits d'un responsable de la
maintenance.</para>
</listitem>
<listitem>
<para>Les modifications doivent &ecirc;tre faites dans
<literal>-current</literal> avant d'&ecirc;tre report&eacute;es dans
<literal>-stable</literal> sauf autorisation expresse du
responsable des versions ou si elles ne s'appliquent pas &agrave;
<literal>-current</literal>. Toute modification non triviale ni
urgente doit rester au moins trois jours dans
<literal>-current</literal> pour &ecirc;tre test&eacute;e suffisamment avant
d'&ecirc;tre report&eacute;e. Le responsable des versions a les m&ecirc;mes
pr&eacute;rogatives sur la branche <literal>-stable</literal> que celles
d&eacute;crites, pour ce qui concerne l'Architecte Principal, par le r&egrave;gle
#5.</para>
</listitem>
<listitem>
<para>Ne vous disputez pas publiquement avec les autres
<foreignphrase>committers</foreignphrase>&nbsp;; cela fait mauvais
effet. Si vous &ecirc;tes en &ldquo;profond&rdquo; d&eacute;saccord sur un point,
n'en discutez qu'en priv&eacute;.</para>
</listitem>
<listitem>
<para>Respectez tous les gels du code et lisez r&eacute;guli&egrave;rement la liste
de diffusion pour les <foreignphrase>committers</foreignphrase> pour
savoir quand il y en a.</para>
</listitem>
<listitem>
<para>En cas de doute sur une proc&eacute;dure, renseignez-vous
d'abord&nbsp;!</para>
</listitem>
<listitem>
<para>Testez vos modifications avant de les int&eacute;grer.</para>
</listitem>
</orderedlist>
<para>Comme indiqu&eacute;, enfreindre l'un de ces r&egrave;gles peut entra&icirc;ner une
suspension provisoire, et, en cas de r&eacute;cidive, une suppression
permanente des privil&egrave;ges de <foreignphrase>committers</foreignphrase>.
Trois membres ou plus de l'&eacute;quipe de base, ou l'Architecte Principal et
un autre membre de l'&eacute;quipe de base, peuvent, s'ils en sont d'accord,
suspendre temporairement ces privil&egrave;ges jusqu'&agrave; ce que l'ensemble de
<literal>-core</literal> examine la question. En cas
d'<quote>urgence</quote> (un <foreignphrase>committer</foreignphrase>
endommageant les archives), une suspension provisoire peut aussi &ecirc;tre
d&eacute;cid&eacute;e par l'un des administrateurs des archives ou tout autre membre
de l'&eacute;quipe de base qui se trouve &ecirc;tre r&eacute;veill&eacute; &agrave; ce moment-l&agrave;. Seule la
totalit&eacute; de l'&eacute;quipe de base peut suspendre pour une dur&eacute;e importante
les droits d'un <foreignphrase>committer</foreignphrase>, ou les
retirer d&eacute;finitivement, cette derni&egrave;re mesure n'&eacute;tant en g&eacute;n&eacute;ral prise
qu'apr&egrave;s consultation avec les
<foreignphrase>committers</foreignphrase>. Le but de cette r&egrave;gle n'est
pas de faire de l'&eacute;quipe de base une bande de dictateurs cruels qui
puissent disposer des <foreignphrase>committers</foreignphrase> comme de
cannettes vides, mais d'avoir une sorte de fusible pour le projet. Si
quelqu'un est s&eacute;v&egrave;rement incontr&ocirc;lable, il est important de pouvoir
r&eacute;agir imm&eacute;diatement, au lieu d'&ecirc;tre paralys&eacute; par la discussion. Dans
tous les cas, le <foreignphrase>committers</foreignphrase> dont les
privil&egrave;ges sont suspendus a le droit d'&ecirc;tre &ldquo;entendu&rdquo;, c'est
&agrave; ce moment-l&agrave; qu'il est d&eacute;cid&eacute; de la dur&eacute;e totale de la suspension. Il
peut aussi demander un r&eacute;vision de la d&eacute;cision apr&egrave;s 30 jours et tous
les 30 jours ensuite (&agrave; moins que la dur&eacute;e totale de la suspension soit
inf&eacute;rieure &agrave; 30 jours). Quelqu'un &agrave; qui les privil&egrave;ges ont &eacute;t&eacute;
d&eacute;finitivement retir&eacute; peut demander que son cas soit revu apr&egrave;s 6 mois.
La proc&eacute;dure de r&eacute;vision est <emphasis>strictement
informelle</emphasis>, et, dans tous les cas, l'&eacute;quipe de base se
r&eacute;serve le droit de prendre en compte ou d'ignorer les demandes de
r&eacute;vision, si elle pense que sa d&eacute;cision initiale &eacute;tait la bonne.</para>
<para>Pour toutes les autres aspects du fonctionnement du projet, l'&eacute;quipe
de base est un sous-ensemble des
<foreignphrase>committers</foreignphrase> et est soumise aux
<emphasis>m&ecirc;me</emphasis> r&egrave;gles. Ce n'est pas parce que quelqu'un
appartient &agrave; l'&eacute;quipe de base qu'il est dispens&eacute; de suivre les
instructions que l'on vient de donner, les &ldquo;pouvoirs
sp&eacute;ciaux&rdquo; de l'&eacute;quipe de base ne sont effectifs que lorsqu'elle
agit en tant que groupe, pas individuellement.
Individuellement, nous sommes tous d'abord des
<foreignphrase>committers</foreignphrase> et ensuite seulement membres
de l'&eacute;quipe de base.</para>
<sect2>
<title>D&eacute;tails</title>
<orderedlist>
<listitem>
<para>Respectez les autres
<foreignphrase>committers</foreignphrase>.</para>
<para>Cela signifie que vous devez traiter les autres
<foreignphrase>committers</foreignphrase> en tant que groupe de
co-d&eacute;veloppeurs qu'ils sont en fait. Malgr&eacute; nos tentatives
occasionnelles pour prouver le contraire, on ne devient pas
<foreignphrase>committer</foreignphrase> en &eacute;tant stupide et
rien n'est plus irritant que d'&ecirc;tre trait&eacute; comme tel par un de vos
collaborateurs. Que nous appr&eacute;cions toujours quelqu'un d'autre
ou pas (chacun a ses jours sans), nous devons malgr&eacute; tout toujours
<emphasis>traiter</emphasis> les autres avec respect, sans quoi
c'est toute l'organisation de l'&eacute;quipe qui se d&eacute;sagr&egrave;ge
rapidement.</para>
<para>Etre capable de travailler ensemble &agrave; long terme est le plus
grand atout du projet, bien plus important que n'importe quel
s&eacute;rie de modifications du code, et transformer les discussions &agrave;
propos du code en disputes qui affectent notre capacit&eacute; &agrave;
travailler harmonieusement ensemble &agrave; long terme n'en vaut
vraiment pas la peine, quelque justification que l'on puisse
imaginer.</para>
<para>Pour respecter cette r&egrave;gle, n'envoyez pas de courrier
&eacute;lectronique quand vous &ecirc;tes en col&egrave;re et ne vous comportez en
outre pas de fa&ccedil;on &agrave; para&icirc;tre inutilement aggressif aux autres.
Commencez par vous calmer et r&eacute;fl&eacute;chissez &agrave; la mani&egrave;re la plus
efficace de convaincre l(es) autre(s) personne(s) de la justesse
de votre point de vue. Ne partez pas sur les chapeaux de roues
pour vous sentir simplement imm&eacute;diatement mieux au prix d'une
dispute &agrave; long terme. Non seulement c'est une mauvaise
&ldquo;gestion des ressources&rdquo;, mais les responsables du
projet sanctionneront s&eacute;v&eacute;rement les manifestations d'aggressivit&eacute;
publiques et r&eacute;p&eacute;t&eacute;es, jusqu'&agrave; suspendre ou vous retirer
d&eacute;finitivement vos privil&egrave;ges de
<foreignphrase>committer</foreignphrase>. Ce n'est pas une chose
qu'ils aiment le moins du monde faire, mais l'unit&eacute; est la
priorit&eacute;. Aucune dose de code ou de judicieux conseils ne s'y
mesure.</para>
</listitem>
<listitem>
<para>Discutez de toute modification importante
<emphasis>avant</emphasis> int&eacute;gration.</para>
<para>Ce n'est pas dans les archives CVS que les modifications
doivent &ecirc;tre int&eacute;gr&eacute;es pour validation ou discussion, cela doit
se faire d'abord sur les listes de dicussion et &ecirc;tre int&eacute;gr&eacute;
ensuite lorsqu'on est arriv&eacute; &agrave; quelque chose qui approche du
consensus. Cela ne signifie pas que vous deviez demander la
permission avant de corriger chaque erreur &eacute;vidente de syntaxe ou
d'orthographe dans une page de manuel, mais simplement que vous
devriez essayer de sentir quand vous envisagez une modification
qui n'est pas aussi triviale et qui demande &agrave; &ecirc;tre discut&eacute;e au
pr&eacute;alable. Les gens n'ont rien contre les modifications
d'envergure si le r&eacute;sultat en est quelque chose de nettement
meilleur que ce qu'ils avaient auparavant, mais ils n'aiment pas
&ecirc;tre <emphasis>surpris</emphasis> par ces modifications. La
meilleure fa&ccedil;on de vous assurer que vous allez dans le bon sens et
de faire valider votre code par un ou plusieurs autres
<foreignphrase>committers</foreignphrase>.</para>
<para>En cas de doute, demandez une validation&nbsp;!</para>
</listitem>
<listitem>
<para>Respectez les responsbales de la maintenance, s'il y en
a.</para>
<para>De nombreuses parties de FreeBSD n'&ldquo;appartiennent&rdquo;
&agrave; personne, c'est-&agrave;-dire qu'il n'y aura personne pour pousser de
hauts cris si vous faites des modifications sur &ldquo;leur&rdquo;
terrain, mais il vaut mieux s'en assurer d'abord. Une de nos
convention est de mettre une ligne indiquant qui maintient dans le
<filename>Makefile</filename> du paquetage ou de la
sous-arborescence activement maintenue par une ou plusieurs
personnes&nbsp; voyez <ulink
url="http://www.FreeBSD.org/handbook/policies.html">http://www.FreeBSD.org/handbook/policies.html</ulink>
pour plus d'information &agrave; ce sujet. Quand il y a plusieurs
personnes qui maintiennent une m&ecirc;me section de code, les
soumissions d'une de ces personnes sur ces sections doivent &ecirc;tre
revues par au moins une des autres personnes qui la maintiennent.
Dans le cas o&ugrave; l'<quote>attribution</quote> n'est pas claire,
vous pouvez aussi consulter les messages de CVS pour les
fichiers concern&eacute;s, pour voir si quelqu'un a travaill&eacute; dessus
r&eacute;cemment ou travaille de fa&ccedil;on pr&eacute;dominante sur ce
domaine.</para>
<para>Il y a d'autres parties de FreeBSD qui sont contr&ocirc;l&eacute;es par
quelqu'un qui g&egrave;re tout un domaine de l'&eacute;volution de FreeBSD,
l'internationalisation ou le r&eacute;seau par exemple. Reportez-vous &agrave;
<ulink
url="http://www.FreeBSD-fr.org/handbook/staff-who.html">http://www.FreeBSD.org/handbook/staff-who.html</ulink>
pour avoir plus d'informations &agrave; ce sujet.</para>
</listitem>
<listitem>
<para>N'intervenez jamais directement sur les archives. Demandez &agrave;
un responsable des archives de le faire.</para>
<para>C'est assez clair&nbsp;-&nbsp;vous n'avez pas le droit de
faire de modifications directement sur les archives, point. En cas
de difficult&eacute;s, adressez-vous &agrave; l'un des responsables des
archives en envoyant un courrier &eacute;lectronique &agrave;
<email>cvs@FreeBSD.org</email> et attendez qu'ils corrigent le
probl&egrave;me et vous relancent. N'essayez pas de r&eacute;gler le probl&egrave;me
vous-m&ecirc;me&nbsp;!</para>
<para>Si vous envisagez de supprimer un &eacute;tiquette ou d'en mettre une
nouvelle, ou bien d'importer du code sur nouvelle branche, il vous
sera peut-&ecirc;tre utile de demander d'abord un avis. Nombreux sont
ceux qui se trompent en faisant cela les premi&egrave;res fois et cela
aboutit &agrave; la modification de nombreux fichiers et irrite les
utilisateurs de <application>CVSup/CTM</application> qui recoivent
tout &agrave; coup de nombreuses mises &agrave; jour inutiles.</para>
</listitem>
<listitem>
<para>Toute modification controvers&eacute;e doit, si le responsable de
la maintenance ou l'Architecte Principal le demande, &ecirc;tre annul&eacute;e
jusqu'&agrave; ce que la discussion soit termin&eacute;e. Les modifications pour
des questions de s&eacute;curit&eacute; peuvent &ecirc;tre effectu&eacute;es par l'Officier
de S&eacute;curit&eacute;, malgr&eacute; les souhaits d'un responsable de la
maintenance.</para>
<para>Ce peut &ecirc;tre dur &agrave; avaler en cas de conflit (quand chaque
partie est bien s&ucirc;r convaincue qu'elle a raison) mais CVS permet
d'&eacute;viter de prolonger la dispute, il est bien plus facile de
revenir sur les modifications, d'attendre que tout le monde se
calme et d'essayer de voir quelle est la meilleure solution.
S'il s'av&egrave;re que la modification &eacute;tait la bonne chose &agrave; faire,
elle peut-&ecirc;tre facilement remise en service. Dans le cas contraire,
les utilisateurs n'auront pas eu &agrave; subir l'&eacute;volution erronn&eacute;e le
temps que tout le monde ait d&eacute;battu de sa pertinence. Il est tr&egrave;s
rare que l'on ait &agrave; revenir sur des modifications archiv&eacute;es, parce
que la discussion met la plupart du temps en &eacute;vidence les
interventions controvers&eacute;s ou non justifi&eacute;es avant m&ecirc;me qu'elles
n'aient &eacute;t&eacute; int&eacute;gr&eacute;es, mais dans les rares cas o&ugrave; cela se produit,
il faut revenir en arri&egrave;re sans discuter de fa&ccedil;on &agrave; ce que l'on
puisse imm&eacute;diatement examiner s'il y avait erreur ou non.</para>
</listitem>
<listitem>
<para>Les modifications doivent &ecirc;tre faites dans
<literal>-current</literal> avant d'&ecirc;tre report&eacute;es dans
<literal>-stable</literal> sauf autorisation expresse du
responsable des versions ou si elles ne s'appliquent pas &agrave;
<literal>-current</literal>. Toute modification non triviale ni
urgente doit rester au moins trois jours dans
<literal>-current</literal> pour &ecirc;tre test&eacute;e suffisamment avant
d'&ecirc;tre report&eacute;e. Le responsable des versions a les m&ecirc;mes
pr&eacute;rogatives sur la branche <literal>-stable</literal> que celles
d&eacute;crites, pour ce qui concerne l'Architecte Principal, par le r&egrave;gle
#5</para>
<para>C'est un autre point <quote>sans appel</quote> parce que c'est
l'ing&eacute;nieur de version qui est en dernier lieu responsable (et
encaisse les coups) si une modification s'av&egrave;re mal fond&eacute;e.
Respectez s'il vous pla&icirc;t cette r&egrave;gle et coop&eacute;rez totalement
avec le responsable des versions pour ce qui concerne la branche
<literal>-stable</literal>. La gestion de la branche
<literal>-stable</literal> peut parfois para&icirc;tre excessivement
conservatrice &agrave; un observateur occasionnel, mais rappelez vous que
c'est le principe m&ecirc;me de <literal>-stable</literal> et que
<literal>-current</literal> suit d'autres r&egrave;gles. Il n'y a aucune
raison d'avoir une branche <literal>-current</literal> si toutes
les modifications vont imm&eacute;diatement dans
<literal>-stable</literal>, sans pouvoir d'abord &ecirc;tre test&eacute;es par
les d&eacute;veloppeurs de <literal>-current</literal>, laissez donc
passer un peu de temps avant de les reporter dans
<literal>-stable</literal>, &agrave; moins que la modification ne soit
critique, urgente, ou suffisamment triviale pour rendre tout
test ult&eacute;rieur superflu (correction d'ortographe dans les pages
de manuel, de bogue flagrant ou de faute de frappe, etc.) En
d'autres termes, faites preuve de bon sens.</para>
</listitem>
<listitem>
<para>Ne vous disputez pas publiquement avec les autres
<foreignphrase>committers</foreignphrase>&nbsp;; cela fait mauvais
effet. Si vous &ecirc;tes en &ldquo;profond&rdquo; d&eacute;saccord sur un point,
n'en discutez qu'en priv&eacute;.</para>
<para>Le projet a une image publique &agrave; conserver et cette image est
tr&egrave;s importante pour nous tous, en particulier si nous voulons
continuer &agrave; attirer de nouveaux membres. Il y aura des situations
o&ugrave;, malgr&eacute; tous les efforts de chacun pour rester mesur&eacute;s,
certains perdront leur calme et laisserons leur col&egrave;re s'exprimer,
et le mieux que nous puissions faire est d'essayer d'en minimiser
les effets jusqu'&agrave; ce que chacun se soit de nouveau calm&eacute;. Cela
signifie que vous ne devez ni laisser exprimer votre col&egrave;re en
public, ni faire suivre de courriers priv&eacute;s sur des listes ou des
alias publics. Ce que les gens se disent entre eux est souvent
moins &eacute;dulcor&eacute; que ce qu'ils disent en public, et ce type
d'&eacute;change n'y a donc pas sa place&nbsp;-&nbsp;cela ne peut
qu'envenimer une situation d&eacute;j&agrave; regrettable. Si la personne qui
vous adresse des reproches prend au moins la pr&eacute;caution de le
faire en priv&eacute;, ayez vous aussi la correction de le garder pour
vous. Si vous estimez avoir &eacute;t&eacute; injustement trait&eacute; par un autre
d&eacute;veloppeur et que cela vous soucie, parlez-en &agrave; l'&eacute;quipe de base
plut&ocirc;t qu'en public. Nous ferons de notre mieux pour jouer les
m&eacute;diateurs et ramener les choses au raisonnable. Quand la
discussion a trait &agrave; une modifications de code et que les
participants n'arrivent apparemment pas &agrave; se mettre d'accord,
l'&eacute;quipe de base peut d&eacute;signer une troisi&egrave;me partie ayant l'accord
mutuel pour r&eacute;soudre le probl&egrave;me. Les autres personnes impliqu&eacute;es
doivent alors accepter de se plier aux d&eacute;cisions de cette
troisi&egrave;me partie.</para>
</listitem>
<listitem>
<para>Respectez tous les gels du code et lisez r&eacute;guli&egrave;rement la
liste de diffusion pour les
<foreignphrase>committers</foreignphrase> pour savoir quand il y
en a.</para>
<para>Soumettre des modifications pendant un gel du code est
vraiment une grave erreur et l'on attend des
<foreignphrase>committers</foreignphrase> qu'ils se tiennent au
courant de ce qui se passe avant de se remanifester apr&egrave;s une
longue absence et soumettre 10 Mo de code accumul&eacute;s pendant ce
temps. Les gens qui se comportent r&eacute;guli&egrave;rement de cette fa&ccedil;on
verront leurs privil&egrave;ges de
<foreignphrase>committers</foreignphrase> suspendus jusqu'&agrave; leur
retour du Joyeux Camp de R&eacute;&eacute;ducation de FreeBSD que nous g&eacute;rons
au Gr<47>enland.</para>
</listitem>
<listitem>
<para>En cas de doute sur une proc&eacute;dure, renseignez-vous
d'abord&nbsp;!</para>
<para>De nombreuses erreurs sont commises parce que quelqu'un est
press&eacute; et estime qu'il sait quelle est la meillleure fa&ccedil;on de
faire quelque chose. Il y a des bonnes chances que vous ne sachiez
en fait pas comment faire ce que vous n'avez encore jamais fait et
que vous ayez vraiment besoin de demander d'abord sans quoi vous
allez vous mettre publiquement dans l'embarras. Il n'y a aucune
honte &agrave; demander &ldquo;Comment diable fait-on cela&nbsp?&rdquo;,
nous savons d&eacute;j&agrave; que vous &ecirc;tes quelqu'un d'intelligent, sans quoi
vous ne seriez pas
<foreignphrase>committer</foreignphrase>.</para>
</listitem>
<listitem>
<para>Testez vos modifications avant de les int&eacute;grer.</para>
<para>Cela peut para&icirc;tre &eacute;vident, mais si c'&eacute;tait vraiment le cas,
nous ne verrions probablement pas autant de cas o&ugrave; les gens ne le
font manifestement pas. Si vos modifications touchent le noyau,
v&eacute;rifiez que vous pouvez toujours compiler et
<literal>GENERIC</literal> et <literal>LINT</literal>. Si vos
modifications s'appliquent ailleurs, assurez-vous que vous pouvez
toujours compiler l'ensemble du syst&egrave;me&nbsp;-&nbsp;<command>make
world</command>. Si vous faites vos modifications sur une branche
donn&eacute;e, veillez &agrave; tester vos modifications sur une machine qui
utilise cette version du syst&egrave;me. Si votre modifications risque
de poser des probl&egrave;mes sur une autre architecture mat&eacute;rielle,
veillez &agrave; tester sur toutes les architectures support&eacute;es. Nous
n'avons actuellement qu'x86 et Alpha, c'est donc assez facile &agrave;
faire. Si vous avez besoin de tester sur l'AXP, votre compte sur
<hostid role="fqdn">beast.FreeBSD.org</hostid> vous permet de
compiler et tester des binaires/noyaux/etc. sur Alpha. Quand
d'autres architectures seront ajout&eacute;es &agrave; la liste des
plates-formes support&eacute;es par FreeBSD, des ressources partag&eacute;es
de test seront disponibles.</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>Autres suggestions</title>
<para>Quand vous int&eacute;grez des modifications de la documentation,
utilisez un correcteur orthographique avant de soumettre. Pour toutes
les documentations en SGML, vous devrirez aussi v&eacute;rifier que vos
directives de formatage sont valides, avec un <command>make
lint</command>.</para>
<para>Pour toutes les pages de manuel en ligne, servez-vous de
<command>manck</command> (au catalogue des logiciels port&eacute;s) sur la
page pour v&eacute;rifier que toutes les r&eacute;f&eacute;rences crois&eacute;es et noms de
fichiers sont corrects et que les <makevar>MKLINK</makevar>s
appropri&eacute;s sont install&eacute;s.</para>
</sect2>
</sect1>
<sect1>
<title>Questions Fr&eacute;quemment Pos&eacute;es propres aux logiciels port&eacute;s</title>
<qandaset>
<qandadiv>
<title>Importer un nouveau logiciel</title>
<qandaentry>
<question>
<para>Comment faire pour importer un nouveau logiciel&nbsp;?</para>
</question>
<answer>
<para>Lisez s'il vous pla&icirc;t d'abord la section sur la copie des
archives.</para>
<para>Pour importer un nouveau logiciel, le plus facile est
d'utiliser la proc&eacute;dure <command>easy-import</command> sur
<hostid>freefall</hostid>. Elle vous posera quelques questions
et importera directement le logiciel dans le r&eacute;pertoire que vous
aurez indiqu&eacute;. Elle a &eacute;t&eacute; &eacute;crite par &a.joerg;, envoyez-lui
s'il vous pla&icirc;t un courrier &eacute;lectronique si vous avez des
questions &agrave; propos de <command>easy-import</command>.</para>
<para>Il y a une chose qu'elle ne fera pas &agrave; votre place&nbsp;:
ajouter le logiciel au <filename>Makefile</filename> du
r&eacute;pertoire de niveau sup&eacute;rieur (cat&eacute;gorie). Il faudra le faire
vous-m&ecirc;me.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Y'a-t-il d'autres choses qu'il faut que je sache quand
j'importe un nouveau logiciel&nbsp;?</para>
</question>
<answer>
<para>V&eacute;rifiez votre portage, pour vous assurez qu'il compile et
que le paquetage est correctement construit. Voici ce qu'il est
recommand&eacute; de faire&nbsp;:</para>
<screen>&prompt.user; <userinput>make install</userinput>
&prompt.user; <userinput>make package</userinput>
&prompt.user; <userinput>make deinstall</userinput>
&prompt.user; <userinput>pkg_add <replaceable>le_paquetage_que_vous_venez_de_compiler</replaceable></userinput>
&prompt.user; <userinput>make deinstall</userinput>
&prompt.user; <userinput>make reinstall</userinput>
&prompt.user; <userinput>make package</userinput>
</screen>
<para>Le chapitre
<ulink url="../handbook/porting.html">faire vous-m&ecirc;me un
portage</ulink> du Manuel de R&eacute;f&eacute;rence vous donnera des
instructions plus d&eacute;taill&eacute;es.</para>
<para>Utilisez &man.portlint.1; pour v&eacute;rifier la syntaxe du
portage. Il n'est pas indispensable d'&eacute;liminer la totalit&eacute; des
messages d'avertissement, mais veillez &agrave; r&eacute;gler les probl&egrave;mes
les plus &eacute;vidents.</para>
<para>Si le logiciel port&eacute; a &eacute;t&eacute; soumis par quelqu'un qui n'a
jamais collabor&eacute; au projet auparavant, ajoutez le nom de cette
personne &agrave; la section <citetitle pubwork="section">Autres
Collaborateurs</citetitle> du Manuel de R&eacute;f&eacute;rence.</para>
<para>Fermez le PR, si le portage r&eacute;sulte d'un PR. Pour fermer un
PR, il suffit d'ex&eacute;cuter <userinput>edit-pr
<replaceable>PR#</replaceable></userinput> sur
<hostid>freefall</hostid> et de modifier la valeur de la
variable <varname>state</varname> de <constant>open</constant>
en <constant>closed</constant>. On vous demandera d'entrer un
commentaire, et c'est tout.</para>
</answer>
</qandaentry>
</qandadiv>
<qandadiv>
<title>Copies des archives</title>
<qandaentry>
<question>
<para>Quand avons-nous besoin qu'une op&eacute;ration de copie soit faite
sur les archives&nbsp;?</para>
</question>
<answer>
<para>Quand vous voulez importer un logiciel en rapport avec un
autre logiciel d&eacute;j&agrave; archiv&eacute; dans un autre r&eacute;pertoire, envoyez
s'il vous pla&icirc;t un courrier &eacute;lectronique au responsable des
logiciels port&eacute;s pour lui demander son avis.
<wordasword>En rapport</wordasword> d&eacute;signe ici une version
diff&eacute;rente ou une version l&eacute;g&egrave;rement modifi&eacute;e. En exemple, on
peut citer <filename>print/ghostscript*</filename> (versions
diff&eacute;rentes) et <filename>x11-wm/windowmaker*</filename>
(version Anglaise et version internationalis&eacute;e).</para>
<para>Comme autre exemple, on peut citer le cas d'un logiciel port&eacute;
d&eacute;plac&eacute; d'un sous-r&eacute;pertoire &agrave; un autre, ou d'une modification du
nom d'un r&eacute;pertoire parce que l'auteur a chang&eacute; le nom de son
logiciel, bien qu'il d&eacute;rive d'un logiciel d&eacute;j&agrave; import&eacute;.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Quand n'avons-nous <emphasis>pas</emphasis> besoin q'une
op&eacute;ration de copie soit faite sur les archives&nbsp;?</para>
</question>
<answer>
<para>Quand il n'y a pas d'historique &agrave; conserver. Si un logiciel
est import&eacute; dans une cat&eacute;gorie erronn&eacute;e et imm&eacute;diatement
d&eacute;plac&eacute;, il suffit d'un simple <command>cvs remove</command> de
l'ancien suivi d'un <command>cvs import</command> du
nouveau.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Que faut-il que je fasse&nbsp;?</para>
</question>
<answer>
<para>Envoyez un courrier &eacute;lectronique au responsable des
logiciels port&eacute;s, qui fera la copie de l'ancien emplacement vers
le nouveau. Vous en serez averti, et l'on attendra alors de vous
que vous ex&eacute;cutiez les op&eacute;rations suivantes&nbsp;:</para>
<procedure>
<step>
<para><command>cvs remove</command> de l'ancien logiciel (si
besoin est),</para>
</step>
<step>
<para>Correction du <filename>Makefile</filename> de niveau
sup&eacute;rieur (cat&eacute;gorie),</para>
</step>
<step>
<para>Mise &agrave; jour de
<filename>CVSROOT/modules</filename></para>
</step>
<step>
<para>Si d'autres logiciels d&eacute;pendent de celui qui vient
d'&ecirc;tre mis &agrave; jour, correction des lignes d&eacute;crivant leurs
d&eacute;pendendances dans leurs
<filename>Makefile</filename>s,</para>
</step>
<step>
<para>Si le logiciel a chang&eacute; de cat&eacute;gories, modification en
cons&eacute;quence de la ligne <makevar>CATEGORIES</makevar> du
<filename>Makefile</filename> du logiciel.</para>
</step>
</procedure>
</answer>
</qandaentry>
</qandadiv>
<qandadiv>
<title>Gel des logiciels port&eacute;s</title>
<qandaentry>
<question>
<para>Qu'est-ce qu'un <quote>gel des logiciels
port&eacute;s</quote>&nbsp;?</para>
</question>
<answer>
<para>Avant livraison d'une nouvelle version, il est n&eacute;cessaire de
limiter les interventions sur les archives des logiciels port&eacute;s
pendant une courte p&eacute;riode, le temps que les paquetages et la
version elle-m&ecirc;me soient compil&eacute;s. Cela pour garantir la
coh&eacute;rence entre les diff&eacute;rents composants de la version, c'est
cela que l'on appelle le <quote>gel des logiciels
port&eacute;s</quote>.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Combien de temps dure ce gel&nbsp;?</para>
</question>
<answer>
<para>Habituellement deux &agrave; trois jours.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Qu'est-ce que cela signifie pour moi &nbsp;?</para>
</question>
<answer>
<para>Pendant le gel des logiciels port&eacute;s, vous ne devez pas
soumettre quoi que ce soit dans l'arborescence des logiciels
port&eacute;s, sauf autorisation explicite du responsable des
logiciels. <quote>Autorisation explicite</quote> correspond ici
&agrave; l'un des deux cas de figure suivants&nbsp;:</para>
<itemizedlist>
<listitem>
<para>Vous avez pos&eacute; la question au responsable des logiciels,
et il vous a r&eacute;pondu&nbsp;: <quote>Allez-y,
int&eacute;grez</quote>.</para>
</listitem>
<listitem>
<para>Le responsable des ports vous a envoy&eacute; un courrier
&eacute;lectronique, soit directement, soit &agrave; la liste de
diffusion, pour signaler un probl&egrave;me &agrave; corriger sur le
logiciel.</para>
</listitem>
</itemizedlist>
<para>Notez bien que vous n'&ecirc;tes pas implicitement autoris&eacute; &agrave;
corriger un logiciel pendant un gel simplement parce qu'il ne
compile plus.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Comment suis-je averti du d&eacute;but du gel des
logiciels&nbsp;?</para>
</question>
<answer>
<para>Le responsable des logiciels port&eacute;s enverra des messages
d'avertissement sur la &a.ports; et la &a.committers; pour
annoncer la mise en oeuvre prochaine d'une nouvelle version,
habituellement deux &agrave; trois semaines &agrave; l'avance. La date exacte
ne sera d&eacute;finitivement fix&eacute;e que quelques jours avant. Cela
parce que le gel des logiciels doit &ecirc;tre synchronis&eacute; avec la
mise en oeuvre de la version elle-m&ecirc;me, et que ce n'est qu'&agrave; ce
moment-l&agrave; que l'on sait exactement quand cette op&eacute;ration aura
lieu.</para>
<para>Quand le gel commencera, il y aura bien s&ucirc;r une nouvelle
annonce sur la &a.committers;.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Comment suis-je averti de la fin du gel des
logiciels&nbsp;?</para>
</question>
<answer>
<para>Quelques heures apr&egrave;s la mise en place de la nouvelle
version, le responsable des logiciels enverra un courrier
&eacute;lectronique &agrave; la &a.ports; et &agrave; la &a.committers pour annoncer
la fin du gel des logiciels. Remarquez que la finalisation de la
version n'implique pas automatiquement la fin du gel. Nous
devons nous assurer qu'un probl&egrave;me de derni&egrave;re minute ne demande
pas de reconstruction imm&eacute;diate de la version.</para>
</answer>
</qandaentry>
</qandadiv>
<qandadiv>
<title>Questions diverses</title>
<qandaentry>
<question>
<para>Comment sais-je si un logiciel port&eacute; compile correctement ou
non&nbsp;?</para>
</question>
<answer>
<para>Commencez par consulter
<ulink url="http://bento.FreeBSD.org/~asami/errorlogs/">http://bento.FreeBSD.org/~asami/errorlogs/</ulink>.
Vous y trouverez les messages d'erreurs des derni&egrave;res
compilations des logiciels port&eacute;s sous
<literal>3-stable</literal> et
<literal>4-current</literal>.</para>
<para>N&eacute;anmoins, il ne suffit pas qu'un logiciel n'y apparaisse
pas pour pouvoir dire qu'il compile correctement. (Une de ses
d&eacute;pendances, par exemple, peut ne pas avoir compil&eacute;.) Voici les
r&eacute;pertoires de <hostid>bento</hostid>, n'h&eacute;sitez pas &agrave; aller y
voir&nbsp;:</para>
<programlisting>
/a/asami/portbuild/3/errors messages d'erreur de la derni&egrave;re compilation de 3-stable
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/logs tous les messages de la derni&egrave;re compilation de 3-stable
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/packages messages d'erreur sur les paquetages de la derni&egrave;re compilation 3-stable
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/bak/errors messages d'erreur de la derni&egrave;re compilation int&eacute;grale de 3-stable
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/bak/logs tous les messages de la derni&egrave;re compilation de l'int&eacute;grale de 3-stable
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/bak/packages messages d'erreur sur les paquetages de la derni&egrave;re compilation int&eacute;grale de 3-stable
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/4/errors messages d'erreur de la derni&egrave;re compilation de 4-current
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/logs tous les messages de la derni&egrave;re compilation de 4-current
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/packages messages d'erreur sur les paquetages de la derni&egrave;re compilation 4-current
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/bak/errors messages d'erreur de la derni&egrave;re compilation int&eacute;grale de 4-current
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/bak/logs tous les messages de la derni&egrave;re compilation de l'int&eacute;grale de 4-current
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/bak/packages messages d'erreur sur les paquetages de la derni&egrave;re compilation int&eacute;grale de 4-current
</programlisting>
<para>Essentiellement, si le logiciel apparait dans
<filename>packages</filename>, ou dans
<filename>logs</filename> mais pas dans
<filename>errors</filename>, il compile correctement. (Les
r&eacute;pertoires <filename>errors</filename> contiennent ce que vous
voyez sur la page Web.)</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>J'ai import&eacute; un nouveau logiciel. Dois-je l'ajouter au
fichier <filename>INDEX</filename>&nbsp;?</para>
</question>
<answer>
<para>Non. Le responsable des logiciels port&eacute;s reg&eacute;n&egrave;re
l'<filename>INDEX</filename> et l'int&egrave;gre r&eacute;guli&egrave;rement aux
archives.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Y'a-t-il d'autres fichiers auxquels je ne dois pas
toucher&nbsp;?</para>
</question>
<answer>
<para>Tous les fichiers imm&eacute;diatement dans
<filename>ports/</filename>, et tous les fichiers des
sous-r&eacute;pertoires dont le nom commence par une majuscule
(<filename>Mk</filename>, <filename>Tools</filename>, etc.). Le
responsable des logiciels est particuli&egrave;rement susceptible pour
ce qui touche &agrave; <filename>ports/Mk/bsd.port.mk</filename>, n'y
touchez donc pas &agrave; moins que vous ne vouliez affronter son
courroux.</para>
</answer>
</qandaentry>
</qandadiv>
</qandaset>
</sect1>
</article>