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

65

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?

— rien101
source

2

Oui, non, je suis d’accord avec vous, Git utilise des listes de diffusion :) Ce que je disais, c’est que vous le croyez avec "de très gros projets" et que je pensais juste que si vous le faites, vous devriez en donner un peu plus. exemples pour les très grands projets. Sinon, la question se résume à "Git utilise la liste de diffusion, pourquoi?" auquel cas la réponse de Jörg W Mittag est mieux adaptée ...

— Shivan Dragon

1

Hrm, eh bien, j’avais l’impression qu’il y en avait plus… Debian utilise un système de messagerie , bien qu’il soit plus complexe que la liste de diffusion. Ok, mais l’essentiel est «quels sont les avantages de l’utilisation d’une liste de diffusion par rapport à un système de suivi des bogues? À moins que la réponse soit "il n'y en a pas, les développeurs git ne sont que des luddites".

— naught101

@ naught101: pourquoi es-tu époustouflé quand tu vois ça? Debian unstable peut être installé et utilisé sans voir aucun exploit racine distant nécessitant une correction ni un redémarrage facile pendant six mois. Cela concerne la version instable de Debian. J'ai des serveurs Debian verrouillés qui ont atteint 4 jours de disponibilité (aucun exploit à la racine distante nécessitant un redémarrage affectant ma configuration pendant cette période). Ces gars-là n'utilisent peut-être pas la dernière technologie à la mode, mais ils font évidemment les choses correctement. J'abandonnerais les trackers de bogues Web pour la stabilité de Debian à tout moment.

— Cedric Martin

2

@ CedricMartin: Je sais, je suis d'accord. Le suivi des bogues de la liste de diffusion fonctionne clairement de manière satisfaisante pour certaines équipes, mais il me semble que cela reste moins facile que le suivi des bogues. Je pensais cependant que, pour les principaux développeurs de projets, la différence peut sembler minime: ils suivent presque tout ce qui se passe de toute façon. Mais pour les nouveaux arrivants, une liste de diffusion est presque impossible à dresser. Vous ne pouvez donc pas avoir une vue d'ensemble de la forme du projet. Un système de suivi des bogues permet aux nouveaux utilisateurs / développeurs de déterminer rapidement l’évolution d’un projet et de déterminer le type d’améliorations considérées comme importantes par l’équipe de base.

— naught101

Greg Kroah-Hartman a une opinion à ce sujet en ce qui concerne le noyau Linux dans le cadre de cette discussion . En particulier: "Il n’ya AUCUN moyen de faire fonctionner le modèle github / gerrit / gitorious pour le noyau. L’échelle à laquelle nous travaillons est d’un niveau totalement différent de celui qui pourrait être traité par ces outils. moyen connu de gérer 10 000 correctifs tous les 2 mois, dans une version stable, avec relecture par des pairs, avec plus de 3 000 développeurs, autre que ce que nous faisons aujourd'hui. "

— naught101

45

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 ...

— moucheron
source

3

Très bonne réponse! L'e-mail est mieux connu que les problèmes, et plus facile à comprendre (ce qui ne veut pas dire que tout le monde "reçoit" l'email: P)

— Andres F.

21

En outre, ce conseil GNU est ancien, bien plus ancien que le Web et les outils de suivi des problèmes basés sur le Web.

— Ross Patterson

@ RossPatterson Je pensais que. Mais il semble peu probable qu'il soit plus ancien que le Web, vu qu'il contient de nombreuses URL ...

— naught101

6

@gnat: Une partie importante de la réponse liée qui est si géniale est la partie "si c'est facile pour vous, vous pouvez entrer ce genre de chose ici" . C’est la clé de nombreux projets open source car aucun soutien téléphonique n’est disponible. Une liste de diffusion est un inconvénient pour moi en tant qu'utilisateur signalant un bogue, car je ne veux pas être obligé de m'inscrire pour recevoir des réponses. Avec un système de suivi des bogues, je peux voir que le problème que j'ai est dans le système, puis revenir le chercher plus tard et voir s'il a été mis à jour. Cela est difficile avec une liste de diffusion, sauf s’il existe un très bon outil de suivi des listes sur le Web, ce qui n’est souvent pas le cas.

— naught101

1

@ naught101 Il n'est peut-être pas plus vieux que le Web, mais il est certainement plus vieux que les trackers basés sur le Web

— sakisk

30

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.

— Jörg W Mittag
source

3

Je pensais que le WWW avait précédé Linux. Légèrement. Ils étaient tous deux très travaillés à peu près au même moment et par différents groupes de personnes; ce n’est vraiment qu’au milieu des années 90 que l’on décolle.

— Donal Fellows

6

Ok, mais le noyau Linux a maintenant un gestionnaire de bugs: bugzilla.kernel.org . Clairement, ce n’est pas un obstacle aussi important.

— naught101

7

-1 Git est sérieusement plus jeune que le web. Vintage 2005. Il y avait beaucoup de trackers d'émission à l'époque, y compris bien sûr Bugzilla. Linus n'aime tout simplement pas les trackers d'émission, et sa parole est loi dans cet environnement.

— Ross Patterson

6

@ RossPatterson - Il a dit que Linux était plus vieux que le Web, pas Git. Je ne pense pas que votre commentaire justifie un vote négatif, puisque vous avez essentiellement répété ce qu'il a dit.

— beatgammit

2

@tjameson Après coup, vous avez raison. Retour à neutre.

— Ross Patterson

17

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.

— sleske
source

5

Bonne réponse, mais je dirais que votre troisième point est un inconvénient majeur de l'e-mail: si un bogue est difficile à corriger et que les développeurs actuels sont paresseux, il est beaucoup plus enterré qu'une entrée dans un suivi des problèmes. Cela pourrait signifier que certains bugs ne sont jamais corrigés, tout simplement parce que les gens ne les connaissent pas

— TheLQ Le

1

@TheLQ: Vrai. Cependant, apparemment, certains projets sont prêts à prendre. Et pour être juste, git est un logiciel assez solide, même sans traqueur de bogues.

— Sleske

1

@TheLQ: Une simple page Web mentionnant tous les bogues connus (et leurs threads associés) ne résoudrait-elle pas ce problème? Quelque chose de semblable à ceci, sauf que les liens pointent vers les threads d'archivage.

— Bonjour tout le monde

1

@ HelloWorld: Eh bien, ce serait un traqueur de problème (simple). Et tout comme un traqueur de problème, il faudrait que quelqu'un le gère ...

— sleske

Y at-il un bon moyen d’obtenir une copie hors ligne du courrier électronique qui a été envoyé alors que je n’étais pas abonné?

— PSkocik

6

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!

— Dominik George
source

4

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.

— Bonjour le monde
source

pourquoi les gens insistent-ils pour créer des versions Web pour suivre les problèmes (BTW cette question ne concerne pas tout ) est abordé dans une autre question: Amener les utilisateurs à rédiger des rapports de bogue utiles et dignes "Les rapports de bogue en ligne modifiables par l'utilisateur sont le moyen le plus efficace d'enseigner les utilisateurs améliorent ... "

— gnat

Je vous remercie. Mais cela justifie-t-il un vote négatif? Le sujet principal de cette réponse concerne les avantages d’un ML et répond assez bien à la question initiale. J'ai supprimé le discours sur les "forums Web".

— Bonjour le monde

2

L'inconvénient mentionné dans cette réponse m'empêche fondamentalement de rester avec la plupart des listes de diffusion dev. Ils envoient tout , donc après avoir signalé un bug, je me désabonne généralement deux semaines plus tard. Les bugtrackers résolvent joliment ce problème en me permettant de m'abonner à des rapports de bugs spécifiques.

— Roman Starkov

6

Correction: éloigne les enfants de 25 ans. Ce n'est que récemment que j'ai appris comment ces listes de diffusion pouvaient contribuer à de vrais projets. Et je déteste ça !!

— Ciro Santilli a annoncé le

2

"Pas besoin de créer un compte séparé pour chaque forum." - souvent pour éviter le spam, vous devez vous inscrire à la liste. Mais cela s'abonne à tous les emails. Vous devez donc vous abonner ET désactiver le "spam" ET ajouter une demande pour vous garder en mode CC ou TO. Comparé à un bugzilla, c'est beaucoup plus à faire.

— Maciej Piechotka