/usr/share/doc/HOWTO/fr-html/Software-Release-Practice-HOWTO.html is in doc-linux-fr-html 2013.01-3.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux (vers 25 March 2009), see www.w3.org">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.71">
<title>HOWTO sur la publication de logiciels</title>
</head>
<body>
<h1>HOWTO sur la publication de logiciels</h1>
<h2>Eric S. Raymond <esr@thyrsus.com> Traduction par Thierry
Bézecourt <thbzcrt@worldnet.fr></h2>
2.4, 12 juillet 2000
<hr>
<em>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.</em>
<hr>
<h2><a name="s1">1. Introduction</a></h2>
<h2><a name="ss1.1">1.1 Raison d'être de ce document</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="ss1.2">1.2 Nouvelles versions de ce document</a></h2>
<p>Ce document sera envoyé chaque mois dans le forum de
discussion <code>comp.os.linux.answers</code> . Ce document est
archivé sur plusieurs sites FTP Linux, dont
<code>metalab.unc.edu</code> dans le répertoire
<code>pub/Linux/docs/HOWTO</code>.</p>
<p>Vous pouvez aussi voir la dernière version, en anglais,
de ce HOWTO sur le World Wide Web à l'URL <a href=
"http://www.linuxdoc.org/HOWTO/Software-Release-Practice.html">http://www.linuxdoc.org/HOWTO/Software-Release-Practice.html</a>.
La version française est disponible à l'adresse
<a href=
"http://metalab.unc.edu/pub/Linux/docs/HOWTO/translations/fr">http://metalab.unc.edu/pub/Linux/docs/HOWTO/translations/fr</a>.</p>
<p>Vous pouvez envoyer vos questions et vos commentaires sur ce
HOWTO à Eric S. Raymond, <a href=
"mailto:esr@snark.thyrsus.com">esr@snark.thyrsus.com</a>.</p>
<h2><a name="ss1.3">1.3 Note du traducteur sur l'usage de l'anglais
dans le document</a></h2>
<p>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.</p>
<h2><a name="s2">2. Règles d'usage pour l'appellation de
votre projet et de votre archive</a></h2>
<p>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).</p>
<p>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.</p>
<h2><a name="ss2.1">2.1 Utilisez le style d'appellation GNU, avec
un préfixe suivi d'un numéro du type
majeur.mineur.patch.</a></h2>
<p>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.</p>
<p>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 :</p>
<dl>
<dt><b>toto-1.2.3.tar.gz</b></dt>
<dd>
<p>L'archive des sources</p>
</dd>
<dt><b>toto.lsm</b></dt>
<dd>
<p>Le fichier LSM (si vous l'envoyez à Metalab).</p>
</dd>
</dl>
<p>N'utilisez <em>pas</em> les noms suivants :</p>
<dl>
<dt><b>toto123.tar.gz</b></dt>
<dd>
<p>Beaucoup de programmes croiront qu'il s'agit du fichier
d'archive d'un projet nommé `toto123', sans numéro de
version.</p>
</dd>
<dt><b>toto1.2.3.tar.gz</b></dt>
<dd>
<p>Beaucoup de programmes croiront qu'il s'agit de l'archive d'un
projet nommé `toto1' à la version 2.3.</p>
</dd>
<dt><b>toto-v1.2.3.tar.gz</b></dt>
<dd>
<p>Beaucoup de programmes prendront cela pour un projet
nommé `toto-v1'.</p>
</dd>
<dt><b>to_to-1.2.3.tar.gz</b></dt>
<dd>
<p>Le caractère souligné est difficile à
prononcer, à taper, et à retenir.</p>
</dd>
<dt><b>ToTo-1.2.3.tar.gz</b></dt>
<dd>
<p>A moins que vous vouliez <em>vraiment</em> ressembler à
un accroc du marketing. Là encore, c'est difficile à
prononcer, à taper et à retenir.</p>
</dd>
</dl>
<p>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 <em>après</em> le numéro de version. Voici
quelques exemples :</p>
<dl>
<dt><b>toto-1.2.3.src.tar.gz</b></dt>
<dd>
<p>sources</p>
</dd>
<dt><b>toto-1.2.3.bin.tar.gz</b></dt>
<dd>
<p>binaires, type non spécifié</p>
</dd>
<dt><b>toto-1.2.3.bin.ELF.tar.gz</b></dt>
<dd>
<p>binaires ELF</p>
</dd>
<dt><b>toto-1.2.3.bin.ELF.static.tar.gz</b></dt>
<dd>
<p>binaires ELF liés statiquement</p>
</dd>
<dt><b>toto-1.2.3.bin.SPARC.tar.gz</b></dt>
<dd>
<p>binaires pour SPARC</p>
</dd>
</dl>
<p>N'utilisez <em>pas</em> 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.</p>
<p>Un bon schéma d'appellation générique
contient, dans l'ordre, les parties suivantes :</p>
<ol>
<li>préfixe du projet</li>
<li>tiret</li>
<li>numéro de version</li>
<li>point</li>
<li>"src" ou "bin" (optionnel)</li>
<li>point ou tiret (un point de préférence)</li>
<li>type de binaire et options (optionnel)</li>
<li>extensions relatives au mode d'archivage et de compression</li>
</ol>
<h2><a name="ss2.2">2.2 Mais respectez le cas échéant
les conventions locales</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="ss2.3">2.3 Choisissez avec le plus grand soin un
préfixe unique et facile à taper</a></h2>
<p>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.</p>
<p>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 <a href="http://metalab.unc.edu/pub/Linux">l'index de
Metalab</a> et l'index des applications (appindex) à
<a href="http://www.freshmeat.net">Freshmeat</a>. Un autre endroit
recommandé est <a href=
"http://www.sourceforge.net">SourceForge</a>, en effectuant une
recherche par nom.</p>
<h2><a name="s3">3. Règles d'usage pour la licence et le
copyright : la théorie</a></h2>
<p>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.</p>
<h2><a name="ss3.1">3.1 Les logiciels à code ouvert et le
copyright</a></h2>
<p>(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")</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="ss3.2">3.2 Déterminer ce qui peut être
qualifié comme logiciel à code ouvert</a></h2>
<p>En ce qui concerne la licence, on peut distinguer plusieurs
sortes de droits transférables via une licence. Les droits
de <em>copie et de redistribution</em>, les droits
d'<em>utilisation</em>, les droits de <em>modification à
usage personnel</em> et les droits de <em>redistribution de copies
modifiées</em>. Une licence peut restreindre chacun de ces
droits ou les accompagner de conditions.</p>
<p>L' <a href="http://www.opensource.org">Open Source
Initiative</a> 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 :</p>
<ol>
<li>Un droit de copie illimité doit être
accordé.</li>
<li>Un droit d'utilisation illimité doit être
accordé.</li>
<li>Un droit de modication illimité pour utilisation
personnelle doit être accordé.</li>
</ol>
<p>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.</p>
<p>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).</p>
<p>Notez que les licences n'autorisant qu'un usage non commercial
ne peuvent <em>pas</em> ê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.</p>
<h2><a name="s4">4. Règles d'usage pour la licence et le
copyright : la pratique</a></h2>
<p>Voici comment appliquer dans la pratique la théorie qui
précède :</p>
<h2><a name="ss4.1">4.1 Donnez le copyright à
vous-même ou à la FSF</a></h2>
<p>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.</p>
<h2><a name="ss4.2">4.2 Choisissez une licence conforme à
l'Open Source Definition</a></h2>
<p>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' <a href="http://www.opensource.org">Open Source
Initiative</a>.</p>
<h2><a name="ss4.3">4.3 N'écrivez pas votre propre licence
si vous pouvez l'éviter.</a></h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="s5">5. Règles d'usage du
développement</a></h2>
<p>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.</p>
<p>D'autres personnes <em>finiront</em> 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.</p>
<h2><a name="ss5.1">5.1 Ecrivez soit en C ANSI pur, soit dans un
langage de script portable</a></h2>
<p>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.</p>
<p>Parmi les langages de script, Python, Perl, Tcl, Emacs Lisp et
PHP respectent ce critère. Le bon vieux shell <em>ne
convient pas</em> ; 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.</p>
<p>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é.</p>
<h2><a name="ss5.2">5.2 Respectez les règles de
portabilité du C</a></h2>
<p>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é.</p>
<p>En revanche, ne supposez <em>pas</em> 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.</p>
<h2><a name="ss5.3">5.3 Utilisez
autoconf/automaker/autoheader</a></h2>
<p>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.</p>
<h2><a name="ss5.4">5.4 Soignez la rigueur de votre code avant
chaque nouvelle version</a></h2>
<p>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.</p>
<p>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).</p>
<h2><a name="ss5.5">5.5 Soignez votre documentation et vos README
avant la livraison</a></h2>
<p>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.</p>
<h2><a name="s6">6. Règles d'usage pour la mise au point de
la distribution</a></h2>
<p>Les indications qui suivent montrent à quoi votre
distribution devrait ressembler lorsqu'on la récupère
et qu'on la décompacte.</p>
<h2><a name="ss6.1">6.1 Assurez-vous que vos archives se
décompactent toujours dans un répertoire nouveau et
unique.</a></h2>
<p>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.
<em>Ne faites jamais cela !</em></p>
<p>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 <em>en-dessous</em> du
répertoire courant.</p>
<p>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.</p>
<pre>
VERS=1.0
toto-$(VERS).tar.gz:
tar --name-prefix='toto-$(VERS)/' -czf toto-$(VERS).tar.gz $(SRC)
</pre>
<p>Si votre version de tar est plus ancienne, faites quelque chose
dans ce genre :</p>
<pre>
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))
</pre>
<h2><a name="ss6.2">6.2 Ecrivez un README</a></h2>
<p>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.</p>
<p>Voici quelques éléments qu'il est bon d'avoir dans
un README :</p>
<ul>
<li>Une brève description du projet.</li>
<li>Un lien vers le site Web du projet, le cas
échéant.</li>
<li>Des indications sur l'environnement de compilation du
développeur et sur les possibles problèmes de
portabilité.</li>
<li>Un plan d'ensemble des fichiers et sous-répertoires
importants.</li>
<li>Les instructions de compilation et d'installation, ou bien un
lien vers le fichier les contenant (habituellement INSTALL).</li>
<li>Le nom des responsables et des contributeurs, ou un lien vers
le fichier contenant ces noms (habituellement CREDITS).</li>
<li>Les dernières nouvelles relatives au projet, ou un lien
vers un fichier les contenant (habituellement NEWS).</li>
</ul>
<h2><a name="ss6.3">6.3 Adoptez les conventions courantes
d'appellation des fichiers</a></h2>
<p>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.</p>
<p>Voici quelques noms recommandés pour les fichiers du
répertoire principal, avec leur signification. Tous ne sont
pas indispensables dans chaque projet.</p>
<dl>
<dt><b>README ou READ.ME</b></dt>
<dd>
<p>le plan d'ensemble, à lire en premier</p>
</dd>
<dt><b>INSTALL</b></dt>
<dd>
<p>instructions de configuration, de compilation et
d'installation</p>
</dd>
<dt><b>CREDITS</b></dt>
<dd>
<p>liste des contributeurs du projet</p>
</dd>
<dt><b>NEWS</b></dt>
<dd>
<p>dernières nouvelles</p>
</dd>
<dt><b>HISTORY</b></dt>
<dd>
<p>histoire du projet</p>
</dd>
<dt><b>COPYING</b></dt>
<dd>
<p>termes de la licence (convention GNU)</p>
</dd>
<dt><b>LICENSE</b></dt>
<dd>
<p>termes de la licence</p>
</dd>
<dt><b>MANIFEST</b></dt>
<dd>
<p>liste des fichiers</p>
</dd>
<dt><b>FAQ</b></dt>
<dd>
<p>"Foire Aux Questions" pour le projet, au format texte.</p>
</dd>
<dt><b>TAGS</b></dt>
<dd>
<p>fichier de tags généré automatiquement,
pour être utilisé par Emacs ou vi</p>
</dd>
</dl>
<p>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.</p>
<p>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.</p>
<p>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é).</p>
<h2><a name="ss6.4">6.4 Prévoyez les mises à
jour</a></h2>
<p>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.</p>
<p>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)
:</p>
<pre>
/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
+
</pre>
<p>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.</p>
<h2><a name="ss6.5">6.5 Fournissez des RPM</a></h2>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="s7">7. Comment bien communiquer</a></h2>
<p>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 :</p>
<h2><a name="ss7.1">7.1 Faites une annonce dans c.o.l.a et sur
Freshmeat</a></h2>
<p>Annoncez vos nouvelles versions dans <a href=
"news:comp.os.linux.announce">comp.os.linux.announce</a>. 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 <a href=
"http://www.freshmeat.net">Freshmeat</a>.</p>
<h2><a name="ss7.2">7.2 Faites une annonce dans un forum de
discussion adéquat</a></h2>
<p>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 <em>fonction</em> remplie par votre logiciel est
pertinente, et restez mesuré.</p>
<p>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.</p>
<p>Votre annonce devrait aussi contenir l'URL du site Web de votre
projet.</p>
<h2><a name="ss7.3">7.3 Ayez un site Web</a></h2>
<p>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 :</p>
<ul>
<li>La charte du projet (pourquoi il existe, quelle est son
audience, etc).</li>
<li>Des liens pour le téléchargement des
sources.</li>
<li>Des instructions relatives à l'inscription à la
ou les liste(s) de diffusion.</li>
<li>Une FAQ (Foire Aux Questions).</li>
<li>Une version en HTML de la documentation.</li>
<li>Des liens vers des projets proches et/ou concurrents.</li>
</ul>
<p>Certains projets ont même une URL pour un accès
anonyme à l'arborescence principale du code source.</p>
<h2><a name="ss7.4">7.4 Hébergez des listes de diffusion
pour votre projet</a></h2>
<p>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.</p>
<h2><a name="ss7.5">7.5 Publiez dans les archives les plus
importantes</a></h2>
<p>Depuis plusieurs années, le <a href=
"http://www.metalab/unc.edu/pub/Linux/">site Metalab</a> est le
plus important des endroits d'échange de logiciels pour
Linux.</p>
<p>Voici quelques autres sites notables :</p>
<ul>
<li>le site <a href="http://www.python.org">Python Software
Activity</a> (pour les logiciels écrits en Python).</li>
<li>le <a href="http://language.perl.com/CPAN">CPAN</a> ou
Réseau d'Archives Perl Global (pour les logiciels
écrits en Perl).</li>
</ul>
<h2><a name="s8">8. La bonne gestion d'un projet</a></h2>
<p>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.</p>
<p>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 <a href=
"http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">The
Cathedral and the Bazaar</a>.</p>
<p>Pour une réflexion sur les motivations psychologiques,
des coutumes de la communauté et de la résolution des
conflits, lisez <a href=
"http://www.tuxedo.org/~esr/writings/homesteading/">Homesteading
the Noosphere</a>.</p>
<p>Pour un exposé des principes économiques et des
modèles commerciaux à adopter, lisez <a href=
"http://www.tuxedo.org/~esr/writings/magic-cauldron/">The Magic
Cauldron</a>.</p>
<p>Si vous êtes allergique à la langue de Shakespeare,
vous pourrez trouver des traductions de ces documents sur le site
<a href="http://www.linux-france.org/article/these/">Linux
France</a>.</p>
<p>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).</p>
</body>
</html>
|