Le Guide du Nouveau ``Committer''

8.1. Détails

1. Respectez les autres committers.

   Cela signifie que vous devez traiter les autres committers en tant que groupe de co-développeurs qu'ils sont en fait. Malgré nos tentatives occasionnelles pour prouver le contraire, on ne devient pas committer en étant stupide et rien n'est plus irritant que d'être traité comme tel par un de vos collaborateurs. Que nous apprécions toujours quelqu'un d'autre ou pas (chacun a ses jours sans), nous devons malgré tout toujours traiter les autres avec respect, sans quoi c'est toute l'organisation de l'équipe qui se désagrège rapidement.

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

   Pour respecter cette règle, n'envoyez pas de courrier électronique quand vous êtes en colère et ne vous comportez en outre pas de façon à paraître inutilement agressif aux autres. Commencez par vous calmer et réfléchissez à la manière la plus efficace de convaincre l(es) autre(s) personne(s) de la justesse de votre point de vue. Ne partez pas sur les chapeaux de roues pour vous sentir simplement immédiatement mieux au prix d'une dispute à long terme. Non seulement c'est une mauvaise ``gestion des ressources'', mais les responsables du projet sanctionneront sévèrement les manifestations d'agressivité publiques et répétées, jusqu'à suspendre ou vous retirer définitivement vos privilèges de committer. Ce n'est pas une chose qu'ils aiment le moins du monde faire, mais l'unité est la priorité. Aucune dose de code ou de judicieux conseils ne s'y mesure.

2. Discutez de toute modification importante avant intégration.

   Ce n'est pas dans les archives CVS que les modifications doivent être intégrées pour validation ou discussion, cela doit se faire d'abord sur les listes de discussion et être intégré ensuite lorsqu'on est arrivé à quelque chose qui approche du consensus. Cela ne signifie pas que vous deviez demander la permission avant de corriger chaque erreur évidente de syntaxe ou d'orthographe dans une page de manuel, mais simplement que vous devriez essayer de sentir quand vous envisagez une modification qui n'est pas aussi triviale et qui demande à être discutée au préalable. Les gens n'ont rien contre les modifications d'envergure si le résultat en est quelque chose de nettement meilleur que ce qu'ils avaient auparavant, mais ils n'aiment pas être surpris par ces modifications. La meilleure façon de vous assurer que vous allez dans le bon sens et de faire valider votre code par un ou plusieurs autres 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'' à personne, c'est-à-dire qu'il n'y aura personne pour pousser de hauts cris si vous faites des modifications sur ``leur'' terrain, mais il vaut mieux s'en assurer d'abord. Une de nos convention est de mettre une ligne indiquant qui maintient dans le 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 à ce sujet. Quand il y a plusieurs personnes qui maintiennent une même section de code, les soumissions d'une de ces personnes sur ces sections doivent être revues par au moins une des autres personnes qui la maintiennent. Dans le cas où l'“attribution” n'est pas claire, vous pouvez aussi consulter les messages de CVS pour les fichiers concernés, pour voir si quelqu'un a travaillé dessus récemment ou travaille de façon prédominante sur ce domaine.

   Il y a d'autres parties de FreeBSD qui sont contrôlées par quelqu'un qui gère tout un domaine de l'évolution de FreeBSD, l'internationalisation ou le réseau par exemple. Reportez-vous à http://www.FreeBSD.org/handbook/staff-who.html pour avoir plus d'informations à ce sujet.

4. N'intervenez jamais directement sur les archives. Demandez à 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 difficultés, adressez-vous à l'un des responsables des archives en envoyant un courrier électronique à <cvs@FreeBSD.org> et attendez qu'ils corrigent le problème et vous relancent. N'essayez pas de régler le problème vous-même !

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

5. Toute modification controversée doit, si le responsable de la maintenance ou l'Architecte Principal le demande, être annulée jusqu'à ce que la discussion soit terminée. Les modifications pour des questions de sécurité peuvent être effectuées par l'Officier de Sécurité, malgré les souhaits d'un responsable de la maintenance.

   Ce peut être dur à avaler en cas de conflit (quand chaque partie est bien sûr convaincue qu'elle a raison) mais CVS permet d'éviter de prolonger la dispute, il est bien plus facile de revenir sur les modifications, d'attendre que tout le monde se calme et d'essayer de voir quelle est la meilleure solution. S'il s'avère que la modification était la bonne chose à faire, elle peut-être facilement remise en service. Dans le cas contraire, les utilisateurs n'auront pas eu à subir l'évolution erronée le temps que tout le monde ait débattu de sa pertinence. Il est très rare que l'on ait à revenir sur des modifications archivées, parce que la discussion met la plupart du temps en évidence les interventions controversés ou non justifiées avant même qu'elles n'aient été intégrées, mais dans les rares cas où cela se produit, il faut revenir en arrière sans discuter de façon à ce que l'on puisse immédiatement examiner s'il y avait erreur ou non.

6. Les modifications doivent être faites dans -current avant d'être reportées dans -stable sauf autorisation expresse du responsable des versions ou si elles ne s'appliquent pas à -current. Toute modification non triviale ni urgente doit rester au moins trois jours dans -current pour être testée suffisamment avant d'être reportée. Le responsable des versions a les mêmes prérogatives sur la branche -stable que celles décrites, pour ce qui concerne l'Architecte Principal, par le règle #5

   C'est un autre point “sans appel” parce que c'est l'ingénieur de version qui est en dernier lieu responsable (et encaisse les coups) si une modification s'avère mal fondée. Respectez s'il vous plaît cette règle et coopérez totalement avec le responsable des versions pour ce qui concerne la branche -stable. La gestion de la branche -stable peut parfois paraître excessivement conservatrice à un observateur occasionnel, mais rappelez vous que c'est le principe même de -stable et que -current suit d'autres règles. Il n'y a aucune raison d'avoir une branche -current si toutes les modifications vont immédiatement dans -stable, sans pouvoir d'abord être testées par les développeurs de -current, laissez donc passer un peu de temps avant de les reporter dans -stable, à moins que la modification ne soit critique, urgente, ou suffisamment triviale pour rendre tout test ultérieur superflu (correction d'orthographe dans les pages de manuel, de bogue flagrant ou de faute de frappe, etc.) En d'autres termes, faites preuve de bon sens.

7. Ne vous disputez pas publiquement avec les autres committers ; cela fait mauvais effet. Si vous êtes en ``profond'' désaccord sur un point, n'en discutez qu'en privé.

   Le projet a une image publique à conserver et cette image est très importante pour nous tous, en particulier si nous voulons continuer à attirer de nouveaux membres. Il y aura des situations où, malgré tous les efforts de chacun pour rester mesurés, certains perdront leur calme et laisserons leur colère s'exprimer, et le mieux que nous puissions faire est d'essayer d'en minimiser les effets jusqu'à ce que chacun se soit de nouveau calmé. Cela signifie que vous ne devez ni laisser exprimer votre colère en public, ni faire suivre de courriers privés sur des listes ou des alias publics. Ce que les gens se disent entre eux est souvent moins édulcoré que ce qu'ils disent en public, et ce type d'échange n'y a donc pas sa place - cela ne peut qu'envenimer une situation déjà regrettable. Si la personne qui vous adresse des reproches prend au moins la précaution de le faire en privé, ayez vous aussi la correction de le garder pour vous. Si vous estimez avoir été injustement traité par un autre développeur et que cela vous soucie, parlez-en à l'équipe de base plutôt qu'en public. Nous ferons de notre mieux pour jouer les médiateurs et ramener les choses au raisonnable. Quand la discussion a trait à une modifications de code et que les participants n'arrivent apparemment pas à se mettre d'accord, l'équipe de base peut désigner une troisième partie ayant l'accord mutuel pour résoudre le problème. Les autres personnes impliquées doivent alors accepter de se plier aux décisions de cette troisième partie.

8. Respectez tous les gels du code et lisez régulièrement 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 après une longue absence et soumettre 10 Mo de code accumulés pendant ce temps. Les gens qui se comportent régulièrement de cette façon verront leurs privilèges de committers suspendus jusqu'à leur retour du Joyeux Camp de Rééducation de FreeBSD que nous gérons au Gröenland.

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

   De nombreuses erreurs sont commises parce que quelqu'un est pressé et estime qu'il sait quelle est la meilleure façon de faire quelque chose. Il y a des bonnes chances que vous ne sachiez en fait pas comment faire ce que vous n'avez encore jamais fait et que vous ayez vraiment besoin de demander d'abord sans quoi vous allez vous mettre publiquement dans l'embarras. Il n'y a aucune honte à demander ``Comment diable fait-on cela ?'', nous savons déjà que vous êtes quelqu'un d'intelligent, sans quoi vous ne seriez pas committer.

10. Testez vos modifications avant de les intégrer.

    Cela peut paraître évident, mais si c'était vraiment le cas, nous ne verrions probablement pas autant de cas où les gens ne le font manifestement pas. Si vos modifications touchent le noyau, vérifiez que vous pouvez toujours compiler et GENERIC et LINT. Si vos modifications s'appliquent ailleurs, assurez-vous que vous pouvez toujours compiler l'ensemble du système - make world. Si vous faites vos modifications sur une branche donnée, veillez à tester vos modifications sur une machine qui utilise cette version du système. Si votre modifications risque de poser des problèmes sur une autre architecture matérielle, veillez à tester sur toutes les architectures supportées. Nous n'avons actuellement qu'x86 et Alpha, c'est donc assez facile à faire. Si vous avez besoin de tester sur l'AXP, votre compte sur beast.FreeBSD.org vous permet de compiler et tester des binaires/noyaux/etc. sur Alpha. Quand d'autres architectures seront ajoutées à la liste des plates-formes supportées par FreeBSD, des ressources partagées de test seront disponibles.

8.2. Autres suggestions

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

Pour toutes les pages de manuel en ligne, servez-vous de manck (au catalogue des logiciels portés) sur la page pour vérifier que toutes les références croisées et noms de fichiers sont corrects et que les MKLINKs appropriés sont installés.