Le Guide du Nouveau Committer

Il vous est demandé d’utiliser ssh(1) ou telnet(1) et Kerberos 5 pour vous connecter aux machines d’archive. Ces méthodes sont globalement plus sûres qu’un simple telnet(1) ou rlogin(1) parce que la négociation de l’authentification est cryptée. Par défaut 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 à la Introduction rapide à SSH.

Les opérations CVS se font habituellement en se connectant à freefall, vérifiant que votre variable d’environnement CVSROOT est bien positionnée à /home/ncvs, et en effectuant les opérations d’extraction (check-out) et de mise à jour (check-in) nécessaires. Si vous avez quelque chose de entièrement nouveau à ajouter (un nouveau logiciel porté, du source d’origine externe, etc.), il existe une procédure appelée "easy-import" qui facilite cette opération. Elle ajoute automagiquement une entrée pour le nouveau module, fait ce qu’il faut via cvs import, etc. - exécutez-la sans arguments et elle vous demandera tout ce qu’elle a besoin de savoir.

Si vous avez la pratique de CVS à distance et vous considérez relativement opérationnel sur CVS en général, vous pouvez aussi effectuer les opérations CVS directement depuis votre machine avec une copie local à jour des sources. N’oubliez cependant pas de positionner CVS_RSH à de façon à utiliser un moyen de transmission sécurisé et fiable. D’une autre côté, si vous ne savez pas ce que cela veut dire, tenez-vous en s’il vous plaît à la méthode qui consiste à vous connecter à freefall et mettre en place vos modifications avec patch(1).

Si vous avez à utiliser les opérations add et delete pour faire en fait une opération "mv", il faut une copie sur l’archive plutôt que votre commande CVS add suivie d’un delete. Dans ce cas, un Conventions et Traditions copiera le(s) fichier(s) là où il(s) doi(ven)t aller et vous avertira une fois qu’il l’aura fait. Le but de la copie dans les archives est de conserver l’historique des modifications, la journalisation. Le Projet FreeBSD accorde une grande importance à l’historique du projet que CVS nous permet de conserver.

Les Administrateurs CVS (Peter Wemm et John Polstra) sont les "propriétaires" 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 dûe à 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’étiquette par exemple, n’essayez pas de la rectifier vous-même ! Envoyez immédiatement un courrier électronique ou téléphonez à John ou Peter et expliquez leur le problème. Satoshi Asami est aussi Administrateur CVS pour la partie ports/ de l’arborescence. Mark Murray est l’administrateur des archives internationales pour les logiciels de cryptographie, en Afrique du Sud.

Si vous êtes nouveau committer, la première chose à faire est de vous ajouter vous-même à la liste des développeurs (section 28.2) du Manuel de Référence. Extraire le manuel de référence et ajouter une entrée à la liste est relativement facile, mais c’est néanmoins un bon test initial de vos compétences CVS. Si vous pouvez le faire, vous n’aurez probablement pas de problèmes par la suite.

L’étape suivante consiste à vous présenter aux autres committers, sans quoi ils n’auront aucune idée de qui vous êtes et à quoi vous travaillez. Il n’est pas nécessaire de rédiger une biographie exhaustive, un paragraphe ou deux suffiront, pour dire qui vous êtes et à quoi vous comptez travailler sur FreeBSD. Envoyez-les par courrier électronique à cvs-committers@FreeBSD.org et vous serez prêt à commencer à travailler !

N’oubliez pas aussi de vous connecter à hub.FreeBSD.org et de vous y créez un fichier /var/forward/utilisateur (où utilisateur est votre nom d’utilisateur), qui contienne votre adresse de courrier électronique principale où vous souhaitez que le courrier électronique adressé à votre_nom_d_utilisateur@FreeBSD.org vous soit redirigé. Les boîtes aux lettres vraiment volumineuses qui demeurent en en permanence sur hub sont souvent "accidentellement" tronquées 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 assigné les premiers mois. Votre mentor est plus ou moins chargé de vous expliquer tout ce que vous ne comprenez pas bien et est aussi responsable de ce que vous faites à vos débuts. Si vous faites une soumission erronée, c’est votre mentor qui sera ennuyé et vous devriez probablement vous fixer comme ligne de conduite de faire passer vos premières soumissions par lui avant de les intégrer aux archives.

Toutes les soumissions doivent être intégrées d’abord à -CURRENT, avant d’aller dans -STABLE. Aucune nouvelle fonctionnalité ou modification à haut risque ne devrait être intégrée à la branche -STABLE.

Si vous travaillez directement sur votre propre code ou sur du code dont il est bien établi que vous avez la responsabilité, il n’est probablement pas nécessaire de valider ce que vous allez faire avec d’autres développeurs avant de soumettre du code. Si vous trouvez un bogue dans un module qui est manifestement orphelin (il y en a malheureusement quelques uns), cela s’y applique aussi. Si, au contraire, vous vous apprêtez à modifier quelque chose qui est activement maintenu par quelqu’un d’autre (ce n’est qu’en surveillant la liste de diffusion des messages de modification CVS de FreeBSD que vous pourrez vous faire une idée de ce qu’il l’est et de ce qui ne l’est pas), envisagez alors de lui envoyer vos modifications, tout comme vous l’auriez fait quand vous n’étiez pas committer. Pour les logiciels portés, vous devriez contacter la personne listée comme MAINTAINER dans le Makefile. Pour le reste des archives, si vous n’êtes pas sûr de qui maintient effectivement tel ou tel module, il peut être utile de passer en revue le résultat de cvs log pour voir qui a soumis des modifications dans le passé. Si vous ne trouvez personne, ou si la personne en charge montre un désintérêt pour la partie en question, allez-y et faites vos modifications.

Si vous avez pour une raison ou une autre des doutes à propos d’une soumission que vous envisagez, faites-la d’abord examiner par -hackers avant de l’intégrer. Il vaut mieux que l’on vous fasse des remarques alors, qu’une fois qu’elle fera partie des archives CVS. S’il vous arrive de soumettre quelque chose qui soulève une controverse, envisagez éventuellement de faire marche arrière en attendant que la question soit réglée. N’oubliez pas - avec CVS, vous pourrez toujours remettre votre modification en service.

Le Projet FreeBSD utilise GNATS pour enregistrer les rapports de bogues et les demandes de modification. Si vous effectuez une correction ou une modification décrite dans un PR - Problem Report, rapport d’anomalie - GNATS, veillez à utiliser edit-pr numéro_de_pr sur freefall pour le fermer. L’usage veut aussi que vous preniez le temps de fermer les rapports ayant trait à vos soumission, le cas échéant. Vous pouvez aussi utiliser vous-même send-pr(1) pour proposer les modifications dont vous pensez qu’il faut les probablement les faire, après une revue plus extensive par les autres participants.

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

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 :

Vous devriez maintenant pouvoir utiliser ssh-add(1) pour vous authentifier à chaque début de session. Il vous demandera la phrase clé pour votre clé privée, et l’enregistrera via votre agent d’authentification (ssh-agent(1)) de façon à ce que vous n’ayez plus à la retaper à chaque fois.

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

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

Comme indiqué, enfreindre l’un de ces règles peut entraîner une suspension provisoire, et, en cas de récidive, une suppression permanente des privilèges de committers. Trois membres ou plus de l’équipe de base, ou l’Architecte Principal et un autre membre de l’équipe de base, peuvent, s’ils en sont d’accord, suspendre temporairement ces privilèges jusqu’à ce que l’ensemble de -core examine la question. En cas d'"urgence" (un committer endommageant les archives), une suspension provisoire peut aussi être décidée par l’un des administrateurs des archives ou tout autre membre de l’équipe de base qui se trouve être réveillé à ce moment-là. Seule la totalité de l’équipe de base peut suspendre pour une durée importante les droits d’un committer, ou les retirer définitivement, cette dernière mesure n’étant en général prise qu’après consultation avec les committers. Le but de cette règle n’est pas de faire de l’équipe de base une bande de dictateurs cruels qui puissent disposer des committers comme de cannettes vides, mais d’avoir une sorte de fusible pour le projet. Si quelqu’un est sévèrement incontrôlable, il est important de pouvoir réagir immédiatement, au lieu d’être paralysé par la discussion. Dans tous les cas, le committers dont les privilèges sont suspendus a le droit d’être "entendu", c’est à ce moment-là qu’il est décidé de la durée totale de la suspension. Il peut aussi demander un révision de la décision après 30 jours et tous les 30 jours ensuite (à moins que la durée totale de la suspension soit inférieure à 30 jours). Quelqu’un à qui les privilèges ont été définitivement retiré peut demander que son cas soit revu après 6 mois. La procédure de révision est strictement informelle, et, dans tous les cas, l’équipe de base se réserve le droit de prendre en compte ou d’ignorer les demandes de révision, si elle pense que sa décision initiale était la bonne.

Pour toutes les autres aspects du fonctionnement du projet, l’équipe de base est un sous-ensemble des committers et est soumise aux même règles. Ce n’est pas parce que quelqu’un appartient à l’équipe de base qu’il est dispensé de suivre les instructions que l’on vient de donner, les "pouvoirs spéciaux" de l’équipe de base ne sont effectifs que lorsqu’elle agit en tant que groupe, pas individuellement. Individuellement, nous sommes tous d’abord des committers et ensuite seulement membres de l’équipe de base.