                   Le Guide du Nouveau ``Committer''

  Projet de Documentation de FreeBSD

   Copyright (c) 1999 Projet de Documentation de FreeBSD

   Septembre 1999

   Nouveau ``committer'', bienvenue dans l'equipe de developpement de
   FreeBSD !

   L'objectif de cette documentation est de vous orienter sur la
   fac,on d'utiliser CVS sur la machine d'archive centrale de
   FreeBSD. Il est presume que vous avez dej`a une connaissance de
   base de CVS, quoique des informations de reference, des guides et
   Questions Frequemment Posees soient disponibles `a l'adresse :
   http://www.cyclic.com/cyclic-pages/books.html

   Bonne chance, et bienvenue `a bord !

   La redistribution du code source (SGML), modifie ou non, et
   compile (HTML, PostScript, etc.) est soumise aux conditions
   suivantes :

    1. Le copyright ci-dessus, la presente liste de conditions et
       l'avertissement qui la suit doivent figurer dans le code
       source.

    2. Le code source distribue sous forme compilee doit faire
       apparaitre le copyright ci-dessus, la presente liste de
       conditions et l'avertissement qui la suit.

   CE DOCUMENT EST FOURNI ``TEL QU'EN L'ETAT'' PAR LE PROJET DE
   DOCUMENTATION FRANC,AISE DE FreeBSD ET IL N'EST DONNE AUCUNE
   GARANTIE, IMPLICITE OU EXPLICITE, QUANT A SON UTILISATION
   COMMERCIALE, PROFESSIONNELLE OU AUTRE. LES COLLABORATEURS DU
   PROJET DE DOCUMENTATION FRANC,AISE DE FreeBSD NE PEUVENT EN AUCUN
   CAS ETRE TENUS POUR RESPONSABLES DE QUELQUE DOMMAGE OU PREJUDICE
   DIRECT, INDIRECT, SECONDAIRE OU ACCESSOIRE (Y COMPRIS LES PERTES
   FINANCIeRES DUES AU MANQUE A GAGNER, A L'INTERRUPTION D'ACTIVITES,
   OU LA PERTE D'INFORMATIONS ET AUTRES) DECOULANT DE L'UTILISATION
   DE LA DOCUMENTATION OU DE L'IMPOSSIBILITE D'UTILISER CELLE-CI, ET
   DONT L'UTILISATEUR ACCEPTE L'ENTIERE RESPONSABILITE.

   Version franc,aise de Frederic Haby
   <frederic.haby@mail.dotcom.fr>.

     --------------------------------------------------------------

1. Details d'organisation

   Machine d'archive         freefall.FreeBSD.org                     
   principale                
   Machine d'archive                                                  
   internationale pour les   internat.FreeBSD.org
   codes de cryptographie    
   Methode de connexion      ssh(1)                                   
   Repertoire CVSROOT        /home/ncvs                               
   Repertoire CVSROOT pour                                            
   la version internationale /home/cvs.crypt
   des codes de              
   cryptographie             
                             John Polstra <jdp@FreeBSD.org> et Peter  
   Administrateurs des       Wemm <peter@FreeBSD.org> ainsi que       
   archives CVS principales  Satoshi Asami <asami@FreeBSD.org> pour   
                             ports/                                   
   Administrateur des                                                 
   archives CVS pour la      
   version internationale    Mark Murray <markm@FreeBSD.org>
   des codes de              
   cryptographie             
   Liste de diffusion        <cvs-committers@FreeBSD.org>             
   Etiquettes CVS            RELENG_3 (3.x-STABLE), HEAD (-CURRENT)   
   importantes               

   Il vous est demande d'utiliser ssh(1) ou telnet(1) et Kerberos 5
   pour vous connecter aux machines d'archive. Ces methodes sont
   globalement plus sures qu'un simple telnet(1) ou rlogin(1) parce
   que la negociation de l'authentification est cryptee. Par defaut
   ssh(1) crypte toute la session. Les utilitaires disponibles
   ssh-agent(1) et scp(1) sont aussi bien plus pratiques. Si vous ne
   connaissez pas ssh(1), reportez-vous `a la Section 7.

     --------------------------------------------------------------

2. Operations CVS

   Les operations CVS se font habituellement en se connectant `a
   freefall, verifiant que votre variable d'environnement CVSROOT est
   bien positionnee `a /home/ncvs, et en effectuant les operations
   d'extraction (check-out) et de mise `a jour (check-in)
   necessaires. Si vous avez quelque chose de entierement nouveau `a
   ajouter (un nouveau logiciel porte, du source d'origine externe,
   etc.), il existe une procedure appelee "easy-import" qui facilite
   cette operation. Elle ajoute automagiquement une entree pour le
   nouveau module, fait ce qu'il faut via cvs import, etc. -
   executez-la sans arguments et elle vous demandera tout ce qu'elle
   a besoin de savoir.

   Si vous avez la pratique de CVS `a distance et vous considerez
   relativement operationnel sur CVS en general, vous pouvez aussi
   effectuer les operations CVS directement depuis votre machine avec
   une copie local `a jour des sources. N'oubliez cependant pas de
   positionner CVS_RSH `a ssh de fac,on `a utiliser un moyen de
   transmission securise et fiable. D'une autre cote, si vous ne
   savez pas ce que cela veut dire, tenez-vous en s'il vous plait `a
   la methode qui consiste `a vous connecter `a freefall et mettre en
   place vos modifications avec patch(1).

   Si vous avez `a utiliser les operations add et delete pour faire
   en fait une operation "mv", il faut une copie sur l'archive plutot
   que votre commande CVS add suivie d'un delete. Dans ce cas, un
   Administrateur CVS copiera le(s) fichier(s) l`a ou 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 `a l'historique du projet que CVS nous permet de
   conserver.

     --------------------------------------------------------------

3. Conventions et Traditions

   Les Administrateurs CVS (Peter Wemm et John Polstra) sont les
   "proprietaires" des archives CVS et sont responsables de chaque et
   de toute modification directe de celles-ci pour mise au propre ou
   rectification d'erreur CVS due `a un committer. Personne d'autre
   ne doit intervenir directement sur les archives. Si vous faites un
   fausse manipulation, une importation incorrecte ou vous trompez
   d'etiquette par exemple, n'essayez pas de la rectifier vous-meme !
   Envoyez immediatement un courrier electronique ou telephonez `a
   John ou Peter et expliquez leur le probleme. Satoshi Asami est
   aussi Administrateur CVS pour la partie ports/ de l'arborescence.
   Mark Murray est l'administrateur des archives internationales pour
   les logiciels de cryptographie, en Afrique du Sud.

   Si vous etes nouveau committer, la premiere chose `a faire est de
   vous ajouter vous-meme `a la liste des developpeurs (section 28.2)
   du Manuel de Reference. Extraire le manuel de reference et ajouter
   une entree `a la liste est relativement facile, mais c'est
   neanmoins un bon test initial de vos competences CVS. Si vous
   pouvez le faire, vous n'aurez probablement pas de problemes par la
   suite.

   L'etape suivante consiste `a vous presenter aux autres committers,
   sans quoi ils n'auront aucune idee de qui vous etes et `a quoi
   vous travaillez. Il n'est pas necessaire de rediger une biographie
   exhaustive, un paragraphe ou deux suffiront, pour dire qui vous
   etes et `a quoi vous comptez travailler sur FreeBSD. Envoyez-les
   par courrier electronique `a <cvs-committers@FreeBSD.org> et vous
   serez pret `a commencer `a travailler !

   N'oubliez pas aussi de vous connecter `a hub.FreeBSD.org et de
   vous y creez un fichier /var/forward/utilisateur (ou utilisateur
   est votre nom d'utilisateur), qui contienne votre adresse de
   courrier electronique principale ou vous souhaitez que le courrier
   electronique adresse `a votre_nom_d_utilisateur@FreeBSD.org vous
   soit redirige. Les boites aux lettres vraiment volumineuses qui
   demeurent en en permanence sur hub sont souvent "accidentellement"
   tronquees sans avertissement, redirigez donc votre courrier, ou
   lisez-le, et vous ne le perdrez pas.

   Tous les nouveaux committers ont un mentor qui leur est assigne
   les premiers mois. Votre mentor est plus ou moins charge de vous
   expliquer tout ce que vous ne comprenez pas bien et est aussi
   responsable de ce que vous faites `a vos debuts. Si vous faites
   une soumission erronee, c'est votre mentor qui sera ennuye et vous
   devriez probablement vous fixer comme ligne de conduite de faire
   passer vos premieres soumissions par lui avant de les integrer aux
   archives.

   Toutes les soumissions doivent etre integrees d'abord `a -CURRENT,
   avant d'aller dans -STABLE. Aucune nouvelle fonctionnalite ou
   modification `a haut risque ne devrait etre integree `a la branche
   -STABLE.

     --------------------------------------------------------------

4. Relations entre developpeurs

   Si vous travaillez directement sur votre propre code ou sur du
   code dont il est bien etabli que vous avez la responsabilite, il
   n'est probablement pas necessaire de valider ce que vous allez
   faire avec d'autres developpeurs 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 appretez `a modifier
   quelque chose qui est activement maintenu par quelqu'un d'autre
   (ce n'est qu'en surveillant la liste de diffusion des messages de
   soumission CVS de FreeBSD que vous pourrez vous faire une idee 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'etiez pas committer. Pour les logiciels portes, vous
   devriez contacter la personne listee comme MAINTAINER dans le
   Makefile. Pour le reste des archives, si vous n'etes pas sur de
   qui maintient effectivement tel ou tel module, il peut etre utile
   de passer en revue le resultat de cvs log pour voir qui a soumis
   des modifications dans le passe. Si vous ne trouvez personne, ou
   si la personne en charge montre un desinteret pour la partie en
   question, allez-y et faites vos modifications.

   Si vous avez pour une raison ou une autre des doutes `a propos
   d'une soumission que vous envisagez, faites-la d'abord examiner
   par -hackers avant de l'integrer. 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
   souleve une controverse, envisagez eventuellement de faire marche
   arriere en attendant que la question soit reglee. N'oubliez pas -
   avec CVS, vous pourrez toujours remettre votre modification en
   service.

     --------------------------------------------------------------

5. GNATS

   Le Projet FreeBSD utilise GNATS pour enregistrer les rapports de
   bogues et les demandes de modification. Si vous effectuez une
   correction ou une modification decrite dans un PR - Problem
   Report, rapport d'anomalie - GNATS, veillez `a utiliser edit-pr
   numero_de_pr sur freefall pour le fermer. L'usage veut aussi que
   vous preniez le temps de fermer les rapports ayant trait `a vos
   soumission, le cas echeant. Vous pouvez aussi utiliser vous-meme
   send-pr(1) pour proposer les modifications dont vous pensez qu'il
   faut les probablement les faire, apres une revue plus extensive
   par les autres participants.

   Vous trouverez plus d'informations sur GNATS aux adresses
   suivantes :

     * http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html

     * http://www.FreeBSD.org/support.html

     * http://www.FreeBSD.org/send-pr.html

     * send-pr(1)

     --------------------------------------------------------------

6. Who's Who

   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
   committer. Rapidement, et en aucun cas exhaustivement, ce sont :

   Satoshi Asami <asami@FreeBSD.org>

           Est le responsable du catalogue des logiciels portes, ce
           qui signifie qu'il a le pouvoir de decision en ce qui
           concerne toute modification aux logiciels portes et `a
           leurs macros-instructions de compilation. Il est aussi
           responsable la gestion des gels du code entre deux
           versions.

   Bruce Evans <bde@FreeBSD.org>

           Est l'Obersturmbahnfuhrer de la Police du Style. Quand
           vous soumettez quelque chose que vous auriez pu faire
           mieux, Bruce sera l`a pour vous le signaler. Remerciez-le
           qu'il y ait quelqu'un pour le faire.

   David Greenman <dg@FreeBSD.org>

           Est notre architecte principal et superviseur du systeme
           de gestion de la memoire virtuelle. Si vous envisagez une
           modification de ce systeme, voyez cela avec David. Si vous
           etes pris dans une discussion apre et insoluble avec un
           autre participant `a propos d'une modification envisagee
           (ce qui, heureusement, ne se produit pas souvent), il peut
           aussi occasionnellement etre necessaire de demander alors
           `a David de mettre sa casquette d'Architecte Principal et
           de prendre la decision finale.

   Jordan K. Hubbard <jkh@FreeBSD.org>

           Est le responsable des versions. Il a la charge de definir
           les dates butees et de superviser le processus de mise en
           place de la nouvelle version. Pendant les gels du code, il
           a aussi le pouvoir de decision 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 -CURRENT dans -STABLE (quelqu'interet que
           cela puisse avoir `a un moment donne), c'est aussi la
           personne `a qui il faut en parler.

   Mark Murray <markm@FreeBSD.org>

           Mark est le responsable des archives CVS internationales
           pour le code de cryptographie, sur internat.FreeBSD.org en
           Afrique du Sud.

           Mark supervise la plupart du code de cryptographie ; si
           vous vous y envisagez des mises `a jour, parlez-en s'il
           vous plait d'abord `a Mark.

   Steve Price <steve@FreeBSD.org>

           Steve est le responsable non officiel de /usr/src/bin.
           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 ``Problem
           Report'', en cooperation avec Poul-Henning Kamp
           <phk@FreeBSD.org>.

   Brian Somers <brian@FreeBSD.org>

           Maintient officiellement /usr/bin/ppp et LPD.

   Garrett Wollman <wollman@FreeBSD.org>

           Si vous avez besoin d'un conseil sur des points obscurs du
           code reseau ou n'etes pas certain d'une modification que
           vous envisagez `a ce sous-systeme, c'est avec Garrett
           qu'il faut en discuter.

     --------------------------------------------------------------

7. Introduction rapide `a SSH

    1. Mettez `a jour et installez le logiciel porte ssh dans
       /usr/ports/security/ssh (il faut une version 1.2.25 ou
       posterieure).

    2. Veillez `a executer ssh-agent(1) avant toute autre
       application. Les utilisateurs de X, par exemple, le font
       habituellement depuis leur fichier .xsession ou .xinitrc.
       Reportez-vous `a ssh-agent(1) pour plus de details.

    3. Generez une paire de cles avec ssh-keygen(1). Ces cles seront
       creees dans le repertoire $HOME/.ssh.

    4. Copiez votre cle publique ($HOME/.ssh/identity.pub) dans le
       fichier authorized_keys de votre repertoire utilisateur sur
       freefall (i.e. $HOME/.ssh/authorized_keys).

   Vous devriez maintenant pouvoir utiliser ssh-add(1) pour vous
   authentifier `a chaque debut de session. Il vous demandera la
   phrase cle pour votre cle privee, et l'enregistrera via votre
   agent d'authentification (ssh-agent(1)) de fac,on `a ce que vous
   n'ayez plus `a la retaper `a chaque fois.

   Testez en faisant quelque chose du style : ssh
   freefall.FreeBSD.org ls /usr.

   Pour plus d'informations, reportez-vous `a
   /usr/ports/security/ssh, ssh(1), ssh-agent(1), scp(1), et
   ssh-keygen(1).

     --------------------------------------------------------------

8. Regles `a Suivre par les Committers FreeBSD

    1. Respectez les autres committers.

    2. Discutez de toute modification importante avant integration.

    3. Respectez les responsables de la maintenance s'il y en a de
       definis par la variable MAINTAINER du Makefile ou dans le
       fichier MAINTAINER au premier niveau de l'arborescence.

    4. N'intervenez jamais directement sur les archives. Demandez au
       reponsable de ces archives de le faire.

    5. Toute modification controversee doit, si le responsable de la
       maintenance ou l'Architecte Principal le demande, etre annulee
       jusqu'`a ce que la discussion soit terminee. Les modifications
       pour des questions de securite peuvent etre effectuees par
       l'Officier de Securite, malgre les souhaits d'un responsable
       de la maintenance.

    6. Les modifications doivent etre faites dans -current avant
       d'etre reportees dans -stable sauf autorisation expresse du
       responsable des versions ou si elles ne s'appliquent pas `a
       -current. Toute modification non triviale ni urgente doit
       rester au moins trois jours dans -current pour etre testee
       suffisamment avant d'etre reportee. Le responsable des
       versions a les memes prerogatives sur la branche -stable que
       celles decrites, pour ce qui concerne l'Architecte Principal,
       par le regle #5.

    7. Ne vous disputez pas publiquement avec les autres committers ;
       cela fait mauvais effet. Si vous etes en ``profond'' desaccord
       sur un point, n'en discutez qu'en prive.

    8. Respectez tous les gels du code et lisez regulierement la
       liste de diffusion pour les committers pour savoir quand il y
       en a.

    9. En cas de doute sur une procedure, renseignez-vous d'abord !

   10. Testez vos modifications avant de les integrer.

   Comme indique, enfreindre l'un de ces regles peut entrainer une
   suspension provisoire, et, en cas de recidive, une suppression
   permanente des privileges de committers. Trois membres ou plus de
   l'equipe de base, ou l'Architecte Principal et un autre membre de
   l'equipe de base, peuvent, s'ils en sont d'accord, suspendre
   temporairement ces privileges jusqu'`a ce que l'ensemble de -core
   examine la question. En cas d'"urgence" (un committer endommageant
   les archives), une suspension provisoire peut aussi etre decidee
   par l'un des administrateurs des archives ou tout autre membre de
   l'equipe de base qui se trouve etre reveille `a ce moment-l`a.
   Seule la totalite de l'equipe de base peut suspendre pour une
   duree importante les droits d'un committer, ou les retirer
   definitivement, cette derniere mesure n'etant en general prise
   qu'apres consultation avec les committers. Le but de cette regle
   n'est pas de faire de l'equipe de base une bande de dictateurs
   cruels qui puissent disposer des committers comme de cannettes
   vides, mais d'avoir une sorte de fusible pour le projet. Si
   quelqu'un est severement incontrolable, il est important de
   pouvoir reagir immediatement, au lieu d'etre paralyse par la
   discussion. Dans tous les cas, le committers dont les privileges
   sont suspendus a le droit d'etre ``entendu'', c'est `a ce
   moment-l`a qu'il est decide de la duree totale de la suspension.
   Il peut aussi demander un revision de la decision apres 30 jours
   et tous les 30 jours ensuite (`a moins que la duree totale de la
   suspension soit inferieure `a 30 jours). Quelqu'un `a qui les
   privileges ont ete definitivement retire peut demander que son cas
   soit revu apres 6 mois. La procedure de revision est strictement
   informelle, et, dans tous les cas, l'equipe de base se reserve le
   droit de prendre en compte ou d'ignorer les demandes de revision,
   si elle pense que sa decision initiale etait la bonne.

   Pour toutes les autres aspects du fonctionnement du projet,
   l'equipe de base est un sous-ensemble des committers et est
   soumise aux meme regles. Ce n'est pas parce que quelqu'un
   appartient `a l'equipe de base qu'il est dispense de suivre les
   instructions que l'on vient de donner, les ``pouvoirs speciaux''
   de l'equipe de base ne sont effectifs que lorsqu'elle agit en tant
   que groupe, pas individuellement. Individuellement, nous sommes
   tous d'abord des committers et ensuite seulement membres de
   l'equipe de base.

     --------------------------------------------------------------

  8.1. Details

    1. Respectez les autres committers.

       Cela signifie que vous devez traiter les autres committers en
       tant que groupe de co-developpeurs qu'ils sont en fait. Malgre
       nos tentatives occasionnelles pour prouver le contraire, on ne
       devient pas committer en etant stupide et rien n'est plus
       irritant que d'etre traite comme tel par un de vos
       collaborateurs. Que nous apprecions toujours quelqu'un d'autre
       ou pas (chacun a ses jours sans), nous devons malgre tout
       toujours traiter les autres avec respect, sans quoi c'est
       toute l'organisation de l'equipe qui se desagrege rapidement.

       Etre capable de travailler ensemble `a long terme est le plus
       grand atout du projet, bien plus important que n'importe quel
       serie de modifications du code, et transformer les discussions
       `a propos du code en disputes qui affectent notre capacite `a
       travailler harmonieusement ensemble `a long terme n'en vaut
       vraiment pas la peine, quelque justification que l'on puisse
       imaginer.

       Pour respecter cette regle, n'envoyez pas de courrier
       electronique quand vous etes en colere et ne vous comportez en
       outre pas de fac,on `a paraitre inutilement agressif aux
       autres. Commencez par vous calmer et reflechissez `a la
       maniere 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
       immediatement mieux au prix d'une dispute `a long terme. Non
       seulement c'est une mauvaise ``gestion des ressources'', mais
       les responsables du projet sanctionneront severement les
       manifestations d'agressivite publiques et repetees, jusqu'`a
       suspendre ou vous retirer definitivement vos privileges de
       committer. Ce n'est pas une chose qu'ils aiment le moins du
       monde faire, mais l'unite est la priorite. Aucune dose de code
       ou de judicieux conseils ne s'y mesure.

    2. Discutez de toute modification importante avant integration.

       Ce n'est pas dans les archives CVS que les modifications
       doivent etre integrees pour validation ou discussion, cela
       doit se faire d'abord sur les listes de discussion et etre
       integre ensuite lorsqu'on est arrive `a quelque chose qui
       approche du consensus. Cela ne signifie pas que vous deviez
       demander la permission avant de corriger chaque erreur
       evidente 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 `a etre discutee au prealable. Les gens n'ont rien
       contre les modifications d'envergure si le resultat en est
       quelque chose de nettement meilleur que ce qu'ils avaient
       auparavant, mais ils n'aiment pas etre surpris par ces
       modifications. La meilleure fac,on de vous assurer que vous
       allez dans le bon sens et de faire valider votre code par un
       ou plusieurs autres committers.

       En cas de doute, demandez une validation !

    3. Respectez les responsables de la maintenance, s'il y en a.

       De nombreuses parties de FreeBSD n'``appartiennent'' `a
       personne, c'est-`a-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 Makefile du paquetage ou de la sous-arborescence
       activement maintenue par une ou plusieurs personnes  voyez
       http://www.FreeBSD.org/handbook/policies.html pour plus
       d'information `a ce sujet. Quand il y a plusieurs personnes
       qui maintiennent une meme section de code, les soumissions
       d'une de ces personnes sur ces sections doivent etre revues
       par au moins une des autres personnes qui la maintiennent.
       Dans le cas ou l'"attribution" n'est pas claire, vous pouvez
       aussi consulter les messages de CVS pour les fichiers
       concernes, pour voir si quelqu'un a travaille dessus recemment
       ou travaille de fac,on predominante sur ce domaine.

       Il y a d'autres parties de FreeBSD qui sont controlees par
       quelqu'un qui gere tout un domaine de l'evolution de FreeBSD,
       l'internationalisation ou le reseau par exemple. Reportez-vous
       `a http://www.FreeBSD.org/handbook/staff-who.html pour avoir
       plus d'informations `a ce sujet.

    4. N'intervenez jamais directement sur les archives. Demandez `a
       un responsable des archives de le faire.

       C'est assez clair - vous n'avez pas le droit de faire de
       modifications directement sur les archives, point. En cas de
       difficultes, adressez-vous `a l'un des responsables des
       archives en envoyant un courrier electronique `a
       <cvs@FreeBSD.org> et attendez qu'ils corrigent le probleme et
       vous relancent. N'essayez pas de regler le probleme
       vous-meme !

       Si vous envisagez de supprimer un etiquette ou d'en mettre une
       nouvelle, ou bien d'importer du code sur nouvelle branche, il
       vous sera peut-etre utile de demander d'abord un avis.
       Nombreux sont ceux qui se trompent en faisant cela les
       premieres fois et cela aboutit `a la modification de nombreux
       fichiers et irrite les utilisateurs de CVSup/CTM qui recoivent
       tout `a coup de nombreuses mises `a jour inutiles.

    5. Toute modification controversee doit, si le responsable de la
       maintenance ou l'Architecte Principal le demande, etre annulee
       jusqu'`a ce que la discussion soit terminee. Les modifications
       pour des questions de securite peuvent etre effectuees par
       l'Officier de Securite, malgre les souhaits d'un responsable
       de la maintenance.

       Ce peut etre dur `a avaler en cas de conflit (quand chaque
       partie est bien sur convaincue qu'elle a raison) mais CVS
       permet d'eviter 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'avere que la modification etait la bonne
       chose `a faire, elle peut-etre facilement remise en service.
       Dans le cas contraire, les utilisateurs n'auront pas eu `a
       subir l'evolution erronee le temps que tout le monde ait
       debattu de sa pertinence. Il est tres rare que l'on ait `a
       revenir sur des modifications archivees, parce que la
       discussion met la plupart du temps en evidence les
       interventions controverses ou non justifiees avant meme
       qu'elles n'aient ete integrees, mais dans les rares cas ou
       cela se produit, il faut revenir en arriere sans discuter de
       fac,on `a ce que l'on puisse immediatement examiner s'il y
       avait erreur ou non.

    6. Les modifications doivent etre faites dans -current avant
       d'etre reportees dans -stable sauf autorisation expresse du
       responsable des versions ou si elles ne s'appliquent pas `a
       -current. Toute modification non triviale ni urgente doit
       rester au moins trois jours dans -current pour etre testee
       suffisamment avant d'etre reportee. Le responsable des
       versions a les memes prerogatives sur la branche -stable que
       celles decrites, pour ce qui concerne l'Architecte Principal,
       par le regle #5

       C'est un autre point "sans appel" parce que c'est l'ingenieur
       de version qui est en dernier lieu responsable (et encaisse
       les coups) si une modification s'avere mal fondee. Respectez
       s'il vous plait cette regle et cooperez totalement avec le
       responsable des versions pour ce qui concerne la branche
       -stable. La gestion de la branche -stable peut parfois
       paraitre excessivement conservatrice `a un observateur
       occasionnel, mais rappelez vous que c'est le principe meme de
       -stable et que -current suit d'autres regles. Il n'y a aucune
       raison d'avoir une branche -current si toutes les
       modifications vont immediatement dans -stable, sans pouvoir
       d'abord etre testees par les developpeurs de -current, laissez
       donc passer un peu de temps avant de les reporter dans
       -stable, `a moins que la modification ne soit critique,
       urgente, ou suffisamment triviale pour rendre tout test
       ulterieur 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.

    7. Ne vous disputez pas publiquement avec les autres committers ;
       cela fait mauvais effet. Si vous etes en ``profond'' desaccord
       sur un point, n'en discutez qu'en prive.

       Le projet a une image publique `a conserver et cette image est
       tres importante pour nous tous, en particulier si nous voulons
       continuer `a attirer de nouveaux membres. Il y aura des
       situations ou, malgre tous les efforts de chacun pour rester
       mesures, certains perdront leur calme et laisserons leur
       colere s'exprimer, et le mieux que nous puissions faire est
       d'essayer d'en minimiser les effets jusqu'`a ce que chacun se
       soit de nouveau calme. Cela signifie que vous ne devez ni
       laisser exprimer votre colere en public, ni faire suivre de
       courriers prives sur des listes ou des alias publics. Ce que
       les gens se disent entre eux est souvent moins edulcore que ce
       qu'ils disent en public, et ce type d'echange n'y a donc pas
       sa place - cela ne peut qu'envenimer une situation dej`a
       regrettable. Si la personne qui vous adresse des reproches
       prend au moins la precaution de le faire en prive, ayez vous
       aussi la correction de le garder pour vous. Si vous estimez
       avoir ete injustement traite par un autre developpeur et que
       cela vous soucie, parlez-en `a l'equipe de base plutot qu'en
       public. Nous ferons de notre mieux pour jouer les mediateurs
       et ramener les choses au raisonnable. Quand la discussion a
       trait `a une modifications de code et que les participants
       n'arrivent apparemment pas `a se mettre d'accord, l'equipe de
       base peut designer une troisieme partie ayant l'accord mutuel
       pour resoudre le probleme. Les autres personnes impliquees
       doivent alors accepter de se plier aux decisions de cette
       troisieme partie.

    8. Respectez tous les gels du code et lisez regulierement la
       liste de diffusion pour les committers pour savoir quand il y
       en a.

       Soumettre des modifications pendant un gel du code est
       vraiment une grave erreur et l'on attend des committers qu'ils
       se tiennent au courant de ce qui se passe avant de se
       remanifester apres une longue absence et soumettre 10 Mo de
       code accumules pendant ce temps. Les gens qui se comportent
       regulierement de cette fac,on verront leurs privileges de
       committers suspendus jusqu'`a leur retour du Joyeux Camp de
       Reeducation de FreeBSD que nous gerons au Gro:enland.

    9. En cas de doute sur une procedure, renseignez-vous d'abord !

       De nombreuses erreurs sont commises parce que quelqu'un est
       presse et estime qu'il sait quelle est la meilleure fac,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 `a demander ``Comment diable
       fait-on cela ?'', nous savons dej`a que vous etes quelqu'un
       d'intelligent, sans quoi vous ne seriez pas committer.

   10. Testez vos modifications avant de les integrer.

       Cela peut paraitre evident, mais si c'etait vraiment le cas,
       nous ne verrions probablement pas autant de cas ou les gens ne
       le font manifestement pas. Si vos modifications touchent le
       noyau, verifiez que vous pouvez toujours compiler et GENERIC
       et LINT. Si vos modifications s'appliquent ailleurs,
       assurez-vous que vous pouvez toujours compiler l'ensemble du
       systeme - make world. Si vous faites vos modifications sur une
       branche donnee, veillez `a tester vos modifications sur une
       machine qui utilise cette version du systeme. Si votre
       modifications risque de poser des problemes sur une autre
       architecture materielle, veillez `a tester sur toutes les
       architectures supportees. Nous n'avons actuellement qu'x86 et
       Alpha, c'est donc assez facile `a faire. Si vous avez besoin
       de tester sur l'AXP, votre compte sur beast.FreeBSD.org vous
       permet de compiler et tester des binaires/noyaux/etc. sur
       Alpha. Quand d'autres architectures seront ajoutees `a la
       liste des plates-formes supportees par FreeBSD, des ressources
       partagees de test seront disponibles.

     --------------------------------------------------------------

  8.2. Autres suggestions

   Quand vous integrez des modifications de la documentation,
   utilisez un correcteur orthographique avant de soumettre. Pour
   toutes les documentations en SGML, vous devriez aussi verifier que
   vos directives de formatage sont valides, avec un make lint.

   Pour toutes les pages de manuel en ligne, servez-vous de manck (au
   catalogue des logiciels portes) sur la page pour verifier que
   toutes les references croisees et noms de fichiers sont corrects
   et que les MKLINKs appropries sont installes.

     --------------------------------------------------------------

9. Questions Frequemment Posees propres aux logiciels portes

   1. Importer un nouveau logiciel

                9.1.1. Comment faire pour importer un nouveau
                logiciel ?

                9.1.2. Y'a-t-il d'autres choses qu'il faut que je
                sache quand j'importe un nouveau logiciel ?

   2. Copies des archives

                9.2.1. Quand avons-nous besoin qu'une operation de
                copie soit faite sur les archives ?

                9.2.2. Quand n'avons-nous pas besoin q'une operation
                de copie soit faite sur les archives ?

                9.2.3. Que faut-il que je fasse ?

   3. Gel des logiciels portes

                9.3.1. Qu'est-ce qu'un "gel des logiciels portes" ?

                9.3.2. Combien de temps dure ce gel ?

                9.3.3. Qu'est-ce que cela signifie pour moi  ?

                9.3.4. Comment suis-je averti du debut du gel des
                logiciels ?

                9.3.5. Comment suis-je averti de la fin du gel des
                logiciels ?

   4. Questions diverses

                9.4.1. Comment sais-je si un logiciel porte compile
                correctement ou non ?

                9.4.2. J'ai importe un nouveau logiciel. Dois-je
                l'ajouter au fichier INDEX ?

                9.4.3. Y'a-t-il d'autres fichiers auxquels je ne dois
                pas toucher ?

    1. Importer un nouveau logiciel

   9.1.1. Comment faire pour importer un nouveau logiciel ?

   Lisez s'il vous plait d'abord la section sur la copie des
   archives.

   Pour importer un nouveau logiciel, le plus facile est d'utiliser
   la procedure easy-import sur freefall. Elle vous posera quelques
   questions et importera directement le logiciel dans le repertoire
   que vous aurez indique. Elle a ete ecrite par Jo:rg Wunsch
   <joerg@FreeBSD.org>, envoyez-lui s'il vous plait un courrier
   electronique si vous avez des questions `a propos de easy-import.

   Il y a une chose qu'elle ne fera pas `a votre place : ajouter le
   logiciel au Makefile du repertoire de niveau superieur
   (categorie). Il faudra le faire vous-meme.

   9.1.2. Y'a-t-il d'autres choses qu'il faut que je sache quand
   j'importe un nouveau logiciel ?

   Verifiez votre portage, pour vous assurez qu'il compile et que le
   paquetage est correctement construit. Voici ce qu'il est
   recommande de faire :

 % make install
 % make package
 % make deinstall
 % pkg_add le_paquetage_que_vous_venez_de_compiler
 % make deinstall
 % make reinstall
 % make package
            

   Le chapitre faire vous-meme un portage du Manuel de Reference vous
   donnera des instructions plus detaillees.

   Utilisez portlint(1) pour verifier la syntaxe du portage. Il n'est
   pas indispensable d'eliminer la totalite des messages
   d'avertissement, mais veillez `a regler les problemes les plus
   evidents.

   Si le logiciel porte a ete soumis par quelqu'un qui n'a jamais
   collabore au projet auparavant, ajoutez le nom de cette personne
   `a la section Autres Collaborateurs du Manuel de Reference.

   Fermez le PR, si le portage resulte d'un PR. Pour fermer un PR, il
   suffit d'executer edit-pr PR# sur freefall et de modifier la
   valeur de la variable state de open en closed. On vous demandera
   d'entrer un commentaire, et c'est tout.

    2. Copies des archives

   9.2.1. Quand avons-nous besoin qu'une operation de copie soit
   faite sur les archives ?

   Quand vous voulez importer un logiciel en rapport avec un autre
   logiciel dej`a archive dans un autre repertoire, envoyez s'il vous
   plait un courrier electronique au responsable des logiciels portes
   pour lui demander son avis. En rapport designe ici une version
   differente ou une version legerement modifiee. En exemple, on peut
   citer print/ghostscript* (versions differentes) et
   x11-wm/windowmaker* (version Anglaise et version
   internationalisee).

   Comme autre exemple, on peut citer le cas d'un logiciel porte
   deplace d'un sous-repertoire `a un autre, ou d'une modification du
   nom d'un repertoire parce que l'auteur a change le nom de son
   logiciel, bien qu'il derive d'un logiciel dej`a importe.

   9.2.2. Quand n'avons-nous pas besoin q'une operation de copie soit
   faite sur les archives ?

   Quand il n'y a pas d'historique `a conserver. Si un logiciel est
   importe dans une categorie erronee et immediatement deplace, il
   suffit d'un simple cvs remove de l'ancien suivi d'un cvs import du
   nouveau.

   9.2.3. Que faut-il que je fasse ?

   Envoyez un courrier electronique au responsable des logiciels
   portes, qui fera la copie de l'ancien emplacement vers le nouveau.
   Vous en serez averti, et l'on attendra alors de vous que vous
   executiez les operations suivantes :

    1. cvs remove de l'ancien logiciel (si besoin est),

    2. Correction du Makefile de niveau superieur (categorie),

    3. Mise `a jour de CVSROOT/modules

    4. Si d'autres logiciels dependent de celui qui vient d'etre mis
       `a jour, correction des lignes decrivant leurs dependances
       dans leurs Makefiles,

    5. Si le logiciel a change de categories, modification en
       consequence de la ligne CATEGORIES du Makefile du logiciel.

    3. Gel des logiciels portes

   9.3.1. Qu'est-ce qu'un "gel des logiciels portes" ?

   Avant livraison d'une nouvelle version, il est necessaire de
   limiter les interventions sur les archives des logiciels portes
   pendant une courte periode, le temps que les paquetages et la
   version elle-meme soient compiles. Cela pour garantir la coherence
   entre les differents composants de la version, c'est cela que l'on
   appelle le "gel des logiciels portes".

   9.3.2. Combien de temps dure ce gel ?

   Habituellement deux `a trois jours.

   9.3.3. Qu'est-ce que cela signifie pour moi  ?

   Pendant le gel des logiciels portes, vous ne devez pas soumettre
   quoi que ce soit dans l'arborescence des logiciels portes, sauf
   autorisation explicite du responsable des logiciels. "Autorisation
   explicite" correspond ici `a l'un des deux cas de figure
   suivants :

     * Vous avez pose la question au responsable des logiciels, et il
       vous a repondu : "Allez-y, integrez".

     * Le responsable des ports vous a envoye un courrier
       electronique, soit directement, soit `a la liste de diffusion,
       pour signaler un probleme `a corriger sur le logiciel.

   Notez bien que vous n'etes pas implicitement autorise `a corriger
   un logiciel pendant un gel simplement parce qu'il ne compile plus.

   9.3.4. Comment suis-je averti du debut du gel des logiciels ?

   Le responsable des logiciels portes enverra des messages
   d'avertissement sur la liste de diffusion `a propos du catalogue
   des logiciels portes de FreeBSD et la liste de diffusion pour les
   committers de FreeBSD pour annoncer la mise en oeuvre prochaine
   d'une nouvelle version, habituellement deux `a trois semaines `a
   l'avance. La date exacte ne sera definitivement fixee que quelques
   jours avant. Cela parce que le gel des logiciels doit etre
   synchronise avec la mise en oeuvre de la version elle-meme, et que
   ce n'est qu'`a ce moment-l`a que l'on sait exactement quand cette
   operation aura lieu.

   Quand le gel commencera, il y aura bien sur une nouvelle annonce
   sur la liste de diffusion pour les committers de FreeBSD.

   9.3.5. Comment suis-je averti de la fin du gel des logiciels ?

   Quelques heures apres la mise en place de la nouvelle version, le
   responsable des logiciels enverra un courrier electronique `a la
   liste de diffusion `a propos du catalogue des logiciels portes de
   FreeBSD et `a la liste de diffusion pour les committers de FreeBSD
   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 probleme de derniere minute
   ne demande pas de reconstruction immediate de la version.

    4. Questions diverses

   9.4.1. Comment sais-je si un logiciel porte compile correctement
   ou non ?

   Commencez par consulter
   http://bento.FreeBSD.org/~asami/errorlogs/. Vous y trouverez les
   messages d'erreurs des dernieres compilations des logiciels portes
   sous 3-stable et 4-current.

   Neanmoins, il ne suffit pas qu'un logiciel n'y apparaisse pas pour
   pouvoir dire qu'il compile correctement. (Une de ses dependances,
   par exemple, peut ne pas avoir compile.) Voici les repertoires de
   bento, n'hesitez pas `a aller y voir :

 
 /a/asami/portbuild/3/errors        messages d'erreur de la derniere compilation de 3-stable
                     /logs          tous les messages de la derniere compilation de 3-stable
                     /packages      messages d'erreur sur les paquetages de la derniere compilation 3-stable
                     /bak/errors    messages d'erreur de la derniere compilation integrale de 3-stable
                     /bak/logs      tous les messages de la derniere compilation de l'integrale de 3-stable
                     /bak/packages  messages d'erreur sur les paquetages de la derniere compilation integrale de 3-stable
                   /4/errors        messages d'erreur de la derniere compilation de 4-current
                     /logs          tous les messages de la derniere compilation de 4-current
                     /packages      messages d'erreur sur les paquetages de la derniere compilation 4-current
                     /bak/errors    messages d'erreur de la derniere compilation integrale de 4-current
                     /bak/logs      tous les messages de la derniere compilation de l'integrale de 4-current
                     /bak/packages  messages d'erreur sur les paquetages de la derniere compilation integrale de 4-current
            

   Essentiellement, si le logiciel apparait dans packages, ou dans
   logs mais pas dans errors, il compile correctement. (Les
   repertoires errors contiennent ce que vous voyez sur la page Web.)

   9.4.2. J'ai importe un nouveau logiciel. Dois-je l'ajouter au
   fichier INDEX ?

   Non. Le responsable des logiciels portes regenere l'INDEX et
   l'integre regulierement aux archives.

   9.4.3. Y'a-t-il d'autres fichiers auxquels je ne dois pas
   toucher ?

   Tous les fichiers immediatement dans ports/, et tous les fichiers
   des sous-repertoires dont le nom commence par une majuscule (Mk,
   Tools, etc.). Le responsable des logiciels est particulierement
   susceptible pour ce qui touche `a ports/Mk/bsd.port.mk, n'y
   touchez donc pas `a moins que vous ne vouliez affronter son
   courroux.

     --------------------------------------------------------------

        Ce document, ainsi que d'autres peut etre telecharge sur
                   ftp.FreeBSD.org/pub/FreeBSD/doc/.

Pour toutes questions `a propos de FreeBSD, lisez la documentation avant
                 de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.
