Il est de notoriété publique que la majorité des informaticiens n’aime pas rédiger de la documentation. C’est donc un domaine en manque de contributeurs!

Le projet de documentation Debian (DDP pour les intimes) est le point central qui essaie de fédérer toutes les initiatives de création de documentation autour de Debian. Mais il suffit de jeter un oeil sur la liste de diffusion associée (debian-doc@lists.debian.org) pour se rendre compte que l’activité du projet est minime.

Pourtant, de nombreux documents sont sous sa responsabilité. Certains concernent les utilisateurs, d’autres plutôt les développeurs, et les derniers sont regroupés dans une catégorie « divers« . Chaque écrivain (technique) en herbe peut y trouver son bonheur!

Pour le moment, la majorité des documents sont rédigés en DebianDoc SGML (paquet debiandoc-sgml) et sont gérés dans un dépôt cvs. Les documents qui sont empaquetés ont souvent une liste de bogues associés (ex: apt-howto, developers-reference, debian-history…). Cette dernière contient souvent des idées d’amélioration qui peuvent constituer un point de départ pour contribuer. Armé de votre éditeur de texte préféré, de cvs pour télécharger la dernière version des sources, et de diff pour créer des patchs, vous pouvez vous lancer dans l’aventure.

Il ne faut pas hésiter à se présenter sur la liste de diffusion, à mentionner sa volonté de participer (en précisant les sujets qui vous intéressent plus particulièrement), et – bien entendu – à poser des questions lorsque vous vous êtes bloqués.

Cet article fait partie d’une série expliquant – par des exemples – comment contribuer à Debian.

En reportant le bogue #428797 sur le paquet xscreensaver, il m’est apparu que le paquet avait beaucoup (trop) de bogues ouverts. J’ai donc regardé de plus près l’état du paquet et j’ai découvert qu’une nouvelle version majeure du logiciel était disponible (5.x contre 4.x dans unstable).

J’ai alors soumis un deuxième bogue (#428798) demandant au mainteneur de mettre en paquet la dernière version. Je lui ai fait remarquer que l’état du paquet n’était pas génial et qu’il devrait s’y remettre ou au moins demander de l’aide…

Dans la même journée, le mainteneur se sentant coupable de négligence m’a demandé comment « rendre la main » puisqu’il ne souhaitait plus continuer de maintenir le paquet. Je lui ai indiqué, et je l’ai incité à envoyer un message à debian-devel pour trouver un mainteneur plus rapidement. Aussitôt dit, aussitôt fait.

Quelques temps après, Jose Luis Rivas adoptait le paquet (avec David Moreno Garza pour le sponsoriser). L’envoi de la version 5.03-1 a suivi peu de temps après et fermait 20 bogues!

Cout de l’opération: 2 bogues et 2 mails envoyés. Bénéfice: 20 bogues fermés et un mainteneur actif pour le paquet.

Cet article fait partie d’une série expliquant – par des exemples – comment contribuer à Debian.

Dans le bogue #313317, Jean-Christophe Dubacq a fourni un patch afin qu’une session SSH préserve correctement la variable d’environnement LANG.

Malheureusement le paquet OpenSSH a accumulé les bogues au fil du temps, et les mainteneurs n’ont visiblement pas le temps de rattraper le retard accumulé. Au lieu d’attendre indéfiniment que le mainteneur Debian traite ce bogue précis, Jean-Christophe est allé sur le site web de OpenSSH afin de trouver où l’on peut signaler les bogues.

Après avoir lu les instructions, il s’est rendu sur leur Bugzilla et s’est créé un compte. Ensuite il a pu soumettre un nouveau bogue (après avoir vérifié que ce bogue n’est pas déjà répertorié). Accompagné du patch, il est probable que le bogue soit traité plus rapidement… du côté Debian, il a pensé à marquer le bogue comme « forwarded » en pointant vers l’adresse du bogue amont.

D’une manière générale, avant de soumettre un bogue en amont, il faudrait s’assurer que le bogue ne soit pas spécifique à Debian. En regardant le paquet source Debian (apt-get source openssh), il est souvent possible de voir si le paquet diverge beaucoup ou pas en inspectant le fichier .diff.gz (avec zless par exemple). Un paquet qui ne diverge pas n’aura pas de changements dans les fichiers sources, il rajoutera juste des fichiers dans le sous-répertoire debian. L’exception qui confirme la règle est l’ajout de fichiers dans debian/patches/. Ces derniers sont des modifications qui seront appliquées dynamiquement à la compilation. Si le paquet diverge sensiblement, et que vous n’êtes pas capable de dire si ces changements ont une influence ou non sur le bogue qui vous intéresse, dans ce cas il vaut peut-être mieux s’abstenir de soumettre le bogue en amont. Si vous le faites malgré tout, signalez impérativement l’incertitude sur l’origine du bogue.

Alternativement à tout cela, il est possible de relancer le mainteneur Debian. Dans le cas de OpenSSH les mises à jour sont fréquentes, le mainteneur est donc disponible, un simple mail poli et courtois peut suffir à débloquer la situation. Demandez-lui des nouvelles du bogue, informez le que vous êtes prêt à faire suivre le bogue en amont s’il pouvait vous confirmer que le bogue n’est pas spécifique à Debian.

C’est un bon moyen pour commencer une carrière de trieur de bogues.

Cet article fait partie d’une série expliquant – par des exemples – comment contribuer à Debian.

Nous sommes nombreux à apprécier Debian, mais mis à part le bouche à oreille qui marche assez bien, il n’y a pas beaucoup de promotion de notre distribution préférée. Trop souvent Debian est présentée comme une distribution difficile d’accès et les préjugés ont la vie dure.

Il y a donc un formidable travail d’information et de promotion à faire. Et les développeurs Debian, aussi doués soient-ils techniquement, ne sont décidément pas très forts pour promouvoir leur distribution préférée. Les annonces de presse (« Press Release ») émanant du projet se comptent sur les doigts d’une main… pourtant on est tous d’accord sur le fait qu’il en faudrait plus.

L’équipe debian-publicity

Si vous êtes à l’aise en anglais, le mieux est de rejoindre l’équipe debian-publicity et de s’abonner à sa liste de diffusion. N’hésitez pas à proposer des annonces et des nouvelles en les envoyant à la liste. Commentez et corrigez les propositions des autres (le jour où il y en aura ;-)). Vous nouvelles pourront soit être intégrées dans times.debian.net soit publiées sur debian-news@lists.debian.org par Alexander Schmehl ou Martin Joey Schulze.

La promotion en français

Si l’anglais n’est pas votre tasse de thé, vous êtes laché dans le vide… je ne connais pas d’équipe francophone dont le but soit la promotion de Debian en France (hormis l’association Debian France peut-être).

Défrichons donc le terrain: il y a une liste de diffusion debian-news-french qui véhicule les nouvelles traduites en français. Les modérateurs sont très compréhensifs et accepteront volontiers de publier des nouvelles originales en français. Charge à vous de rédiger les premières annonces… pour les faire relire, je suggère de les envoyer à debian-devel-french. La liste ne sert que rarement à discuter de technique, et elle fédère un grand nombre de contributeurs francophones.

Promouvoir ailleurs

J’ai cité essentiellement les médias employés par Debian pour véhiculer les annonces et les nouvelles, mais la force d’une communauté c’est aussi son aspect décentralisé. Tout ne doit pas nécessairement passer par le projet lui-même. Bloguez sur Debian, créez des sites indépendants traitant de Debian, participez à ces sites…

Exercice pratique

Rédigez une courte introduction présentant cette initiative et publiez là sur votre blog ou sur votre site web! Faites circuler l’information afin de susciter des vocations de contributeurs au sein de la communauté des utilisateurs de Debian.

Cet article fait partie d’une série expliquant – par des exemples – comment contribuer à Debian.

Lorsqu’un mainteneur Debian n’a plus le temps de maintenir un logiciel, il l’abandonne (« orphan » en anglais). Pour cela, il ouvre un bogue spécial sur le paquet wnpp et envoie une nouvelle version du paquet qui change le mainteneur en « Debian QA Group <packages@qa.debian.org> ».

L’équipe QA va assurer la maintenance du paquet, le temps qu’un nouveau mainteneur propose de reprendre le paquet. Si personne ne se propose, le paquet finira par être supprimé de la distribution. C’est souvent une bonne chose (cela permet de se débarrasser des logiciels obsolètes), mais il y a aussi des cas où garder le paquet aurait été intéressant si un bon mainteneur était disponible.

Pour éviter que des paquets utiles ne disparaissent, il peut être intéressant de surveiller la liste des paquets orphelins et d’essayer d’avertir la communauté des utilisateurs/développeurs du logiciel lorsque le paquet est abandonné chez Debian et d’essayer de susciter des vocations pour que quelqu’un reprenne la maintenance du paquet Debian avant qu’il ne soit trop tard.

Pour rester informé des paquets abandonnés, il est possible de s’abonner au paquet « wnpp » sur le système de suivi de paquets, mais vous recevrez également tous les messages concernant les mises en paquet, les recherches de co-mainteneurs, etc. Les paquets récemment abandonnés sont également signalés dans Debian Weekly News (dont la fréquence de publication est malheureusement très aléatoire ces derniers temps).

Pour chaque bogue « O: » que vous jugez intéressant de suivre, il est possible de vous y abonner (individuellement cette fois-ci) en envoyant un message à XXXXXX-subscribe@bugs.debian.org (en remplaçant XXXXXX par le numéro du bogue évidemment).

Cet article fait partie d’une série expliquant – par des exemples – comment contribuer à Debian.

Assurer le support technique est une composante essentielle à l’écosystème du logiciel libre.

Que cela soit sur une liste de diffusion comme debian-user-french@lists.debian.org, sur des forums, ou sur des canaux IRC comme #debian-fr sur irc.debian.org, la logique sous-jacente est toujours la même: avec une communauté ouverte et accueillante, cela permet d’avoir plus d’utilisateurs et donc, à terme, plus de contributeurs. En outre, lorsqu’un utilisateur rencontre une difficulté, il est possible qu’il mette le doigt sur un problème réel, vous pouvez alors l’aider à signaler le bogue.

Enfin, lorsqu’on cherche à résoudre les problèmes des autres, on est obligé de se documenter et de se renseigner sur des sujets variés. C’est une excellente démarche qui contribue au développement de nouvelles compétences. La lecture des autres réponses complète de manière utile vos propres recherches.

Quoi qu’il en soit, cette activité a fait partie intégrante de mes débuts chez Debian (voir des vieux exemples) et je considère encore que c’est un premier pas nécessaire pour être au contact de la communauté (qui est aujourd’hui bien plus étendue qu’elle ne l’était à mon époque ;-)).

Cet article fait partie d’une série expliquant – par des exemples – comment contribuer à Debian.

Pour ceux qui savent programmer, il y a de nombreux bogues pour lesquels la situation est claire: soit parce que le bogue a été bien diagnostiqué et qu’on sait relativement bien comment l’application aurait du se comporter, soit parce que le bogue était directement un souhait d’amélioration (priorité « wishlist ») clairement formulé.

Dans ces cas là, et si on maîtrise le langage de programmation dans lequel le logiciel est écrit, c’est souvent un défi amusant que d’essayer de se plonger dans du code que l’on n’a pas écrit, de le comprendre et d’être capable de le modifier pour qu’il se comporte comme on le souhaite.

Ainsi, après avoir spécifié le bon comportement de dpkg -S face à un lien symbolique inconnu du système de paquetage, j’ai envoyé un patch au bogue 443290 qui corrige le comportement de dpkg dans ce cas particulier.

Notez au passage que le BTS dispose d’un tag « patch » qui permet de signaler qu’un correctif est disponible pour le bogue, et qu’en envoyant mon patch j’ai mis control@bugs.debian.org en copie cachée afin que le BTS enregistre la commande « tag 433290 + patch » qui est placée au début de mon message.

Cet article fait partie d’une série expliquant – par des exemples – comment contribuer à Debian.

Une fois un problème identifié, il faut proposer une solution. Cela ne signifie pas nécessairement écrire du code… dans bien des cas, avant d’en arriver au code, il faut définir quel devrait être le comportement correct d’une application.

Un exemple avec le bogue #433290 qui défend l’idée que dpkg -S ne devrait pas échouer sur /usr/bin/man qui est un lien symbolique (n’appartenant à aucun paquet) mais pointant sur le binaire /usr/lib/man-db/man (qui appartient au paquet man-db).

On comprend aisément le besoin de l’utilisateur qui souhaite savoir quel paquet fournit la fonctionnalité /usr/bin/man et qui n’obtient pas la réponse attendue. Mais il faut mettre en balance l’exactitude technique: on ne peut pas dire que /usr/bin/man appartient au paquet man-db si ce n’est pas le cas.

J’ai donc fait une proposition intermédiaire où dpkg informe que /usr/bin/man n’est pas empaqueté mais que c’est un lien symbolique pointant sur un fichier empaqueté.

Pas besoin d’être programmeur pour spécifier le comportement satisfaisant l’utilisateur tout en étant techniquement juste. Il faut juste du temps, des idées et du bon sens.

N’hésitez pas à donner d’autres exemples dans les commentaires.

Cet article fait partie d’une série expliquant – par des exemples – comment contribuer à Debian.