d7cec802c5
share/sgml directories, create a public identifier for it and replace all SYSTEM references to the file with PUBLIC references. There was no repo-copy made of these files as there is no important history to preserve.
1233 lines
62 KiB
Text
1233 lines
62 KiB
Text
<!--
|
||
The FreeBSD Documentation Project
|
||
The FreeBSD French Documentation Project
|
||
|
||
$FreeBSD: doc/fr_FR.ISO8859-1/articles/committers-guide/article.sgml,v 1.3 2001/06/11 01:18:48 ache Exp $
|
||
Original revision: n.nn
|
||
-->
|
||
<!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V3.1-Based Extension//EN" [
|
||
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"> %man;
|
||
<!ENTITY % urls PUBLIC "-//FreeBSD//ENTITIES Common Document URL Entities//FR"> %urls;
|
||
<!ENTITY % abstract PUBLIC "-//FreeBSD//ENTITIES DocBook Abstract Entities//FR"> %abstract;
|
||
<!ENTITY % artheader PUBLIC "-//FreeBSD//ENTITIES DocBook ArtHeader Entities//FR"> %artheader;
|
||
<!ENTITY % translators PUBLIC "-//FreeBSD//ENTITIES DocBook Translator Entities//FR"> %translators;
|
||
|
||
<!ENTITY % authors SYSTEM "../../../en_US.ISO8859-1/books/handbook/authors.ent"> %authors;
|
||
<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//FR"> %mailing-lists;
|
||
<!ENTITY sgml.todo SYSTEM "../../books/handbook/todo.sgml">
|
||
<!ENTITY sgml.in-progress SYSTEM "../../books/handbook/in-progress.sgml">
|
||
<!ENTITY rel.current CDATA "3.2">
|
||
]>
|
||
|
||
<article lang="fr">
|
||
<artheader>
|
||
<title>Le Guide du Nouveau
|
||
“<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>
|
||
</artheader>
|
||
|
||
<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<47>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>
|