diff --git a/fr_FR.ISO8859-1/articles/committers-guide/article.sgml b/fr_FR.ISO8859-1/articles/committers-guide/article.sgml index 13b0ae5fcd..78f074ed4e 100644 --- a/fr_FR.ISO8859-1/articles/committers-guide/article.sgml +++ b/fr_FR.ISO8859-1/articles/committers-guide/article.sgml @@ -1,1233 +1,1233 @@ %man; %urls; %abstract; %artheader; %translators; %authors; %mailing-lists; ]>
Le Guide du Nouveau “<foreignphrase>Committer</foreignphrase>” Projet de Documentation de FreeBSD Septembre 1999 1999 Projet de Documentation de FreeBSD Nouveau “committer”, bienvenue dans l'équipe de développement de FreeBSD ! L'objectif de cette documentation est de vous orienter sur la façon d'utiliser CVS sur la machine d'archive centrale de FreeBSD. Il est présumé que vous avez déjà une connaissance de base de CVS, quoique des informations de référence, des guides et Questions Fréquemment Posées soient disponibles à l'adresse : http://www.cyclic.com/cyclic-pages/books.html Bonne chance, et bienvenue à bord ! &abstract.license; &abstract.disclaimer; &trans.a.haby; Détails d'organisation Machine d'archive principale freefall.FreeBSD.org Machine d'archive internationale pour les codes de cryptographie internat.FreeBSD.org Méthode de connexion &man.ssh.1; Répertoire CVSROOT /home/ncvs Répertoire CVSROOT pour la version internationale des codes de cryptographie /home/cvs.crypt Administrateurs des archives CVS principales &a.jdp; et &a.peter; ainsi que &a.asami; pour ports/ Administrateur des archives CVS pour la version internationale des codes de cryptographie &a.markm; Liste de diffusion cvs-committers@FreeBSD.org Etiquettes CVS importantes RELENG_3 (3.x-STABLE), HEAD (-CURRENT) Il vous est demandé d'utiliser &man.ssh.1; ou &man.telnet.1; et Kerberos 5 pour vous connecter aux machines d'archive. Ces méthodes sont globalement plus sûres qu'un simple &man.telnet.1; ou &man.rlogin.1; parce que la négociation de l'authentification est cryptée. Par défaut &man.ssh.1; crypte toute la session. Les utilitaires disponibles &man.ssh-agent.1; et &man.scp.1; sont aussi bien plus pratiques. Si vous ne connaissez pas &man.ssh.1, reportez-vous à la . Opérations CVS 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 d'entiérement nouveau à ajouter (un nouveau logiciel + 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 à ssh 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 &man.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 Administrateur CVS 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. Conventions et Traditions 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 soummission erronée, c'est votre mentor qui sera ennuyé et vous + 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. Relations entre développeurs Si vous travaillez directement sur votre propre code ou sur du code dont il est bien établi que vous avez la responsabilité, il n'est probablement pas nécessaire de valider ce que vous allez faire avec d'autres développeurs avant de soumettre du code. Si vous trouvez un bogue dans un module qui est manifestement orphelin (il y en a malheureusement quelques uns), cela s'y applique aussi. Si, au contraire, vous vous apprêtez à modifier quelque chose qui est activement maintenu par quelqu'un d'autre (ce n'est qu'en surveillant la &a.cvsall; que vous pourrez vous faire une idée de ce qu'il l'est et de ce qui ne l'est pas), envisagez alors de lui envoyer vos modifications, tout comme vous l'auriez fait quand vous n'étiez pas 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ésinterêt pour la partie en question, + 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. 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 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 &man.send-pr.1; pour proposer les modifications dont vous pensez qu'il faut les probablement les faire, après une revue plus extensive par les autres participants. 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 &man.send-pr.1; 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 : &a.asami; - Est le reponsable du catalogue des logiciels portés, ce qui + Est le responsable du catalogue des logiciels portés, ce qui signifie qu'il a le pouvoir de décision en ce qui concerne toute modification aux logiciels portés et à leurs macros-instructions de compilation. Il est aussi responsable la gestion des gels du code entre deux versions. &a.bde; Est l'Obersturmbahnfuhrer de la Police du Style. Quand vous soumettez quelque chose que vous auriez pu faire mieux, Bruce sera là pour vous le signaler. Remerciez-le qu'il y ait quelqu'un pour le faire. &a.dg; Est notre architecte principal et superviseur du système de gestion de la mémoire virtuelle. Si vous envisagez une modification de ce système, voyez cela avec David. Si vous êtes pris dans une discussion âpre et insoluble avec un autre participant à propos d'une modification envisagée (ce qui, heureusement, ne se produit pas souvent), il peut aussi occasionnellement être nécessaire de demander alors à David de mettre sa casquette d'Architecte Principal et de prendre la décision finale. &a.jkh; Est le responsable des versions. Il a la charge de définir les dates butées et de superviser le processus de mise en place de la nouvelle version. Pendant les gels du code, il a aussi le pouvoir de décision sur toutes les modifications sur la branche de code qui est en cours de finalisation. S'il y a quelque chose que vous voudriez voir reporter de -CURRENT dans -STABLE (quelqu'intérêt que cela puisse avoir à un moment donné), c'est aussi la personne à qui il faut en parler. &a.markm; 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 à jour, parlez-en s'il vous plaît d'abord à Mark. &a.steve; 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 coopération avec &a.phk;. &a.brian; Maintient officiellement /usr/bin/ppp et LPD. &a.wollman; Si vous avez besoin d'un conseil sur des points obscurs du code réseau ou n'êtes pas certain d'une modification que vous envisagez à ce sous-système, c'est avec Garrett qu'il faut en discuter. Introduction rapide à <application>SSH</application> Mettez à jour et installez le logiciel porté ssh dans /usr/ports/security/ssh (il faut une version 1.2.25 ou postérieure). Veillez à exécuter &man.ssh-agent.1; avant toute autre application. Les utilisateurs de X, par exemple, le font habituellement depuis leur fichier .xsession ou .xinitrc. Reportez-vous à &man.ssh-agent.1; pour plus de détails. Générez une paire de clés avec &man.ssh-keygen.1;. Ces clés seront créées dans le répertoire $HOME/.ssh. Copiez votre clé publique ($HOME/.ssh/identity.pub) dans le fichier authorized_keys de votre répertoire utilisateur sur freefall (i.e. $HOME/.ssh/authorized_keys). Vous devriez maintenant pouvoir utiliser &man.ssh-add.1; pour vous authentifier à chaque début de session. Il vous demandera la phrase clé pour votre clé privée, et l'enregistrera via votre agent d'authentification (&man.ssh-agent.1;) de façon à ce que vous n'ayez plus à la retaper à chaque fois. Testez en faisant quelque chose du style : ssh freefall.FreeBSD.org ls /usr. Pour plus d'informations, reportez-vous à /usr/ports/security/ssh, &man.ssh.1;, &man.ssh-agent.1;, &man.scp.1;, et &man.ssh-keygen.1;. Régles à Suivre par les <foreignphrase>Committers</foreignphrase> FreeBSD Respectez les autres committers. Discutez de toute modification importante avant intégration. - Respectez les reponsables de la maintenance s'il y en a de + Respectez les responsables de la maintenance s'il y en a de définis par la variable MAINTAINER du Makefile ou dans le fichier MAINTAINER au premier niveau de l'arborescence. N'intervenez jamais directement sur les archives. Demandez au reponsable de ces archives de le faire. 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. 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. 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é. 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. En cas de doute sur une procédure, renseignez-vous d'abord ! Testez vos modifications avant de les intégrer. 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. Détails 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 aggressif aux autres. + 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'aggressivité + 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. 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 dicussion et être intégré + 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 ! - Respectez les responsbales de la maintenance, s'il y en + 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. 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. 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 erronnée le + 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. 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'ortographe dans les pages + 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. 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. 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. + au Gröenland. 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 meillleure façon de + 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. 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. 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 devrirez aussi vérifier que vos + 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. Questions Fréquemment Posées propres aux logiciels portés Importer un nouveau logiciel Comment faire pour importer un nouveau logiciel ? Lisez s'il vous plaît d'abord la section sur la copie des archives. Pour importer un nouveau logiciel, le plus facile est d'utiliser la procédure easy-import sur freefall. Elle vous posera quelques questions et importera directement le logiciel dans le répertoire que vous aurez indiqué. Elle a été écrite par &a.joerg;, envoyez-lui s'il vous plaît un courrier électronique si vous avez des questions à propos de easy-import. Il y a une chose qu'elle ne fera pas à votre place : ajouter le logiciel au Makefile du répertoire de niveau supérieur (catégorie). Il faudra le faire vous-même. Y'a-t-il d'autres choses qu'il faut que je sache quand j'importe un nouveau logiciel ? Vérifiez votre portage, pour vous assurez qu'il compile et que le paquetage est correctement construit. Voici ce qu'il est recommandé de faire : &prompt.user; make install &prompt.user; make package &prompt.user; make deinstall &prompt.user; pkg_add le_paquetage_que_vous_venez_de_compiler &prompt.user; make deinstall &prompt.user; make reinstall &prompt.user; make package Le chapitre faire vous-même un portage du Manuel de Référence vous donnera des instructions plus détaillées. Utilisez &man.portlint.1; pour vérifier la syntaxe du portage. Il n'est pas indispensable d'éliminer la totalité des messages d'avertissement, mais veillez à régler les problèmes les plus évidents. Si le logiciel porté a été soumis par quelqu'un qui n'a jamais collaboré au projet auparavant, ajoutez le nom de cette personne à la section Autres Collaborateurs du Manuel de Référence. Fermez le PR, si le portage résulte d'un PR. Pour fermer un PR, il suffit d'exécuter 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. Copies des archives Quand avons-nous besoin qu'une opération de copie soit faite sur les archives ? Quand vous voulez importer un logiciel en rapport avec un autre logiciel déjà archivé dans un autre répertoire, envoyez s'il vous plaît un courrier électronique au responsable des logiciels portés pour lui demander son avis. En rapport désigne ici une version différente ou une version légèrement modifiée. En exemple, on peut citer print/ghostscript* (versions différentes) et x11-wm/windowmaker* (version Anglaise et version internationalisée). Comme autre exemple, on peut citer le cas d'un logiciel porté déplacé d'un sous-répertoire à un autre, ou d'une modification du nom d'un répertoire parce que l'auteur a changé le nom de son logiciel, bien qu'il dérive d'un logiciel déjà importé. Quand n'avons-nous pas besoin q'une opération de copie soit faite sur les archives ? Quand il n'y a pas d'historique à conserver. Si un logiciel - est importé dans une catégorie erronnée et immédiatement + est importé dans une catégorie erronée et immédiatement déplacé, il suffit d'un simple cvs remove de l'ancien suivi d'un cvs import du nouveau. Que faut-il que je fasse ? Envoyez un courrier électronique au responsable des logiciels portés, qui fera la copie de l'ancien emplacement vers le nouveau. Vous en serez averti, et l'on attendra alors de vous que vous exécutiez les opérations suivantes : cvs remove de l'ancien logiciel (si besoin est), Correction du Makefile de niveau supérieur (catégorie), Mise à jour de CVSROOT/modules Si d'autres logiciels dépendent de celui qui vient d'être mis à jour, correction des lignes décrivant leurs - dépendendances dans leurs + dépendances dans leurs Makefiles, Si le logiciel a changé de catégories, modification en conséquence de la ligne CATEGORIES du Makefile du logiciel. Gel des logiciels portés Qu'est-ce qu'un gel des logiciels portés ? Avant livraison d'une nouvelle version, il est nécessaire de limiter les interventions sur les archives des logiciels portés pendant une courte période, le temps que les paquetages et la version elle-même soient compilés. Cela pour garantir la cohérence entre les différents composants de la version, c'est cela que l'on appelle le gel des logiciels portés. Combien de temps dure ce gel ? Habituellement deux à trois jours. Qu'est-ce que cela signifie pour moi  ? Pendant le gel des logiciels portés, vous ne devez pas soumettre quoi que ce soit dans l'arborescence des logiciels portés, sauf autorisation explicite du responsable des logiciels. Autorisation explicite correspond ici à l'un des deux cas de figure suivants : Vous avez posé la question au responsable des logiciels, et il vous a répondu : Allez-y, intégrez. Le responsable des ports vous a envoyé un courrier électronique, soit directement, soit à la liste de diffusion, pour signaler un problème à corriger sur le logiciel. Notez bien que vous n'êtes pas implicitement autorisé à corriger un logiciel pendant un gel simplement parce qu'il ne compile plus. Comment suis-je averti du début du gel des logiciels ? Le responsable des logiciels portés enverra des messages d'avertissement sur la &a.ports; et la &a.committers; pour annoncer la mise en oeuvre prochaine d'une nouvelle version, habituellement deux à trois semaines à l'avance. La date exacte ne sera définitivement fixée que quelques jours avant. Cela parce que le gel des logiciels doit être synchronisé avec la mise en oeuvre de la version elle-même, et que ce n'est qu'à ce moment-là que l'on sait exactement quand cette opération aura lieu. Quand le gel commencera, il y aura bien sûr une nouvelle annonce sur la &a.committers;. Comment suis-je averti de la fin du gel des logiciels ? Quelques heures après la mise en place de la nouvelle version, le responsable des logiciels enverra un courrier électronique à la &a.ports; et à la &a.committers pour annoncer la fin du gel des logiciels. Remarquez que la finalisation de la version n'implique pas automatiquement la fin du gel. Nous devons nous assurer qu'un problème de dernière minute ne demande pas de reconstruction immédiate de la version. Questions diverses Comment sais-je si un logiciel porté compile correctement ou non ? Commencez par consulter http://bento.FreeBSD.org/~asami/errorlogs/. Vous y trouverez les messages d'erreurs des dernières compilations des logiciels portés sous 3-stable et 4-current. Néanmoins, il ne suffit pas qu'un logiciel n'y apparaisse pas pour pouvoir dire qu'il compile correctement. (Une de ses dépendances, par exemple, peut ne pas avoir compilé.) Voici les répertoires de bento, n'hésitez pas à aller y voir : /a/asami/portbuild/3/errors messages d'erreur de la dernière compilation de 3-stable                     /logs tous les messages de la dernière compilation de 3-stable                     /packages messages d'erreur sur les paquetages de la dernière compilation 3-stable                     /bak/errors messages d'erreur de la dernière compilation intégrale de 3-stable                     /bak/logs tous les messages de la dernière compilation de l'intégrale de 3-stable                     /bak/packages messages d'erreur sur les paquetages de la dernière compilation intégrale de 3-stable                   /4/errors messages d'erreur de la dernière compilation de 4-current                     /logs tous les messages de la dernière compilation de 4-current                     /packages messages d'erreur sur les paquetages de la dernière compilation 4-current                     /bak/errors messages d'erreur de la dernière compilation intégrale de 4-current                     /bak/logs tous les messages de la dernière compilation de l'intégrale de 4-current                     /bak/packages messages d'erreur sur les paquetages de la dernière compilation intégrale de 4-current - Essentiellement, si le logiciel apparait dans + Essentiellement, si le logiciel apparaît dans packages, ou dans logs mais pas dans errors, il compile correctement. (Les répertoires errors contiennent ce que vous voyez sur la page Web.) J'ai importé un nouveau logiciel. Dois-je l'ajouter au fichier INDEX ? Non. Le responsable des logiciels portés regénère l'INDEX et l'intègre régulièrement aux archives. Y'a-t-il d'autres fichiers auxquels je ne dois pas toucher ? Tous les fichiers immédiatement dans ports/, et tous les fichiers des sous-répertoires dont le nom commence par une majuscule (Mk, Tools, etc.). Le responsable des logiciels est particulièrement susceptible pour ce qui touche à ports/Mk/bsd.port.mk, n'y touchez donc pas à moins que vous ne vouliez affronter son courroux.
diff --git a/fr_FR.ISO8859-1/articles/contributing/article.sgml b/fr_FR.ISO8859-1/articles/contributing/article.sgml index 8d82306817..c2911765f0 100644 --- a/fr_FR.ISO8859-1/articles/contributing/article.sgml +++ b/fr_FR.ISO8859-1/articles/contributing/article.sgml @@ -1,653 +1,653 @@ %man; %freebsd; %authors; %abstract; %artheader; %translators; %newsgroups; %mailing-lists; %trademarks; ]>
Collaborer à FreeBSD $FreeBSD$ Cet article décrit les différentes manières pour une personne individuelle ou une organisation de collaborer au projet FreeBSD. &abstract.license; &abstract.disclaimer; &trans.a.fonvieille; Première version de &a.fr.dntt; Jordan Hubbard Contribution de &tm-attrib.freebsd; &tm-attrib.ieee; &tm-attrib.general; collaborer Alors, comme ça vous voulez collaborer à FreeBSD? C'est génial! FreeBSD s'appuie sur les contributions de sa base d'utilisateurs pour survivre. Vos contributions ne sont pas seulement appréciées, elles sont vitales pour la constante progression de FreeBSD. Contrairement à ce que certains pourraient vous faire croire, vous n'avez pas besoin d'être un expert programmeur ou un ami proche de l'équipe principale de FreeBSD pour avoir vos contributions acceptées. Un grand nombre, toujours en augmentation, de collaborateurs à travers le monde, dont les âges et l'expertise technique sont très variables, développent FreeBSD. Il y a toujours plus de travail à faire que de personnes disponibles pour s'en occuper, et davantage d'aide est toujours appréciée. Le projet FreeBSD est responsable de tout l'environnement du système d'exploitation, et pas seulement d'un noyau ou de quelques utilitaires éparpillés. Ainsi, nos listes TODO (à faire) s'étendent sur une large gamme de tâches: depuis la documentation, les béta-tests et la présentation, jusqu'à l'installateur système et des types de développement du noyau hautement spécialisés. Des personnes de n'importe quel niveau de compétence, dans presque tous les domaines, pourront sûrement aider le projet. Les entités commerciales engagées dans des entreprises relatives à FreeBSD sont également encouragées à nous contacter. Vous avez besoin d'une extension spéciale pour faire fonctionner votre produit? Vous nous trouverez réceptif à vos requêtes, du moment quelles ne sont pas trop exotiques. Vous travaillez sur un produit à valeur ajoutée? Faites-le nous savoir! Nous serons peut être en mesure de coopérer sur certains aspects. Le monde du logiciel libre va à l'encontre de nombreuses idées reçues sur la manière dont les logiciels sont développés, vendus, et maintenus, et nous vous invitons à lui donner au moins un second regard. Les besoins La liste suivante de tâches et de sous-projets représente une sorte d'amalgame des différentes listes TODO et des demandes d'utilisateurs. Tâches de non-programmeur De nombreuses personnes impliquées dans FreeBSD ne sont pas des programmeurs. Le projet comprend des rédacteurs de documentation, des concepteurs de site web, et des personnes assurant le support. La contribution de ces personnes se matérialise sous la forme d'un investissement en temps et une volonté d'apprendre. Lisez la FAQ et le Manuel régulièrement. Si quelque chose est mal expliquée, pas à jour ou tout simplement complètement faux, signalez-le nous. Mieux, envoyez nous un correctif (le SGML n'est pas difficile à apprendre, mais il n'y aucune objection à des soumissions en format ASCII). Aidez à traduire la documentation FreeBSD dans votre langue. Si la documentation existe déjà dans votre langue, vous pouvez aider à traduire des documents supplémentaires ou contrôler que les traductions sont à jour. Consultez tout d'abord la FAQ sur les traductions dans l'Introduction au Projet de Documentation de FreeBSD. Notez que vous ne vous engagez pas à traduire chacun des documents FreeBSD ce faisant — en tant que volontaire, vous pouvez faire autant que vous le désirez. Une fois que quelqu'un commence à traduire, presque toujours d'autres personnes rejoindront l'effort. Si vous n'avez le temps et l'énergie pour ne traduire qu'une partie de la documentation, traduisez les instructions d'installation. Lisez la &a.questions; et le &ng.misc; de temps en temps (ou même régulièrement). Il peut être très gratifiant de partager son expérience et d'aider les gens à résoudre leurs problèmes; parfois vous pourrez même apprendre quelque chose de nouveau! Ces forums peuvent être également une source d'idées sur ce qu'il faut améliorer. Tâches de programmeur La plupart des tâches listées ici nécessitent soit un investissement considérable en temps, soit une connaissance en profondeur du noyau, ou les deux. Cependant, il y a également de nombreuses tâches utiles pour les “programmeurs occasionnels”. Si vous utilisez FreeBSD-CURRENT et que vous avez une bonne connexion Internet, il existe une machine current.FreeBSD.org qui compile une version complète une fois par jour—à chaque fois, essayez d'installer la dernière version et rapportez toutes les erreurs durant le processus. Lisez la &a.bugs;. Il peut y avoir un problème que vous pouvez commenter de manière constructive ou avec des correctifs que vous pouvez tester. Ou vous pourrez même tenter de corriger un de ces problèmes vous-même. Si vous connaissez un correctif qui a été appliqué avec succès sur la branche -CURRENT mais qui n'a pas été intégré dans la branche -STABLE après un intervalle de temps raisonnable (normalement quelques semaines), envoyez au responsable un rappel poli. Déplacer des contributions logiciels vers src/contrib dans l'arborescence des sources. Assurez vous que le code dans src/contrib est à jour. Compiler l'arbre des sources (ou une partie) avec tous les messages d'avertissements activés et corriger les avertissements. Corriger les avertissements pour les logiciels portés qui font des choses obsolètes comme utiliser gets() ou inclure malloc.h. Si vous avez collaboré à un des logiciels portés, envoyez vos correctifs à leur auteur original (cela vous rendra la vie plus facile lors de la sortie de la prochaine version). Récupérer des copies de normes précises comme &posix;. Vous pouvez trouver des liens sur ces normes sur le site du Projet FreeBSD de conformité aux normes C99 et POSIX. Comparer le comportement de FreeBSD avec celui requis par la norme. Si le comportement diffère, en particulier pour des éléments subtiles et obscures de la spécification, envoyez un rapport de bogue à ce sujet. Si vous en êtes capable, déterminez comment le corriger et joignez un correctif à votre rapport de bogue. Si vous pensez que la norme est erronée, demandez à l'organisme de normalisation de considérer la question. Suggérer d'autres tâches pour cette liste! Travailler avec la base de données des rapports de bogue (PR) base de données des rapports de bogue La liste des PRs de FreeBSD donne tous les rapports de problème actuellement actifs et les demandes d'amélioration qui ont été soumis par les utilisateurs de FreeBSD. La base de données des PRs comprend des tâches de programmeurs et de non-programmeurs. Consultez les PRs ouverts, et voyez s'il y a quelque chose qui peut vous intéresser. Certaines de ces tâches peuvent être des tâches très simples qui ne nécessitent qu'une paire d'yeux supplémentaire pour vérifier et confirmer que le correctif dans le PR est correct. D'autres peuvent être bien plus complexes, ou pourront même ne pas inclure de correctif du tout. Commencez avec des PRs qui n'ont pas été assignés à quelqu'un d'autre. Si le PR est assigné à quelqu'un d'autre, mais qu'il semble que c'est quelque chose dont vous pouvez vous charger, envoyez un courrier électronique à la personne en question et demandez si vous pouvez travailler dessus—elle pourra déjà avoir un correctif prêt à être testé, ou des idées supplémentaires sur lesquelles vous pourrez discuter. Comment participer Les contributions au système tombent généralement dans une ou plusieurs des 5 catégories suivantes: Rapport de bogue et commentaires généraux Une idée ou une suggestion d'intérêt technique général devrait être envoyée à la &a.hackers;. De même, les personnes intéressées par de telles choses (et qu'un grand volume de courrier électronique ne dérange pas) devraient s'abonner à la &a.hackers; en envoyant un courrier électronique à &a.majordomo;. Voir le Manuel FreeBSD pour plus d'information à ce propos et sur les autres listes de diffusion. Si vous trouvez un bogue ou que vous soumettez une modification spécifique, rapportez-le en utilisant le programme &man.send-pr.1; ou son équivalent web. Essayez de remplir chaque champ du rapport de bogue. A moins qu'ils ne dépassent 65KO, inclure tous les correctifs directement dans le rapport. Si le correctif peut être appliqué directement sur l'arbre des sources ajoutez [PATCH] dans le synopsis du rapport. Quand vous ajoutez des correctifs, ne pas utiliser le copier-coller car ce dernier transforme les tabulations en espaces et rend les correctifs inutilisables. Pensez à compresser les correctifs et à utiliser &man.uuencode.1; s'ils dépassent 20KO. Après avoir rempli un rapport, vous devriez recevoir une confirmation accompagnée d'un numéro de suivi. Conservez ce numéro de suivi afin que vous puissiez nous soumettre plus de détails au sujet du problème en envoyant un courrier électronique à FreeBSD-gnats-submit@FreeBSD.ORG. Utilisez le numéro comme sujet du message, e.g. "Re: kern/3377". Toute information supplémentaire sur un rapport de bogue devrait être soumise de cette manière. Si vous ne recevez aucune confirmation dans un temps raisonnable (de 3 jours à une semaine, en fonction de votre connexion pour le courrier électronique) ou qu'il vous est, pour quelque raison que ce soit, impossible d'utiliser la commande &man.send-pr.1;, vous pouvez demander à quelqu'un de le faire pour vous en envoyant un courrier électronique à la &a.bugs;. Voir aussi cet article sur comment écrire de bon rapports de bogue. Modifications de la documentation soumissions concernant la documentation Les modifications de la documentation sont supervisées par la &a.doc;. Veuillez consulter l'Introduction au Projet de Documentation de FreeBSD pour des instructions complètes. Envoyez les soumissions et les modifications (même les plus petites sont les bienvenues!) en utilisant la commande send-pr comme décrit dans Rapport de bogue et commentaires généraux. Modifications dans le code source existant FreeBSD-CURRENT Un ajout ou une modification du code source existant est une toute autre affaire et dépend beaucoup de comment est à jour votre version par rapport à l'état courant du développement de FreeBSD. Il y a une version spéciale de FreeBSD, connue sous le nom de “FreeBSD-CURRENT” qui est disponible de diverses manières pour le confort des développeurs qui travaillent activement sur le système. Voir le Manuel FreeBSD pour plus d'informations sur la manière d'obtenir et d'utiliser FreeBSD-CURRENT. Travailler sur des sources plus anciennes signifie que malheureusement parfois vos modifications pourront être trop obsolètes ou trop divergentes pour permettre une réintégration aisée dans FreeBSD. On peut limiter ce type de changements en souscrivant à la &a.announce; et la &a.current;, où des discussions sur l'état courant du système ont lieu. En supposant que vous pouvez vous arranger pour avoir de manière sure des sources à jour comme base pour vos modifications, l'étape suivante est de produire un ensemble de diffs à envoyer à ceux qui sont chargés de maintenir FreeBSD. Cela est fait à l'aide de la commande &man.diff.1;. - Le format &man.diff.1; préferré pour + Le format &man.diff.1; préféré pour soumettre des correctifs est le format unifié généré par la commande diff -u. Cependant, pour des correctifs qui modifient sensiblement une partie du code, le format de contexte généré par diff -c peut s'avérer plus lisible et donc préférable. diff Par exemple: &prompt.user; diff -c oldfile newfile ou &prompt.user; diff -c -r olddir newdir générera un ensemble de “context diffs” pour un fichier source ou une hiérarchie de répertoires donnés. De même, &prompt.user; diff -u oldfile newfile ou &prompt.user; diff -u -r olddir newdir effectuera la même chose, mais dans le format unifié. Voir la page de manuel de &man.diff.1; pour plus de détails. Une fois que vous avez un ensemble de diffs (que vous pouvez tester avec la commande &man.patch.1;), vous devrez les soumettre pour qu'ils puissent être inclus dans FreeBSD. Utiliser le programme &man.send-pr.1; comme décrit dans Rapport de bogue et commentaires généraux. Ne pas simplement envoyez les diffs à la &a.hackers; ou ils seront perdus! Nous apprécions énormément votre soumission (c'est un projet fait par des volontaires!), mais parce que nous sommes très occupés, nous ne pourrons pas les étudier immédiatement, mais cela restera dans la base de données des PRs jusqu'à ce que nous le fassions. Identifiez votre soumission en ajoutant [PATCH] dans le synopsis du rapport. uuencode Si cela vous semble approprié (e.g. vous avez ajouté, effacé ou renommé des fichiers), archivez vos modifications dans un fichier tar et lancez le programme &man.uuencode.1; dessus. Les archives &man.shar.1; sont aussi les bienvenues. Si votre modification est de nature potentiellement sensible, e.g. si vous n'êtes pas sûr des problèmes de copyright concernant sa distribution ou que vous n'êtes tout simplement pas prêt à le distribuer sans relecture attentive, alors vous devriez l'envoyer directement à la &a.core; plutôt que de le soumettre avec &man.send-pr.1;. La liste de diffusion de l'équipe de base atteint un plus petit groupe de personnes qui réalise la plupart du travail quotidien de FreeBSD. Notez que ce groupe est aussi très occupé et donc que vous ne devriez leur envoyez de courrier électronique que lorsque cela est vraiment nécessaire. Veuillez vous référer à &man.intro.9; et &man.style.9; pour plus d'informations sur la manière de coder. Nous apprécierons le fait que vous soyez au moins conscient de ces problèmes avant de soumettre du code. Nouveau code source ou logiciel à valeur ajoutée importante Dans le cas d'une contribution importante, ou l'addition d'une importante fonctionnalité à FreeBSD, il devient presque nécessaire d'envoyer les modifications soit sous la forme d'archives tar uuencodées soit en les chargeant sur un site web ou FTP. Si vous n'avez pas accès à un site web ou FTP, demandez sur la liste de diffusion appropriée à ce que quelqu'un héberge ces modifications pour vous. Lorsque l'on travaille avec un grand volume de code, le sujet sensible des copyrights revient invariablement. Les copyrights acceptables pour le code inclus dans FreeBSD sont: copyright BSD Le copyright BSD. Ce copyright est le plus apprécié de par son côté “sans attaches” et très attractif pour les entreprises commerciales. Loin de décourager un usage commercial, le projet FreeBSD encourage activement une telle participation avec intérêts commerciaux pour ceux qui pourraient être tentés par la suite d'investir quelque chose dans FreeBSD. GPLLicence Publique Générale GNU Licence Publique Générale GNU La Licence Publique Générale GNU, ou “GPL”. Cette licence n'est pas aussi populaire chez nous à cause du volume d'efforts supplémentaires demandés à celui qui voudrait utiliser le code dans un but commercial, mais étant donné la quantité de code GPL dont nous avons actuellement besoin (compilateur, assembleur, formateur de texte, etc...) il serait absurde de refuser des contributions sous cette licence. Le code sous GPL va également dans une partie différente de l'arborescence, soit /sys/gnu soit/usr/src/gnu, et est de ce fait aisément identifiable par toute personne pour laquelle la licence GPL poserait un problème. Les contributions venant avec un autre type de copyright doivent être soigneusement vérifiées avant que leur intégration à FreeBSD ne soit prise en considération. Les contributions pour lesquelles des restrictions commerciales particulières s'appliquent sont généralement rejetées, bien que les auteurs sont toujours encouragés à rendre disponible de telles modifications par leurs propres moyens. Pour mettre un copyright de “style BSD” sur votre travail, inclure le texte suivant au tout début de chaque fichier de code source que vous voulez protéger, en remplaçant le texte entre les %% par l'information appropriée. Copyright (c) %%proper_years_here%% %%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ Pour votre convenance, une copie de ce texte peut être trouvée dans /usr/share/examples/etc/bsd-style-copyright. Contribution financière, matérielle ou accès Internet Nous sommes toujours très heureux d'accepter des donations pour poursuivre la cause du projet FreeBSD, et dans un effort volontaire comme le notre, un rien peut faire du chemin! Les donations de matériel sont également très importantes pour augmenter notre liste de périphériques supportés puisque nous manquons généralement de fonds pour acheter de tels éléments nous-mêmes. <anchor id="donations">Donation de fonds La Fondation FreeBSD est une fondation à but non lucratif et exempte d'impôts fondée pour servir les objectifs du projet FreeBSD. En tant qu'entitée 501(c)3, la Fondation est généralement exempte de l'impôt fédéral des Etats Unis comme de l'impôt de l'état du Colorado. Les dons à une entitée exempte d'impôts sont souvent déductibles de l'impôt fédéral. Les dons sous forme de chèques peuvent être adressés à:
The FreeBSD Foundation 7321 Brockway Dr. Boulder, CO 80303 USA
La Fondation FreeBSD est désormais en mesure d'accepter les donations par l'intermédiaire du service web PayPal. Pour faire un don, veuillez visiter le site web de la Fondation. Plus d'informations au sujet de la Fondation FreeBSD peuvent être trouvés dans La Fondation FreeBSD -- une introduction. Pour contacter la Fondation par courrier électronique, écrire à bod@FreeBSDFoundation.org. Contribution en matériel dons Le projet FreeBSD accepte avec joie les donations de - matériel. Si vous êtes interessés pour nous faire un don de - matériel, contactez le Bureau de liaison des donations. Contribution d'accès Internet Nous pouvons toujours utiliser de nouveau sites miroirs pour les site FTP, WWW ou cvsup. Si vous voulez devenir un tel miroir, voyez le document devenir un site mirroir FreeBSD pour plus d'informations.