1217 lines
57 KiB
XML
1217 lines
57 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
|
|
"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
|
|
<!--
|
|
The FreeBSD Documentation Project
|
|
The FreeBSD French Documentation Project
|
|
|
|
$FreeBSD$
|
|
Original revision: n.nn
|
|
-->
|
|
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="fr">
|
|
<info><title>Le Guide du Nouveau
|
|
“<foreignphrase>Committer</foreignphrase>”</title>
|
|
|
|
|
|
<authorgroup>
|
|
<author><personname><surname>Projet de Documentation de FreeBSD</surname></personname></author>
|
|
</authorgroup>
|
|
|
|
<pubdate>Septembre 1999</pubdate>
|
|
|
|
<copyright>
|
|
<year>1999</year>
|
|
<holder>Projet de Documentation de FreeBSD</holder>
|
|
</copyright>
|
|
|
|
<releaseinfo>$FreeBSD$</releaseinfo>
|
|
|
|
<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 :
|
|
<link xlink:href="http://www.cyclic.com/cyclic-pages/books.html">http://www.cyclic.com/cyclic-pages/books.html</link></para>
|
|
|
|
<para>Bonne chance, et bienvenue à bord !</para>
|
|
|
|
&trans.a.haby;
|
|
|
|
</abstract>
|
|
</info>
|
|
|
|
<sect1 xml: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><systemitem>freefall.FreeBSD.org</systemitem></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>
|
|
<emphasis>Machine d'archive internationale pour les codes de
|
|
cryptographie</emphasis>
|
|
</entry>
|
|
<entry><systemitem>internat.FreeBSD.org</systemitem></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 xml:id="cvs.operations">
|
|
<title>Opérations CVS</title>
|
|
|
|
<para>Les opérations CVS se font habituellement en se connectant à
|
|
<systemitem>freefall</systemitem>, 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 de 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 à
|
|
<systemitem>freefall</systemitem> 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 xml: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 à
|
|
<systemitem>hub.FreeBSD.org</systemitem> et de vous y créez un fichier
|
|
<filename>/var/forward/utilisateur</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 <systemitem>hub</systemitem> 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 soumission erronée, c'est votre mentor qui sera ennuyé et vous
|
|
devriez probablement vous fixer comme ligne de conduite de faire passer
|
|
vos premières soumissions par lui avant de les intégrer aux
|
|
archives.</para>
|
|
|
|
<para>Toutes les soumissions doivent être intégrées d'abord à
|
|
<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 xml: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
|
|
<varname>MAINTAINER</varname> dans le <filename>Makefile</filename>.
|
|
Pour le reste des archives, si vous n'êtes pas sûr de qui maintient
|
|
effectivement tel ou tel module, il peut être utile de passer en revue
|
|
le résultat de <command>cvs log</command> pour voir qui a soumis des
|
|
modifications dans le passé. Si vous ne trouvez personne, ou si la
|
|
personne en charge montre un désintérêt pour la partie en question,
|
|
allez-y et faites vos modifications.</para>
|
|
|
|
<para>Si vous avez pour une raison ou une autre des doutes à 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 xml: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 numéro_de_pr</command>
|
|
sur <systemitem>freefall</systemitem> 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><link xlink:href="http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html">http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html</link></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><link xlink:href="http://www.FreeBSD.org/support.html">http://www.FreeBSD.org/support.html</link></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><link xlink:href="http://www.FreeBSD.org/send-pr.html">http://www.FreeBSD.org/send-pr.html</link></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>&man.send-pr.1;</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 xml: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 responsable du catalogue des logiciels portés, ce qui
|
|
signifie qu'il a le pouvoir de décision en ce qui concerne toute
|
|
modification aux logiciels portés et à 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
|
|
<systemitem>internat.FreeBSD.org</systemitem> 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 xml: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>$HOME/.ssh</filename>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Copiez votre clé publique
|
|
(<filename>$HOME/.ssh/identity.pub</filename>)
|
|
dans le fichier <filename>authorized_keys</filename> de votre
|
|
répertoire utilisateur sur <systemitem>freefall</systemitem>
|
|
(i.e.
|
|
<filename>$HOME/.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 responsables de la maintenance s'il y en a de
|
|
définis par la variable <varname>MAINTAINER</varname> 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 agressif 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'agressivité
|
|
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 discussion 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 responsables 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 <link xlink:href="http://www.FreeBSD.org/handbook/policies.html">http://www.FreeBSD.org/handbook/policies.html</link>
|
|
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 à
|
|
<link xlink:href="http://www.FreeBSD-fr.org/handbook/staff-who.html">http://www.FreeBSD.org/handbook/staff-who.html</link>
|
|
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 erroné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'orthographe dans les pages
|
|
de manuel, de bogue flagrant ou de faute de frappe, etc.) En
|
|
d'autres termes, faites preuve de bon sens.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Ne vous disputez pas publiquement avec les autres
|
|
<foreignphrase>committers</foreignphrase> ; 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 meilleure façon de
|
|
faire quelque chose. Il y a des bonnes chances que vous ne sachiez
|
|
en fait pas comment faire ce que vous n'avez encore jamais fait et
|
|
que vous ayez vraiment besoin de demander d'abord sans quoi vous
|
|
allez vous mettre publiquement dans l'embarras. Il n'y a aucune
|
|
honte à 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
|
|
<systemitem class="fqdomainname">beast.FreeBSD.org</systemitem> 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 devriez aussi vérifier que vos
|
|
directives de formatage sont valides, avec un <command>make
|
|
lint</command>.</para>
|
|
|
|
<para>Pour toutes les pages de manuel en ligne, servez-vous de
|
|
<command>manck</command> (au catalogue des logiciels portés) sur la
|
|
page pour vérifier que toutes les références croisées et noms de
|
|
fichiers sont corrects et que les <varname>MKLINK</varname>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
|
|
<systemitem>freefall</systemitem>. 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 le_paquetage_que_vous_venez_de_compiler</userinput>
|
|
&prompt.user; <userinput>make deinstall</userinput>
|
|
&prompt.user; <userinput>make reinstall</userinput>
|
|
&prompt.user; <userinput>make package</userinput>
|
|
</screen>
|
|
|
|
<para>Le chapitre
|
|
<link xlink:href="../handbook/porting.html">faire vous-même un
|
|
portage</link> 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
|
|
PR#</userinput> sur
|
|
<systemitem>freefall</systemitem> 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 erronée et immédiatement
|
|
déplacé, il suffit d'un simple <command>cvs remove</command> de
|
|
l'ancien suivi d'un <command>cvs import</command> du
|
|
nouveau.</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>Que faut-il que je fasse ?</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épendances dans leurs
|
|
<filename>Makefile</filename>s,</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Si le logiciel a changé de catégories, modification en
|
|
conséquence de la ligne <varname>CATEGORIES</varname> 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
|
|
<link xlink:href="http://bento.FreeBSD.org/~asami/errorlogs/">http://bento.FreeBSD.org/~asami/errorlogs/</link>.
|
|
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 <systemitem>bento</systemitem>, 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 apparaît dans
|
|
<filename>packages</filename>, ou dans
|
|
<filename>logs</filename> mais pas dans
|
|
<filename>errors</filename>, il compile correctement. (Les
|
|
répertoires <filename>errors</filename> contiennent ce que vous
|
|
voyez sur la page Web.)</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>J'ai importé un nouveau logiciel. Dois-je l'ajouter au
|
|
fichier <filename>INDEX</filename> ?</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>
|