path: root/fr_FR.ISO8859-1/articles/committers-guide/article.sgml

<!--
     The FreeBSD Documentation Project
     The FreeBSD French Documentation Project

     $FreeBSD$
     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.ISO_8859-1/books/handbook/authors.ent"> %authors;
<!ENTITY % mailing-lists SYSTEM "../../books/handbook/mailing-lists.ent"> %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ö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>