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.

C’est vraisemblablement la contribution la plus simple et la plus largement pratiquée. Les utilisateurs avides de nouveautés emploient les versions testing/unstable qui évoluent en permanence. Lorsqu’ils rencontrent des problèmes, ils consultent immédiatement le système de suivi de bogues pour voir s’il est déjà répertorié. Si ce n’est pas le cas, ils se chargent de rédiger un rapport de bogue détaillé, grâce à l’outil reportbug (voir le paquet).

Ensuite, ils répondent du mieux qu’ils peuvent aux sollicitations que le mainteneur leur envoient pour comprendre dans quelles circonstances le problème se manifeste. C’est pourquoi l’usage de la langue anglaise est de rigueur… toutefois si l’anglais vous bloque, il est possible de demander de l’assistance sur la liste de diffusion debian-user-french@lists.debian.org. D’autres pourront peut-être reproduire le problème et signaler le bogue pour vous.

On peut aussi formuler des souhaits d’améliorations (ajout de fonctionnalité, changement d’un comportement par défaut, etc.), la priorité « wishlist » du BTS est dédiée à cela.

Sachez enfin, qu’on peut consulter tous les bogues que l’on a soumis avec une URL comme celle-ci (ici avec mon email hertzog@debian.org) : http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=hertzog@debian.org

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