ATÉLILI

ATELIERS D'INFORMATIQUE LIBRE À LILLE

User Tools

Site Tools


atelier:17

Atelier 17 : «Que faut-il savoir pour écrire un rapport de bug ?»

Thème : Les rapports de bug

Description :

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 ? Quelles précautions prendre avant de transmettre mon rapport ?

Plan/Déroulement :

  • 18h30 : Accueil : présentations des atélilis, présentation du CCL
  • 18h45 : Points d'organisation des atélilis : a) quels lieux pour les atélilis ? b) install-party en parallèle ? c) Qui organise les atélilis ? d) prep un restau !
  • 19h : Rappel/lecture du thème d'atelier proposé
  • 19h05 : Début de l'atelier
    • Est-ce que mon rapport de bug sera lu ou est-ce que ça ne sert à rien ?
    • Différentes plateformes de bugs, différentes gestions : debian, tails, github, upstream, microsoft windows, mozilla
    • Aparté : Debian : stable, testing, unstable, quelle différence ?
    • Aperçu de la liste des bugs d'un paquet. Voir Ressources.
    • Quelles précautions prendre avant de transmettre mon rapport ? (vérifier bugs existants, vérifier si le bug correspond, vérifier que mes logiciels proviennent de dépots standards/non-teintés ). Voir page Reporting.
    • Installer reportbug. Démonstration exemple fictif.
    • Quel type d'information peut-on nous demander dans un rapport de bug ? (étapes pour le reproduire, messages d'erreur précis, versions des logiciels installés, log verbose… )
    • Comment transmettre le rapport à la plateforme de bug ? (reportbug, email, web…). Voir page Reporting
    • Échanges entre le mainteneureuse et l'utilisateurice. Que peut-on me demander de faire ? (tester autre version du paquet, backtrace gdb, valgrind, essayer un patch…)
    • Et vous, vos bugs rencontrés ?

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

Ressources

Annonces

Retours sur cet atelier

https://lists.ffdn.org/wws/arc/chti-data-network/2017-04/msg00016.html

On a poursuit des réflexions par email, vis à vis de ce qui est exigé au sein d'un rapport de bug et du curseur effort utilisateurice/développeuseur.

Sans lien avec cet atelier, on pourra aussi lire cet autre retour d'une vraie “Bug squashing party” : https://anarc.at/blog/2017-04-09-montreal-bsp-report/

Addition de Novembre 2017 : Pinaraf de Chtinux écrit un journal sur la démarche qui l'a mené à écrire un patch concernant un module du noyau, bravo ! Lien : https://linuxfr.org/users/pied/journaux/d-un-kernel-panic-a-un-patch

atelier/17.txt · Last modified: 2017/11/12 19:35 by 2a01:e35:8be8:e4e0:e2cb:4eff:feff:c527