Pourquoi certains grands projets, comme Git et Debian, utilisent-ils uniquement une liste de diffusion et non un outil de suivi des problèmes?

Le traqueur de bogues pour tout projet de taille décente me semble une évidence - il est très facile d'organiser des centaines ou des milliers de problèmes, sans que les problèmes ne se rencontrent ou ne se mélangent.

Ainsi, lorsque je vois de très gros projets, comme Git, qui utilise une liste de diffusion comme méthode principale de coordination de la maintenance et du développement, je suis un peu époustouflé. Exemples:

• Git - Page communautaire :

  ... Les rapports de bugs doivent être envoyés à cette liste de diffusion.

• Système de suivi des bogues Debian , par Wikipedia:

  ... Sa particularité réside dans le fait qu’il n’a aucune interface Web pour éditer les rapports de bogues - toutes les modifications sont faites par courrier électronique.

De nombreux suiveurs de bogues modernes intègrent très bien la messagerie électronique (vous pouvez recevoir des commentaires ou des notifications concernant les bogues que vous êtes en train de surveiller ou qui vous sont attribués), ainsi que par les systèmes de contrôle de version (les validations peuvent être marquées comme résolvant un problème, etc. .) Une grande partie de ceci devrait être fait manuellement avec une liste de diffusion, et vous recevrez des tonnes de courriels sur des bugs qui ne vous intéressent pas.

Quels sont donc les principaux avantages d’une liste de diffusion par rapport à un système de suivi des anomalies basé sur le Web? Pourquoi certains grands projets utilisent-ils uniquement une liste de diffusion?

La préférence que vous observez semble être une conséquence naturelle de la recommandation clairement énoncée dans les normes de codage GNU . Il est suggéré de signaler les bogues par e-mail, comme vous pouvez le voir ci-dessous citation (j'ai marqué en gras la partie qui concerne directement vos observations):

4.7.2 --help

L' --helpoption standard devrait afficher une brève documentation sur la procédure à suivre pour appeler le programme, sur la sortie standard, puis se terminer avec succès. Les autres options et arguments doivent être ignorés une fois que cela est vu, et le programme ne doit pas remplir sa fonction normale.

Vers la fin de la ‘--help’sortie de l’ option, placez des lignes indiquant l’adresse e-mail pour les rapports de bogues , la page d’accueil du paquet (normalement ‘http://www.gnu.org/software/pkg’, et la page générale pour obtenir de l’aide sur les programmes GNU. Le format devrait être le suivant:

    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>

Il est correct de mentionner d’autres listes de diffusion et pages Web appropriées.

La préférence ci-dessus, à son tour, reflète l'acceptation universelle du courrier électronique en tant que forme de communication électronique. Tout --helpmessage de lecture utilisateur tel que suggéré ci-dessus est supposé comprendre facilement ce qu’il faut faire s’ils voient un bogue - le mailing est facile.

Le traqueur de problème pourrait être (et je pense que c'est ) meilleur pour un développeur travaillant dans le projet, mais pour un public plus large, il serait plus difficile de présenter et d'expliquer comment l'utiliser, notamment en tenant compte de la grande variété et des différences entre les différents systèmes de suivi des problèmes .

Un projet peut utiliser Bugzilla, un autre collera avec JIRA, un troisième avec ... GNATS , etc.

Report bugs to: mailing-address

La note ci-dessus ne signifie pas que les projets ne doivent pas utiliser le suivi des problèmes en interne . Comme expliqué dans une excellente réponse à la question connexe ,

Votre traqueur de bogues est pour votre commodité, pas celle de vos clients. Si vous ne vous inquiétez pas de prendre leur numéro de téléphone ou de courrier électronique et de le saisir vous-même, que pensez-vous qu'ils ressentent?

Vous devez pouvoir saisir des problèmes et les attribuer manuellement à un client ...

Avec Git, en particulier, il existe une raison historique simple: Git a été lancé par des pirates Linux pour des pirates Linux, et utilise le même modèle de développement et les mêmes outils que Linux lui-même. Cependant, Linux est plus ancien que le WWW, donc quand Linux a été lancé, il n’existait tout simplement pas de suivi des problèmes sur le Web, car il n’y avait pas de Web!

En conséquence, la communauté Linux a mis au point des outils et des workflows extrêmement efficaces pour traiter les rapports de bogues et les révisions de code par courrier électronique. Ils n'avaient donc aucune raison de tout laisser tomber et de repartir à zéro lorsqu'ils ont lancé le projet Git.

Pour Git:

Il y a plusieurs discussions sur la liste de diffusion où les gens proposent d'utiliser une sorte de traqueur de bogues. Ces initiatives semblent toutes avoir échoué, aussi la raison pour laquelle Git n'utilise pas de traqueur de bogues est probablement simplement que la plupart des contributeurs ne le trouvent pas utile.

Dans un message publié sur la liste de diffusion , Junio ​​C Hamano (responsable de la maintenance de Git) a expliqué pourquoi il estimait qu'un système de suivi des bogues n'était pas très utile. Je ne veux pas inclure tout le message (c'est assez long), mais cela revient à:

• Si vous recherchez uniquement des informations sur les problèmes résolus, la recherche dans les archives de la liste fonctionne tout aussi bien que la recherche d'un système de suivi des bogues.
• Si vous signalez un véritable bogue et que les gens veulent s'en occuper, la liste fonctionne également bien.
• Si personne ne souhaite travailler sur un problème, il tombera entre les mailles du filet, même dans un système de suivi des bogues.
• Un système de suivi des bogues serait un système supplémentaire à gérer, à vérifier régulièrement si de nouveaux bogues étaient résolus, à réparer les bogues corrigés, etc. En bref, un travail supplémentaire pour un bénéfice minime.

Debian utilise un système de suivi des bogues, son interface par défaut est la messagerie électronique. Et c'est pratique. Lucas Nussbaum, chef de projet Debian actuel, a posté il y a quelques jours :

debbugs est le logiciel derrière le système de suivi des bogues de Debian (BTS). Il est également utilisé par le projet GNU. Bien qu'il soit souvent perçu comme un style ancien, il présente plusieurs fonctionnalités uniques, telles que le suivi du statut des bogues dans chaque version et branche d'un package) ou la possibilité d'effectuer toutes les interactions par courrier électronique, ce qui facilite grandement le travail. hors ligne ou dans des environnements mal connectés.

La dernière partie est une fonctionnalité meurtrière ici - il suffit de mettre en file d'attente ces rapports dans votre file d'attente de courrier local jusqu'à ce que vous quittiez l'avion!

• Garde les enfants de 9 ans.
• Pas besoin de créer un compte séparé pour chaque forum.
• [mineur] Expérience utilisateur cohérente sur différentes listes de diffusion et une courbe d'apprentissage nulle lors de l'inscription à une nouvelle liste.
• Fonctionne hors ligne. vous pouvez vous connecter à Internet et télécharger un lot de courriers, puis partir en randonnée, écrire vos réponses tout en profitant de Dame nature et les envoyer plus tard.
• Permet le cryptage et / ou la signature de courrier via GPG.
• Décentralisé - Si le forum tombe en panne, vous en avez toujours une copie, elle est également inviolable, un modérateur / pirate malfaisant ne peut pas altérer facilement ce que vous avez dit. Personne ne peut défaire l'histoire.
• Permet les filtres, les dossiers et toutes les fonctionnalités organisationnelles avancées d'un client de messagerie.
• "Notifications push" - vous pouvez laisser votre client de messagerie ouvert et recevoir des notifications concernant les nouvelles réponses.
• Un seul endroit pour les gouverner tous - inutile de passer d'un site à l'autre.
• Immunité contre toutes les vulnérabilités de sécurité impliquant le Web (html / javascript / injections, etc.)
• No bloat - Pas de badges, signatures en mouvement, annonces, balises Web, javascript. C'est tout simple et au point - la discussion.
• Moins de charge serveur qu'une configuration LAMP.

Un inconvénient des listes de diffusion qui me vient à l’esprit est que les forums sont divisibles en catégories et sous-catégories alors que les listes de diffusion ne le sont pas. Cela peut être imité en divisant une liste de diffusion en plusieurs listes de diffusion, puis les utilisateurs peuvent utiliser les filtres appropriés pour placer chaque message dans son dossier correspondant (chaque dossier étant une catégorie). Dans les forums Web, c'est automatique.