Question Comment puis-je suivre un bug qui a provoqué un crash et qui a été signalé via apport / whoopsie?


Auparavant, lorsqu’un programme tombait en panne, surtout quand un utilisateur utilisait une version préliminaire d’Ubuntu, apport pouvait être utilisé pour ouvrir un rapport de bogue. L'utilisateur pourrait alors suivre le bogue, voir si cela affectait les autres, aider à le réparer, etc.

A partir de Precise 12.04, ce comportement et ce workflow ont changé. Comme je l'ai découvert dans Bogue n ° 993450 "L'application ne parvient pas à soumettre un rapport de bogue", par défaut, le score n’ouvre plus de rapport de bogue (et c’est gênant mais pas impossible de le faire). Dans le même temps, les gens notent un nouveau processus "whoopsie", comme décrit à Qu'est-ce que le processus "whoopsie" et que fait-il?.

Après un peu plus de googler, j'ai creusé ce plan, qui décrit tout le processus: ErrorTracker - Wiki Ubuntu. (Il ne mentionnait pas whoopsie ou marguerite, alors je les ai ajoutées - corrigez-moi si je me trompe).

Wow - cela semble être un excellent travail pour rationaliser et améliorer le processus de création de rapports de plantage.

Je reste avec cette question: comment un utilisateur apprend-il quel est le statut du problème? Le schéma directeur a maintenant cette exigence

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

qui semble inexploité. Y a-t-il quelque chose disponible entre-temps?

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 répartition dans les notes de publication. Cela devrait intéresser tous ceux qui ont essayé d'aider Ubuntu.


50
2018-05-21 18:54


origine


En relation: askubuntu.com/questions/159957/… - student


Réponses:


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

A partir de Precise 12.04, ce comportement et ce workflow ont changé. Comme je l'ai découvert dans le bogue n ° 993450, «Apport ne parvient pas à soumettre un rapport de bogue», par défaut, ouvrez n'ouvre plus de rapport de bogue (et il est difficile mais impossible de le faire).

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

Dans une version finale de Ubuntu, nous affichons maintenant des boîtes de dialogue d'erreur. Ceci est une grande amélioration par rapport à un programme "disparaissant" sans aucun retour d’information et l’utilisateur se demandant ce qui vient de se passer.

Les statistiques issues 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 apprend-il quel est le statut du problème? Le schéma directeur a maintenant cette exigence

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

Je vais supprimer ça. Ce n'était jamais l'intention. L'interface utilisateur prend soin de ne pas faire de promesses concernant l'obtention de commentaires sur le rapport.

Ce ne sont pas des rapports de bogues.

Notre objectif est de réduire le temps nécessaire aux développeurs pour trouver les problèmes les plus pressants, collecter les informations nécessaires pour les résoudre et obtenir les correctifs pour les utilisateurs.

Nous avons résolu le problème de trouver les problèmes les plus urgents. C'est la première page de http://errors.ubuntu.com.

La collecte rapide des informations nécessaires et sans impliquer une longue boucle de rétroaction avec les utilisateurs rencontrant le problème est traitée dans fondations-q-bucket-améliorations. Le plan consiste à permettre aux développeurs d’accéder au processus de collecte des informations côté serveur. Si j'ai besoin de / var / log / syslog mais que ce n’est pas déjà fourni, je modifie simplement un paramètre http://errors.ubuntu.com et la personne suivante qui subit l'erreur l'ajoute automatiquement aux données qu'elle envoie.

La résolution rapide des problèmes d'utilisateurs est abordée dans Fondations-q-mises à jour-de-crash-rapports. Lorsque les utilisateurs soumettent un rapport d'erreur et que cette erreur a déjà été corrigée et publiée, une boîte de dialogue s'affiche pour leur demander s'ils souhaitent mettre à niveau la version du logiciel qui résout 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 les humains. C'est là que le démon de signalement d'erreur (whoopsie) doit envoyer des rapports.

Ce serait absolument merveilleux pour d'autres personnes de s'impliquer. Je suis actuellement le seul pirate à plein temps.

Le système comporte quatre parties.

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

Il y a un ensemble de scripts légèrement obsolète sous le répertoire setup / dans lp: marguerite cela devrait vous donner une idée de la façon dont les pièces s'emboîtent. J'ai travaillé sur des charmes de juju pour le remplacer. L'objectif est une commande unique pour déployer toute l'infrastructure du cloud à des fins de test et de développement.

Vous pouvez trouver mon adresse email sur Rampe de lancement si vous avez d'autres questions de développement.

Plus d'informations:


44
2018-06-11 15:24



"Les statistiques des données collectées lorsque les gens choisissent d'envoyer ces rapports apparaissent sur errors.ubuntu.com. "; Ce n'est pas correct, seulement si votre application est écrite dans un langage de programmation pris en charge. Par exemple, aucun programme écrit en mono ne contient des erreurs. Ceci est discriminatoire à l'extrême. Ubuntu devrait fournir un terrain de jeu égal et ne pas exclure les programmes basés sur la langue dans laquelle ils sont écrits. - trampster
Je pense que tu as manqué la partie où il travaille seul, mon pote. Il n'y a pas de problème avec le support des langues populaires en premier. - Vadi
En effet, @Vadi est correct. Il n'y a rien de discriminatoire à ce sujet. Si quelqu'un veut intervenir et mettre en œuvre le support Mono, je serai heureux de revoir et de fusionner sa branche de distribution. - Evan


Pour afficher les rapports d'incident soumis, vous pouvez aller sur https://errors.ubuntu.com/


1
2018-05-31 09:49



Merci. Mais la manière dont je peux suivre l’état des problèmes que j’ai rencontrés n’est toujours pas claire et le site est un peu difficile à comprendre (Comment interpréter les données du graphique errors.ubuntu.com? - Demandez à Ubuntu) - nealmcb


Pour afficher les rapports de votre propre système, essayez ceci, comme indiqué dans 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 Launchpad, 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.


1
2018-06-02 03:58