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

50

Auparavant, lorsqu’un programme plantait, particulièrement 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 apport n'ouvre plus un 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 schéma qui décrit tout le processus: ErrorTracker - Wiki Ubuntu . (Il ne mentionne ni whoopsie ni 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 génération de rapports de plantage.

Je reste avec cette question: comment un utilisateur apprend-il l’état 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 de disponible entre-temps?

Comment un développeur entre-t-il dans le jeu? Aller à lien 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 quiconque essaie d'aider Ubuntu.

    
posée nealmcb 21.05.2012 - 20:54
la source

3 réponses

44

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'apporte plus de rapport de bogue (et il est difficile, mais pas impossible de le faire).

Apport 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 retour d’information 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 lien .

  

Je reste avec cette question: comment un utilisateur apprend-il l’état 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 intention est de réduire le temps nécessaire aux développeurs pour trouver les problèmes les plus urgents, collecter les informations nécessaires pour les résoudre et les corriger.

Nous avons résolu le problème de trouver les problèmes les plus pressants. C'est la page d'accueil de lien .

La collecte rapide des informations nécessaires, sans impliquer une longue boucle de feedback 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 celui-ci n'est pas déjà fourni, je modifie simplement un paramètre sur lien et la prochaine personne qui rencontre l'erreur. l'ajoute automatiquement aux données envoyées.

La résolution rapide des problèmes des utilisateurs est abordée dans Fondations-q-updates- des rapports d'erreur à partir de crash . 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 vous demander s'ils souhaitent mettre à niveau la version du logiciel qui résout le problème qu'ils viennent de rencontrer.

  

Comment un développeur entre-t-il dans le jeu? Aller à lien fournit simplement un message d'erreur "Type de contenu incorrect".

lien n'est pas destiné à être utilisé par des humains. Il est là pour que le démon de signalement d'erreur (whoopsie) envoie des rapports à.

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

Le système comporte quatre parties.

  • Apport , qui fournit l’interface utilisateur du bureau.
  • Whoopsie , qui prend en charge les rapports (et les fichiers core) créés par Apport et les charge dans le 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 principaux en rapports retracés et génère les statistiques que vous voyez sur lien .
  • Erreurs , qui est un site Web basé sur Django fournissant à la fois une vue lisible des données et une API RESTful permettant de l'utiliser. / li>

Il existe un ensemble de scripts légèrement obsolète sous le répertoire setup / dans lp: daisy qui 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 l’infrastructure complète dans le cloud à des fins de test et de développement.

Si vous avez d’autres questions de développement, vous pouvez trouver mon adresse électronique sur Launchpad .

Plus d'infos:

réponse donnée Evan 11.06.2012 - 17:24
la source
1

Pour afficher les rapports d'incident soumis, vous pouvez aller à lien

    
réponse donnée blueyed 31.05.2012 - 11:49
la source
1

Pour voir les rapports de votre propre système, essayez ceci, comme indiqué dans lien

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.

    
réponse donnée nealmcb 02.06.2018 - 05:58
la source

Lire d'autres questions sur les étiquettes