2. Comment participer

2.1. 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 liste de diffusion pour les discussions techniques sur FreeBSD. 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 liste de diffusion pour les discussions techniques sur FreeBSD en envoyant un courrier électronique à <majordomo@FreeBSD.org>. 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 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 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 send-pr(1), vous pouvez demander à quelqu'un de le faire pour vous en envoyant un courrier électronique à la liste de diffusion des rapports de bogue de FreeBSD.

Voir aussi cet article sur comment écrire de bon rapports de bogue.

2.2. Modifications de la documentation

Les modifications de la documentation sont supervisées par la liste de diffusion du groupe de documentation de FreeBSD. 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.

2.3. Modifications dans le code source existant

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 liste de diffusion pour les annonces relatives à FreeBSD et la liste de diffusion à propos de la branche FreeBSD-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 diff(1).

Le format diff(1) préferré 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.

Par exemple:

% diff -c oldfile newfile

ou

% 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,

% diff -u oldfile newfile

ou

% diff -u -r olddir newdir

effectuera la même chose, mais dans le format unifié.

Voir la page de manuel de diff(1) pour plus de détails.

Une fois que vous avez un ensemble de diffs (que vous pouvez tester avec la commande patch(1)), vous devrez les soumettre pour qu'ils puissent être inclus dans FreeBSD. Utiliser le programme send-pr(1) comme décrit dans Rapport de bogue et commentaires généraux. Ne pas simplement envoyez les diffs à la liste de diffusion pour les discussions techniques sur FreeBSD 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.

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 uuencode(1) dessus. Les archives 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 liste de diffusion de l'équipe de base de FreeBSD plutôt que de le soumettre avec 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 à intro(9) et 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.

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

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

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

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