                        Le Guide du Nouveau "Committer"

  Projet de Documentation de FreeBSD

   Version: 43126

   Copyright (c) 1999 Projet de Documentation de FreeBSD

   Septembre 1999 par .
   Resume

   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 !

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

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

   Table des matieres

   1. Details d'organisation

   2. Operations CVS

   3. Conventions et Traditions

   4. Relations entre developpeurs

   5. GNATS

   6. Who's Who

   7. Introduction rapide `a SSH

   8. Regles `a Suivre par les Committers FreeBSD

   9. Questions Frequemment Posees propres aux logiciels portes

1. Details d'organisation

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

   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, << Introduction rapide `a SSH >>.

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
   modification 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

           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

           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

           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

           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

           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 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.

   Brian Somers

           Maintient officiellement /usr/bin/ppp et LPD.

   Garrett Wollman

           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

   9.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 ?

   9.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 ?

   9.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 ?

   9.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 ?

    9.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 ?
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, 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.      
    9.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 ?
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.    
    9.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 ?
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.                                                                                
    9.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 ?
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.                           
