diff options
Diffstat (limited to 'fr_FR.ISO8859-1/articles/committers-guide/article.sgml')
-rw-r--r-- | fr_FR.ISO8859-1/articles/committers-guide/article.sgml | 1233 |
1 files changed, 0 insertions, 1233 deletions
diff --git a/fr_FR.ISO8859-1/articles/committers-guide/article.sgml b/fr_FR.ISO8859-1/articles/committers-guide/article.sgml deleted file mode 100644 index 13b0ae5fcd..0000000000 --- a/fr_FR.ISO8859-1/articles/committers-guide/article.sgml +++ /dev/null @@ -1,1233 +0,0 @@ -<!-- - The FreeBSD Documentation Project - The FreeBSD French Documentation Project - - $FreeBSD: doc/fr_FR.ISO8859-1/articles/committers-guide/article.sgml,v 1.5 2001/07/13 15:48:38 nik Exp $ - Original revision: n.nn ---> -<!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V4.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 PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//EN"> %authors; -<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//FR"> %mailing-lists; -<!ENTITY sgml.todo SYSTEM "../../books/handbook/todo.sgml"> -<!ENTITY sgml.in-progress SYSTEM "../../books/handbook/in-progress.sgml"> -<!ENTITY rel.current CDATA "3.2"> -]> - -<article lang="fr"> - <articleinfo> - <title>Le Guide du Nouveau - “<foreignphrase>Committer</foreignphrase>”</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 “<foreignphrase>committer</foreignphrase>”, - bienvenue dans l'équipe de développement de FreeBSD !</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à une connaissance de base de CVS, - quoique des informations de référence, des guides et Questions - Fréquemment Posées soient disponibles à l'adresse : - <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 à bord !</para> - - &abstract.license; - &abstract.disclaimer; - &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 à 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 à - <hostid>freefall</hostid>, vérifiant que votre variable d'environnement - <envar>CVSROOT</envar> est bien positionnée à - <filename>/home/ncvs</filename>, et en effectuant les opérations - d'extraction (<foreignphrase>check-out</foreignphrase>) et de mise à - jour (<foreignphrase>check-in</foreignphrase>) nécessaires. Si vous - avez quelque chose d'entiérement nouveau à 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. – 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 à 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 à jour des sources. N'oubliez cependant pas de positionner - <envar>CVS_RSH</envar> à <wordasword>ssh</wordasword> de façon à - 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 à la méthode qui consiste à vous connecter à - <hostid>freefall</hostid> et mettre en place vos modifications avec - &man.patch.1;.</para> - - <para>Si vous avez à 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à 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 à 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 à 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 ! Envoyez immédiatement un courrier - électronique ou téléphonez à 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 à faire est de vous ajouter vous-même à 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 à 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 à vous présenter aux autres - <foreignphrase>committers</foreignphrase>, sans quoi ils n'auront aucune - idée de qui vous êtes et à 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 à quoi vous comptez travailler sur - FreeBSD. Envoyez-les par courrier électronique à - <email>cvs-committers@FreeBSD.org</email> et vous serez prêt à commencer - à travailler !</para> - - <para>N'oubliez pas aussi de vous connecter à - <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é à - <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 à vos débuts. Si vous faites - une soummission 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 à - <literal>-CURRENT</literal>, avant d'aller dans - <literal>-STABLE</literal>. Aucune nouvelle fonctionnalité ou - modification à haut risque ne devrait être intégrée à 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 à 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ésinterê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 à 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 – 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 - <foreignphrase>Problem Report</foreignphrase>, rapport - d'anomalie - <application>GNATS</application>, veillez à - 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 à 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 :</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 :</para> - - <variablelist> - <varlistentry> - <term>&a.asami;</term> - - <listitem> - <para>Est le reponsable 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 à 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à 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 à propos d'une modification envisagée (ce qui, - heureusement, ne se produit pas souvent), il peut aussi - occasionnellement être nécessaire de demander alors à 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 à - un moment donné), c'est aussi la personne à 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 ; si - vous vous y envisagez des mises à jour, parlez-en s'il vous plaît - d'abord à 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 - “<foreignphrase>Problem Report</foreignphrase>”, 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 à 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 à <application>SSH</application></title> - - <procedure> - <step> - <para>Mettez à 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 à 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 à &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 à 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 à ce que vous n'ayez - plus à la retaper à chaque fois.</para> - - <para>Testez en faisant quelque chose du style : <command>ssh - freefall.FreeBSD.org ls /usr</command>.</para> - - <para>Pour plus d'informations, reportez-vous à - <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 à 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 reponsables 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'à 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 à - <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> ; cela fait mauvais - effet. Si vous êtes en “profond” 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 !</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'à 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é à ce moment-là. 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 “entendu”, c'est - à ce moment-là 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 (à moins que la durée totale de la suspension soit - inférieure à 30 jours). Quelqu'un à 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 à l'équipe de base qu'il est dispensé de suivre les - instructions que l'on vient de donner, les “pouvoirs - spéciaux” 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 à 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 à - propos du code en disputes qui affectent notre capacité à - travailler harmonieusement ensemble à 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 à paraître inutilement aggressif aux autres. - Commencez par vous calmer et réfléchissez à 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 à long terme. Non seulement c'est une mauvaise - “gestion des ressources”, mais les responsables du - projet sanctionneront sévérement les manifestations d'aggressivité - publiques et répétées, jusqu'à 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 dicussion et être intégré - ensuite lorsqu'on est arrivé à 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 à ê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 !</para> - </listitem> - - <listitem> - <para>Respectez les responsbales de la maintenance, s'il y en - a.</para> - - <para>De nombreuses parties de FreeBSD n'“appartiennent” - à personne, c'est-à-dire qu'il n'y aura personne pour pousser de - hauts cris si vous faites des modifications sur “leur” - 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 voyez <ulink - url="http://www.FreeBSD.org/handbook/policies.html">http://www.FreeBSD.org/handbook/policies.html</ulink> - pour plus d'information à 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 à - <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 à ce sujet.</para> - </listitem> - - <listitem> - <para>N'intervenez jamais directement sur les archives. Demandez à - un responsable des archives de le faire.</para> - - <para>C'est assez clair - vous n'avez pas le droit de - faire de modifications directement sur les archives, point. En cas - de difficultés, adressez-vous à l'un des responsables des - archives en envoyant un courrier électronique à - <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 !</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 à la modification de nombreux fichiers et irrite les - utilisateurs de <application>CVSup/CTM</application> qui recoivent - tout à coup de nombreuses mises à 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'à 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 à 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 à faire, - elle peut-être facilement remise en service. Dans le cas contraire, - les utilisateurs n'auront pas eu à subir l'évolution erronnée le - temps que tout le monde ait débattu de sa pertinence. Il est très - rare que l'on ait à 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 à 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 à - <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 à 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>, à moins que la modification ne soit - critique, urgente, ou suffisamment triviale pour rendre tout - test ulté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> ; cela fait mauvais - effet. Si vous êtes en “profond” désaccord sur un point, - n'en discutez qu'en privé.</para> - - <para>Le projet a une image publique à conserver et cette image est - très importante pour nous tous, en particulier si nous voulons - continuer à 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'à 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 - cela ne peut - qu'envenimer une situation déjà 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 à 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 à une modifications de code et que les - participants n'arrivent apparemment pas à 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'à leur - retour du Joyeux Camp de Rééducation de FreeBSD que nous gérons - au Gröenland.</para> - </listitem> - - <listitem> - <para>En cas de doute sur une procédure, renseignez-vous - d'abord !</para> - - <para>De nombreuses erreurs sont commises parce que quelqu'un est - pressé et estime qu'il sait quelle est la meillleure 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 à demander “Comment diable fait-on cela ?”, - nous savons déjà 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 - <command>make - world</command>. Si vous faites vos modifications sur une branche - donnée, veillez à 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 à tester sur toutes les architectures supportées. Nous - n'avons actuellement qu'x86 et Alpha, c'est donc assez facile à - 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 à 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 devrirez 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 ?</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 à propos de <command>easy-import</command>.</para> - - <para>Il y a une chose qu'elle ne fera pas à votre place : - 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 ?</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 :</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 à 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 à 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 ?</para> - </question> - - <answer> - <para>Quand vous voulez importer un logiciel en rapport avec un - autre logiciel déjà 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 à 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à 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 ?</para> - </question> - - <answer> - <para>Quand il n'y a pas d'historique à conserver. Si un logiciel - est importé dans une catégorie erronné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 ?</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 :</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 à jour de - <filename>CVSROOT/modules</filename></para> - </step> - - <step> - <para>Si d'autres logiciels dépendent de celui qui vient - d'être mis à jour, correction des lignes décrivant leurs - dépendendances 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> ?</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 ?</para> - </question> - - <answer> - <para>Habituellement deux à trois jours.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Qu'est-ce que cela signifie pour moi ?</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 - à l'un des deux cas de figure suivants :</para> - - <itemizedlist> - <listitem> - <para>Vous avez posé la question au responsable des logiciels, - et il vous a répondu : <quote>Allez-y, - intégrez</quote>.</para> - </listitem> - - <listitem> - <para>Le responsable des ports vous a envoyé un courrier - électronique, soit directement, soit à la liste de - diffusion, pour signaler un problème à corriger sur le - logiciel.</para> - </listitem> - </itemizedlist> - - <para>Notez bien que vous n'êtes pas implicitement autorisé à - 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 ?</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 à trois semaines à 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'à ce - moment-là 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 ?</para> - </question> - - <answer> - <para>Quelques heures après la mise en place de la nouvelle - version, le responsable des logiciels enverra un courrier - électronique à la &a.ports; et à 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 ?</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 à aller y - voir :</para> - - <programlisting> -/a/asami/portbuild/3/errors messages d'erreur de la dernière compilation de 3-stable - /logs tous les messages de la dernière compilation de 3-stable - /packages messages d'erreur sur les paquetages de la dernière compilation 3-stable - /bak/errors messages d'erreur de la dernière compilation intégrale de 3-stable - /bak/logs tous les messages de la dernière compilation de l'intégrale de 3-stable - /bak/packages messages d'erreur sur les paquetages de la dernière compilation intégrale de 3-stable - /4/errors messages d'erreur de la dernière compilation de 4-current - /logs tous les messages de la dernière compilation de 4-current - /packages messages d'erreur sur les paquetages de la dernière compilation 4-current - /bak/errors messages d'erreur de la dernière compilation intégrale de 4-current - /bak/logs tous les messages de la dernière compilation de l'intégrale de 4-current - /bak/packages messages d'erreur sur les paquetages de la dernière compilation inté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é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> ?</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 ?</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 à <filename>ports/Mk/bsd.port.mk</filename>, n'y - touchez donc pas à moins que vous ne vouliez affronter son - courroux.</para> - </answer> - </qandaentry> - </qandadiv> - </qandaset> - </sect1> -</article> |