HOWTO sur la publication de logiciels

HOWTO sur la publication de logiciels
Eric S. Raymond <[email protected]> Traduction par Thierry
B�zecourt <[email protected]>
2.0, 18 septembre 1999

Ce HOWTO d�crit des m�thodes de publication de logiciel convenant �
des projets de logiciel libre pour Linux. En adoptant ces r�gles, vous
permettrez � vos utilisateurs de compiler votre code et de l'utiliser
plus facilement, et � d'autres d�veloppeurs de mieux le comprendre et
de vous aider � l'am�liorer. Ce document est � lire absolument par
les d�veloppeurs d�butants. Ceux qui ont plus d'exp�rience devraient
le parcourir � nouveau au moment de publier un nouveau projet. Il sera
mis � jour p�riodiquement afin de refl�ter l'�volution des r�gles de
bonne pratique.
______________________________________________________________________

Table des mati�res

1. Introduction

1.1 Raison d'�tre de ce document
1.2 Nouvelles versions de ce document

2. R�gles d'usage pour le nommage de votre projet et de votre archive

2.1 Utilisez le style de nommage GNU, avec un pr�fixe suivi d'un num�rotage du type majeur.mineur.patch.
2.2 Mais respectez le cas �ch�ant les conventions locales
2.3 Choisissez avec le plus grand soin un pr�fixe unique et facile � taper

3. R�gles d'usage pour la licence et le copyright : la th�orie

3.1 Les logiciels � code ouvert et le copyright
3.2 D�terminer ce qui peut �tre qualifi� comme logiciel � code ouvert

4. R�gles d'usage pour la licence et le copyright : la pratique

4.1 Donnez le copyright � vous-m�me ou � la FSF
4.2 Choisissez une licence conforme � l'Open Source Definition
4.3 N'�crivez pas votre propre licence si vous pouvez l'�viter.

5. R�gles d'usage du d�veloppement

5.1 Ecrivez soit en C ANSI pur, soit dans un langage de script portable
5.2 Respectez les r�gles de portabilit� du C
5.3 Utilisez autoconf/automaker/autoheader
5.4 Soignez la rigueur de votre code avant chaque nouvelle version

6. R�gles d'usage pour la mise au point de la distribution

6.1 Assurez-vous que vos archives se d�compactent toujours dans un r�pertoire nouveau et unique.
6.2 Ecrivez un README
6.3 Adoptez les conventions courantes de nommage des fichiers
6.4 Fournissez des RPM

7. Comment communiquer

7.1 Faites une annonce dans c.o.l.a
7.2 Faites une annonce dans un forum de discussion ad�quat
7.3 Ayez un site Web
7.4 H�bergez des listes de diffusion pour votre projet
7.5 Publiez dans les archives les plus importantes

8. La bonne gestion d'un projet

______________________________________________________________________

11.. IInnttrroodduuccttiioonn

11..11.. RRaaiissoonn dd''��ttrree ddee ccee ddooccuummeenntt

Un vaste ensemble de traditions relatives au d�veloppement de
logiciels libres permet � d'autres personnes de porter le code plus
facilement, de l'utiliser et de participer � son d�veloppement.
Certaines de ces conventions sont des traditions du monde Unix
ant�rieures � Linux ; d'autres ont �t� suscit�es r�cemment par
l'apparition de nouveaux outils et de nouvelles technologies comme le
World Wide Web.

Ce document vous aidera � acqu�rir ces r�gles d'usage. Il se compose
de plusieurs sections th�matiques, chacune contenant une liste de
points � v�rifier. Consid�rez que ces sections sont pour votre
distribution comme la liste de contr�le qu'un pilote d'avion v�rifie
avant le d�collage.

11..22.. NNoouuvveelllleess vveerrssiioonnss ddee ccee ddooccuummeenntt

Ce document sera envoy� chaque mois dans le forum de discussion
comp.os.linux.answers . Ce document est archiv� sur plusieurs sites
FTP Linux, dont metalab.unc.edu dans le r�pertoire
pub/Linux/docs/HOWTO.

Vous pouvez aussi voir la derni�re version, en anglais, de ce HOWTO
sur le World Wide Web � l'URL
<http://metalab.unc.edu/LDP/HOWTO/Software-Release-Practice.html>. La
version fran�aise est disponible � l'adresse
<http://metalab.unc.edu/pub/Linux/docs/HOWTO/translations/fr>.

Vous pouvez envoyer vos questions et vos commentaires sur ce HOWTO �
Eric S. Raymond, [email protected] <mailto:[email protected]>.

22.. RR��gglleess dd''uussaaggee ppoouurr llee nnoommmmaaggee ddee vvoottrree pprroojjeett eett ddee vvoottrree aarrcchhiivvee

Au fur et � mesure que s'accro�t la charge de travail des
gestionnaires d'archives comme Metalab, le site PSA ou le CPAN, les
soumissions sont de plus en plus souvent trait�es, en tout ou en
partie, par des programmes (et non en totalit� par des humains).

Il est donc tr�s important que le nom de votre projet et celui de
votre fichier d'archive suivent des r�gles pr�cises, afin que des
programmes informatiques puissent les analyser et les comprendre.

22..11.. nnuumm��rroottaaggee dduu ttyyppee mmaajjeeuurr..mmiinneeuurr..ppaattcchh.. UUttiilliisseezz llee ssttyyllee ddee
nnoommmmaaggee GGNNUU,, aavveecc uunn pprr��ffiixxee ssuuiivvii dd''uunn

Vous faciliterez la vie � tout le monde en donnant � vos archives des
noms dans le style GNU : un pr�fixe-racine alphanum�rique tout en
minuscules, suivi par un tiret, puis un num�ro de version, une
extension et d'autres suffixes.

Supposons que vous ayez un projet nomm� "toto", qui en est � la
version 1, mise � jour 2, niveau 3. S'il est compos� d'une seule
archive (sans doute le code source), voici � quoi devrait ressembler
son nom :

ttoottoo--11..22..33..ttaarr..ggzz
L'archive des sources

ttoottoo..llssmm
Le fichier LSM (si vous l'envoyez � Metalab).

N'utilisez _p_a_s les noms suivants :

ttoottoo112233..ttaarr..ggzz
Beaucoup de programmes croiront qu'il s'agit du fichier
d'archive d'un projet nomm� `toto123', sans num�ro de version.

ttoottoo11..22..33..ttaarr..ggzz
Beaucoup de programmes croiront qu'il s'agit de l'archive d'un
projet nomm� `toto1' � la version 2.3.

ttoottoo--vv11..22..33..ttaarr..ggzz
Beaucoup de programmes prendront cela pour un projet nomm�
`toto-v1'.

ttoo__ttoo--11..22..33..ttaarr..ggzz
Le caract�re soulign� est difficile � prononcer, � taper, et �
retenir.

TTooTToo--11..22..33..ttaarr..ggzz
A moins que vous vouliez _v_r_a_i_m_e_n_t ressembler � un accroc du
marketing. L� encore, c'est difficile � prononcer, � taper et �
retenir.

Si vous voulez faire s�par�ment une archive de sources et une archive
de binaires, ou diff�rentes archives de binaires, ou encore indiquer
un certain type d'option de compilation dans le nom de l'archive,
rajoutez pour cela une extension _a_p_r_�_s le num�ro de version. Voici
quelques exemples :

ttoottoo--11..22..33..ssrrcc..ttaarr..ggzz
sources

ttoottoo--11..22..33..bbiinn..ttaarr..ggzz
binaires, type non sp�cifi�

ttoottoo--11..22..33..bbiinn..EELLFF..ttaarr..ggzz
binaires ELF

ttoottoo--11..22..33..bbiinn..EELLFF..ssttaattiicc..ttaarr..ggzz
binaires ELF li�s statiquement

ttoottoo--11..22..33..bbiinn..SSPPAARRCC..ttaarr..ggzz
binaires pour SPARC

N'utilisez _p_a_s des noms comme `toto-ELF.1.2.3.tar.gz', car les
programmes ont beaucoup de mal � s�parer un infixe (tel que `ELF') de
la racine du mot.

Un bon sch�ma de nommage g�n�rique contient, dans l'ordre, les parties
suivantes :

1. pr�fixe du projet

2. tiret

3. num�ro de version

4. point

5. "src" ou "bin" (optionnel)

6. point ou tiret (un point de pr�f�rence)

7. type de binaire et options (optionnel)

8. extensions relatives au mode d'archivage et de compression

22..22.. MMaaiiss rreessppeecctteezz llee ccaass ��cchh��aanntt lleess ccoonnvveennttiioonnss llooccaalleess

Certains projets ou communaut�s ont des conventions bien �tablies pour
les noms et les num�ros de version, et ces conventions ne sont pas
toujours compatibles avec les conseils qui pr�c�dent. Par exemple, les
modules Apache ont en g�n�ral des noms du genre mod_foo, et ils ont �
la fois un num�ro de version propre et le num�ro de la version
d'Apache avec laquelle ils fonctionnent. De m�me, les num�ros de
version des modules Perl peuvent �tre trait�s comme des nombres
d�cimaux (par exemple, vous pouvez voir 1,303 � la place de 1.3.3), et
les distributions s'appellent en g�n�ral Foo-Bar-1.303.tar.gz pour la
version 1.303 du module Foo::Bar.

Apprenez et respectez les conventions des communaut�s et d�veloppeurs
sp�cialis�s ; suivez les r�gles ci-dessus dans le cas g�n�ral.

22..33.. ttaappeerr CChhooiissiisssseezz aavveecc llee pplluuss ggrraanndd ssooiinn uunn pprr��ffiixxee uunniiqquuee eett
ffaacciillee ��

Le pr�fixe-racine devrait �tre le m�me pour tous les fichiers d'un
projet, et il devrait �tre facile � lire, � taper et � retenir.
N'utilisez pas le caract�re "soulign�". Et ne mettez pas de majuscules
ou de MajusculesInt�rieures sans une tr�s bonne raison -- cela d�range
le trajet naturel de l'oeil humain, et vous aurez l'air de faire du
marketing.

C'est difficile de s'y retrouver lorsque deux projets ont le m�me nom.
Assurez-vous donc, dans la mesure du possible, qu'il n'y a pas de
conflit de nommage avant de publier votre premi�re version. Un bon
endroit pour le v�rifier est l'index de Metalab
<http://metalab.unc.edu/pub/Linux>.

33.. RR��gglleess dd''uussaaggee ppoouurr llaa lliicceennccee eett llee ccooppyyrriigghhtt :: llaa tthh��oorriiee

La licence que vous choisissez d�finit le contrat social que vous
souhaitez mettre en place avec vos co-d�veloppeurs et vos
utilisateurs. Le copyright que vous mettez sur le logiciel sert
principalement de d�claration l�gale de votre droit � fixer les termes
de la licence sur le logiciel et sur les oeuvres qui en sont d�riv�es.

33..11.. LLeess llooggiicciieellss �� ccooddee oouuvveerrtt eett llee ccooppyyrriigghhtt

(Note du traducteur : dans cette section comme dans celles qui
suivent, l'expression "(logiciel �) code ouvert" est utilis�e pour
traduire l'anglais "open source", tandis que l'expression habituelle
"logiciel libre" sert � transcrire "free software")

Tout ce qui n'appartient pas au domaine public poss�de un copyright,
voire plusieurs. Selon la Convention de Berne (qui a force de loi aux
Etats-Unis depuis 1978), le copyright n'a pas besoin d'�tre explicite.
C'est-�-dire que les auteurs d'une oeuvre sont d�tenteurs du copyright
m�me s'il n'y a pas de note de copyright.

Il peut �tre tr�s difficile de d�terminer qui peut �tre compt� comme
un auteur, surtout lorsque de nombreuses mains ont travaill� sur le
logiciel. C'est ce qui fait l'importance des licences. En pr�cisant
les conditions dans lesquelles l'oeuvre peut �tre utilis�e, elles
donnent aux utilisateurs des droits qui les prot�gent des actions
arbitraires que pourraient entreprendre les d�tenteurs du copyright.

Dans le logiciel propri�taire, les termes de la licence sont formul�s
de mani�re � prot�ger le copyright. Ils permettent de donner quelques
droits aux utilisateurs tout en assurant au propri�taire (le d�tenteur
du copyright) la plus grande possibilit� d'action possible sur le plan
l�gal. Le d�tenteur du copyright a une grande importance, et la
licence est tellement restrictive dans l'esprit que les d�tails
techniques de ses termes sont g�n�ralement sans importance.

Dans le logiciel � code ouvert, la situation est souvent exactement
inverse ; le copyright existe pour prot�ger la licence. Les seuls
droits qui sont toujours conserv�s au d�tenteur du copyright sont ceux
qui permettent de renforcer la licence. Parmi les autres droits, un
petit nombre seulement sont r�serv�s, et c'est l'utilisateur qui a la
plus grande libert�. En particulier, le d�tenteur du copyright ne peut
pas modifier la licence sur une copie que vous poss�dez d�j�. Par
cons�quent, le d�tenteur du copyright dans les logiciels � code ouvert
n'a presque aucune importance -- contrairement aux termes de la
licence.

Normalement, le d�tenteur du copyright sur un projet est le
responsable actuel du projet ou une organisation m�c�ne. Le changement
de responsable � la t�te d'un projet se manifeste souvent par la
modification du copyright. Toutefois ce n'est pas une r�gle absolue ;
dans de nombreux projets � code source ouvert, le copyright revient �
de multiples personnes, et il n'y a pas de cas connu o� cela ait
entra�n� des complications sur le plan l�gal.

Certains projets choisissent de donner le copyright � la Free Software
Foundation, avec l'id�e que cette fondation a un int�r�t dans la
d�fense du logiciel � code ouvert, et poss�de les avocats pour s'en
occuper.

33..22.. oouuvveerrtt DD��tteerrmmiinneerr ccee qquuii ppeeuutt ��ttrree qquuaalliiffii�� ccoommmmee llooggiicciieell ��
ccooddee

En ce qui concerne la licence, on peut distinguer plusieurs sortes de
droits transf�rables via une licence. Les droits de _c_o_p_i_e _e_t
_r_e_d_i_s_t_r_i_b_u_t_i_o_n, les droits d'_u_t_i_l_i_s_a_t_i_o_n, les droits de _m_o_d_i_f_i_c_a_t_i_o_n _�
_u_s_a_g_e _p_e_r_s_o_n_n_e_l et les droits de _r_e_d_i_s_t_r_i_b_u_t_i_o_n _d_e _c_o_p_i_e_s _m_o_d_i_f_i_�_e_s.
Une licence peut restreindre chacun de ces droits ou les accompagner
de conditions.

L'Open Source Initiative <http://www.opensource.org> est le r�sultat
d'un important effort de r�flexion sur ce qui fait un ``logiciel �
code ouvert'' ou (dans une terminologie plus ancienne) un ``logiciel
libre''. L'association place les contraintes suivantes sur les
licences :

1. Un droit de copie illimit� doit �tre accord�.

2. Un droit d'utilisation illimit� doit �tre accord�.

3. Un droit de modication illimit� pour utilisation personnelle doit
�tre accord�.

Ces r�gles proscrivent les restrictions sur la redistribution de
binaires modifi�s ; cela correspond aux besoins des distributeurs de
logiciels, � qui il faut pouvoir livrer sans entraves du code en �tat
de marche. Cela permet aux auteurs de demander que le code source
modifi� soit redistribu� sous la forme du code source original plus
des patchs, ce qui fait appara�tre les intentions de l'auteur et, dans
un``suivi d'audit'', toutes les modifications faites par d'autres
personnes.

L'OSD est la d�finition l�gale de la marque de certification `OSI
Certified Open Source', et vaut toutes les d�finitions qu'on a pu
faire du ``logiciel libre''. Toutes les licences courantes (MIT, BSD,
Artistic et GPL/LGPL) la v�rifient (encore que certaines, comme la
GPL, ajoutent d'autres restrictions que vous devriez comprendre avant
de les adopter).

Notez que les licences n'autorisant qu'un usage non commercial ne
peuvent _p_a_s �tre qualifi�es de licences � code ouvert, m�me si elles
affichent la licence ``GPL'' ou quelque autre licence courante. Elles
font de la discrimination envers des occupations, des personnes et des
groupes particuliers. Elles rendent la vie trop compliqu�e aux
distributeurs de CD-ROM et aux autres personnes qui essaient de
diffuser commercialement les logiciels � code ouvert.

44.. RR��gglleess dd''uussaaggee ppoouurr llaa lliicceennccee eett llee ccooppyyrriigghhtt :: llaa pprraattiiqquuee

Voici comment appliquer dans la pratique la th�orie qui pr�c�de :

44..11.. DDoonnnneezz llee ccooppyyrriigghhtt �� vvoouuss--mm��mmee oouu �� llaa FFSSFF

Dans certains cas, si vous avez derri�re vous une organisation m�c�ne
qui poss�de des avocats, vous pouvez choisir de donner le copyright �
cette organisation.

44..22.. CChhooiissiisssseezz uunnee lliicceennccee ccoonnffoorrmmee �� ll''OOppeenn SSoouurrccee DDeeffiinniittiioonn

L'Open Source Definition (D�finition du Code Ouvert) est la r�gle d'or
pour les licences. L'OSD n'est pas une licence en soi ; elle d�finit
plut�t un ensemble minimal de droits qu'une licence doit garantir afin
d'�tre consid�r�e comme une licence � code ouvert. On peut trouver
L'OSD, avec des documents compl�mentaires, sur le site Web de l'Open
Source Initiative <http://www.opensource.org>.

44..33.. NN''��ccrriivveezz ppaass vvoottrree pprroopprree lliicceennccee ssii vvoouuss ppoouuvveezz ll''��vviitteerr..

Les licences compatibles � l'OSD et connues de tous ont des traditions
d'interpr�tation bien �tablies. Les d�veloppeurs (et, dans la mesure
o� ils s'y int�ressent, les utilisateurs) savent ce qui en d�coule, et
mesurent les risques et les inconv�nients qu'elles comportent. Par
cons�quent, utilisez si possible l'une des licences standards sur le
site OSI.

Si vous devez �crire votre propre licence, prenez soin de la faire
certifier par l'OSI. Cela vous �pargnera de nombreuses discussions et
des co�ts importants. Si vous n'�tes jamais pass� par l�, vous ne
pouvez pas imaginer pas � quel point un d�bat sur les licences peut
tourner au vinaigre ; les gens s'enflamment, parce que les licences
sont consid�r�es comme des pactes presque sacr�s qui touchent aux
valeurs essentielles de la communaut� des logiciels ouverts.

De plus, l'existence d'une tradition d'interpr�tation bien �tablie
pourrait se r�v�ler importante si un jour votre licence faisait
l'objet d'un proc�s. A la date o� on �crit ces lignes (septembre
1999), il n'y a pas d'exemple de d�cision judiciaire qui ait confirm�
ou invalid� une licence de logiciel � code ouvert. Toutefois, c'est un
principe de droit (au moins aux Etats-Unis, et sans doute dans
d'autres pays de droit coutumier comme l'Angleterre et le reste du
Commonwealth) que les cours de justice doivent interpr�ter les
licences et les contrats en fonction des attentes et des pratiques de
la communaut� qui les a produits.

55.. RR��gglleess dd''uussaaggee dduu dd��vveellooppppeemmeenntt

La plupart de ces r�gles visent � assurer la portabilit�, non
seulement entre les diff�rentes distributions de Linux, mais aussi
avec d'autres vari�t�s d'Unix. La portabilit� vers Unix n'est pas
seulement une question de professionnalisme ou de savoir-vivre entre
programmeurs, c'est aussi une assurance non n�gligeable contre les
�volutions futures de Linux lui-m�me.

D'autres personnes finiront par essayer de compiler votre code dans
d'autres environnements que Linux ; avec la portabilit�, vous recevrez
moins de messages ennuyeux de la part d'utilisateurs perplexes.

55..11.. EEccrriivveezz ssooiitt eenn CC AANNSSII ppuurr,, ssooiitt ddaannss uunn llaannggaaggee ddee ssccrriipptt
ppoorrttaabbllee

Pour des raisons de portabilit� et de stabilit�, il est fortement
recommand� d'�crire soit en C ANSI pur, soit dans un langage de script
dont la portabilit� soit garantie par une impl�mentation multi-
plateforme unique.

Parmi les langages de script, Python, Perl, Tcl et Emacs Lisp
respectent ce crit�re. Le bon vieux shell _n_e _c_o_n_v_i_e_n_t _p_a_s ; il existe
trop d'impl�mentations diff�rentes, chacune ayant des particularit�s
subtiles, et l'environnement du shell est souvent transform� de
mani�re impr�visible par des configurations propres � chaque
utilisateur, comme les alias.

Java promet beaucoup sur le plan de la portabilit�, mais les
impl�mentations disponibles sur Linux sont encore sommaires et mal
int�gr�es dans le syst�me d'exploitation. Java est encore un choix
exotique, bien qu'il ait de fortes chances de gagner en popularit�
lorsqu'il aura plus de maturit�.

55..22.. RReessppeecctteezz lleess rr��gglleess ddee ppoorrttaabbiilliitt�� dduu CC

Si vous �crivez en C, n'h�sitez pas � utiliser � fond les
fonctionnalit�s d�crites dans la norme ANSI -- y compris les
prototypes de fonction, qui vous aideront � rep�rer les incoh�rences
entre modules. Les compilateurs du type K&R rel�vent du pass�.
En revanche, ne supposez _p_a_s que certaines caract�ristiques
sp�cifiques � GCC comme l'option `-pipe' ou les fonctions imbriqu�es
sont disponibles. Cela vous poursuivra et vous vous en repentirez le
jour o� quelqu'un portera votre logiciel vers un syst�me autre que
Linux, et d�pourvu de GCC.

55..33.. UUttiilliisseezz aauuttooccoonnff//aauuttoommaakkeerr//aauuttoohheeaaddeerr

Si vous �crivez en C, utilisez autoconf/automaker/autoheader pour
assurer la portabilit�, v�rifier la configuration du syst�me et
affiner vos makefiles. De nos jours, les gens qui compilent � partir
des sources s'attendent � devoir juste taper "configure; make" et que
tout se compile proprement - sans la moindre erreur.

55..44.. SSooiiggnneezz llaa rriigguueeuurr ddee vvoottrree ccooddee aavvaanntt cchhaaqquuee nnoouuvveellllee vveerrssiioonn

Si vous �crivez en C, faites une compilation de test avec l'option
-Wall et corrigez les erreurs r�sultantes, au moins une fois avant
chaque nouvelle version. On trouve comme cela un nombre surprenant
d'erreurs. Pour �tre vraiment complet, compilez aussi avec l'option
-pedantic.

Si vous �crivez en Perl, v�rifiez votre code avec perl -c (voire -T
dans les cas ad�quats). Utilisez perl -w 'use strict' religieusement
(consultez la documentation de Perl pour plus d'informations).

66.. RR��gglleess dd''uussaaggee ppoouurr llaa mmiissee aauu ppooiinntt ddee llaa ddiissttrriibbuuttiioonn

Les indications qui suivent montrent � quoi votre distribution devrait
ressembler lorsqu'on la r�cup�re et qu'on la d�compacte.

66..11.. rr��ppeerrttooiirree nnoouuvveeaauu eett uunniiqquuee.. AAssssuurreezz--vvoouuss qquuee vvooss aarrcchhiivveess ssee
dd��ccoommppaacctteenntt ttoouujjoouurrss ddaannss uunn

L'erreur la plus aga�ante que font les d�veloppeurs novices est de
fabriquer des archives qui d�compactent les fichiers et r�pertoires de
la distribution dans le r�pertoire courant, avec le risque d'�craser
des fichiers d�j� pr�sents. _N_e _f_a_i_t_e_s _j_a_m_a_i_s _c_e_l_a _!

A la place, faites en sorte que les fichiers de vos archives partagent
le m�me r�pertoire, avec un nom d�rivant de celui du projet. Ainsi,
ils se placeront dans un seul r�pertoire, juste _e_n_-_d_e_s_s_o_u_s du
r�pertoire courant.

Voici un moyen de r�aliser cela dans un makefile, en supposant que le
r�pertoire de votre distribution est `toto' et que SRC est une
variable contenant la liste des fichiers de votre distribution. Vous
devez avoir GNU tar 1.13.

VERS=1.0
toto-$(VERS).tar.gz:
tar --name-prefix='toto-$(VERS)/' -czf toto-$(VERS).tar.gz $(SRC)

Si votre version de tar est plus ancienne, faites quelque chose dans
ce genre :

toto-$(VERS).tar.gz:
@ls $(SRC) | sed s:^:toto-$(VERS)/: >MANIFEST
@(cd ..; ln -s toto toto-$(VERS))
(cd ..; tar -czvf toto/toto-$(VERS).tar.gz `cat toto/MANIFEST`)
@(cd ..; rm toto-$(VERS))

66..22.. EEccrriivveezz uunn RREEAADDMMEE

Fournissez un fichier nomm� README ou READ.ME, qui donne une vision
d'ensemble de votre distribution. C'est une vieille convention, et
c'est le premier fichier que l'intr�pide explorateur lira apr�s avoir
extrait les sources (Note du traducteur : le fichier README, comme son
nom l'indique, est �crit en anglais afin d'�tre lisible par le plus
grand nombre de personnes possible. Vous pouvez aussi, si vous le
jugez utile, fournir une traduction fran�aise dans un fichier nomm�
LISEZMOI, pour les utilisateurs francophones).

Voici quelques �l�ments qu'il est bon d'avoir dans un README :

� Une br�ve description du projet.

� Un lien vers le site Web du projet, le cas �ch�ant.

� Des indications sur l'environnement de compilation du d�veloppeur
et sur les possibles probl�mes de portabilit�.

� Un plan d'ensemble des fichiers et sous-r�pertoires importants.

� Les instructions de compilation et d'installation, ou bien un lien
vers le fichier les contenant (habituellement INSTALL).

� Le nom des responsables et des contributeurs, ou un lien vers le
fichier contenant ces noms (habituellement CREDITS).

� Les derni�res nouvelles relatives au projet, ou un lien vers un
fichier les contenant (habituellement NEWS).

66..33.. AAddoopptteezz lleess ccoonnvveennttiioonnss ccoouurraanntteess ddee nnoommmmaaggee ddeess ffiicchhiieerrss

Avant m�me d'avoir regard� le README, votre intr�pide explorateur aura
parcouru la liste des fichiers dans r�pertoire principal de votre
distribution. Ces noms, par eux-m�mes, contiennent de l'information.
En suivant certaines r�gles de nommage, vous donnerez � l'explorateur
de bons indices pour orienter son parcours.

Voici quelques noms recommand�s pour les fichiers du r�pertoire
principal, avec leur signification. Tous ne sont pas indispensables
dans chaque projet.

RREEAADDMMEE oouu RREEAADD..MMEE
le plan d'ensemble, � lire en premier

IINNSSTTAALLLL
instructions de configuration, de compilation et d'installation

CCRREEDDIITTSS
liste des contributeurs du projet

NNEEWWSS
derni�res nouvelles

HHIISSTTOORRYY
histoire du projet

CCOOPPYYIINNGG
termes de la licence (convention GNU)

LLIICCEENNSSEE
termes de la licence

MMAANNIIFFEESSTT
liste des fichiers

FFAAQQ
Foire Aux Questions pour le projet, au format texte.

TTAAGGSS
Fichier de tags g�n�r� automatiquement, pour �tre utilis� par
Emacs ou vi

Remarquez que la convention g�n�rale est que les fichiers dont le nom
ne comporte que des majuscules sont des fichiers d'information sur le
projet lui-m�me, et ne sont pas des �l�ments du syst�me � compiler.

66..44.. FFoouurrnniisssseezz ddeess RRPPMM

Le format standard de facto pour les distributions de binaires �
installer est celui qu'utilise le Red Hat Package Manager, RPM. Il est
pr�sent dans les distributions Linux les plus populaires, et il est
support� en pratique par toutes les autres (sauf Debian et Slackware ;
et Debian peut faire des installations � partir de RPM).

Par cons�quent, c'est une bonne id�e de fournir sur le site de votre
projet des RPM installables en m�me temps qu'une archive des sources.

C'est aussi une bonne id�e d'inclure dans votre archive de sources le
fichier de sp�cification du RPM, avec dans le Makefile une entr�e qui
fabrique les RPM � partir de lui. Le fichier de sp�cification devrait
avoir l'extension `.spec' ; c'est comme cela que l'option -t de rpm le
trouve � l'int�rieur de l'archive.

Encore un point de style : g�n�rez votre fichier de sp�cification avec
un script shell qui ins�re automatiquement le num�ro de version en
analysant le Makefile ou un fichier version.h.

77.. CCoommmmeenntt ccoommmmuunniiqquueerr

Votre logiciel n'apportera pas grand-chose � l'univers si vous �tes le
seul � conna�tre son existence. De plus, en �tablissant une pr�sence
visible sur Internet pour votre projet, vous pourrez recruter plus
facilement des utilisateurs et des co-d�veloppeurs. On le fait
habituellement comme ceci :

77..11.. FFaaiitteess uunnee aannnnoonnccee ddaannss cc..oo..ll..aa

Annoncez vos nouvelles versions dans comp.os.linux.announce
<news:comp.os.linux.announce>. Non seulement ce forum est lu par un
grand nombre de personnes, mais c'est aussi un fournisseur important
pour des sites Web d'information comme Freshmeat
<http://www.freshmeat.net>.

77..22.. FFaaiitteess uunnee aannnnoonnccee ddaannss uunn ffoorruumm ddee ddiissccuussssiioonn aadd��qquuaatt

Trouvez un forum USENET dont le th�me de discussion est directement
concern� par votre application, et faites-y aussi votre annonce.
N'envoyez votre message qu'aux endroits o� la _f_o_n_c_t_i_o_n remplie par
votre logiciel est pertinente, et restez mesur�.

Si (par exemple) vous publiez un programme en Perl qui interroge des
serveurs IMAP, vous devriez probablement envoyer un message dans
comp.mail.imap. Mais s�rement pas dans comp.lang.perl, � moins que le
programme utilise de mani�re instructive des techniques Perl avanc�es.

Votre annonce devrait aussi contenir l'URL du site Web de votre
projet.

77..33.. AAyyeezz uunn ssiittee WWeebb

Si vous comptez �tablir une communaut� substantielle d'utilisateurs ou
de d�veloppeurs autour de votre projet, celui-ci devrait avoir son
site Web. Voici des �l�ments que l'on trouve habituellement sur un
site Web :

� La charte du projet (pourquoi il existe, quelle est son audience,
etc).

� Des liens pour le t�l�chargement des sources.

� Des instructions relatives � l'inscription � la ou les liste(s) de
diffusion.

� Une FAQ (Foire Aux Questions).

� Une version en HTML de la documentation.

� Des liens vers des projets proches et/ou concurrents.

Certains projets ont m�me une URL pour un acc�s anonyme �
l'arborescence principale du code source.

77..44.. HH��bbeerrggeezz ddeess lliisstteess ddee ddiiffffuussiioonn ppoouurr vvoottrree pprroojjeett

Il est d'usage d'avoir une liste de d�veloppement priv�e qui permet
aux collaborateurs du projet de communiquer et d'�changer des patchs.
Vous voudrez peut-�tre cr�er en plus une liste d'annonces pour les
gens qui veulent �tre inform�s de la progression du projet.

77..55.. PPuubblliieezz ddaannss lleess aarrcchhiivveess lleess pplluuss iimmppoorrttaanntteess

Depuis plusieurs ann�es, le site Metalab
<http://www.metalab/unc.edu/pub/Linux/> est le plus important des
endroits d'�change de logiciels pour Linux.

Voici quelques autres sites notables :

� le site Python Software Activity <http://www.python.org>
(pour les logiciels �crits en Python).

� le CPAN <http://language.perl.com/CPAN> ou R�seau d'Archives Perl
Global (pour les logiciels �crits en Perl).

88.. LLaa bboonnnnee ggeessttiioonn dd''uunn pprroojjeett

Bien g�rer un projet lorsque tous les participants sont b�n�voles
pr�sente des d�fis particuliers. Le sujet est trop large pour �tre
trait� dans le cadre d'un HOWTO. Heureusement, il existe des documents
de r�flexion qui vous aideront � comprendre les principaux points.

Pour un essai sur l'organisation de base du d�veloppement et du
principe `distribuez t�t, mettez � jour souvent' propre au `mode
bazar', lisez The Cathedral and the Bazaar
<http://www.tuxedo.org/~esr/writings/cathedral-bazaar/>.

Pour une r�flexion sur les motivations psychologiques, des coutumes de
la communaut� et de la r�solution des conflits, lisez Homesteading the
Noosphere <http://www.tuxedo.org/~esr/writings/homesteading/>.

Pour un expos� des principes �conomiques et des mod�les commerciaux �
adopter, lisez The Magic Cauldron
<http://www.tuxedo.org/~esr/writings/magic-cauldron/>.

Si vous �tes allergique � la langue de Shakespeare, vous pourrez
trouver des traductions de ces documents sur le site Linux France
<http://www.linux-france.org/article/these/>.

Ces papiers ne pr�tendent pas se poser comme les r�f�rences ultimes �
propos des d�veloppements � code source ouvert. Mais ils constituent
les premi�res analyses s�rieuses �crites sur le sujet, et n'ont pas
encore �t� d�pass�s.