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

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.2-Based Extension//EN"
	"../../../share/sgml/freebsd42.dtd" [
<!ENTITY % entities PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Entity Set//FR" "../../share/sgml/entities.ent">
%entities;
]>

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

     $FreeBSD$
     Original revision: n.nn
-->

<article lang="fr">
  <articleinfo>
    <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>

    <releaseinfo>$FreeBSD$</releaseinfo>

    <abstract>
      <para>Nouveau &ldquo;<foreignphrase>committer</foreignphrase>&rdquo;,
        bienvenue dans l'équipe de développement de FreeBSD&nbsp;!</para>

      <para>L'objectif de cette documentation est de vous orienter sur la
        façon d'utiliser CVS sur la machine d'archive centrale de FreeBSD. Il
        est présumé que vous avez déj&agrave; une connaissance de base de CVS,
        quoique des informations de référence, des guides et Questions
        Fréquemment Posé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>

      &trans.a.haby;

    </abstract>
  </articleinfo>

  <sect1 id="admin">
    <title>Dé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éthode de connexion</emphasis></entry>
	    <entry>&man.ssh.1;</entry>
	  </row>

	  <row>
	    <entry><emphasis>Répertoire CVSROOT</emphasis></entry>
	    <entry>/home/ncvs</entry>
	  </row>

	  <row>
	    <entry><emphasis>Ré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é d'utiliser &man.ssh.1; ou &man.telnet.1;
      et Kerberos 5 pour vous connecter aux machines d'archive. Ces méthodes
      sont globalement plus sûres qu'un simple &man.telnet.1; ou
      &man.rlogin.1; parce que la négociation de l'authentification est
      cryptée. Par dé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érations CVS</title>

    <para>Les opérations CVS se font habituellement en se connectant &agrave;
      <hostid>freefall</hostid>, vérifiant que votre variable d'environnement
      <envar>CVSROOT</envar> est bien positionnée &agrave;
      <filename>/home/ncvs</filename>, et en effectuant les opérations
      d'extraction (<foreignphrase>check-out</foreignphrase>) et de mise &agrave;
      jour (<foreignphrase>check-in</foreignphrase>) nécessaires. Si vous
      avez quelque chose de entièrement nouveau &agrave; ajouter (un nouveau logiciel
      porté, du source d'origine externe, etc.), il existe une procédure
      appelée <quote>easy-import</quote> qui facilite cette opération. Elle
      ajoute automagiquement une entrée pour le nouveau module, fait ce qu'il
      faut via <command>cvs import</command>, etc. &ndash; exé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érez
      relativement opérationnel sur CVS en général, vous pouvez aussi effectuer
      les opé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çon &agrave;
      utiliser un moyen de transmission sécurisé et fiable. D'une autre côté,
      si vous ne savez pas ce que cela veut dire, tenez-vous en s'il vous
      plaît &agrave; la mé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érations <command>add</command> et
      <command>delete</command> pour faire en fait une opération
      <quote>mv</quote>, il faut une copie sur l'archive plutô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ù 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é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û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'étiquette
      par exemple, n'essayez <emphasis role="bold">pas</emphasis> de la
      rectifier vous-même&nbsp;! Envoyez immédiatement un courrier
      électronique ou téléphonez &agrave; John ou Peter et expliquez leur le
      problè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 êtes nouveau <foreignphrase>committer</foreignphrase>, la
      première chose &agrave; faire est de vous ajouter vous-même &agrave; la liste des
      développeurs (section 28.2) du Manuel de Référence. Extraire le manuel
      de référence et ajouter une entrée &agrave; la liste est relativement facile,
      mais c'est néanmoins un bon test initial de vos compétences CVS. Si
      vous pouvez le faire, vous n'aurez probablement pas de problèmes par
      la suite.</para>

    <para>L'étape suivante consiste &agrave; vous présenter aux autres
      <foreignphrase>committers</foreignphrase>, sans quoi ils n'auront aucune
      idée de qui vous êtes et &agrave; quoi vous travaillez. Il n'est pas
      nécessaire de rédiger une biographie exhaustive, un paragraphe ou deux
      suffiront, pour dire qui vous êtes et &agrave; quoi vous comptez travailler sur
      FreeBSD. Envoyez-les par courrier électronique &agrave;
      <email>cvs-committers@FreeBSD.org</email> et vous serez prê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éez un fichier
      <filename>/var/forward/<replaceable>utilisateur</replaceable></filename>
      (où <replaceable>utilisateur</replaceable> est votre nom d'utilisateur),
      qui contienne votre adresse de courrier électronique principale où vous
      souhaitez que le courrier électronique adressé &agrave;
      <replaceable>votre_nom_d_utilisateur</replaceable>@FreeBSD.org vous soit
      redirigé. Les boîtes aux lettres vraiment volumineuses qui demeurent en
      en permanence sur <hostid>hub</hostid> sont souvent
      <quote>accidentellement</quote> tronqué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é les premiers mois. Votre mentor est plus ou
      moins chargé de vous expliquer tout ce que vous ne comprenez pas bien et
      est aussi responsable de ce que vous faites &agrave; vos débuts. Si vous faites
      une soumission erronée, c'est votre mentor qui sera ennuyé et vous
      devriez probablement vous fixer comme ligne de conduite de faire passer
      vos premières soumissions par lui avant de les intégrer aux
      archives.</para>

    <para>Toutes les soumissions doivent être intégrées d'abord &agrave;
      <literal>-CURRENT</literal>, avant d'aller dans
      <literal>-STABLE</literal>. Aucune nouvelle fonctionnalité ou
      modification &agrave; haut risque ne devrait être intégrée &agrave; la branche
      <literal>-STABLE</literal>.</para>
  </sect1>

  <sect1 id="developer.relations">
    <title>Relations entre développeurs</title>

    <para>Si vous travaillez directement sur votre propre code ou sur du code
      dont il est bien établi que vous avez la responsabilité, il n'est
      probablement pas nécessaire de valider ce que vous allez faire avec
      d'autres dé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ê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é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'étiez pas
      <foreignphrase>committer</foreignphrase>. Pour les logiciels portés,
      vous devriez contacter la personne listée comme
      <makevar>MAINTAINER</makevar> dans le <filename>Makefile</filename>.
      Pour le reste des archives, si vous n'êtes pas sûr de qui maintient
      effectivement tel ou tel module, il peut être utile de passer en revue
      le résultat de <command>cvs log</command> pour voir qui a soumis des
      modifications dans le passé. Si vous ne trouvez personne, ou si la
      personne en charge montre un désintérê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é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ève
      une controverse, envisagez éventuellement de faire marche arrière
      en attendant que la question soit réglé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é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é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 échéant. Vous pouvez aussi utiliser vous-même
      &man.send-pr.1; pour proposer les modifications dont vous pensez qu'il
      faut les probablement les faire, aprè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 responsable du catalogue des logiciels portés, ce qui
            signifie qu'il a le pouvoir de décision en ce qui concerne toute
            modification aux logiciels porté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ème de
            gestion de la mémoire virtuelle. Si vous envisagez une
            modification de ce système, voyez cela avec David. Si vous êtes
            pris dans une discussion âpre et insoluble avec un autre
            participant &agrave; propos d'une modification envisagée (ce qui,
            heureusement, ne se produit pas souvent), il peut aussi
            occasionnellement être nécessaire de demander alors &agrave; David
            de mettre sa casquette d'Architecte Principal et de prendre la
            décision finale.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>&a.jkh;</term>

	<listitem>
	  <para>Est le responsable des versions. Il a la charge de définir les
            dates buté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é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érêt que cela puisse avoir &agrave;
            un moment donné), 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î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é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éseau ou n'êtes pas certain d'une modification que vous
            envisagez &agrave; ce sous-systè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é
          <application>ssh</application> dans
	  <filename>/usr/ports/security/ssh</filename> (il faut une version
	  1.2.25 ou postérieure).</para>
      </step>

      <step>
	<para>Veillez &agrave; exé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étails.</para>
      </step>

      <step>
	<para>Générez une paire de clés avec &man.ssh-keygen.1;. Ces clés
          seront créées dans le répertoire
	  <filename><envar>$HOME</envar>/.ssh</filename>.</para>
      </step>

      <step>
	<para>Copiez votre clé publique
	  (<filename><envar>$HOME</envar>/.ssh/identity.pub</filename>)
	  dans le fichier <filename>authorized_keys</filename> de votre
	  ré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ébut de session. Il vous demandera la phrase clé
      pour votre clé privée, et l'enregistrera via votre agent
      d'authentification (&man.ssh-agent.1;) de faç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é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égration.</para>
      </listitem>

      <listitem>
	<para>Respectez les responsables de la maintenance s'il y en a de
          dé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ée doit, si le responsable de
          la maintenance ou l'Architecte Principal le demande, être annulée
          jusqu'&agrave; ce que la discussion soit terminée. Les modifications pour
          des questions de sécurité peuvent être effectuées par l'Officier de
          Sécurité, malgré les souhaits d'un responsable de la
          maintenance.</para>
      </listitem>

      <listitem>
	<para>Les modifications doivent être faites dans
          <literal>-current</literal> avant d'être reporté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 être testée suffisamment avant
          d'être reportée. Le responsable des versions a les mêmes
          prérogatives sur la branche <literal>-stable</literal> que celles
          décrites, pour ce qui concerne l'Architecte Principal, par le règle
	  #5.</para>
      </listitem>

      <listitem>
	<para>Ne vous disputez pas publiquement avec les autres
          <foreignphrase>committers</foreignphrase>&nbsp;; cela fait mauvais
          effet. Si vous êtes en &ldquo;profond&rdquo; désaccord sur un point,
          n'en discutez qu'en privé.</para>
      </listitem>

      <listitem>
	<para>Respectez tous les gels du code et lisez réguliè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édure, renseignez-vous
          d'abord&nbsp;!</para>
      </listitem>

      <listitem>
	<para>Testez vos modifications avant de les intégrer.</para>
      </listitem>
    </orderedlist>

    <para>Comme indiqué, enfreindre l'un de ces règles peut entraîner une
      suspension provisoire, et, en cas de récidive, une suppression
      permanente des privilèges de <foreignphrase>committers</foreignphrase>.
      Trois membres ou plus de l'équipe de base, ou l'Architecte Principal et
      un autre membre de l'équipe de base, peuvent, s'ils en sont d'accord,
      suspendre temporairement ces privilè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 être
      décidée par l'un des administrateurs des archives ou tout autre membre
      de l'équipe de base qui se trouve être réveillé &agrave; ce moment-l&agrave;. Seule la
      totalité de l'équipe de base peut suspendre pour une durée importante
      les droits d'un <foreignphrase>committer</foreignphrase>, ou les
      retirer définitivement, cette dernière mesure n'étant en général prise
      qu'après consultation avec les
      <foreignphrase>committers</foreignphrase>. Le but de cette règle n'est
      pas de faire de l'é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évèrement incontrôlable, il est important de pouvoir
      réagir immédiatement, au lieu d'être paralysé par la discussion. Dans
      tous les cas, le <foreignphrase>committers</foreignphrase> dont les
      privilèges sont suspendus a le droit d'être &ldquo;entendu&rdquo;, c'est
      &agrave; ce moment-l&agrave; qu'il est décidé de la durée totale de la suspension. Il
      peut aussi demander un révision de la décision après 30 jours et tous
      les 30 jours ensuite (&agrave; moins que la durée totale de la suspension soit
      inférieure &agrave; 30 jours). Quelqu'un &agrave; qui les privilèges ont été
      définitivement retiré peut demander que son cas soit revu après 6 mois.
      La procédure de révision est <emphasis>strictement
      informelle</emphasis>, et, dans tous les cas, l'équipe de base se
      réserve le droit de prendre en compte ou d'ignorer les demandes de
      révision, si elle pense que sa décision initiale était la bonne.</para>

    <para>Pour toutes les autres aspects du fonctionnement du projet, l'équipe
      de base est un sous-ensemble des
      <foreignphrase>committers</foreignphrase> et est soumise aux
      <emphasis>même</emphasis> règles. Ce n'est pas parce que quelqu'un
      appartient &agrave; l'équipe de base qu'il est dispensé de suivre les
      instructions que l'on vient de donner, les &ldquo;pouvoirs
      spéciaux&rdquo; de l'é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'équipe de base.</para>

    <sect2>
      <title>Dé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éveloppeurs qu'ils sont en fait. Malgré nos tentatives
            occasionnelles pour prouver le contraire, on ne devient pas
            <foreignphrase>committer</foreignphrase> en étant stupide et
            rien n'est plus irritant que d'être traité comme tel par un de vos
            collaborateurs. Que nous apprécions toujours quelqu'un d'autre
            ou pas (chacun a ses jours sans), nous devons malgré tout toujours
            <emphasis>traiter</emphasis> les autres avec respect, sans quoi
            c'est toute l'organisation de l'équipe qui se désagrè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érie de modifications du code, et transformer les discussions &agrave;
            propos du code en disputes qui affectent notre capacité &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ègle, n'envoyez pas de courrier
            électronique quand vous êtes en colère et ne vous comportez en
            outre pas de façon &agrave; paraître inutilement agressif aux autres.
            Commencez par vous calmer et réfléchissez &agrave; la maniè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é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évèrement les manifestations d'agressivité
            publiques et répétées, jusqu'&agrave; suspendre ou vous retirer
            définitivement vos privilèges de
            <foreignphrase>committer</foreignphrase>. Ce n'est pas une chose
            qu'ils aiment le moins du monde faire, mais l'unité est la
            priorité. 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égration.</para>

	  <para>Ce n'est pas dans les archives CVS que les modifications
            doivent être intégrées pour validation ou discussion, cela doit
            se faire d'abord sur les listes de discussion et être intégré
            ensuite lorsqu'on est arrivé &agrave; quelque chose qui approche du
            consensus.  Cela ne signifie pas que vous deviez demander la
            permission avant de corriger chaque erreur é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; être discutée au
            préalable. Les gens n'ont rien contre les modifications
            d'envergure si le résultat en est quelque chose de nettement
            meilleur que ce qu'ils avaient auparavant, mais ils n'aiment pas
            être <emphasis>surpris</emphasis> par ces modifications. La
            meilleure faç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 responsables 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ême section de code, les
            soumissions d'une de ces personnes sur ces sections doivent être
            revues par au moins une des autres personnes qui la maintiennent.
            Dans le cas où l'<quote>attribution</quote> n'est pas claire,
            vous pouvez aussi consulter les messages de CVS pour les
            fichiers concernés, pour voir si quelqu'un a travaillé dessus
            récemment ou travaille de façon prédominante sur ce
            domaine.</para>

	  <para>Il y a d'autres parties de FreeBSD qui sont contrôlées par
            quelqu'un qui gère tout un domaine de l'évolution de FreeBSD,
            l'internationalisation ou le ré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és, adressez-vous &agrave; l'un des responsables des
            archives en envoyant un courrier électronique &agrave;
            <email>cvs@FreeBSD.org</email> et attendez qu'ils corrigent le
            problème et vous relancent. N'essayez pas de régler le problème
            vous-même&nbsp;!</para>

	  <para>Si vous envisagez de supprimer un étiquette ou d'en mettre une
            nouvelle, ou bien d'importer du code sur nouvelle branche, il vous
            sera peut-être utile de demander d'abord un avis. Nombreux sont
            ceux qui se trompent en faisant cela les premiè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ée doit, si le responsable de
            la maintenance ou l'Architecte Principal le demande, être annulée
            jusqu'&agrave; ce que la discussion soit terminée. Les modifications pour
            des questions de sécurité peuvent être effectuées par l'Officier
            de Sécurité, malgré les souhaits d'un responsable de la
            maintenance.</para>

	  <para>Ce peut être dur &agrave; avaler en cas de conflit (quand chaque
            partie est bien sûr convaincue qu'elle a raison) mais CVS permet
            d'é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ère que la modification était la bonne chose &agrave; faire,
            elle peut-être facilement remise en service. Dans le cas contraire,
            les utilisateurs n'auront pas eu &agrave; subir l'évolution erronée le
            temps que tout le monde ait débattu de sa pertinence. Il est très
            rare que l'on ait &agrave; revenir sur des modifications archivées, parce
            que la discussion met la plupart du temps en évidence les
            interventions controversés ou non justifiées avant même qu'elles
            n'aient été intégrées, mais dans les rares cas où cela se produit,
            il faut revenir en arrière sans discuter de façon &agrave; ce que l'on
            puisse immédiatement examiner s'il y avait erreur ou non.</para>
	</listitem>

	<listitem>
	  <para>Les modifications doivent être faites dans
            <literal>-current</literal> avant d'être reporté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 être testée suffisamment avant
            d'être reportée. Le responsable des versions a les mêmes
            prérogatives sur la branche <literal>-stable</literal> que celles
            décrites, pour ce qui concerne l'Architecte Principal, par le règle
            #5</para>

	  <para>C'est un autre point <quote>sans appel</quote> parce que c'est
            l'ingénieur de version qui est en dernier lieu responsable (et
            encaisse les coups) si une modification s'avère mal fondée.
            Respectez s'il vous plaît cette règle et coopé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ître excessivement
            conservatrice &agrave; un observateur occasionnel, mais rappelez vous que
            c'est le principe même de <literal>-stable</literal> et que
            <literal>-current</literal> suit d'autres règles. Il n'y a aucune
            raison d'avoir une branche <literal>-current</literal> si toutes
            les modifications vont immédiatement dans
            <literal>-stable</literal>, sans pouvoir d'abord être testées par
            les dé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érieur superflu (correction d'orthographe 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 êtes en &ldquo;profond&rdquo; désaccord sur un point,
            n'en discutez qu'en privé.</para>

	  <para>Le projet a une image publique &agrave; conserver et cette image est
            très importante pour nous tous, en particulier si nous voulons
            continuer &agrave; attirer de nouveaux membres. Il y aura des situations
            où, malgré tous les efforts de chacun pour rester mesurés,
            certains perdront leur calme et laisserons leur colè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é. Cela
            signifie que vous ne devez ni laisser exprimer votre colère en
            public, ni faire suivre de courriers privés sur des listes ou des
            alias publics. Ce que les gens se disent entre eux est souvent
            moins édulcoré que ce qu'ils disent en public, et ce type
            d'échange n'y a donc pas sa place&nbsp;-&nbsp;cela ne peut
            qu'envenimer une situation déj&agrave; regrettable. Si la personne qui
            vous adresse des reproches prend au moins la précaution de le
            faire en privé, ayez vous aussi la correction de le garder pour
            vous. Si vous estimez avoir été injustement traité par un autre
            développeur et que cela vous soucie, parlez-en &agrave; l'équipe de base
            plutôt qu'en public. Nous ferons de notre mieux pour jouer les
            mé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'équipe de base peut désigner une troisième partie ayant l'accord
            mutuel pour résoudre le problème. Les autres personnes impliquées
            doivent alors accepter de se plier aux décisions de cette
            troisième partie.</para>
	</listitem>

	<listitem>
	  <para>Respectez tous les gels du code et lisez réguliè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ès une
            longue absence et soumettre 10 Mo de code accumulés pendant ce
            temps. Les gens qui se comportent régulièrement de cette façon
            verront leurs privilèges de
            <foreignphrase>committers</foreignphrase> suspendus jusqu'&agrave; leur
            retour du Joyeux Camp de Rééducation de FreeBSD que nous gérons
            au Gr&ouml;enland.</para>
	</listitem>

	<listitem>
	  <para>En cas de doute sur une procédure, renseignez-vous
            d'abord&nbsp;!</para>

	  <para>De nombreuses erreurs sont commises parce que quelqu'un est
            pressé et estime qu'il sait quelle est la meilleure faç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éj&agrave; que vous ê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égrer.</para>

	  <para>Cela peut paraître évident, mais si c'était vraiment le cas,
            nous ne verrions probablement pas autant de cas où les gens ne le
            font manifestement pas. Si vos modifications touchent le noyau,
            vé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ème&nbsp;-&nbsp;<command>make
            world</command>. Si vous faites vos modifications sur une branche
            donnée, veillez &agrave; tester vos modifications sur une machine qui
            utilise cette version du système. Si votre modifications risque
            de poser des problèmes sur une autre architecture matérielle,
            veillez &agrave; tester sur toutes les architectures supporté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ées &agrave; la liste des
            plates-formes supportées par FreeBSD, des ressources partagées
            de test seront disponibles.</para>
	</listitem>
      </orderedlist>
    </sect2>

    <sect2>
      <title>Autres suggestions</title>

      <para>Quand vous intégrez des modifications de la documentation,
        utilisez un correcteur orthographique avant de soumettre. Pour toutes
        les documentations en SGML, vous devriez aussi vé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és) sur la
        page pour vérifier que toutes les références croisées et noms de
        fichiers sont corrects et que les <makevar>MKLINK</makevar>s
        appropriés sont installés.</para>
    </sect2>
  </sect1>

  <sect1>
    <title>Questions Fréquemment Posées propres aux logiciels porté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î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édure <command>easy-import</command> sur
	      <hostid>freefall</hostid>. Elle vous posera quelques questions
              et importera directement le logiciel dans le répertoire que vous
              aurez indiqué. Elle a été écrite par &a.joerg;, envoyez-lui
              s'il vous plaît un courrier é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épertoire de niveau supérieur (catégorie). Il faudra le faire
              vous-mê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érifiez votre portage, pour vous assurez qu'il compile et
              que le paquetage est correctement construit. Voici ce qu'il est
              recommandé 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ême un
              portage</ulink> du Manuel de Référence vous donnera des
              instructions plus détaillées.</para>

	    <para>Utilisez &man.portlint.1; pour vérifier la syntaxe du
              portage. Il n'est pas indispensable d'éliminer la totalité des
              messages d'avertissement, mais veillez &agrave; régler les problèmes
              les plus évidents.</para>

	    <para>Si le logiciel porté a été soumis par quelqu'un qui n'a
              jamais collaboré au projet auparavant, ajoutez le nom de cette
              personne &agrave; la section <citetitle pubwork="section">Autres
              Collaborateurs</citetitle> du Manuel de Référence.</para>

	    <para>Fermez le PR, si le portage résulte d'un PR. Pour fermer un
              PR, il suffit d'exé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é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éj&agrave; archivé dans un autre répertoire, envoyez
              s'il vous plaît un courrier électronique au responsable des
              logiciels portés pour lui demander son avis.
	      <wordasword>En rapport</wordasword> désigne ici une version
              différente ou une version légèrement modifiée. En exemple, on
              peut citer <filename>print/ghostscript*</filename> (versions
	      différentes) et <filename>x11-wm/windowmaker*</filename>
	      (version Anglaise et version internationalisée).</para>

	    <para>Comme autre exemple, on peut citer le cas d'un logiciel porté
              déplacé d'un sous-répertoire &agrave; un autre, ou d'une modification du
              nom d'un répertoire parce que l'auteur a changé le nom de son
              logiciel, bien qu'il dérive d'un logiciel déj&agrave; importé.</para>
	  </answer>
	</qandaentry>

	<qandaentry>
	  <question>
	    <para>Quand n'avons-nous <emphasis>pas</emphasis> besoin q'une
              opé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é dans une catégorie erronée et immédiatement
              déplacé, 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 électronique au responsable des
              logiciels porté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écutiez les opé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érieur (catégorie),</para>
	      </step>

	      <step>
		<para>Mise &agrave; jour de
                  <filename>CVSROOT/modules</filename></para>
	      </step>

	      <step>
		<para>Si d'autres logiciels dépendent de celui qui vient
                  d'être mis &agrave; jour, correction des lignes décrivant leurs
                  dépendances dans leurs
                  <filename>Makefile</filename>s,</para>
	      </step>

	      <step>
		<para>Si le logiciel a changé de catégories, modification en
                  consé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és</title>

	<qandaentry>
	  <question>
	    <para>Qu'est-ce qu'un <quote>gel des logiciels
              portés</quote>&nbsp;?</para>
	  </question>

	  <answer>
	    <para>Avant livraison d'une nouvelle version, il est nécessaire de
              limiter les interventions sur les archives des logiciels portés
              pendant une courte période, le temps que les paquetages et la
              version elle-même soient compilés. Cela pour garantir la
              cohérence entre les différents composants de la version, c'est
              cela que l'on appelle le <quote>gel des logiciels
              porté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és, vous ne devez pas
              soumettre quoi que ce soit dans l'arborescence des logiciels
              porté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é la question au responsable des logiciels,
                  et il vous a répondu&nbsp;: <quote>Allez-y,
                  intégrez</quote>.</para>
	      </listitem>

	      <listitem>
		<para>Le responsable des ports vous a envoyé un courrier
                  électronique, soit directement, soit &agrave; la liste de
                  diffusion, pour signaler un problème &agrave; corriger sur le
                  logiciel.</para>
	      </listitem>
	    </itemizedlist>

	    <para>Notez bien que vous n'êtes pas implicitement autorisé &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ébut du gel des
              logiciels&nbsp;?</para>
	  </question>

	  <answer>
	    <para>Le responsable des logiciels porté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éfinitivement fixée que quelques jours avant. Cela
              parce que le gel des logiciels doit être synchronisé avec la
              mise en oeuvre de la version elle-même, et que ce n'est qu'&agrave; ce
              moment-l&agrave; que l'on sait exactement quand cette opération aura
              lieu.</para>

	    <para>Quand le gel commencera, il y aura bien sû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ès la mise en place de la nouvelle
              version, le responsable des logiciels enverra un courrier
              é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ème de dernière minute ne demande
              pas de reconstruction immédiate de la version.</para>
	  </answer>
	</qandaentry>
      </qandadiv>

      <qandadiv>
	<title>Questions diverses</title>

	<qandaentry>
	  <question>
	    <para>Comment sais-je si un logiciel porté 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ères
              compilations des logiciels portés sous
              <literal>3-stable</literal> et
              <literal>4-current</literal>.</para>

	    <para>Néanmoins, il ne suffit pas qu'un logiciel n'y apparaisse
              pas pour pouvoir dire qu'il compile correctement. (Une de ses
              dépendances, par exemple, peut ne pas avoir compilé.) Voici les
              répertoires de <hostid>bento</hostid>, n'hésitez pas &agrave; aller y
              voir&nbsp;:</para>

	    <programlisting>
/a/asami/portbuild/3/errors        messages d'erreur de la derniè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è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è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ère compilation inté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ère compilation de l'inté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ère compilation inté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è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è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è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ère compilation inté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ère compilation de l'inté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ère compilation intégrale de 4-current
	    </programlisting>

	    <para>Essentiellement, si le logiciel apparaît dans
	      <filename>packages</filename>, ou dans
	      <filename>logs</filename> mais pas dans
	      <filename>errors</filename>, il compile correctement. (Les
	      répertoires <filename>errors</filename> contiennent ce que vous
              voyez sur la page Web.)</para>
	  </answer>
	</qandaentry>

	<qandaentry>
	  <question>
	    <para>J'ai importé un nouveau logiciel. Dois-je l'ajouter au
              fichier <filename>INDEX</filename>&nbsp;?</para>
	  </question>

	  <answer>
	    <para>Non. Le responsable des logiciels portés regénère
              l'<filename>INDEX</filename> et l'intègre réguliè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édiatement dans
              <filename>ports/</filename>, et tous les fichiers des
              sous-répertoires dont le nom commence par une majuscule
	      (<filename>Mk</filename>, <filename>Tools</filename>, etc.). Le
              responsable des logiciels est particuliè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>