Mardi 4 avril à 18h30 : Atélili sur les rapports de bug
par
popularité : 1%
Que faut-il savoir pour écrire un rapport de bug ?
L’un des atouts des logiciels libres, c’est que quand ça plante, il est plus facile de comprendre pourquoi, et de communiquer le problème aux auteurs du logiciel afin qu’il soit corrigé. Cette pratique occasionne un tournant dans notre usage de l’informatique, qui évolue d’une logique clientèliste (simple usage du logiciel) à une logique contributive (aider à l’amélioration du logiciel).
Les distributions GNU/Linux disposent généralement d’une plateforme de traitement de bugs, et invitent à suivre une procédure spécifique pour les rapporter. Dans le cas de Debian, l’outil « reportbug » permet de pré-remplir un rapport de bug. Même si la procédure d’envoi est semi-automatisée et que vous y êtes guidés, il peut être utile de connaître quelles informations sont envoyées, et de passer un peu de temps à en récolter d’autres afin de s’assurer que le rapport contienne toutes les informations utiles.
Parmi les informations facultatives (selon la nature du bug), celles produites par gdb. gdb est l’outil de débogage par excellence, et il est certainement disponible dans votre distribution Linux. Il permet d’exécuter un programme, d’interroger son état et de contrôler son déroulement. Il permet notamment d’indiquer précisément où le programme a planté, ce qui permettra au programmeur d’analyser le code correspondant et donc de retrouver la source de l’erreur.
Avant de présenter ces outils, on parlera des situations de bugs et des ambiguïtés et questions qu’elles soulèvent : quel type d’information peut-on nous demander dans un rapport de bug ? Est-ce que mon rapport de bug sera lu ou est-ce que ça ne sert à rien ? Que puis-je faire pour augmenter la qualité du rapport ?
Plan/Déroulement :
-
18h30 : Accueil, puis on démarre
Infos pratiques :
-
Date : le mardi 4 avril 2017 à 18h30
-
Lieu : C.C.L. (Centre Culturel Libertaire), 4 rue Colmar, Metro Porte des postes / voir sur openstreetmap
Commentaires