HOWTO sur la publication de logiciels
Eric S. Raymond <
[email protected]> Traduction par Thierry
B�zecourt <
[email protected]>
2.4, 12 juillet 2000
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
1.3 Note du traducteur sur l'usage de l'anglais dans le document On a choisi de ne pas traduire les noms de fichiers que l'auteur recommande d'inclure dans un logiciel. En effet, le monde des logiciels libres est fortement internationalis�, et il utilise l'anglais comme langue commune. On supposera donc que le lecteur qui souhaiterait mettre en application les conseils de ce HOWTO conna�t suffisamment d'anglais pour �crire des documents tels que le fichier README ou le fichier INSTALL. Cela n'interdit pas, bien entendu, d'inclure dans les projets une version fran�aise de ces documents, qui sera tr�s appr�ci�e des utilisateurs francophones, qu'ils parlent ou non l'anglais.
2. R�gles d'usage pour l'appellation de votre projet et de votre archive
2.1 Utilisez le style d'appellation GNU, avec un pr�fixe suivi d'un num�ro 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
5.5 Soignez votre documentation et vos README avant la livraison
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 d'appellation des fichiers
6.4 Pr�voyez les mises � jour
6.5 Fournissez des RPM
7. Comment bien communiquer
7.1 Faites une annonce dans c.o.l.a et sur Freshmeat
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://www.linuxdoc.org/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]>.
11..33.. OOnn aa cchhooiissii ddee nnee ppaass ttrraadduuiirree lleess nnoommss ddee ffiicchhiieerrss qquuee ll''aauutteeuurr
rreeccoommmmaannddee dd''iinncclluurree ddaannss uunn llooggiicciieell.. EEnn eeffffeett,, llee mmoonnddee ddeess llooggii��
cciieellss lliibbrreess eesstt ffoorrtteemmeenntt iinntteerrnnaattiioonnaalliiss��,, eett iill uuttiilliissee ll''aannggllaaiiss
ccoommmmee llaanngguuee ccoommmmuunnee.. OOnn ssuuppppoosseerraa ddoonncc qquuee llee lleecctteeuurr qquuii ssoouuhhaaiitt��
eerraaiitt mmeettttrree eenn aapppplliiccaattiioonn lleess ccoonnsseeiillss ddee ccee HHOOWWTTOO ccoonnnnaa��tt ssuuffffiissaamm��
mmeenntt dd''aannggllaaiiss ppoouurr ��ccrriirree ddeess ddooccuummeennttss tteellss qquuee llee ffiicchhiieerr RREEAADDMMEE oouu
llee ffiicchhiieerr IINNSSTTAALLLL.. CCeellaa nn''iinntteerrddiitt ppaass,, bbiieenn eenntteenndduu,, dd''iinncclluurree ddaannss
lleess pprroojjeettss uunnee vveerrssiioonn ffrraann��aaiissee ddee cceess ddooccuummeennttss,, qquuii sseerraa ttrr��ss
aapppprr��ccii��ee ddeess uuttiilliissaatteeuurrss ffrraannccoopphhoonneess,, qquu''iillss ppaarrlleenntt oouu nnoonn
ll''aannggllaaiiss.. NNoottee dduu ttrraadduucctteeuurr ssuurr ll''uussaaggee ddee ll''aannggllaaiiss ddaannss llee ddooccuu��
mmeenntt
22.. RR��gglleess dd''uussaaggee ppoouurr ll''aappppeellllaattiioonn 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��rroo dduu ttyyppee mmaajjeeuurr..mmiinneeuurr..ppaattcchh.. UUttiilliisseezz llee ssttyyllee dd''aappppeell��
llaattiioonn 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 fabrication 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 d'appellation 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 d�crites 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 noms avant de publier votre premi�re version. Deux bons
endroits pour v�rifier ceci sont l'index de Metalab
<
http://metalab.unc.edu/pub/Linux> et l'index des applications
(appindex) � Freshmeat <
http://www.freshmeat.net>. Un autre endroit
recommand� est SourceForge <
http://www.sourceforge.net>, en effectuant
une recherche par nom.
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 auteurs 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 _d_e
_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'' (note du traducteur : OSI est ici l'Open
Source Initiative et n'a rien � voir avec l'Organisme de
Standardisation Internationale ou ISO). 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 emplois, 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 de l'Open Source Initiative.
Si vous devez �crire votre propre licence, prenez soin de la faire
certifier par l'Open Source Initiative. 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� ces lignes sont �crites (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 _f_i_n_i_r_o_n_t 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, Emacs Lisp et PHP
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, ou 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 et 'use strict'
religieusement (consultez la documentation de Perl pour plus
d'informations).
55..55.. SSooiiggnneezz vvoottrree ddooccuummeennttaattiioonn eett vvooss RREEAADDMMEE aavvaanntt llaa lliivvrraaiissoonn
Passez-les au correcteur d'orthographe. Si vous donnez l'impression de
ne pas conna�tre l'orthographe et de vous en moquer, les gents
penseront que vous avez aussi b�cl� votre code.
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.
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 dd''aappppeellllaattiioonn ddeess ffiicchhiieerrss
Avant m�me d'avoir regard� le README, votre intr�pide explorateur aura
parcouru la liste des fichiers dans le r�pertoire principal de votre
distribution. Ces noms, par eux-m�mes, contiennent de l'information.
En suivant certaines r�gles d'appellation, 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.
La pr�sence d'une FAQ vous soulagera beaucoup. Quand une question
relative au projet revient fr�quemment, rajoutez-la dans la FAQ. Puis
demandez aux utilisateurs de lire la FAQ avant de poser des questions
ou d'envoyer des rapports de bogues. Une FAQ bien entretenue peut
r�duire d'au moins un ordre de grandeur la charge du support pour les
mainteneurs du projet.
Il est bon d'avoir un fichier HISTORY ou NEWS avec un historique du
projet mis � jour � chaque nouvelle version. Entre autres choses, il
pourrait vous aider � prouver votre ant�riorit� si vous �tiez pris
dans un proc�s pour contrefa�on (ce n'est jamais encore arriv� �
personne, mais autant y �tre pr�par�).
66..44.. PPrr��vvooyyeezz lleess mmiisseess �� jjoouurr
Votre logiciel �voluera dans le temps au rythme des versions
successives. Certains des changements ne seront pas compatibles avec
l'existant. Par cons�quent, r�fl�chissez bien � l'organisation du
logiciel afin que plusieurs versions puissent �tre install�es et
coexister sur le m�me syst�me. C'est particuli�rement important pour
les biblioth�ques de fonctions : vous ne pouvez pas compter que tous
les programmes clients soient mis � jour d'un seul coup pour s'adapter
aux modifications de vos interfaces.
Les projets Emacs, Python et Qt ont adopt� une bonne convention pour
traiter ce probl�me, celle des r�pertoires num�rot�s par version.
Voici � quoi ressemble une hi�rarchie de biblioth�ques Qt (${ver} est
le num�ro de version) :
/usr/lib/qt
/usr/lib/qt-${ver}
/usr/lib/qt-${ver}/bin # Emplacement de moc
/usr/lib/qt-${ver}/lib # Emplacement des .so
/usr/lib/qt-${ver}/include # Emplacement des fichiers d'en-t�te
+
Une telle organisation vous permet de faire coexister plusieurs
versions. Les programmes clients doivent sp�cifier quelle version de
la biblioth�que ils d�sirent, mais c'est un faible prix � payer en
comparaison des incompatibilit�s d'interface qu'ils �vitent.
66..55.. 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.
Note : si vous fournissez des RPM sources, utilisez BuildRoot pour
fabriquer le programme dans /tmp ou /var/tmp. Si vous ne le faites
pas, l'installation, r�alis�e au cours de la partie install de votre
fabrication, se d�roulera dans les r�pertoires finaux. Ceci se
produira m�me en cas d'homonymie de fichiers ou si vous ne d�sirez pas
r�ellement installer le produit. Une fois la fabrication termin�e, les
fichiers seront install�s � leur emplacement d�finitif, et la base de
donn�es RPM du syst�me ne sera pas mise � jour. Des SRPM ayant ce
mauvais comportement sont des champs de mines et doivent �tre �vit�s.
77.. CCoommmmeenntt bbiieenn 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 eett ssuurr FFrreesshhmmeeaatt
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 (l'auteur esp�re toutefois qu'ils le seront un
jour).
