web-dev-qa-db-fra.com

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 suivi des bogues pour tout projet de taille décente me semble un peu évident: il facilite vraiment l'organisation de centaines ou de milliers de problèmes, sans que les problèmes entrent en collision ou se mélangent.

Donc, quand je vois de très gros projets, comme Git, utiliser une liste de diffusion comme principale méthode de coordination de la maintenance et du développement, je suis un peu stupéfait. Exemples:

  • Git - Communauté page:

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

  • système de suivi des bogues Debian , selon Wikipedia:

    ... Sa caractéristique unique est qu'il ne dispose d'aucune forme d'interface Web pour modifier les rapports de bogues - toutes les modifications sont effectuées par e-mail.

De nombreux trackers de bogues modernes ont une très bonne intégration avec le courrier électronique (vous pouvez recevoir des commentaires ou des notifications sur les bogues que vous regardez ou qui vous sont attribués), ainsi que sur les systèmes de contrôle de version (les commits peuvent être marqués comme résolvant un problème, etc. .). Une grande partie de cela devrait être effectuée manuellement avec une liste de diffusion, et vous recevez des tonnes d'e-mails sur les bogues qui ne vous intéressent pas.

Quels sont donc les principaux avantages d'une liste de diffusion par rapport à un outil de suivi des bogues sur le Web? Pourquoi certains grands projets utilisent-ils uniquement une liste de diffusion?

project-managementcommunicationissue-trackingemail
66
naught101

La préférence que vous observez ressemble à une conséquence naturelle de la recommandation clairement indiquée dans GNU Coding Standards . Il suggère de signaler les bugs par e-mail, comme vous pouvez le voir dans la citation ci-dessous (j'ai marqué en gras la partie qui répond directement à vos observations):

4.7.2 --help

L'option standard --help Devrait produire une brève documentation pour savoir comment appeler le programme, sur la sortie standard, puis quitter avec succès. Les autres options et arguments doivent être ignorés une fois que cela est vu, et le programme ne doit pas exécuter sa fonction normale.

Vers la fin de la sortie de l'option ‘--help’, Veuillez placer des lignes donnant l'adresse e-mail pour les rapports de bogues , la page d'accueil du package (normalement ‘http://www.gnu.org/software/pkg’, Et la page générale pour obtenir de l'aide sur l'utilisation des 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 permis de mentionner d'autres listes de diffusion et pages Web appropriées.

Au-dessus de la préférence, à son tour, reflète l'acceptation universelle du courrier électronique comme une forme de communication électronique. Tout utilisateur lisant le message --help Comme suggéré ci-dessus est censé comprendre facilement ce qu'il doit faire s'il voit un bogue - l'envoi est facile.

Le suivi des problèmes pourrait être (et je pense que est ) meilleur pour un développeur travaillant sur le projet, mais pour un public plus large, il serait plus difficile de présenter et d'expliquer comment l'utiliser, en tenant compte notamment 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 restera avec JIRA, le troisième avec ... MOUCHERONS , etc etc, etc. Il n'y a tout simplement aucun moyen de présenter tout cela " Zoo "d'une manière qui serait aussi standard et uniforme que

Report bugs to: mailing-address

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

Votre traqueur de bogues est pour la commodité votre, pas pour vos clients. Si vous ne pouvez pas prendre la peine de prendre leur problème de téléphone ou de courrier électronique et de le saisir vous-même, comment pensez-vous qu'ils se sentent?

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

45
gnat

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

En conséquence, la communauté Linux a développé des outils et des flux de travail extrêmement efficaces pour traiter les rapports de bogues et les révisions de code par courrier électronique, et il n'y avait aucune raison pour eux de jeter tout ce travail et de recommencer à zéro lorsqu'ils ont commencé le projet Git.

30
Jörg W Mittag

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 avoir échoué, donc la raison pour laquelle Git n'utilise pas de bug tracker est probablement simplement que la plupart des contributeurs ne le trouvent pas utile.

Dans un publication sur la liste de diffusion , Junio ​​C Hamano (le responsable de Git) a résumé pourquoi il pense qu'un tracker de bug n'est pas très utile. Je ne veux pas inclure l'intégralité du message (c'est assez long), mais cela se résume à:

  • Si vous recherchez uniquement des informations sur les problèmes résolus, la recherche dans les archives de la liste fonctionne aussi bien que la recherche d'un outil de suivi des bogues.
  • Si vous signalez un véritable bug et que les gens veulent s'en occuper, la liste fonctionne également bien.
  • Si personne n'est intéressé à travailler sur un problème, il passera à travers les mailles du filet, même dans un traqueur de bogues.
  • Un traqueur de bogues serait un autre système qui doit être maintenu, vérifié régulièrement pour de nouveaux bogues, fermé les bogues corrigés, etc., bref, un travail supplémentaire pour peu d'avantages.
17
sleske

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

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

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

6
Dominik George
  • Éloigne 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'abonnement à une nouvelle liste.
  • Fonctionne hors ligne. vous pouvez vous connecter à Internet et télécharger un lot de mails, puis partir en randonnée, rédiger vos réponses tout en profitant de mère nature et les envoyer plus tard.
  • Permet le chiffrement et/ou la signature du courrier via GPG.
  • Décentralisé - Si le forum tombe en panne, vous en auriez toujours une copie, il est également infalsifiable, un modérateur/hacker maléfique ne peut pas facilement altérer ce que vous avez dit. Personne ne peut défaire l'histoire.
  • Permet des filtres, des 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 de nouvelles réponses.
  • Un seul endroit pour les gouverner tous - pas besoin de sauter entre différents sites.
  • Insensible à toutes les vulnérabilités de sécurité impliquant le web (html/javascript/injections, etc.)
  • Pas de ballonnement - Pas de badges, signatures mobiles fantaisistes, annonces, balises Web, ballonnement javascript. C'est tout simple et au point - discussion.
  • Moins de charge serveur qu'une configuration LAMP.

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

4
Hello World