Comment puis-je suivre un bogue qui a provoqué un crash et qui a été rapporté via apport / whoopsie?

52

Auparavant, lorsqu'un programme bloquait, en particulier lorsqu'un utilisateur utilisait une pré-version d'Ubuntu, il pouvait être utilisé pour ouvrir un rapport de bogue. L'utilisateur peut ensuite suivre le bogue, voir s'il en affecte d'autres, aider à le résoudre, etc.

Depuis Precise 12.04, ce comportement et ce flux de travail ont changé. Comme je l'ai découvert dans le bogue n ° 993450, «Apport ne parvient pas à envoyer un rapport de bogue» , par défaut, un rapport de bogue n'apparaît plus (et il est gênant, mais pas impossible, de le faire). En même temps, les gens remarquent un nouveau processus "whoopsie", comme décrit dans Qu'est-ce que le processus "Whoopsie" et que fait-il? .

Après un peu plus de recherches sur Google, j’ai creusé ce schéma, qui décrit tout le processus: ErrorTracker - Ubuntu Wiki . (Il n’a pas été question de whoopsie ou de marguerite, je les ai donc ajoutées - corrigez-moi si je me suis trompé).

Wow - cela semble être un excellent travail pour rationaliser et améliorer le processus de signalement des incidents.

Je reste avec cette question: comment un utilisateur peut-il connaître l'état du problème? Le plan a maintenant cette exigence

L'utilisateur devrait avoir un moyen de vérifier l'état de son rapport d'incident; Par exemple, ils peuvent consulter un ID de rapport pour consulter des statistiques et / ou tout bogue associé. Par exemple, fournissez un numéro de série au moment du dépôt qu’ils pourront charger ultérieurement via une page Web.

ce qui semble non implémenté. Y a-t-il quelque chose de disponible dans l'intervalle?

Et comment un développeur entre-t-il dans le jeu? Aller à https://daisy.ubuntu.com fournit simplement un message d'erreur "Type de contenu incorrect".

Enfin, je suggère de documenter les modifications du comportement de la répartition dans les notes de publication. Cela devrait intéresser quiconque a essayé d'aider Ubuntu.

nealmcb
la source
1
Connexes: askubuntu.com/questions/159957/…
étudiant

Réponses:

45

Merci de votre intérêt pour le projet de suivi des erreurs Ubuntu .

Depuis Precise 12.04, ce comportement et ce flux de travail ont changé. Comme je l'ai découvert dans le bogue n ° 993450, «Apport ne parvient pas à envoyer un rapport de bogue», par défaut, un rapport de bogue n'apparaît plus (et il est gênant, mais pas impossible, de le faire).

Apport n'a jamais créé de rapports de bogues après la publication. Lorsqu'une version est encore en cours de développement, vous pouvez utiliser la méthode apport pour classer les bogues (et les rapports d'erreur) du Launchpad.

Dans une version finale d'Ubuntu, nous affichons maintenant les boîtes de dialogue d'erreur. Il s’agit là d’une grande amélioration par rapport à un programme qui «disparaît» sans aucun retour et l’utilisateur se demandant ce qui vient de se passer.

Les statistiques des données collectées lorsque les utilisateurs choisissent d’envoyer ces rapports apparaissent sur http://errors.ubuntu.com .

Je reste avec cette question: comment un utilisateur peut-il connaître l'état du problème? Le plan a maintenant cette exigence

L'utilisateur devrait avoir un moyen de vérifier l'état de son rapport d'incident; Par exemple, ils peuvent consulter un ID de rapport pour consulter des statistiques et / ou tout bogue associé. Par exemple, fournissez un numéro de série au moment du dépôt qu’ils pourront charger ultérieurement via une page Web.

Je vais enlever ça. Cela n'a jamais été l'intention. L'interface utilisateur veille à ne pas faire de promesses quant à l'obtention de commentaires sur le rapport.

Ce ne sont pas des rapports de bugs.

Notre objectif est de réduire le temps nécessaire aux développeurs pour rechercher les problèmes les plus urgents, collecter les informations nécessaires à leur résolution et permettre aux utilisateurs de les résoudre.

Nous avons résolu le problème de la recherche des problèmes les plus urgents. C'est la page d'accueil de http://errors.ubuntu.com .

La collecte des informations nécessaires rapidement, sans impliquer une longue boucle de rétroaction avec les utilisateurs confrontés au problème, est abordée dans les améliorations de foundation-q-bucketing . L'objectif est de permettre aux développeurs de se connecter au serveur côté processus de collecte d'informations. Si j'ai besoin de / var / log / syslog mais que ce n'est pas déjà fourni, je modifie simplement un paramètre sur http://errors.ubuntu.com et la personne suivante qui rencontre l'erreur ajoute automatiquement cette erreur aux données envoyées.

Les correctifs rapides pour les utilisateurs sont abordés dans les rapports sur les fondations-q-updates-à partir de crash . Lorsque les utilisateurs envoient un rapport d'erreur et que cette erreur a déjà été corrigée et publiée, une boîte de dialogue s'ouvre leur demandant s'ils souhaitent effectuer une mise à niveau vers la version du logiciel qui corrige le problème qu'ils viennent de rencontrer.

Et comment un développeur entre-t-il dans le jeu? Aller à https://daisy.ubuntu.com fournit simplement un message d'erreur "Type de contenu incorrect".

http://daisy.ubuntu.com n'est pas destiné à être utilisé par des humains. C'est là que le démon de rapport d'erreur (whoopsie) doit envoyer des rapports.

Il serait absolument merveilleux que d’autres personnes s’impliquent. Je suis actuellement le seul à pirater ce poste à temps plein.

Le système comporte quatre parties.

  • Apport , qui fournit l'interface utilisateur du bureau.
  • Whoopsie , qui prend les rapports (et les core dumps) créés par Apport et les transfère au serveur de suivi des erreurs, Daisy.
  • Daisy , qui collecte les rapports de Whoopsie et les traite. C'est le coeur du service. C'est ce qui transforme les fichiers de base en rapports retracés et génère les statistiques que vous voyez sur http://errors.ubuntu.com .
  • Errors , un site Web basé sur Django offrant à la fois une vue des données lisible par l'homme et une API RESTful permettant de les utiliser.

Il y a un ensemble de scripts légèrement obsolète dans le répertoire setup / de lp: daisy qui devrait vous donner une idée de la manière dont les morceaux s’assemblent. J'ai travaillé sur des charmes de juju pour remplacer ceci. L'objectif est de disposer d'une commande unique pour déployer toute l'infrastructure dans le nuage à des fins de test et de développement.

Vous pouvez trouver mon adresse email sur Launchpad si vous avez d'autres questions sur le développement.

Plus d'informations:

Evan
la source
"Les statistiques des données collectées lorsque les utilisateurs choisissent d'envoyer ces rapports s'affichent sur errors.ubuntu.com ." Ce n'est pas correct, uniquement si votre application est écrite dans un langage de programmation pris en charge. Par exemple, aucun programme écrit en mono ne contient d'erreurs. C'est discriminatoire à l'extrême. Ubuntu devrait offrir un terrain de jeu égal et ne pas exclure de programmes basés sur la langue dans laquelle ils sont écrits.
trampster
2
Je pense que vous avez raté la partie où il travaille seul, mec. Il n'y a pas de problème avec le support des langues populaires en premier.
Vadim Peretokin
5
En effet, @Vadi est correct. Il n'y a rien de discriminatoire à ce sujet. Si quelqu'un veut renforcer et implémenter le support Mono, je passerai avec plaisir en revue et fusionnera sa branche de répartition.
Evan
4

Pour afficher les rapports de votre propre système, essayez ceci, comme indiqué à l' adresse https://bugs.launchpad.net/ubuntu/+source/apport/+bug/994921/comments/43.

xdg-open https://errors.ubuntu.com/user/`sudo cat /var/lib/whoopsie/whoopsie-id`

Sans autorisations spéciales sur le tableau de bord, vous ne pouvez pas afficher les rapports réels, mais vous pouvez voir les programmes sur lesquels ils ont été signalés et utiliser les identifiants fournis pour les consulter lorsque vous parlez aux développeurs disposant des autorisations appropriées.

nealmcb
la source